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

Новости информационной безопасности




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

44045a1d4cbaec976766cd6206eee205.jpg

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

DISCLAIMER


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

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


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

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

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

946868d575b064e8f552c06fa0b8c363.png

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


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

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


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

Выбор инструмента


За годы развития информационных сетей было создано большое количество инструментов для сетевого сканирования. Среди актуального ПО можно выделить следующие сканеры:
Кратко рассмотрим основные преимущества и недостатки указанных инструментов для целей обогащения 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 входят:
Если говорить о минусах Zmap, то здесь можно отметить возможность сканирования адресов только по одному порту по состоянию на данный момент.

Из связанных с Zmap проектов, расширяющих его функциональность под интересующие задачи, можно выделить следующие:


О возможностях 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-стека.

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


При этом у сканера есть ряд недостатков:

Сравнительная таблица сканеров


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

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


253a0d74ef6cf82937472729a65f1cd0.png

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


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

Выбор инфраструктуры


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

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


a07061a458b372bd5bddbec15b9fb7a5.jpg

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

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


Как уже упоминалось ранее, массовое сетевое сканирование создает поток трафика с высоким значением 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-адресам, а также времени, когда это возможно.

Аутсорсинг сетевого сканирования


0ad0fe7bdfc413fb9e6326362bed1d9d.jpg

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

Shodan


ce6877d6b6b39cb0639d148a7992e46e.jpg

Первый и наиболее известный поисковый движок по опубликованным сервисам в сети Интернет, который изначально создавался как поисковик по IoT и был запущен в 2009 году Джоном Матерли [11]. На настоящий момент поисковик предлагает несколько уровней доступа к информации внутри себя. Без регистрации возможности весьма базовые, при регистрации и покупке членства становится доступна следующая функциональность:


Упомянутых возможностей уже достаточно для базового OSINT [12], однако полностью свои возможности поисковик раскрывает с Enterprise-подпиской, а именно:
В рамках проекта Shodan был создан ряд связанных проектов, таких как malware-hunter, honeypot scan, exploits, обогащающих результаты сканирования.

Censys


29b24e4efeb65eb7c9d22fee64baa3e8.jpg

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

К преимуществам поисковика над Shodan можно отнести следующие возможности:


В число недостатков входят:
Если для достижения поставленной цели достаточно результатов, собираемых на поддерживаемом Censys диапазоне портов, то отсутствие возможности сканирования по запросу не должно стать серьезным препятствием ввиду высокой скорости обновления результатов сканирования.

ZoomEye


b0a9c446b5585b1256f1f707c2bdd40a.jpg

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


К числу недостатков можно отнести:

Сравнительная таблица сервисов


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

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


1fd028d5843b449c8820b81d3f5d620f.png

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


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

f32ab2cc38acf9802402815b460574d0.jpg

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


Также хорошо IVRE подходит и для анализа больших сканов сети Интернет.

Выводы


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

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

Дата: 2018-10-11 10:51:33

Источник: https://habr.com/post/426025/

информационная безопасность,блог компании инфосистемы джет,nmap,zmap,masscan,shodan,censys,zoomeye,ivre,сетевое сканирование