Колонка Дениса Макрушина. Наступательная безопасность

В 2013 году на конференции Black Hat Europe исследователь и наш постоянный автор Алексей Синцов представил публике исследование, в котором описал концепцию активного ханипота и опробовал ее на практике.

Другие статьи в выпуске:

Xakep #198. Случайностей не бывает

• Содержание выпуска
• Подписка на «Хакер»-60%

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

С одной стороны, на рынке информационной безопасности явно выделяются тренды в направлении классической пассивной защиты: появляются новые игроки со своими SIEM-системами, «импортозамещаются» классические средства защиты, развиваются технологии борьбы с APT. С другой стороны, в индустрии всплыли компании, которые не брезгуют продавать полноценную малварь, предназначенную для комплексного мониторинга зараженной рабочей станции. В результате подобные разработки находят своего потребителя в лице правоохранительных органов.

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

Нападение — лучшая форма защиты

«Лучшая защита — это нападение», — говорил Александр Македонский. Слова полководца подкрепляет тот факт, что защищающаяся сторона вынуждена определить множество вариантов действий стороны атакующей. И как результат, следом за сценарием атаки идет сценарий реакции на это событие, что откидывает защищающуюся сторону на шаг назад. Это в классической модели процесса конфликта.

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

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

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

Почему бизнесу неинтересны решения подобного класса? Потому что «false positive» может отправить клиента в ханипот, а бизнес уложить на лопатки. Так что незачем испытывать судьбу. И тем не менее в ходе расследования ИБ-инцидента этот бизнес вынужден инвестировать средства в оперативно-разыскные мероприятия, чтобы найти «ответчика».

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

Основные вопросы, которые может вызвать активный ханипот, атакующий нарушителя:

• Легально ли с юридической точки зрения атаковать хакера в ответ?
• Как мне убедиться в том, что ханипот не атакует клиента?

Юридические аспекты

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

Рассмотрим сценарий, который описывал Алексей.

1. Атакующий успешно эксплуатирует уязвимость (или серию уязвимостей) в веб-приложении (SQL inj, XSS, bruteforce и так далее) и попадает в закрытую зону веб-ресурса (админ-панель).
2. В админ-панели атакующий находит документы, которые предназначены для внутреннего пользования, и скачивает эти документы.
3. Документ содержит payload, который открывает канал утечки каких-либо данных об атакующем.

Последний пункт — тот самый камень преткновения между логикой и законом. С одной стороны, злодей скомпрометировал целевую информационную систему. Несет ли объект атаки ответственность за все последующие действия злодея? Ответ: да, несет. Однако все зависит от payload’a. Если документ содержит эксплойт или каким-либо образом допускает исполнение произвольного кода в операционной системе, то это нарушение закона. И такой инцидент законодательство каждой страны описывает по-своему.

Например, это может нарушать «privacy laws» в США. Эти законы (Wiretap Act, Electronic Communication Privacy Act) ограничивают вмешательство в частную жизнь, даже если это происходит в процессе взлома offensive-ханипота. С другой стороны, есть такое понятие, как «льгота для сервиса, находящегося под защитой», которое позволяет собирать информацию о злоумышленниках до тех пор и только в тех случаях, когда такая технология направлена строго на защиту какого-либо объекта. Другими словами, существуют льготы для оперативно-разыскных мероприятий.

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

Архитектура offensive honeypot

Решение типа «offensive honeypot» должно выполнять следующие задачи:

1. Определять начальную стадию атаки.
2. Идентифицировать все последующие обращения атакующего к целевой системе (то есть отделить его от потока легитимных обращений к целевой ИС).
3. Фиксировать каждое действие атакующего.
4. На каждом этапе атаки получать информацию об атакующем и его окружении.
   При этом — никаких false positive. Последний пункт — полет фантазии и творчество для специалиста, проектирующего ханипот.

В своем исследовании Алексей классифицировал возможных атакующих следующим образом:

1. Автоматизированные средства (боты).
2. Скрипт-киддисы.
3. Black hat’ы.
4. White hat’ы.

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

Рассмотрим архитектуру решения на примере ханипота для веб-приложений. Впоследствии мы расширим эту концепцию до полноценной инфраструктуры.

Итак, требования к архитектуре:

• быстрая интеграция с целевой ИС;
• прозрачность как для клиента, так и для атакующего.

Фронтенд для целевой информационной системы решает следующие задачи:

1. Анализ запроса к бэкенду (задача web application firewall).
2. В случае если запрос легитимный, фронтенд перенаправляет его бэкенду.
3. Если запрос нелегитимный, фронтенд осуществляет фингерпринт браузера пользователя и перенаправляет его в ханипот (либо внедряет JS-код в оригинальные страницы).

О конкретных инструментах и их использовании мы поговорим в следующем материале. Пока что можно сделать прогноз: в качестве средства frontend будет использоваться веб-сервер nginx (возможно использование в связке с NAXSI WAF). Более того, пейлоадам и сценариям, при которых они будут загружаться на сторону атакующего, можно посвятить отдельный номер.

Заключение

«Наступательная безопасность» — понятие, которое с ростом количества инцидентов в корпоративном и государственном секторе будет набирать обороты и в будущем станет появляться в инфраструктуре в том или ином виде. Еще позавчера понятие «кибервойска» было в словарном запасе футурологов и фанатов жанра киберпанк. Возможно, уже завтра активные защитные решения, основанные на наступательном принципе, станут неотъемлемой частью этих самых «кибервойск».

Задай вопрос Денису

Теперь ты можешь задать свой умный (или не очень) вопрос на тему безопасности в целом и малвари в частности, а Денис — публично на него ответит. Спамим сюда: condifesa@gmail.com.