Динамическое обнаружение шелл-кода в электронных документах

Лидеры антивирусного рынка подтвердили, что не даром едят свой хлеб. 15 из 44 поймали эксплоит. А теперь поставим себя на место злоумышленников и подготовим еще одну рассылку с этим же эксплоитом. После ряда небольших преобразований исходный документ с работоспособным эксплоитом еще раз проверим на связке АВ:

Рисунок 2.

Всего 4 из 44 детектов. Какой же вывод напрашивается? Вывод достаточно очевидный: «наличие АВ необходимое, но не достаточное условие компьютерной безопасности в организации!». Варианты решения проблемы:

1. Отключить интернет.

-Не подходит т.к. разработчикам надо читать rsdn, habr и т.д. закупщикам надо общаться с поставщиками, руководству с заказчиками и т.д.

2. Организовать курсы повышения ИБ-грамотности сотрудников.

-Дорого (сотрудников порядка 1000). Сложно (разнесены географически).

3. Навести порядок на рабочих станциях сотрудников, и запретить устанавливать стороннее ПО.

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

Динамическое обнаружения шелл-кода. Теоретическая часть.

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

Задача шелл кода - сформировать (скачать или распаковать из себя и сбросить на диск) и запустить стороннее приложение на системе пользователя. Как показал инцидент АВ-решениям достаточно сложно (и бессмысленно) своевременно угнаться за разновидностями шелл-кодов и детектировать их по сигнатуре. Сигнатуру самой уязвимость тоже можно модифицировать.

Был проведен эксперимент суть которого в следующем. Открывались документы (безвредные) различными программами (Office, Adobe Reader и т.д.) под отладчиком и было обнаружено, что в процессе открытия у них не принято качать и запускать какие-либо исполняемые файлы. А при открытии документов с эксплоитами (в качестве набора данных были взяты примеры из metasploita) процессы Winword, Acrord32 вызывают такие Api-функции как UrlDownloadToFile + WinExec. Есть и другие нехарактерные функции, но перечислять здесь их не будем.

Таким образом, наша идея свелась вот к чему. Было решено реализовать модуль-отладчик, который бы описывал правила вызовов API- функций для конкретного приложения. И в случае срабатывания правила пользователь информируется о подозрительном действии.

Требования:

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

Отладчик использует системный IDebugClient, что, как показала практика, быстрее и гибче, чем стандартные Debug API. Код приложения планируется опубликовать в ближайшее время.

Практические испытания

Настало время перейти от теории к практике. Устроим небольшое испытание, суть которого в следующем. Откроем чистый .doc документ (т.е. без эксплоита) с включенным мониторингом Api-функции WinExec, затем документ с эксплоитом.

На рисунке 3 показан запуск сначала обычного doc-файла, а потом файла с эксплоитом.

Рисунок 3.

Видно различие: во втором случае вызывается функция WinExec. Причём вызывается 2 раза т.к. после запуска тела вируса происходит открытие WinWord с каким-то реальным документом. Это связано с тем, что при эксплуатации уязвимости приложение WinWord аварийно завершает работу, что выглядит подозрительно. Поэтому после этого вирусописатели решили заново запускать WinWord, передав ему вполне нормальный документ. Это уменьшает подозрительность происходящих на компьютере действий: ну, мелькнуло окошко ворда. Но потом же документ открылся! Как показывает практика, это действительно сильно уменьшает подозрения пользователя и осложняет своевременное реагирование на инцидент.

Ниже представлено видео, где демонстрируется процесс детекта конкретного трояна.

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

Данное решение позволяет своевременно оповещать об инциденте и имеет потенциал по развитию недопустимости исполнения шелл-кода.

Также мы реализовали комплекс exploit-hunting в котором клиентское ПО открывает из общего диска документы и проверяет их на содержание шелл-кода.

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