СОИБ. Анализ. Способы обхода DPI, WAF, DLP и д.р.


В рамках недавней PHDays проходил ряд докладов связанных с анализом эффективности существующих средств защиты:
·        В обход DPI, Олли-Пекка Ниеми (Opi)
·        Теория лжи: обход современных WAF, Владимир Воронцов
·        Десяток способов преодоления DLP-систем, Александр Кузнецов, Александр Товстолип

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

1.             
В своем докладе Олли-Пекка рассказал про пентестовую утилиту Evader, некоторые техники обхода средств защиты (evasion).  Сама утилита Evader – вещь отличная, но у доклада было несколько минусов:
·        Во-первых, несоответствие содержания и названия. К DPI никакого отношения. Область действия Evader и описываемых способов обхода – в основном сигнатурные сетевые системы защиты (NGFW, IPS)
·        Во-вторых, доклад не оправдывал уровень сложности – 200. Вполне хватило бы и 100. Так как это был краткий пересказ определений различных техник обхода и демонстрация интерфейса Evader
·        В-третьих, старая тема. Аналогичный доклад я уже слышал в Stonesoft 2 года назад. С того времени новых слов не прибавилось

Теперь по сути вопроса: так как в докладе не прозвучало какие именно средства какими недостатками обладают, нам потребуется самостоятельно развернуть тестовый стенд Evader, о котором я уже писал ранее. Прогнать его используя mongbat со всеми возможными комбинациями обхода (evasion), определить те, которые не обнаруживаются нашим сетевым средством защиты. Дополнительно настроить средства защиты, так чтобы обнаруживать атаки даже с техниками обхода (уверен, что в 90% случаев это можно сделать). А для оставшихся 10% необнаруживаемых атак принять решение о необходимости иных “компенсирующих” мер.


Например, если у нас web приложение, а FW и IPS не могу определить атаки, то нужен WAF. Либо, как предлагает Stonesoft, использовать временную меру Stonesoft Evasion Prevention System (EPS), которую можно впихнуть в любую работающую инфраструктуру.

2.             
Доклад про обход WAF был очень хорош в части презентационных навыков докладчика и интересности – слушался легко и непринуждённо.  НО полезной информации, которая была нужна мне и о которой я писал выше, там не было:
·        Сам докладчик говорит, по ряду недостатков WAF (DoS, Protocol-Level Evasion, защищаемые Hostname, HTTP Protocol Pollution), говорит что они связаны с плохой настройкой средства защиты, потом совершает логическую ошибку и говорит что плохи сами WAF.
·        Техники обхода перечислялись в режиме пересказа, без демонстраций, деталей и т.п.
·        По ходу дела докладчик неоднократно говорит “в корпоративных WAF всё настолько плохо, что я не буду их рассматривать в данном разделе, рассмотрю только open source средства защиты”. Из этого я делаю вывод, что у докладчика всё настолько плохо с получением “корпоративных” WAF на тестирование и с опытом их настройки, что он не хочет трогать эту больную тему
Для подтверждения того что утверждение докладчика не очевидно, привожу следующий аналитический отчет

·        Докладчик ссылается на  недавнее сравнение облачных сервисов WAF, в котором делаются выводы об их слабой эффективности.  Тут я могу сказать только то, что облачные сервисы на данный момент действительно слабые (слабее чем выделенные корпоративные WAF). Связано это с настройкой WAF у данного конкретного провайдера услуг, а не с какой-то со слабостью решений типа WAF в принципе.

·        Часть уязвимостей, приведенных автором, являются уязвимостями конечных сервисов и приложений и не имеют отношения к WAF (который их отлично детектирует). Зачем автор привел их в данной теме? Наверное, решил выложить все, что он знает в безопасности web.
·        В самом конце докладчик говорит, что разрабатывает собственное принципиально новое средство защиты web приложений (вот и открылись истинные причины критики WAF)

На самом деле, в WAF есть достаточно много правил нормализации и контроля протоколов, надо только их корректно настроить. Вполне возможно автор доклада не потратил достаточно времени на изучение возможных вариантов настройки “корпоративных” WAF.

Сами принципы и технологии работы современных корпоративных WAF сильно отличаются от того, про что рассказывал докладчик, это давно уже не набор детектируемых сигнатур. В них уже есть:
·        система полномочного разграничения доступа, в которой мы задаем явно, что можно делать пользователю в web приложении (не путать с блокированием запросов по сигнатурам атак)
·        динамическое профилирование, в рамках которого система автоматически стоит профили запросов нормальных пользователей и обнаруживает аномальное отклонение
·        защита от автоматизированных атак (Automated Attack), в рамках которой обнаруживаются внешняя инвентаризация, перебор, фазинг и т.п.
·        корреляция с системами защиты БД, в рамках которого WAF получает информацию, о том какой реально запрос и ответ прошел от сервера web приложения к серверу БД
Эти механизмы не упоминались и делаю вывод, что они докладчику были неизвестны.

3.             
Преодоление DLP. По мнению докладчиков основные проблемы из-за настроек по-умолчанию, ошибок в конфигурации, не поддерживаемой системы. Но были и явные недостатки самих DLP решений (к сожалению, без уточнения, какая версия какого продукта тестировалась):
·        отключение службы с правами администратора (путем переименования файла службы)
·        копирование защищаемых документов в локально-подключенный криптоконнтейнер
·        побитовое копирование документа в конец картинки
·        когда система сначала разрешает копирование, потом блокирует и удаляет файл с носителя, можно попробовать произвести восстановление удаленного файла
·        удаление лога с событиями DLP с правами администратора


Все приведенные недостатки могут быть использованы с натяжкой. Так что, в процессе устранения вендорами таких недостатков, можно принимать альтернативные меры – грамотно настраивать права пользователей в ОС и к файловой системе, контролировать перечень установленного стороннего ПО и постоянную активность сервисов DLP.

4.            Общей же мыслью всех трех докладчиков является необходимость грамотной настройки средств защиты информации, постоянному мониторингу и оптимизации настройки. Принцип “поставил и забыл” в мире реального ИБ – не работает.

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

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

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

6.            Ещё один вывод – Чтобы хакер смог понять, как обойти нашу систему защиты, ему нужно развернуть и протестировать у себя точный аналог. Если мы используем дорогое корпоративное решение, то обычному хакеру этот вариант недоступен.

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


Комментарии

Анонимный написал(а)…
А как быть, если была найдена уязвимость в сайте одной фирмы из вашего списка "Полезные контакты ИБ на Кубани"

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

Вот только до конца копать желания нет, после какого срока можно выложить уязвимость на хабр ?

Если вам интересно, я могу вам прислать видео.
Анонимный написал(а)…
Вернее желание есть дальше копать, но вот только надо ли это данной фирме и не сильно они обидятся.

Как бы вы поступили на их месте " в случае когда прислали, долгое бездействие, дальнейшее исследование человеком дыры ?

Спасибо большое за внимание, важно ваше мнение, как человека связанного с IT.
Dmitry Evteev написал(а)…
Если владелец системы не давал своего разрешение на "копать", тогда тут недалеко от статьи.
Сергей Борисов написал(а)…
Если тебя интересует вознаграждение по программе Bugbounty, то рассчитывать на это не стоит.

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


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

Я бы на твоем месте добился того что меня услышали и получил бы ответ от компании.
дальше по обстоятельствам




Roman S написал(а)…
По преодолению DLP, у 99% инсайдеров низкий технический уровень, не будут они переименовывать службы, удалять логи. Они просто распечатают документ или сфоткают его. Вот как с этим бороться, это вопрос.

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

Хватило бы спасибо и после закрытия дырки, адекватного восприятия публикации.

Компания микротест )
Сергей Борисов написал(а)…
Связывайся с Ильей Яблонко или Светланой Гущиной по телефону или email. А лучше и так и так.
Учитывай что сайт находится на хостинге и разрабатывался сторонней организацией.
Сергей Борисов написал(а)…
Roman, не думаю что всё так плохо.
О DLP в режиме мониторинга пользователи могут даже не знать. И не смогут тестировать когда события регистрировались, а когда нет.

Печать документа также контролируется. Ставится водяная метка. Потом имея документ можно легко вычислить кто печатал.
Фотографиями много не унесешь.
Тем более я соглашусь с тезисом который прозвучал на форуме "DLP это защита от утечки документов а не информации"
То есть защищаем именно документы целиком. С информацией - её утечку полностью предотвратить в принципе не возможно (по крайне мерее пока не научатся стирать память мозга)
Анонимный написал(а)…
Сергей, давайте я вам видео пришлю или ссылку на друбокс, чтоб вы поняли где ошибка, я уже писал письмо, почти неделю назад.

В данном случае сегмент находится на IP принадлежащем именно микротесту.

Я вам сейчас ссылку на почту скину.
Roman S написал(а)…
Сергей: Вендорам, можно в принципе сделать несколько шагов и в защите именно информации. Информация содержится не только в документах, но и в разнообразных базах, порой весьма специфичных. Например, группы контрагентов в парусе или 1с, которые выводятся в виде списка прямо в форме базы.

По идее, достаточно ввести в функционал DLP системы функцию скриншотов с распознаванием текста. Тогда мы отвязываемся от цифрового носителя (документа), и привязываемся как раз к информации, которую видит человек. Дальше, по вдруг вскрывшимся фактам утечки информации (не документа), можно уже сужать круг людей. К сожалению не все DLP такое умеют.

Кстати говоря, не помню, был ли озвучен в докладе, еще один банальный метод слива, как временное изъятие харда из компьютера или применение liveCD. Тут тоже большого ума не надо и любые агентские модули в дауне. Однако функции распознавания фактов изъятия накопителей из компа или применения livecd, я что-то в DLP система не встречал, хотя реализуется это достаточно просто.

Популярные сообщения из этого блога

СКЗИ. НПА. Некоторые вопросы применения криптографии

Модель угроз безопасности клиента финансовой организации

КИИ. Категорирование объектов, часть 3