А. Белоус - Кибероружие и кибербезопасность. О сложных вещах простыми словами

Рандомизация размещения адресного пространства (ASLR)

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

Пещера в коде (Code Cave)

Code Cave (пещера в коде) представляет собой кусок кода, который записывается другой программой в память стороннего процесса. Этот код может быть выполнен посредством создания удаленного потока внутри целевого процесса. Code cave зачастую является ссылкой на секцию скриптовых функций кода, куда в принципе можно инжектировать любые инструкции. Например, если в памяти скрипта 5 байт, и 3 байта используются, в оставшиеся 2 байта скрипта можно добавить внешний код.

Контрольная сумма

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

Рассмотрим ниже более подробно основные методы проникновения. Примеры из этого раздела будут продемонстрированы на базе исполняемого файла SSH-клиента с именем putty. Есть несколько причин для выбора именно этого приложения в качестве подопытного образца. Putty написан на C++ и использует множество библиотек и API-функций. Во-вторых, внедрение вредоноса в ssh-клиент привлекает меньше внимания, поскольку программа уже выполняет tcp-соединение, и, таким образом, будет проще избежать мониторинга со стороны системы безопасности.

Код бэкдора [96] будет взят из шелл-кода, используемого при обратном TCP-соединении и написанного Стивеном Фивером (Stephen Fever) под meterpreter. Главная цель — инжектировать шелл-код в целевой PE-файл без «порчи» функциональности приложения. Инжектированный шелл-код будет запускаться в отдельном потоке и будет постоянно пытаться подсоединиться к обработчику. Вторая задача — во время выполнения всех этих манипуляций необходимо оставаться незаметным настолько, насколько это возможно.

Общий подход внедрения вредоноса в PE-файл состоит из 4 шагов:

1. Нахождение доступного пространства для кода трояна.

2. Перехват потока выполнения.

3. Внедрение трояна.

4. Восстановление потока выполнения.

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

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

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

При помощи дизассемблера или редактора LordPE РЕ-файл можно расширить при помощи добавления заголовка новой секции. На рисунке ниже показана таблица секций исполняемого файла putty. При помощи PE-редактора добавлена новая секция «NewSec» размером 1000 байт.

Рис. 8.20. Таблица секций

Во время создания новой секции важно установить флаги на чтение/запись/выполнение, чтобы запустить шелл-код, когда РЕ-об-раз проецируется (тар) в память.

Puc. 8.21. Выставление флагов на чтение/запись/выполнение

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

Puc. 8.22. Добавление пустых байтов

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

Рис. 8.23. Новая секция. NewSec успешно добавлена в исполняемый файл

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

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

Puc. 8.24. Результаты проверки исполняемого файла с новой пустой секцией

Второй подход — это использование Code Cave

Во втором методе, направленном на решение проблемы доступного пространства, используются code сауе’ы из целевого исполняемого файла. Практически все скомпилированные бинарные файлы имеют code cave’bi, которые могут быть использованы для внедрения вредоноса. Code cave по сравнению с новой секцией привлекает намного меньше внимания, поскольку в этом случае применяются уже существующие обычные секции. Дополнительный и не менее важный плюс заключается в том, что после внедрения вредоноса размер PE-файла не меняется. Однако эта техника имеет свои недостатки.

Количество и размер code cave’oe варьируется от файла к файлу, но в целом общий размер будет меньше, чем при добавлении новой секции. При использовании code cave’oe код бэкдора следует уменьшать настолько, насколько возможно. Второй недостаток — это набор флагов. Поскольку выполнение будет перенаправляться в code cave, у секции должны быть права на выполнение. В случае с некоторыми шелл-кодами (которые сами себя кодируют или подвергают обфускации) требуется права на запись для того, чтобы выполнять изменения внутри секции.