Использовать алфавитное преобразование с разделением каждого байта на два четырехбитных полубайта и добавлением их к печатному символу в формате ASCII (такому как A или a).

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

NOP-цепочки

Иногда перед shell-кодом вставляют длинную цепочку инструкций NOP (которую еще называют дорожкой или трамплином из NOP-ов, от англ. no operation), как это показано на рис. 19.3. Такие цепочки не являются обязательными, но они часто входят в состав эксплойта, чтобы увеличить вероятность его успешного срабатывания. Здесь делается ставка на то, что управление попадет к одной из множества инструкций NOP, в результате чего рано или поздно будет выполнен сам shell-код.

Рис. 19.3. Размещение цепочки из инструкций NOP и кода командной оболочки

Обычно такие цепочки состоят из инструкций NOP (0x90), но, чтобы избежать обнаружения, авторы эксплойтов могут пойти на различные уловки. Вместо NOP могут использоваться опкоды в диапазоне от 0x40 до 0x4f, которые соответствуют однобайтным инструкциям для инкрементирования и декрементирования регистров общего назначения. Кроме того, этот диапазон состоит из печатных символов в формате ASCII. Это может пригодиться, поскольку NOP-цепочки выполняются до запуска декодера и, как следствие, должны отвечать тем же требованиям со стороны фильтра, что и остальной shell-код.

Поиск кода командной оболочки

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

Зараженные веб-страницы чаще всего используют JavaScript, чтобы собрать информацию о системе пользователя и проверить, установлены ли в ней уязвимые

версии браузера или плагинов. Для преобразования закодированных текстовых данных в двоичный пакет, готовый для выполнения, обычно используется функция unescape. Shell-код часто хранится в виде закодированной строки, которая встроена в скрипт, запускающий эксплойт.

Функция unescape интерпретирует текст %uXXYY как символ в кодировке Unicode, в котором байты следуют от старшего к младшему. При этом XX и YY воспринимаются как шестнадцатеричные значения. В компьютерах, в которых используется противоположный порядок следования байтов (как в x86), результатом декодирования будет последовательность YY XX. Рассмотрим, к примеру, следующую текстовую строку:

%u1122%u3344%u5566%u7788%u99aa%ubbcc%uddee

После декодирования она превратится в такую двоичную последовательность байтов:

22 11 44 33 66 55 88 77 aa 99 cc bb ee dd

Если символ % не идет сразу после буквы u, он воспринимается как отдельный байт, закодированный в шестнадцатеричном формате. Например, строка %41%42%43%44 будет декодирована в двоичную последовательность байтов 41 42 43 44.

ПРИМЕЧАНИЕ

В рамках одной текстовой строки можно использовать символы воднобайтной и двухбайтной кодировке. Эта методика часто встречается при использовании JavaScript, в том числе и в документах PDF.

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

Основную часть кода командной оболочки обычно можно распознать по использованию типичных API-вызовов для внедрения в процесс, которые мы обсудили в главе 12, а именно VirtualAllocEx, WriteProcessMemory и CreateRemoteThread. Если вредонос запускает удаленный поток без поправки на сдвиг или поиска внешних зависимостей, то буфер, который он записывает в другой процесс, скорее всего, будет содержать shell-код. Авторам вредоносного ПО это на руку, ведь таким образом код командной оболочки может собрать и выполнить себя сам, без помощи вредоноса, который его доставил.

Иногда код командной оболочки хранится в незакодированном виде внутри медиафайла. Дизассемблеры, такие как IDA Pro, способны загружать любые двоичные файлы, включая те, в которых потенциально содержится shell-код. Но при этом IDA Pro может не знать, какие байты являются исполняемыми, а это сделает анализ невозможным.

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

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

Даже если поиск не дал никаких результатов, это не значит, что shell-кода в файле нет, поскольку некоторые форматы файлов допускают встраивание закодированных данных. Например, эксплойты, нацеленные на критическую уязвимость CVE-2010-0188 в Adobe Reader, используют неправильно сформированные TIFFизображения, которые хранятся внутри PDF-документов как закодированная в Base64 строка и могут быть сжаты с помощью библиотеки zlib. Вы должны быть знакомы с форматом файла, с которым работаете, и знать, какие данные он может нести, — это поможет вам в поиске вредоносного содержимого.

Итоги главы

Авторам кода командной оболочки приходится использовать различные приемы для обхода ограничений, свойственных нестандартным средам выполнения, в которых этот код работает. Это касается определения собственного местоположения в памяти и ручного поиска всех своих зависимостей, что в дальнейшем позволит взаимодействовать с системой. Для экономии места эти зависимости обычно обфусцируются путем замены имен функций в кодировке ASCII на их хешированные значения. Очень часто почти весь shell-код оказывается закодированным, что позволяет ему обойти любые проверки данных в атакуемом процессе. Все эти методики могут легко обескуражить начинающего аналитика безопасности. Но материал, представленный в этой главе, должен помочь вам распознать их, чтобы вы могли сосредоточиться на основной функциональности кода командной оболочки.

Лабораторные работы

Сейчас вы сможете применить полученные в этой главе знания, чтобы изучить примеры, созданные на основе реального shell-кода. Поскольку отладчик не может загружать и запускать код командной оболочки напрямую, для динамического анализа двоичных файлов мы будем использовать утилиту shellcode_launcher.exe. Инструкции по ее применению можно найти в главе 19 и в приложении В, где приводится подробный анализ работ.

Лабораторная работа 19.1

Проанализируйте файл Lab19-01.bin, используя утилиту shellcode_laun­ cher.exe.

Вопросы

1.Каким образом закодирован shell-код?

2.Какие функции он импортирует вручную?

3.С каким сетевым узлом он взаимодействует?

4.Что он оставляет после себя в файловой системе?

5.Каково его назначение?

Лабораторная работа 19.2

Файл Lab19-02.exe содержит фрагмент shell-кода, который внедрится в другой процесс и будет в нем выполнен. Проанализируйте этот файл.

Вопросы

1.В какой процесс внедряется shell-код?

2.Где расположен shell-код?

3.Каким образом он закодирован?

4.Какие функции он импортирует вручную?

5.С каким сетевым узлом он взаимодействует?

6.Каково его назначение?

Лабораторная работа 19.3

Проанализируйте файл Lab19-03.pdf. Если вам не удается найти код командной оболочки, просто пропустите эту часть лабораторной и переходите к анализу файла Lab19-03_sc.bin с помощью утилиты shellcode_launcher.exe.

Вопросы

1.Какой эксплойт использован в этом PDF-документе?

2.Каким образом закодирован shell-код?

3.Какие функции он импортирует вручную?

4.Что он оставляет после себя в файловой системе?

5.Каково его назначение?