TGBR E-ZineS #1:

Автор: NeoN

Обзор WOW Loader

Седня будем мусолить косточки очередному супер нужному и полезному лоадеру всех времен и народов, и имя ему Wow Loader. Стоит сие создание 200 у.ё. и написан он человеком с ником EvilPhreak. По заявлениям автора там используется мощный 0дей способ чтобы обойти все фаерволы нафиг. Между тем сами покупатели весьма иного мнения, лоадер не слишком корректно работает, малый отстук и вообще странная штука. И кто же все-таки прав?

1. Общее впечатление

Криптовка присутствует, судить какого качества она не будем, так как всегда можно перекриптовать. После распаковки видим что на борту лоадера поместилась еще и длл, зачем она нужна выясним позднее. При исполнении лоадер создает 4 файла, один из них ernel32.dll и несколько файлов с рандомным названием Не шибком то и беспалевно. Но всебы ничего.. если, например, фаерволл блокирует попытки синжектится в процесс, или попросту нет инета - лоадер уходит в замечательный вечный цикл, из которого выбратся ему не посилу, ибо не предусмотрено было сие создателем. Цикл тот содержит в себе sleep и createfile который пытается открыть на чтение тот самый фаил со случайным именем. И если тот не создается - лоадер будет долго зиять в списке процессов. Плюс ко всему - большинство антивирусов, да и некоторые фаерволлы весьма критично относятся к файлам в system32 и просто так записать туда удастся не всегда.
Сам код потрясает, вродебы лоадер должен стремится сократить размер, так нет, в коде насчитывается аж 3 цикла Process32First\Next, 1 повторное копирование одного и тогоже хендла процесса, большое количество CreateFile, для которых не сделано никакой обертки, чтобы сократить размер. Полоска нупов также присутствует - еще работает чтоли?

2. Обход фаерволлов

Собственно то из за чего и писался обзорчик - "0дей" обход фаерволлов. На самом деле в лоадере предусмотрено аж два обхода, один из них при наличии установленного ZoneAlarm, а второй при его неналичии. Для определения наличия зоналярма используется небольшая функция, состоящая из цикла Process32First\Next и сравнения получаемых имен процессов с "zlclient.exe", собственно именем процесса зоналярма.

2.1. ZoneAlarm case

В случае наличия противного ZoneAlarm на компе, лоадер делает следующее:
- создает секции и выделяет память
- ищет хендл процесса explorer.exe, OpenProcess его
- делает DuplicateHandle для полученного хендла
- заполняет структурки и вызывает NtConnectPort
- GetThreadContext\SetThreadContext\ResumeThread
Последний пункт отчетливо бросается в глаза, ибо это самый заезженный способ создания потока исполнения в другом процессе. Отличия от паблик версии присутствие DuplicateHandle, и то уже тоже не тру. А вот первые строчки могут показатся неискушенным людям несусветным приватом. Но погодите радоваться, зайдите в гугл и поищте немножко - и вуаля - статья на всеми любимом секюритилаб.ру на русском языке, с пояснениями и огромной кучей исходников. По такому прекрасному описанию и горе сорцов не написать обход просто возмутительно. Итого имеем что первый способ попахивает пабликом, притом 2006 года выпуска. С горечью разочарования посмотрим второй способ.

2.2. Не ZoneAlarm case

Думаете тут намного лучше все? Хех, зря... В случае когда на компе зоналярма нет - лоадер создает файлик с именем "ernel32.dll". Почему такое название сейчас выясним. Так вот после этого лоадер берет привелегии с помощью функции RtlAdjustPrivilege:

.code:0040217E lea ecx, [ebp+var_4]
.code:00402181 push ecx
.code:00402182 push 0
.code:00402184 push 1
.code:00402186 push 14h
.code:00402188 call RtlAdjustPrivilege

Затем начинается цикл Process32First\Next с поиском svchost.exe, после нахождения оного лоадер открывает фаил svchost.exe, и ищет там строку "ernel32.dll", естественно она там присутствует, так как svchost.exe импортирует функции kernel32.dll. Именно поэтому такое странное название файла и было выбрано. Найдя оффсет этого имени лоадер запускает цикл Thread32First\Next и для каждого потока выполняет следующий код:

.code:00401F11 push [ebp+dwThreadId] ; dwThreadId
.code:00401F14 push 0 ; bInheritHandle
.code:00401F16 push 10h ; dwDesiredAccess
.code:00401F18 call OpenThread ; Открытие потока svchost.exe
.code:00401F1E mov [ebp+hThread], eax
.code:00401F21 test eax, eax
.code:00401F23 jz short open_err ; ошибка открытия?

.code:00401F25 push 0
.code:00401F27 push 0
.code:00401F29 push [ebp+str_ernel32]; Смещение строки "ernel32.dll" в процессе svchost
.code:00401F2C push LoadLibraryExA ; Оффсет на лоадлибрари
.code:00401F32 push [ebp+hThread]
.code:00401F35 call NtQueueApcThread ; Добавление коллбека в очередь

.code:00401F3B push [ebp+hThread] ; hObject
.code:00401F3E call CloseHandle
.code:00401F44 open_err:

Как видно из кода, лоадер открывает поток, и выполняет для него фукнцию NtQueueApcThread, которая добавляет заданный адрес в очередь. В данном случае будет выполнена фукнция LoadLibraryExA с параметром "ernel32.dll". Что как вы уже понимаете, загрузит распакованную из лоадера длл и выполнит нужный код. На этом обход фактически закончился. Приватный ли он? Ответ нет. Поиск в гугле по фразе "NtQueueApcThread" опять дает положительные результаты. Тоже читаем и втыкаем, там весьма четко прописано, что делает эта функция и какое её "неправильное" предназначение.

3. Инжектнутый код

Инжекнутый код исполняется либо в процессе в коорый удался инжект, либо прямо в процессе лоадера. Код восстанавливает нужный ему импорт, затем начинается действо: лоадер перехватывает функцию ZwCreateSection, для этого предварительно делает VirtualProtect для адресов ZwCreateSection и ZwQuerySection, а после этого пишет конструкцию push \\ ret.
Перехватчик ZwCreateSection запоминает полученный хендл после вызова настоящей функции и устанавливает хук на ZwQuerySection.
Перехватчик ZwQuerySection в свою очередь снимает хук с функции, и сверяет хендлы - запомненный и тот что передали в ZwQuerySection. Если они совпадают, то перехватчик обнуляет базовый адрес секции. Перехват функции реализован не шибком надежно - если хендлы не совпали, то функция ZwQuerySection остается незахученой, и в следующий раз будет хукнута только в перехватчике ZwCreateSection.
Так вот после перехвата лоадер берет параметр реестра http\shell\open\command, где расположен по обычаю путь до IE, и запускает процесс с замороженным потоком. Благодаря тому что CreateProcess вызывает ZwCreateSection и ZwQuerySection, то перехватчики будут работать. Затем все возвращается опять к VirtualProtect, повторяться снова, и теперь уже после очередного обнуления адреса секции идет к следующему куску кода. Этот кусок создает временный фаил, в котором расположился код по скачиванию ехе и его запуску. После создания файла создается секция с помощью ZwCreateSection и мапится в процесс IE по его базовому адресу. В первый раз созданный таким образом процесс убивается с помощью TerminateProcess, и возвращается опять к VirtualProtect. Уже со второго раза процесс оставляется в живых, лоадер делает ResumeThread на потоке этого процесса и ожидает его завершения.

Итого, данный билд лоадера буквально собран из каких то кусочков, которые нестабильно работают, также непонятны круголя вокруг ZwCreateSection. Все можно найти в гугле, и собрать в кучу. Так как на носу праздник, в качестве подарка будет сам этот лоадер, база иды и на десерт - сорец на си.
Лежит тут - ../soft/wowloader.zip Вес - 115кб

Only for TGBR E-ZineS, by Neon, TGBR.ORG 27.12.07

С Новым Годом!