14.07.2005

Хроника инцидента

Уязвимости форума phpBB давно уже стали “притчей во языцех”, хотя на мой взгляд, это далеко не самая богатая на ошибки программа. Да и факт широкого использования этой платформы для создания форумов говорит о ее привлекательности как для администраторов сайтов, так и для злоумышленников.

Уязвимости форума phpBB давно уже стали “притчей во языцех”, хотя на мой взгляд, это далеко не самая богатая на ошибки программа. Да и факт широкого использования этой платформы для создания форумов говорит о ее привлекательности как для администраторов сайтов, так и для злоумышленников.

Мои сложности в отношениях с phpBB усугубляются еще тем странным фактом, что новые уязвимости обычно появляются в те моменты, когда я в отъезде и не имею полноценного доступа к своему форуму. До недавнего времени бог миловал и ни одной из уязвимостей злоумышленникам воспользоваться не удавалось. И вот во время моего очередного вояжа была обнаружена новая ошибка (см. http://www.securitylab.ru/55520.html), позволяющая удаленному пользователю выполнять на форуме произвольные команды. Т. е., пользователь получал через строку ввода браузера возможность задавать команды операционной системы и просматривать вывод из этих команд в окне браузера. Вывод этот достаточно коряв и неудобочитаем, но вполне подходит для сбора информации о системе и ее последующей обработки с целью получения более высокого уровня доступа к форуму и, возможно, компьютеру, на котором форум работает. А там, чем черт не шутит, может удастся прорваться и к другим ресурсам сети.

Итак, перейдем к описанию событий. При просмотре файла с сообщениями Apache об ошибках были обнаружены странные записи, фрагмент которых приведен ниже, а полный протокол вы может найти в файле.

sh: cannot determine current directory

...

sh: cannot determine current directory

sh: sysctl: not found

...

sh: sysctl: not found

Reading specs from /opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/specs

gcc version 2.95.3 20010315 (release)

...

Наличие подобных записей не могло не привлечь внимания и далее началось планомерное исследование и восстановление событий, которое и описано ниже. По временным меткам из журнала ошибок не составило большого труда найти форум, по отношению к которому были совершены описываемые действия и выделить из журналов доступа записи соответствующих сессий. В результате были обнаружены две сессии, которые следовали одна за другой практически без паузы и судя по многим признакам были организованы одним человеком. Сначала злоумышленник воспользовался простыми операциями для проверки своих возможностей, заходя на форум из сети PPPoE MTU. По-видимому в этом случае не использовалось никаких методов сокрытия, тем более, что в этой сети адреса с большой вероятностью выделяются динамически. Кстати, после завершения анализа администраторам MTU было направлено письмо с записями, подтверждающими факт инцидента, но они сочли возможным игнорировать это обращение. Приведу пару строк начального этапа, когда супостат только пытался прощупать почву. Желающие могут увидеть полный протокол в файле.

ppp11-172.pppoe.mtu-net.ru - - [29/Jun/2005:18:55:13 +0400] "GET /Forum/viewtopic.php?p=15&highlight='.die(123).' HTTP/1.1" 200 12442 "-" "firefox (compatible; firefox; FreeBSD 4.5; SV1; .NET CLR 1.1.4322)"
ppp11-172.pppoe.mtu-net.ru - - [29/Jun/2005:18:56:25 +0400] "GET /Forum/viewtopic.php?p=15&cmd=%65%63%68%6F%20%5F%53%54%41%52%54%5F% 20%3B%20%6C%73%20%3B%20%65%63%68%6F%20%5F%45%4E%44%5F &highlight=%27%2E%70%61%73%73%74%68%72%75%28%24%5F%47%45%54%5B%63%6D%64%5D%29%2E%27 HTTP/1.1" 200 33302 "-" "-"

Использованное URL-кодирование не совсем удобно для чтения, поэтому файлы протокола были преобразованы так, чтобы действия атакующего были более наглядны. Желающие могут посмотреть полную расшифровку записей для обеих сессий (сессия 1 – MTU, сессия 2 – Amenworld). В этих файлах легко увидеть полный протокол использованных злоумышленником команд, а мы лишь кратко рассмотрим те, которые оказались потенциально наиболее опасными для форума и посмотрим, что удалось увидеть супостату. Полный набор использованных в той и другой сессиях команд приведен в таблице с сохранением хронологического порядка.

Видно, что в первой сессии злоумышленник даже не пытался выполнить каких-либо активных операций против форума, но собирал (и небезуспешно) информацию о файловой структуре форума и хосте, на котором форум работает. Были предприняты также некоторые попытки исследования всей файловой структуры хоста. Отметим, что даже эта деятельность оставила следы в журнале ошибок Apache, которые и послужили толчком с исследованию ситуации.

Посмотрим сейчас более подробно на команды, которые выполнялись во второй сессии, поскольку там супостату удалось получить некоторую информацию о хосте и были предприняты попытки копирования на форум того или иного файла (по-видимому shell-сценария для получения более удобного доступа). Итак, после проведения рекогносцировки злоумышленник посмотрел список активных пользователей системы (команда w). Далее последовала неудачная попытка запуска компилятора C и столь же неудачная попытка его поиска. Далее супостат попытался прочитать конфигурационный файл форума (cat config.php). Эта попытка должна была увенчаться успехом и видимо было много радости, когда на экране появилось содержимое файла config.php с именем пользователя и паролем для доступа к базе данных форума. Однако радость эта была преждевременной, поскольку воспользоваться полученной информацией не удалось по нескольким причинам. Во-первых, пароль, написанный открытым текстом в файле config.php, не является паролем для доступа к базе данных, а всего лишь содержит фразу, по которой с помощью неизвестной злоумышленнику функции создается пароль с помощью которого и происходит подключение к базе данных. Догадаться об использованном алгоритме преобразования непросто, поскольку количество степеней свободы при выборе преобразования открытой парольной фразы в реальный пароль практически не ограничено, а искать в исходных текстах форума, которые к тому же достаточно сильно отличаются от оригинальных текстов phpBB, можно весьма долго. Вторая причина неудачи заключается в том, что доступ к базе данных открыт только с данного хоста, поэтому для работы с базой (изменения или хотя бы прочтения из нее данных) нужно иметь на форуме shell. Впоследствии попытки залить на форум тот или иной файл предпринимались, но закончились неудачей, поскольку не было найдено ни одной известной программы, позволяющей загрузить файл с удаленного хоста (wget. Fetch и т. д.). Можно было попытаться сохранить shell-скрипт в каталоге /tmp с помощью команды cat, но эта работа слишком кропотлива при таком способе ввода команд и наверное это послужило причиной того, что подобной попытки даже не было предпринято1. Отмечу, что в описываемом случае это тоже не помогло бы ничуть, поскольку запуск программ или сценариев из каталога /tmp наглухо закрыт.

Сессия 1 (MTU)

Сессия 2 (Amenworld)

ls

ls -la

cd i

cd i; ls

cd c; ls

uname -a; hostname; id; ls -la

sysctl -A

which sysctl

echo $OSTYPE

uname -a

pwd

ls; pwd

ls

cd ..; ls -la

ls -la

cd db; ls -la

cd ../; ls -la

cd ../; ls

cd /; ls -la

cd /www/; ls -la

cd /www/htdocs/; ls -la

cd /www/htdocs/proxy/; ls -la

ls -la ..

ls -la .

ls -la .\.

ls -la ..

id

pwd

ls

uname

uname -a

w

gcc -v

/usr/bin/gcc -v

whereis gcc

ls -al

cat config.php

ls -al

cat /etc/passwd

pwd

ls -al ../

ls -al ../../

ls -al /

ls -al /tmp

ls -al /www

ls -al /www/htdocs

ls -al /www/htdocs/proxy

lynx -v

wget

fetch

links

ls -la /home

ypcat

cat

cat config.php | tail -l 25

cat config.php

ping -c1 www.mail.com

cat /etc/passwd

ls -la /export/spare/home/XXXXXXX

ls -la /export/spare/home/XXXXXXX/public_html

ls -la /export/spare/home/XXXXXXX/site

ls /etc

ls -al /etc

cat /etc/httpd.conf

ls -la

ls -la images/avatars/

ls -la

ls -la c

Далее была предпринята попытка проверить доступность сайта www.mail.com. Цели такой проверки могли быть самыми разными (например, попытаться отправить заинтересовавшие фалы на какой-либо адрес по электронной почте), однако и тут супостата постигла неудача, поскольку пакеты ICMP из блока адресов, к которому принадлежит форум, наглухо заблокированы.

Далее была предпринята (полагаю, успешная) попытка чтения файла /etc/passwd. Что ж, от этого сложно защититься, но информация из файла /etc/passwd ОС Solaris никакой ценности не представляет, поэтому причин для расстройства нет. Попытки покопаться в моем домашнем каталоге (супостат оказался из числа знающих меня людей) также не привели к каким-либо успехам и в заключение были выполнены команды чтения конфигурационного файла Apache и каталогов с пиктограммами форума. Конфигурационный файл Web-сервера наверное прочитать удалось, но польза от фала, содержащего лишь общие настройки для злоумышленника весьма сомнительна. Так что пользуйтесь им на здоровье, может быть чему-то научитесь, но этот файл можно было получить и более простым путем (например, из дистрибутива Apache для Solaris).

Итак, подведем итоги и сделаем выводы на будущее.

  1. Форум достаточно уязвим и требует постоянного присмотра.

  2. Злоумышленнику удалось получить некоторую информацию о файловой структуре хоста и форума, а также содержимое нескольких конфигурационных файлов.

  3. Реальной угрозы для форума и хоста в целом полученная супостатом информация не представляет, поскольку не дает ему каких-либо дополнительных возможностей на форуме или доступа к хосту.

  4. Попытки “залить” на форум какой-либо файл оказались неудачными по причине отсутствия на хосте используемых для таких операций программ. Отмечу, что даже при удачной “заливке” файла на форум воспользоваться им злоумышленнику все равно бы не удалось, поскольку запуск программ из открытых для записи каталогов жестко блокируется.

  5. Сведения из конфигурационного фала форума никакой ценности не представляют, поскольку значение переменной $dbpasswd из этого фала не является паролем, дающим доступ к базе данных форума или иным базам на этом хосте.

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

1Может просто не хватило ума, но a-priori злоумышленника, проникшего в вашу систему, не следует считать недоумком, поскольку такая недооценка “чревата боком”.

Николай Малых

или введите имя

CAPTCHA