(записки антивируса-любителя)
Когда получаешь накануне дня святого валентина поздравительное письмо со ссылкой, то ужасно хочется узнать, что же там такое, по этой ссылке. Все в один голос утверждают, что такие подозрительные ссылки ни в коем случае нельзя открывать, но мы-то знаем, что если аккуратно, то можно. Например, скачать такую страницу, а потом разглядеть внимательно в любимом текстовом редакторе.
В моем случае было нечто вроде
<meta http-equiv=«refresh» content=«1;url='valentine.exe'»>
…
<a href="valentine.exe">blah-blah</a>
Неприкрытое приглашение стать новым пользователем вируса. Также аккуратно скачав valentine.exe, и переменовав его в .txt, чтобы ненароком не запустить, можно поковырять его изнутри.
Онлайн файл-сканнер Касперского определяет этот файл как зараженный вирусом «Email-Worm.Win32.Zhelatin.vg».
Сказать, что количество информации, сообщаемое о вирусах, меня не устраивает — ничего не сказать. Оно просто катастрофически мало. Оно не говорит, во-первых, чего не следует делать. Во-вторых, оно зомбирует пользователей «держите антивирусные базы обновленными». Обновленные базы — оно, конечно, очень хорошо, я только за. Только от первой волны эпидемии эти базы не спасут, так как в них попросту нет сигнатур еще не вышедших вирусов.
Поэтому, чтобы рассеять, — по крайней мере, для себя, — атмосферу мрака и ужаса, окружающего внутренне устройство вируса, я засучил рукава и выяснил следующее.
Общая схема работы вируса такова:
1. Оригинальный «valentine.exe» извлекает из своего тела кусок кода, который сначала расшифровывается, а затем распаковывается с помощью функции RtlUncompressBuffer. Этот код сохраняется в файле %SYSTEMROOT%/system32/diperto$p-$t.sys, где $p и $t — идентификаторы процесса и потока (в шестнадцатеричном формате) «valentine.exe», записывающего файл. Также создается файл %SYSTEMROOT%/system32/diperto.ini:
[config]
[local]
uport=1211
[peers]
Порт менятся случайным образом. Магическое слово «peers» может означать то, что зараженный компьютер будет входить в ботнет.
2. «valentine.exe» загружает драйвер «diperto.sys», используя функции Windows API, после чего прекращает свою работу.
3. «diperto.sys» создает устройство под названием «DRV_MODULE_MYDR», а также эвент под именем «Ir<fk^7k». Все это можно увидеть с помощью WinObj.exe
4. После инициализации, драйвер запускает новый поток в режие ядра, который, в свою очередь извлекает кусок зашифрованного кода из тела драйвера. Код «зашифрован» операцией «исключающее или» и представляет собой исполняемый файл Windows.
5. Затем находит процесс под названием «services.exe» - контролер служб Windows, подсоединяется к нему, выделяет в адресном пространстве процесса новый блок памяти, куда записывает расшифрованный кусок кода.
6. Для передачи управления вредоносному коду, драйвер использует APC — asynchronous procedure call. Используя функцию KeInsertQueueApc он ставит в очередь на исполнение асинхронный вызов, который будет «доставлен» после любого следующего системного вызова из процесса-жертвы. После этого драйвер прекращает свою работу.
7. Вкратце все это выглядит так:
valentive --> расшифровывает кусок себя --> diperto.sys --> расшифровывает кусок себя --> services.exe.
На данном этапе возникает два вопроса: а) к чему все эти манипуляции? б) как нам защититься это этого зверя?
Ответ на второй вопрос, в общем-то очевиден. Достаточно закрыть доступ на запись %SYSTEMROOT%/system32, в результате самый первый шаг обламывается и вирус идет лесом. Но, представим на минуту, что он мутировал, и умеет записывать файл в любое другое место. Тогда единственное, что может нас спасти — отобрать у себя право на регистрацию и загрузку драйверов (что, по сути, аналогично праву записи в раздел реестра «HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services»).
По умолчанию, такие права есть только у группы Adminisrtrators.
Ну и теперь самый интересный вопрос — зачем столько телодвижений? А вот зачем. Обычно подобная операция внедрения кода и запуска его на выполнение производится с помощью связки «OpenProceess — VirtualAllocEx — WriteProcessMemory — CreateRemoteThread», на которую антивирусы обращают пристальное внимание. В нашем случае цепочка выглядит так: «KeAttachProcess — ZwAllocateVirtualMemory — rep movds — KeInsertQueueApc». «rep movsd» означает, что вредоносный код копируется напрямую в пространство жертвы, не используя никакие функции вообще. На сегодняшний день выявить такого рода проникновение антивирусы не в состоянии.
Немного статистики:
— размер оригинального файла: 117 248 байтов.
— размер файла драйвера: 129 920 байтов.
— оригинальный файл скомпилирован MINGW GCC. Который, кстати, помогает выворачивать мозг наизнанку, когда пытаешься отследить вызовы функций в незнакомом стиле
— оригинальный файл нашпигован ложными вызовами вроде CreateWaitableTimer(0, 0, 0); или IsBadHugeReadPtr(0, 0); или DeleteAtom(0). Не совсем понятно, кого они призваны сбить с толку — антивирусы или человека.
Во второй части рассмотрим собственно то, как работает вирус, внедренный в процесс services.exe.
Когда получаешь накануне дня святого валентина поздравительное письмо со ссылкой, то ужасно хочется узнать, что же там такое, по этой ссылке. Все в один голос утверждают, что такие подозрительные ссылки ни в коем случае нельзя открывать, но мы-то знаем, что если аккуратно, то можно. Например, скачать такую страницу, а потом разглядеть внимательно в любимом текстовом редакторе.
В моем случае было нечто вроде
<meta http-equiv=«refresh» content=«1;url='valentine.exe'»>
…
<a href="valentine.exe">blah-blah</a>
Неприкрытое приглашение стать новым пользователем вируса. Также аккуратно скачав valentine.exe, и переменовав его в .txt, чтобы ненароком не запустить, можно поковырять его изнутри.
Онлайн файл-сканнер Касперского определяет этот файл как зараженный вирусом «Email-Worm.Win32.Zhelatin.vg».
Сказать, что количество информации, сообщаемое о вирусах, меня не устраивает — ничего не сказать. Оно просто катастрофически мало. Оно не говорит, во-первых, чего не следует делать. Во-вторых, оно зомбирует пользователей «держите антивирусные базы обновленными». Обновленные базы — оно, конечно, очень хорошо, я только за. Только от первой волны эпидемии эти базы не спасут, так как в них попросту нет сигнатур еще не вышедших вирусов.
Поэтому, чтобы рассеять, — по крайней мере, для себя, — атмосферу мрака и ужаса, окружающего внутренне устройство вируса, я засучил рукава и выяснил следующее.
Общая схема работы вируса такова:
1. Оригинальный «valentine.exe» извлекает из своего тела кусок кода, который сначала расшифровывается, а затем распаковывается с помощью функции RtlUncompressBuffer. Этот код сохраняется в файле %SYSTEMROOT%/system32/diperto$p-$t.sys, где $p и $t — идентификаторы процесса и потока (в шестнадцатеричном формате) «valentine.exe», записывающего файл. Также создается файл %SYSTEMROOT%/system32/diperto.ini:
[config]
[local]
uport=1211
[peers]
Порт менятся случайным образом. Магическое слово «peers» может означать то, что зараженный компьютер будет входить в ботнет.
2. «valentine.exe» загружает драйвер «diperto.sys», используя функции Windows API, после чего прекращает свою работу.
3. «diperto.sys» создает устройство под названием «DRV_MODULE_MYDR», а также эвент под именем «Ir<fk^7k». Все это можно увидеть с помощью WinObj.exe
4. После инициализации, драйвер запускает новый поток в режие ядра, который, в свою очередь извлекает кусок зашифрованного кода из тела драйвера. Код «зашифрован» операцией «исключающее или» и представляет собой исполняемый файл Windows.
5. Затем находит процесс под названием «services.exe» - контролер служб Windows, подсоединяется к нему, выделяет в адресном пространстве процесса новый блок памяти, куда записывает расшифрованный кусок кода.
6. Для передачи управления вредоносному коду, драйвер использует APC — asynchronous procedure call. Используя функцию KeInsertQueueApc он ставит в очередь на исполнение асинхронный вызов, который будет «доставлен» после любого следующего системного вызова из процесса-жертвы. После этого драйвер прекращает свою работу.
7. Вкратце все это выглядит так:
valentive --> расшифровывает кусок себя --> diperto.sys --> расшифровывает кусок себя --> services.exe.
На данном этапе возникает два вопроса: а) к чему все эти манипуляции? б) как нам защититься это этого зверя?
Ответ на второй вопрос, в общем-то очевиден. Достаточно закрыть доступ на запись %SYSTEMROOT%/system32, в результате самый первый шаг обламывается и вирус идет лесом. Но, представим на минуту, что он мутировал, и умеет записывать файл в любое другое место. Тогда единственное, что может нас спасти — отобрать у себя право на регистрацию и загрузку драйверов (что, по сути, аналогично праву записи в раздел реестра «HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services»).
По умолчанию, такие права есть только у группы Adminisrtrators.
Ну и теперь самый интересный вопрос — зачем столько телодвижений? А вот зачем. Обычно подобная операция внедрения кода и запуска его на выполнение производится с помощью связки «OpenProceess — VirtualAllocEx — WriteProcessMemory — CreateRemoteThread», на которую антивирусы обращают пристальное внимание. В нашем случае цепочка выглядит так: «KeAttachProcess — ZwAllocateVirtualMemory — rep movds — KeInsertQueueApc». «rep movsd» означает, что вредоносный код копируется напрямую в пространство жертвы, не используя никакие функции вообще. На сегодняшний день выявить такого рода проникновение антивирусы не в состоянии.
Немного статистики:
— размер оригинального файла: 117 248 байтов.
— размер файла драйвера: 129 920 байтов.
— оригинальный файл скомпилирован MINGW GCC. Который, кстати, помогает выворачивать мозг наизнанку, когда пытаешься отследить вызовы функций в незнакомом стиле
mov [esp], a mov [esp+4], b mov [esp+8], c call F ; calls F(a, b, c);
— оригинальный файл нашпигован ложными вызовами вроде CreateWaitableTimer(0, 0, 0); или IsBadHugeReadPtr(0, 0); или DeleteAtom(0). Не совсем понятно, кого они призваны сбить с толку — антивирусы или человека.
Во второй части рассмотрим собственно то, как работает вирус, внедренный в процесс services.exe.
