11 Октября, 2018

Использование offensive-методов для обогащения Threat Intelligence

Инфосистемы Джет



На сегодняшний день Threat Intelligence, или активный сбор информации об угрозах информационной безопасности, представляет собой инструмент первой необходимости в процессе выявления инцидентов ИБ. Среди типовых источников TI можно выделить бесплатные подписки с вредоносными индикаторами, бюллетени производителей оборудования и ПО с описаниями уязвимостей, отчеты исследователей безопасности с детальными описаниями угроз, а также коммерческие подписки TI-вендоров. При этом зачастую сведения, получаемые с помощью вышеперечисленных источников, не обладают достаточной степенью полноты и актуальности. Повышению эффективности и улучшению качества TI может способствовать применение OSINT (разведка на основе открытых источников) и offensive-методов (то есть методов, характерных не для защищающейся, а для нападающей стороны) в информационной безопасности, о которых и пойдет речь в данной статье.

DISCLAIMER

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

Не вместо, а вместе

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

Так, использование дополнительных методов TI способно повысить его оперативность и помочь при решении ряда задач. Например, при очередной IoT-эпидемии, затрагивающей определенные уязвимые версии прошивок, как скоро удастся получить фид с IP-адресами потенциально уязвимых устройств, для того чтобы оперативно выявлять их активность на периметре? Или при срабатывании правил систем мониторинга по индикатору (IP-адресу или доменному имени), который был помечен вредоносным год и более назад, как понять, остается ли он до сих пор вредоносным, при условии, что инициировать какую-либо дополнительную проверку индикатора по состоянию «на сейчас», как правило, невозможно.

То есть особенно полезным дополнение и обогащение будет для среднеживущих индикаторов согласно «пирамиде боли» Дэвида Бьянко [0] (IP-адреса, доменные имена, сетевые артефакты), однако в некоторых обстоятельствах возможно получить новые долгоживущие индикаторы (вверх по пирамиде) при применении соответствующей аналитики.



Сканирование Интернета

Одним из методов, полезных для получения Threat Intelligence, считается сетевое сканирование.

Что обычно собирается при сканировании

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

При решении задачи расширения объема Threat Intelligence целью скана будет вся сеть Интернет. В ходе сканирования публичного адресного пространства (~ 3.7 миллиарда IPv4-адресов, исключая зарезервированные адреса) можно извлечь следующую полезную информацию:
  • Какие узлы подвержены уязвимостям, широко эксплуатируемым в рамках актуальных вредоносных кампаний и ввиду данного факта представляющим собой потенциальные источники вредоносных воздействий.
  • Какие узлы являются управляющими серверами ботнет-сетей [1] , обращения к которым может идентифицировать скомпрометированный узел в защищаемом периметре.
  • Какие узлы относятся к непубличной части распределенных анонимных сетей, которые возможно использовать для незаметного неконтролируемого выхода за пределы защищаемого периметра.
  • Более подробную информацию об узлах, «засветившихся» в срабатываниях системы мониторинга.
Выбор инструмента

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


Nmap

Пожалуй, самый известный сетевой сканер, созданный 20 лет назад. Благодаря возможности применения кастомных скриптов (через Nmap Scripting Engine), это чрезвычайно гибкий инструмент, не ограничивающийся лишь простым сбором прикладных «баннеров». На настоящий момент написано достаточно большое количество NSE-скриптов, многие из которых доступны бесплатно. Поскольку Nmap отслеживает каждое соединение, иными словами, обладает синхронной природой, применять его для больших сетей, таких как Интернет, не стоит по причине невысокой скорости работы сканера. В то же время данный инструмент целесообразно задействовать на небольших выборках адресов, получаемых более быстрыми инструментами, ввиду мощности NSE.

О скорости Nmap

Несмотря на изначально невысокую производительность, с момента выхода данного сканера его разработчиками было добавлено много функциональных возможностей, повышающих скорость сканирования. В их числе параллельные режимы работы и задание рейта в пакетах в секунду. Однако даже с «выкрученными» настройками Nmap отстает от своих асинхронных конкурентов по скорости. На примере сканирования /15 подсети по 443/tcp-порту с виртуальной машины с 1 CPU Xeon Gold 6140 и гигабитным каналом получаем:
  • 71.08 секунды для Nmap с параметрами
    -T5 -n -Pn -p 443 --open --min-rate 1000000 --randomize-hosts --defeat-rst-ratelimit –oG nmap.txt
  • 9.15 секунды для Zmap с параметрами
    -p 443 –o zmap.txt

Zmap

Достаточно известный, хотя и не первый в своем роде асинхронный сетевой сканер, появившийся в 2013 году. Согласно докладу разработчиков, опубликованному на 22 конференции USENIX Security Simposium [5] , инструмент способен просканировать весь публичный диапазон адресов, запускаемый на среднестатистическом компьютере с гигабитным подключением к сети Интернет, менее чем за 45 минут (по одному порту). В число преимуществ Zmap входят:
  • Высокая скорость работы; с использованием фреймворка PF_RING и 10-гигабитного подключения теоретическое время сканирования публичного IPv4 адресного пространства составляет 5 минут (по одному порту).
  • Поддержка случайного порядка сканирования сетевых адресов.
  • Поддержка модулей для TCP SYN-сканов, ICMP, DNS-запросов, UPnP, BACNET [6] , UDP-зондирования.
  • Присутствие в репозиториях распространенных дистрибутивов GNU/Linux (кроме того, есть поддержка Mac OS и BSD).
  • В дополнение к Zmap разработан ряд связанных проектов по утилитам, расширяющим функциональность сканера.
Если говорить о минусах Zmap, то здесь можно отметить возможность сканирования адресов только по одному порту по состоянию на данный момент.

Из связанных с Zmap проектов, расширяющих его функциональность под интересующие задачи, можно выделить следующие:ZGrab – сканер прикладных протоколов с поддержкой протоколов TTP, HTTPS, SSH, Telnet, FTP, SMTP, POP3, IMAP, Modbus, BACNET, Siemens S7 и Tridium Fox (banner grabber с расширенными возможностями).
  • ZDNS – утилита для быстрых DNS-запросов.
  • ZTag – утилита для тегирования результатов сканирования, выдаваемых ZGrab.
  • ZBrowse – утилита на базе headless-дистрибутива Chrome для отслеживания изменений содержимого веб-сайтов.
О возможностях ZGrab

Продвинутый сканер прикладных протоколов ZGrab, для которого уже вышла версия 2.0 (полного функционального паритета с версией 1.Х пока нет, однако в ближайшее время он будет достигнут, после чего можно будет говорить о полном замещении старой версии новой), позволяет достаточно гибко фильтровать результаты сканирования благодаря поддержке структурированного формата вывода (JSON). Например, для сбора только Distinguished Name Issuer’а и Subject’а из HTTPS-сертификатов достаточно простой команды:
zmap --target-port=443 --output-fields=saddr | ./zgrab2 tls -o - | jq '.ip + "|" + .data.tls.result.handshake_log.server_certificates.certificate.parsed.issuer_dn + "|" + .data.tls.result.handshake_log.server_certificates.certificate.parsed.subject_dn' > zmap-dn-443.txt

Masscan


Асинхронный сканер, созданный в том же году, что и Zmap, по командному синтаксису схожий с Nmap.

Создателем (Роберт Дэвид Грэм) была заявлена большая производительность, чем у всех существовавших на тот момент асинхронных сканеров, включая Zmap, достигнутая за счет использования кастомного TCP/IP-стека.

Преимущества сканера:

Высокая скорость работы с теоретической производительностью до 10 миллионов пакетов в секунду, что позволяет просканировать все IPv4 публичное пространство за несколько минут (по одному порту) на 10-гигабитном подключении – так же, как и у Zmap с задействованием фреймворка PF_RING.
  • Поддержка протоколов TCP, SCTP и UDP (через отправку UDP-пейлоадов от Nmap).
  • Поддержка случайного порядка сканирования сетевых адресов.
  • Поддержка выбора как диапазона IP, так и диапазона портов при сканировании.
  • Поддержка различных форматов вывода результатов сканирования (XML, grepable, JSON, бинарный, в виде списка).
При этом у сканера есть ряд недостатков:
  • В связи с использованием кастомного TCP/IP-стека рекомендуется запускать сканирование на выделенном IP во избежание конфликтов со стеком ОС.
  • По сравнению с ZGrab возможности banner grabber'а достаточно ограниченные.
Сравнительная таблица сканеров

В сводной таблице ниже представлено сравнение функциональных возможностей рассмотренных сканеров.

Значения в строках таблицы

"++" – очень хорошо реализовано
"+" – реализовано
"±" – реализовано с ограничениями
"-" – не реализовано



Выбор целей и способа сканирования


После выбора используемого инструментария нужно определиться с объектом и целью сканирования, то есть понять, что и для чего сканировать. Если с первым, как правило, вопросов не возникает (это публичное IPv4 адресное пространство за рядом исключений), то со вторым все зависит от желаемого конечного результата. Например:
  • Для выявления узлов, подверженных той или иной уязвимости, разумно сначала пройтись по сканируемому диапазону быстрым инструментом (Zmap, Masscan), чтобы определить узлы с открытыми портами уязвимых служб; после финализации перечня адресов стоит использовать Nmap с соответствующим NSE-скриптом, если таковой существует, или создать кастомный скрипт на основе доступной информации об уязвимости в публикациях исследователей безопасности. Иногда бывает достаточно простого grep'а по собранным прикладным баннерам, ведь многие службы выводят информацию о своей версии в нем.
  • Для выявления узлов сокрытой инфраструктуры – как анонимных сетей, так и C2-узлов (то есть управляющих серверов ботнет-сетей) – потребуется составление кастомных пейлоадов / зондов.
  • Для решения широкого круга задач по выявлению скомпрометированных узлов, частей инфраструктуры анонимных сетей и прочего достаточно много может дать сбор и парсинг сертификатов при TLS-рукопожатии
Выбор инфраструктуры

Тот факт, что современные быстрые сканеры могут показывать впечатляющие результаты на достаточно скромных ресурсах среднестатистического процессора, не означает, что нагрузка на сетевую инфраструктуру будет незначительной. В силу специфики трафика, создаваемого при сканировании, получается достаточно существенный рейт пакетов в секунду. По опыту одно ядро среднестатистического процессора (на CPU производства последних лет, в виртуальной среде, под любой ОС, без какого-либо тюнинга стека TCP/IP) способно генерировать поток порядка 100-150 тысяч пакетов в секунду на полосу в ~50 Мбит/с, что является серьезной нагрузкой для программных маршрутизаторов. У аппаратного сетевого оборудования также могут возникнуть проблемы при достижении лимита производительности ASIC'ов. При этом при скорости сканирования в 100-150 Kpps (тысяч пакетов в секунду) обход публичного IPv4-диапазона может занять более 10 часов, т.е. достаточно существенный промежуток времени. Для действительно быстрого сканирования следует применять распределенную сеть сканирующих узлов, разделяющих сканируемый пул на части. Также обязателен случайный порядок сканирования для того, чтобы утилизация Интернет-каналов и пакетная загрузка оборудования провайдеров на «последней миле» не была существенной.

Сложности и «тонкие» моменты



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

Проблемы с производительностью и доступностью

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

Не все VPS одинаково полезны

На VPS, арендованных не у мейнстримовых хостеров, можно столкнуться с ситуацией, когда на производительных VM (по нескольку vCPU и парой гигабайт памяти) пакетные рейты Zmap и Masscan не поднимаются выше пары десятков Kpps. Чаще всего негативную роль играет сочетание устаревшего железа и неоптимальной комбинации ПО виртуальной среды. Так или иначе, по опыту автора, более или менее существенные гарантии производительности можно получить только у компаний – лидеров рынка.

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

Что ищем и как?

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

Один известный пример

В качестве примера можно взять исследование [5] 2013 года авторов Zmap, посвященное выявлению узлов TOR-сети. На момент публикации документа путем анализа цепочки сертификатов и выявления особым образом сгенерированных subject name в самоподписанных сертификатах удалось найти ~67 тысяч TOR-узлов, работающих на порту tcp/443, и ~2,9 тысяч узлов, работающих на tcp/9001. В настоящее время перечень выявляемых данным способом TOR-узлов оказывается гораздо меньше (применяется большее разнообразие портов, используются obfs-транспорты, происходит миграция на Let's Encrypt-сертификаты), что вынуждает использовать иные аналитические методы для решения подобной задачи.

Жалобы о злоупотреблении


При сканировании сети Интернет существует практически 100%-ый риск получения потока abuse-жалоб. Особенно досаждают автоматически сгенерированные abuse по паре десятков SYN-пакетов. А если сканирования повторяются на регулярной основе, может пойти поток и вручную созданных жалоб.

Кто жалуется чаще всего

Основные источники abuse (в основном автоматических) – образовательные учреждения в доменной зоне *.edu. По опыту особенно следует избегать сканирования адресов из ASN, принадлежащих Индианскому Университету (США). Также в презентациях авторов Zmap [5] и Masscan [7] можно найти несколько занимательных примеров неадекватной реакции на сетевое сканирование.

Не стоит легкомысленно относиться к этим abuse, потому что:
  • В случае получения жалоб хостер чаще всего блокирует трафик к или от арендованных виртуальных машин или даже приостанавливает их функционирование.
  • Интернет-провайдер может отключить аплинк в целях исключения рисков блокирования автономной системы.
Лучшая практика по минимизации жалоб заключается в выполнении следующих действий:
  1. Ознакомление с Terms of Service вашего интернет/хостинг-провайдера.
  2. Создание на адресах-источниках скана информационной страницы, рассказывающей о назначении сканирования; внесение соответствующих пояснений в DNS TXT-записи.
  3. Разъяснение сути сканов при получении жалоб о злоупотреблении.
  4. Ведение списка исключений из сканирования, внесение в исключения подсети обратившихся по первому требованию, приведение разъяснений по процедуре внесения в исключения на информационной странице.
  5. Проведение сканирования не дольше и не чаще, чем это требуется для решения поставленной задачи.
  6. Распределение трафика сканирования по source, destination-адресам, а также времени, когда это возможно.
Аутсорсинг сетевого сканирования

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

Кроме упомянутых сервисов, существует достаточно большое число проектов, так или иначе связанных с глобальным сетевым сканированием. Например:
  • Punk.sh (бывший поисковик по вебу PunkSPIDER)
  • Project Sonar (датасет с результатами сетевых сканов от Rapid7)
  • Thingful (еще один поисковик по IoT)
Shodan



Первый и наиболее известный поисковый движок по опубликованным сервисам в сети Интернет, который изначально создавался как поисковик по IoT и был запущен в 2009 году Джоном Матерли [11] . На настоящий момент поисковик предлагает несколько уровней доступа к информации внутри себя. Без регистрации возможности весьма базовые, при регистрации и покупке членства становится доступна следующая функциональность:
  • Поиск по базовым фильтрам.
  • Выдача детальных сведений об узлах («raw data»).
  • «Базовый» API с возможностью по интеграции с распространенными утилитами, такими как Maltego, Metasploit, Nmap и другие.
  • Возможность экспорта результатов поиска (платно, за «Credits» – внутреннюю валюту сервиса).
  • Возможность сканирования по запросу отдельных адресов и диапазонов (платно, за «Credits»).
Упомянутых возможностей уже достаточно для базового OSINT [12] , однако полностью свои возможности поисковик раскрывает с Enterprise-подпиской, а именно:
  • Сканирование «по запросу» всего публичного IPv4-диапазона сети Интернет, включая проверку задаваемого диапазона портов и указание протокол-специфичных сборщиков баннеров.
  • Уведомления в режиме реального времени по результатам запускаемых сканирований.
  • Возможность выгрузки «сырых» результатов сканирования для дальнейшего анализа (ограничений нет, доступна вся база).
  • Возможность разработки кастомных сборщиков под специфичные задачи (нестандартные протоколы и т.п.).
  • Доступ к историческим результатам сканирования (до октября 2015).
В рамках проекта Shodan был создан ряд связанных проектов, таких как malware-hunter, honeypot scan, exploits, обогащающих результаты сканирования.

Censys



Поисковый движок по IoT и не только, созданный автором Zmap Закиром Дурумериком и публично представленный в 2015 году. Поисковик использует технологии Zmap и ряда связанных с ним проектов (ZGrab и ZTag). Без регистрации, в отличие от Shodan, поисковик ограничен 5 запросами в сутки с одного IP. После регистрации возможности использования расширяются: появляется API, увеличивается поисковая выдача по запросам (до 1000 результатов), однако наиболее полный доступ, включающий в себя выгрузку исторических данных, становится доступным только на Enterprise-плане.

К преимуществам поисковика над Shodan можно отнести следующие возможности:
  • Нет ограничений по поисковым фильтрам на базовых тарифных планах.
  • Большая скорость обновления результатов автоматического сканирования (ежесуточно, по заверениям авторов; скорость Shodan существенно ниже).
В число недостатков входят:
  • Меньшее число сканируемых портов по сравнению с Shodan.
  • Отсутствие возможности сканирования «по запросу» (как по IP-диапазонам, так и по портам).
  • Меньшая глубина обогащения результатов средствами «из коробки» (что очевидно, учитывая большее число инструментов Shodan, реализованных через связанные проекты).
Если для достижения поставленной цели достаточно результатов, собираемых на поддерживаемом Censys диапазоне портов, то отсутствие возможности сканирования по запросу не должно стать серьезным препятствием ввиду высокой скорости обновления результатов сканирования.

ZoomEye



IoT-поисковик, созданный китайской ИБ-компанией Knowsec Inc в 2013 году. На сегодняшний день поисковик работает с использованием собственных разработок – Xmap (хостовый сканер) и Wmap (веб-сканер). Поисковиком собирается информация по достаточно широкому диапазону портов, при поиске возможна категоризация по большому числу критериев (порты, сервисы, ОС, приложения) с детализацией по каждому хосту (содержимое прикладных баннеров). В результатах поиска выводится перечень возможных уязвимостей для идентифицированного прикладного ПО из родственного проекта SeeBug (без проверки на применимость). Для зарегистрированных аккаунтов также доступен API и веб-поиск с полным набором фильтров, но с ограничением по числу выводимых результатов. Для снятия ограничений предлагается приобретение Enterprise-плана. Из плюсов поисковика можно отметить:
  • Большое число сканируемых портов (примерно аналогично Shodan).
  • Расширенная поддержка веба.
  • Идентификатор прикладного ПО и ОС.
К числу недостатков можно отнести:
  • Медленный интервал обновления результатов сканирования.
  • Отсутствие возможности сканирования по запросу.
  • Обогащение результатов сканирования ограничивается идентификацией сервисов, прикладного ПО, ОС и потенциальных уязвимостей.
Сравнительная таблица сервисов

В сводной таблице ниже представлено сравнение функциональных возможностей рассмотренных сервисов.

Значения в строках таблицы

"++" – очень хорошо реализовано
"+" – реализовано
"±" – реализовано с ограничениями
"-" – не реализовано



Сканируем сами себя

Собственная инфраструктура также может быть полезным источником TI, чтобы можно было понять, какие новые хосты и сервисы появились в сети, являются ли они уязвимыми или даже вредоносными? Если для сканирования периметра возможно задействование внешних сервисов (например, такой сценарий использования является официально поддерживаемым юзкейсом Shodan), то все действия внутри периметра возможно проводить только самостоятельно. Круг инструментов для сетевого анализа в этом случае может быть достаточно обширным: это как пассивные анализаторы, такие как Bro [13] , Argus [14] , Nfdump [15] , p0f [16] , так и активные сканеры – Nmap, Zmap, Masscan и их коммерческие конкуренты. А помочь в интерпретации собранных результатов может фреймворк IVRE [17] , позволяющий получить свой собственный Shodan/Censys подобный инструмент.



Фреймворк разработан группой ИБ-исследователей, один из авторов – активный разработчик утилиты scapy [18] Пьер Лалет [19] . В число возможностей фреймворка входят:
  • Применение средств визуальной аналитики для выявления паттернов и аномальных отклонений.
  • Продвинутый поисковый движок c детальным парсингом результатов сканирования.
  • Интеграция со сторонними утилитами через API с поддержкой Python.
Также хорошо IVRE подходит и для анализа больших сканов сети Интернет.

Выводы

Сканирование и активная сетевая разведка – это отличные инструменты, которые уже давно используются различными исследователями в области ИБ. Однако для «классических» безопасников подобные методы работы пока еще в новинку. Применение OSINT и offensive-методов в сочетании с классическими defensive-средствами поможет значительно усилить защиту и обеспечить ее проактивность.

Ссылки

[0] https://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html
[1] https://malware-hunter.shodan.io/
[2] https://nmap.org
[3] https://zmap.io
[4] https://github.com/robertdavidgraham/masscan
[5] https://zmap.io/paper.pdf
[6] https://en.wikipedia.org/wiki/BACnet
[7] https://www.defcon.org/images/defcon-22/dc-22-presentations/Graham-McMillan-Tentler/DEFCON-22-Graham-McMillan-Tentler-Masscaning-the-Internet.pdf
[8] https://shodan.io
[9] https://censys.io
[10] https://www.zoomeye.org
[11] https://twitter.com/achillean
[12] https://en.wikipedia.org/wiki/Open-source_intelligence
[13] https://www.bro.org/
[14] http://qosient.com/argus/
[15] http://nfdump.sourceforge.net/
[16] http://lcamtuf.coredump.cx/p0f/
[17] https://github.com/cea-sec/ivre
[18] https://scapy.net/
[19] https://github.com/p-l-

Михаил Ларин, эксперт Центра мониторинга и реагирования на инциденты ИБ Jet CSIRT, «Инфосистемы Джет».

Оригинал статьи