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

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

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

Автор: Агиевич Игорь aka shanker (http://habrahabr.ru/users/shanker/)

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

Предпосылки создания

Идея динамического обнаружения шелл-кода в электронных документах возникла после участия в расследовании нескольких компьютерных инцидентов. Их краткая история следующая. Происходила серия однотипных атак. Каждая атака производилась следующим образом: на почтовый ящик пришли письма от известных отправителей с понятной получателю темой и содержанием. Как позже выяснилось, данная информация злоумышленниками была получена в результате предыдущей атаки. Также письмо содержало вложение – .doc документ.

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

При расследовании инцидента было выяснено:

  • Связка эксплоит – троян заточена под WinXP (хотя на дворе уже 2012 год!!)
  • Эксплоит – немного модифицированный пример из metasploit’a.
  • Троян примитивен – исходные фрагменты которого даже не продаются, а доступны бесплатно в интернете! Отсутствовали крипторы, обфускаторы, что сыграло роль (скорее всего) в потери бдительности антивирусов.
  • Данная атака совершалась на организацию и ранее. Более старые эксплоиты (актуальные на тот момент), немного более простое тело трояна. И даже при таком примитивном подходе по ее итогам у атакующих появились настоящие документы организации (что показала последняя рассылка).

Результаты предварительного анализа

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

 Рисунок 1.

Лидеры антивирусного рынка подтвердили, что не даром едят свой хлеб. 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 в котором клиентское ПО открывает из общего диска документы и проверяет их на содержание шелл-кода.

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

Не ждите, пока хакеры вас взломают - подпишитесь на наш канал и станьте неприступной крепостью!

Подписаться