Страница 32 из 70
http://www.host.com/cgi-bin/wtb/data?fid=root;;root;;a;;&oper=admininterface&login=root&pass=root&data=/tmp
http://www.host.com/cgi-bin/wtb/data?fid=root;;root;;a;;&oper=admininterface&login=bdadmfid=root&pass=root&wtbadmin=../../../../../../../../../../../../tmp/wtwrong.txt.
Налицо обычная подмена, в результате которой будет создан журнал /tmp/wtwrong.txt. Обращение к нему повлечет за собой считывание информации из лога и доступу к админке.
Удостоверившись, что баг работает, хакер полез на google.com и отправил запрос wtboard. В ответ на поисковой реквест взломщик получил множество ссылок. Одна из них вела на страницу провайдера из Москвы. Это очень заинтересовало нашего героя, и вот он проник на страницу администрирования. Обратившись к разделу темплейт-кода, злоумышленник вбил SSI-запрос, выполняющий системную команду.
.
Но взломщика не интересовал файл с аккаунтами. Он закачал wget’ом простой perl-бэкдор и запустил. В результате на порту 37900 открылся шелл, стартующий /bin/sh в интерактивном режиме. Так сетевой партизан получил WWW-права. К сожалению, добиться рутовых привилегий оказалось непросто – ядро было пропатчено фиксом от grsecurity, а система практически не содержала уязвимых сервисов (оно и понятно: дистрибутив носил гордое имя SlackWare :)).
За абсолютные права хакер готов был пойти на любые извращения. Он решил попробовать один из методов локальной атаки, который заключается в поиске важных данных в системных логах. Сперва взломщик пропарсил /var/log/messages, однако ничего интересного он не обнаружил. Не думай, что наш герой надеялся увидеть там пароли в чистом виде. Он пролистал messages, чтобы найти информацию о каких-нибудь интересных демонах. Последние любят писать аккаунты в свои журналы. К сожалению, поиск не увенчался успехом, поэтому взломщик перешел в каталог /usr/www/logs и открыл редактором документ access_log. Дело в том, что на провайдерском сервере крутился биллинг, позволяющий просмотреть состояние счета. Все бы ничего, да вот только соединение инициировалось по небезопасному протоколу, а в качестве метода передачи использовался GET. Все условия для отлова паролей. Кстати, обычные пользователи в биллинг не пускались – скрипт анализировал IP-адрес, а лишь затем принимал решение о допуске, но даже это не мешало паролям храниться в текстовом журнале. Так хакер обнаружил пароль от логина alpha. Этот юзер являлся системным и имел рабочий шелл. Хакер предпочитал шпионить в консоли под полноценным аккаунтом, а не под web-правами, поэтому быстро залогинился под alpha. Теперь он мог полноценно передвигаться по домашней директории юзера. В каталоге не было интересных файлов, кроме лога .bash_history. Взломщик всегда проверял его содержимое, надеясь набрести на интересные команды. Он поспешно открыл журнал редактором оболочки mc и стал исследовать лог. В журнале действительно было много интересной информации. Хакер быстро понял, что alpha следит за WWW-ресурсами, так как вся его работа проводилась в каталоге /usr/www. Помимо этого, работник знал пароль от суперпользователя, посему активно юзал команду su. А зря. Иногда alpha ошибался в команде, а затем «сорил» паролем в консоль. Теперь взломщику ничего не мешало поиметь законные рутовые права. Ведь он подсмотрел пароль, а также имел нулевой gid. Последний позволял переключить права с помощью /bin/su.
Одним зарутанным провайдером стало больше :). Все из-за того, что админ вовремя не настроил фаервол. Фаервол отпугивает хакера: если бы alpha следил еще и за ним, то взломщик вряд ли смог порутать WWW-сервер. Хотя кто знает, ведь существует много способов обхода даже самых навороченных фаерволов…
Бывает, что хакер находит баг, который не позволяет поднять привилегии без использования какого-нибудь заковыристого метода. Так случилось при взломе сервера одного иноземного университета http://trinity.edu. Хакер даже не знал, в какой точке планеты этот университет, он ломал сервер по заказу. Надо сказать, взлом не обошелся без использования самого хардкорного метода. Сперва хакер начал сканировать Web. Так вышло, что на роутере стоял фаервол, фильтрующий все порты, кроме 21, 22 и 80. Баннер FTPD показал, что на сервере крутится SunOS 5.9, которая по тем временам была самой надежной из Солярок. Соответственно, первый метод (использование эксплоита) отпадал сразу. Итак, хакер начал с WWW. Бегло просмотрев скрипты, состряпанные студентами, взломщик наткнулся на занятный сценарий с названием view.cgi, которому передавался всего один параметр – название файла. По-видимому, скрипт создавался, чтобы показывать сишные проекты (когда взломщик ткнул по ссылке, перед ним появился исходник файла project). Особо не надеясь на успех, наш герой изменил значение параметра на /etc/passwd, но это привело к фатальной ошибке. Интерпретатор ругался на то, что не может найти файл /www/students/cgi/projects/etc/passwd.cpp. Потирая руки, сетевой партизан еще раз поменял значение опции на «../../../../../etc/passwd%00», и сервер без проблем показал файл с аккаунтами. Почему так произошло? Все просто: из-за нулевого байта расширение «.cpp» не было приплюсовано к открываемому документу – функции open() передавался файл /etc/passwd%00.cpp, что фактически открывало системный passwd.
Взломщик увидел, что в системе прописаны порядка сотни учетных записей. В таком случае целесообразно применить перебор на пару «login:login», ведь особо одаренные студенты любят устанавливать пароль, равный логину (либо не задавать его вообще). Хакер скормил имена студентов специальному скрипту и передал список пар переборщику Brutus. В качестве сервиса был выбран FTP, ибо другие порты фильтровались сетевым экраном. Спустя пару минут, Brutus сообщил, что несколько студентов действительно выбрали пароль, равный логину. Не медля наш герой прицепился к шеллу по SSH и был готов к повышению своих прав.
Поиск информации в логах ни к чему путному не привел. Доступ к историям команд админов был закрыт от посторонних глаз, логи студентов-ламеров не содержали ничего интересного. Наконец, взломщик вспомнил, что пароль может содержаться в .htpasswd. Команда locate .htpasswd показала три подобных конфига. Два из них имели атрибут 400, а последний не содержал полезных хэшей (в документе хранилась строка guest:пароль, но юзер guest вообще не присутствовал в /etc/passwd). Второй поисковый запрос был направлен на нахождение конфигов .htaccess. Их было больше, и почти все хакер мог посмотреть. В одном из таких файлов наш герой нашел ссылку на базу с паролями, который назывался .secure. В нем он обнаружил все юзерские хэши. Этакий дубликат /etc/shadow. Оставалось взять из него рутовый пароль и расшифровать его прогой John The Ripper. Джоник запускался на мощной 4-процессорной тачке, которую хакер купил за $100 якобы для математических вычислений :). Брутфорсер запускался в трех режимах – single, wordlist и all. Стартовый скрипт, который обращался к John, содержал всего три строки.
start.sh – запуск John The Ripper в разных режимах
./john -single passwd > > crk_passwd
./john -w:big_wordlist.txt -rules passwd > > crk_passwd
./john -i:all passwd > > crk_passwd
Загрузив все четыре камня, взломщик отошел от компа, надеясь, что к его возвращению пароль успешно раскриптуется. Спустя час пароль действительно был расшифрован. Взломщику повезло: в качестве пароля выступало слово «Street00». Кстати, подобное словечко было получено благодаря опции -rules, которая извращает словарные слова, подставляя к ним всякие нулики и меняя регистр букв. Вот, собственно и все. Теперь злоумышленник вошел на сервер под рутом, благо sshd разрешал подобные операции. Проверив, что пароль действительно совпадает с системным, наш герой обменял системный аккаунт на пару сотен WMZ.