Сравнение систем класса External Attack Surface Management

Сравнение систем класса External Attack Surface Management

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

image

Введение

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

С ростом количества таких ресурсов и увеличением вычислительной мощи компьютеров количество кибератак неуклонно растёт, о чем свидетельствуют некоторые цифры:

  • В мире за первый квартал 2023 года совершается на 7% больше кибератак, чем за аналогичный период 2022 года.
  • В РФ эксперты отмечают рост кибератак на 60% в первом квартале 2023 года в сравнении с 2022.
  • «Лаборатория Касперского» зафиксировала увеличение в 2 раза количества атак с применением фишинга за 2022 год по сравнению с 2021.
  • По данным «РТ-Солар» в 2022 году веб-атаки составляли примерно 11% от всех типов инцидентов, а для инцидентов с высокой долей критичности — 85%.
  • Согласно The DFIR report — 7,7% от всех способов получения злоумышленником первоначального доступа к системе составила эксплуатация уязвимостей на публичнодоступных ресурсах.

Помимо атак, связанных с эксплуатацией уязвимостей на самих ресурсах, серьезной проблемой остается наличие уязвимостей в ПО, установленном на узлах, имеющих выход в Интернет:

  • Согласно отчёту Google, в более чем половине случаев атак на облачные системы стал использоваться перебор (brute force) учетных данных, также злоумышленники при атаках на облачные системы эксплуатировали уязвимости в программном обеспечении в 36,7% случаев.
  • «Positive technologies» в отчёте за 2022 год приводит следующую статистику: «Число успешных атак, направленных на веб-ресурсы организаций, увеличилось на 56%. Если в 2021 году веб-ресурсы компаний становились объектами атак в 17% случаев, то в 2022 году доля таких инцидентов составила 22%».
  • Расследование массовых взломов 1С-Битрикс компании СайберОК показало, что злоумышленники могут годами использовать известные уязвимости для доступа к системам.

Актуальность

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

1) Неправильная конфигурация сетевого доступа и недостатки конфигурации приложений

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

К этой же категории можно отнести общедоступные страницы сайтов, содержащие конфигурационную информацию, панели для администраторов или описание API, доступ к которым должен быть ограничен.

Согласно данным «Paloalto» в 2022 году четверть проблем, связанных с общедоступными ресурсами, заключалась в открытых RDP-серверах, 17% из которых были с открытыми страницами входа для администраторов.

2) Устаревшее ПО

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

Ярким примером может служить случай, произошедший в мае 2023 года: массовый дефейс веб-ресурсов, использующих CMS «1С-Битрикс: Управление сайтом». Массовые взломы были проведены загодя, начиная с 2022 года через известные уязвимости (включая CVE-2022-27228), а целями атакующих являлись все не обновлённые версии «1С-Битрикс: Управление сайтом». Своевременное обновление данного ПО могло бы предотвратить компрометацию большей части ресурсов.

3) Новые уязвимости

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

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

Для того, чтобы упростить эту задачу, могут использоваться сервисы для управления поверхностью атаки (далее — ASM-сервисы, Attack Surface Management). Поверхность атаки, согласно определению Национального Института Стандартов и Технологий США, представляет собой совокупность точек на границе системы, системных элементов или среды, к которым злоумышленник может попытаться получить доступ, воздействовать на них или извлечь из них данные.

ASM-сервисы предоставляют результаты пользовательских запросов в виде IP-адресов, доменов, связанных с этими адресами, информацию об открытых портах и запущенных сетевых службах. Некоторые ASM-сервисы анализируют версии программного обеспечения, установленного на исследуемом хосте и предоставляют информацию о потенциальных уязвимостях.

Методология, ожидаемые результаты

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

В фокус исследования попали системы отобранные по географическому признаку: в выборку вошли представители США, Кореи, Армении и Китая: Shodan, Censys, Criminal IP, Netlas, Hunter.how.

Для сравнения применялся ряд критериев:

  • периодичность сканирования;
  • количество сканируемых портов, поддерживаемых протоколов и проб сетевых сервисов;
  • общее количество обнаруживаемых устройств и сетевых сервисов;
  • выявление ошибок конфигурации и уязвимостей, с присвоенным идентификатором CVE (Common Vulnerabilities and Exposures);
  • качественные характеристики.

Результаты исследования, проведенного экспертами CyberOK, могут помочь определиться с выбором ASM-системы для решения той или иной задачи.

1.1 Сравнение ASM по периодичности сканирования

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

Shodan сканирует весь Интернет не реже 1 раза в неделю, но дополнительно можно использовать API этого сервиса для сканирования в любой нужный момент — подробная информация об этом представлена на официальном сайте сервиса.

Для получения информации о периодичности сканирований сервиса Criminal IP были проанализированы узлы, расположенные в разных странах (РФ, США, Германия). Рассматривалась даты обновлений информации для популярных открытых портов (80, 443, 22 и т.д.).

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

Рисунок 1.

По информации с официального GITHUB-репозитория сервиса, Hunter.how ежедневно сканирует все 65 535 портов пространства IPv4 и с той же периодичностью обновляет данные сканирований свыше 40 млн. сервисов.

Censys в своём сервисе сосредоточен на задачах глобального сканирования популярных портов, сканирования облачных провайдеров (таких как Amazon, Google и Azure), глобального сканирования наименее популярных портов (3455 портов на пространстве IPv4) и сканирования всех портов пространства IPv4 с низкой фоновой скоростью. Подробная информация об этом представлена на официальном сайте сервиса.

На основании полученных результатов можно сделать вывод, что наиболее высокая периодичность сканирования всего Интернета осуществляется ASM-сервисами Shodan и Hunter.how. Однако остальные ASM-системы обладают и могут предоставлять особые возможности и более специализированные результаты сканирований.

Таблица 1. Периодичность сканирования

1.2 Сравнение ASM по количеству обнаруживаемых ими устройств и сетевых сервисов

Поскольку при обработке пользовательского запроса ASM-системы не производят сканирование всей сети, а лишь выполняют поиск по сохранённым результатам, важной характеристикой является количество обнаруженных сетевых сервисов и узлов во время регулярного сканирования всего Интернета. Информация о количестве обнаруживаемых сетевых сервисах представлена в Таблице 2. В Таблице 3 представлена информация о количестве обнаруженных в РФ сетевых сервисах. В Таблице 4 представлена информация о количестве обнаруженных в РФ узлах.

Важно заметить, что в контексте этого раздела «сетевой сервис» означает запись в базе данных (БД) с результатами сканирования ASM, которую можно найти поисковым запросом. Некоторые ASM разделяют на разные записи в БД сетевые сервисы, которые доступны по разным URI (иногда даже URL), поэтому полученные значения не полностью однородны.

Анализ таблицы показывает, что по количеству обнаруженных сетевых сервисов в мире лидирует Hunter.how, а по количеству узлов — Censys. По количеству обнаруживаемых сетевых сервисов и узлов в РФ лидирует Hunter.how. Такой результат говорит о том, что вероятность найти уязвимые узлы выше при использовании именно этого сервиса.

1.3 Категории протоколов

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

  • обнаружение открытых портов;
  • определение сетевых протоколов;
  • определение программного обеспечения (ПО).

Для определения программного обеспечения системы класса ASM отправляют сетевые запросы, которые условно можно разделить на два типа:

  • стандартные запросы, соответствующие сетевому протоколу;
  • нестандартные запросы, специфичные для определённого ПО.

Из-за того, что под термином «протокол» различные системы подразумевают разные понятия, следует дать определения терминам, которые используются в рамках данной статьи:

  • Пробы протоколов — способ определения протоколов прикладного уровня модели OSI (The Open Systems Interconnection model), путём отправки соответствующего стандартного сетевого запроса.
  • Пробы сетевого сервиса — совокупность стандартных и нестандартных сетевых запросов.

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

На основании полученного результата можно сделать вывод о том, что наибольшее количество обнаруживаемых портов представлено ASM-системой Censys, а наибольшее количество проб сетевых сервисов и поддерживаемых протоколов — системой Shodan.

Большее количество поддерживаемых протоколов делает ASM-систему более гибкой, позволяет находить более критичные и менее защищённые устройства. Ярким примером служат ПЛК (Программируемые Логические Контроллеры) в системах АСУ ТП (Автоматизированные Системы Управления Технологическим Процессом): данные устройства предназначены для работы в реальном времени и, в силу того, что приоритетным для них является быстродействие и способность обрабатывать большие объемы данных, при разработке прошивок для них, механизмам защиты уделяется меньше внимание. В то же время, уязвимый ПЛК может иметь выход в Интернет, что позволяет злоумышленнику проэксплуатировать уязвимость и нарушить процесс производства. Другими примерами «ценных находок» для злоумышленника являются контроллеры управления материнскими платами или медицинское оборудование.

1.4 Определение продуктов

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

  • выбраны несколько типов ПО;
  • выбраны несколько представителей каждого типа ПО (при выборе ориентировались на то, что ПО распространено на территории РФ, список критичных уязвимостей ПО регулярно пополняется и эти уязвимости достаточно часто успешно эксплуатируются злоумышленниками);
  • для каждого выбранного ПО были сформированы запросы, позволяющие найти это ПО, используя несколько методов поиска. Текст запросов можно посмотреть в расширенной таблице.

1.4.1 Простой поиск

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

В Таблице 6 представлены продукты, а также количество уникальных записей в БД, которые нашёл каждый из сервисов. Запросы для их поиска в каждом из ASM-сервисов находятся в расширенной таблице.

Примечание:

  • В hunter.how нельзя выполнить поиск без указания полей, поэтому поиск выполнялся по полю «web.body».
  • В результатах, полученных из Censys и hunter.how, в скобках отражено количество уникальных узлов.

1.4.2 Поиск с использованием меток

ASM-сервисы для удобства пользователей могут сами отмечать некоторые сканируемые ресурсы определенными метками/тегами. Алгоритм, по которому сервисы определяют продукты, зачастую неизвестен, однако поиск с использованием таких кодовых слов способен показать более релевантные результаты.

В Таблице 7 представлены продукты, а также количество уникальных записей в БД, которые нашёл каждый из сервисов. Запросы, составленные с использованием соответствующих меток для их поиска в каждом из ASM-сервисов, можно посмотреть в расширенной таблице.

1.4.3 Углубленный поиск

Наиболее точным методом поиска является поиск по уникальным признакам ПО. Для того, чтобы получить эти признаки, необходимо проанализировать несколько результатов для разных ресурсов. В случае веб-приложений, такими признаками могут быть хэш-код файла «favicon.ico» или специфичное содержимое HTTP-заголовка. Результаты при таком поиске получаются наиболее точными и, зачастую, более полными.

В Таблице 8 представлены продукты, а также количество уникальных записей в БД, которые нашёл каждый из сервисов. Запросы, составленные с использованием некоторых специфичных признаков для их поиска в каждом из ASM-сервисов, можно посмотреть в расширенной таблице.

1.5 Обработка уязвимостей

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

1.5.1 Общая информация

В Таблице 9 представлена информация о формате обработки уязвимостей различными ASM-системами.

Рисунок 3. Инфографика системы Shodan для поля vuln

Рисунок 4. Инфографика системы Shodan для поля vuln.verified

Рисунок 5. Инфографика системы Netlas для поля cve.name

1.5.2 Насколько «врут» ASM’ы

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

Из всех уязвимостей, отмечаемых системой Shodan как vuln_verified=True, были выбраны критичные, активно эксплуатируемые в последние несколько лет и определяемые на узлах в РФ. В качестве одного из источников таких уязвимостей был выбран ресурс CISA (Cybersecurity & Infrastructure Security Agency) «Known Exploited Vulnerabilities Catalog». Для того, чтобы проверить является ли узел действительно уязвимым, использовались активные сетевые проверки, которые не оказывают вредоносного воздействия, но, при этом, определяют уязвимость с высокой степенью достоверности.

Для каждой такой уязвимости в Shodan были выполнены запросы типа «country:RU vuln:{CVE-….-….} vuln_verified=True». Для результатов, которые вернул сервис, запускалась соответствующая активная проверка. После этого подсчитывалось количество результатов до её запуска и после. Результаты представлены в Таблице 10.

Для Netlas проводился аналогичный эксперимент.

В CriminalIP информация об уязвимостях сетевого сервиса отражается в поле vulnerability. На момент проведения исследования, ни одна уязвимость из списка, подготовленного нами для этого эксперимента, не была обнаружена в поле vulnerability.

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

1.6 Сравнение предоставляемой информации

В данном разделе представлено сравнение рассматриваемых ASM-систем с точки зрения пользователя.

1.6.1 Сравнение по техническим характеристикам

В Таблице 12 представлены данные о том, какую информацию об узле предоставляют системы, какие есть возможности для группировки результатов, а также возможности API.

1.6.2 Сравнение по качеству UI/UX

В Таблице 13 представлено сравнение ASM-сервисов с точки зрения качества UI/UX. Удобство запросов оценивалось субъективно: так, у Shodan построение запроса интуитивно понятно, у CriminalIP — аналогично. У Netlas стоит отметить удобный интерфейс с возможностью поиска необходимого параметра — своего рода «конструктор» запросов. У Hunter.how можно выделить несколько бо́льшую функциональность: например, можно сделать запрос на количество открытых портов. Censys также обладает большой функциональностью: поддерживает символы «?» и «*», спец. символы «\n», «\t», возможность поиска по CPE и т.д.

1.6.3 Сравнение по качеству данных

Случайным образом были выбраны 8 различных узлов для сравнения. На каждом из них открыто несколько портов, запущено несколько сетевых сервисов. Собиралась информация о том, какие порты, продукты и домены определят ASM'ы. Достоверная информация об открытых портах собиралась с помощью утилиты nmap. Корректность определения доменов проводилась с помощью отправки прямых DNS-запросов (в качестве результата возвращается IP-адрес, связанный с соответствующим доменным именем). Если сетевой порт, сервис, технология или домен были ошибочно определены ASM, то в таблице 14 эти значения выделяются красным цветом.

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

Методика оценивания точности доменов, связанных с узлом: каждому ASM-у присваивается 16 баллов (по 2 за каждый узел); за каждый узел, для которого система нашла хотя бы один неверный домен с верным доменом второго уровня вычитается 0,5 балла; за каждый узел с хотя бы одним неверно определённым доменом второго уровня вычитается 1 балл; за каждый узел с количеством неверно определённых доменов более половины от общего числа определённых доменов у ASM-a вычитается 2 балла; для каждого узла, для которого система не определила ни одного домена, из оценки вычитается 2 балла. Итоговый балл нормируется по 5-бальной шкале. Данная методика применяется поскольку достоверно не известно точное число доменов, связанных с рассматриваемым ip-адресом, а большое количество (более половины) неверных результатов может мешать пользователю сервиса.

Пример 1. Система определила узлу домены test.abc.ru, test2.abc.ru, test3.abc.ru, при этом только первый не соответствовал ответу на прямой DNS-запрос. Тогда, поскольку остальные домены проверку прошли и abc.ru — верный домен второго уровня, для этого узла вычитается 0,5 балла.

Пример 2. Система определила узлу домены test.def.ru, test2.abc.ru, test3.abc.ru, при этом только первый не соответствовал ответу на прямой DNS-запрос. Тогда, поскольку остальные домены проверку прошли, и abc.ru — верный домен второго уровня, для этого узла вычитается 1 балл.

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

Заключение

Подводя итоги, можно сказать, что ни один из рассмотренных сервисов не превосходит остальных по всем категориям. Однако выбор ASM-a стоит основывать исходя из поставленной задачи. Одни лучше справляются с определением открытых портов и используемых на исследуемом узле продуктах. У других — более удобный API или интерфейс в веб-приложении. Кроме того, некоторые рассмотренные сервисы предлагают больше возможностей, но в рамках данной статьи проводилось сравнение одинаковой по смыслу функциональности.

Автор: Пушкин Максим, специалист направления развития экспертизы CyberOK.


Список использованных источников

  1. https://www.infosecurity-magazine.com/news/global-cyber-attacks-rise-7-q1-2023/#:~:text=Weekly%20cyber%2Dattacks%20have%20increased,of%201248%20attacks%20per%20week
  2. https://www.kommersant.ru/doc/5999865
  3. https://www.kaspersky.com/about/press-releases/2023_the-number-of-phishing-attacks-doubled-to-reach-over-500-million-in-2022
  4. https://rt-solar.ru/analytics/reports/2880/
  5. https://thedfirreport.com/2023/03/06/2022-year-in-review/
  6. https://services.google.com/fh/files/blogs/gcat_threathorizons_full_july2022.pdf
  7. https://www.ptsecurity.com/ru-ru/research/analytics/cybersecurity-threatscape-2022/#id2
  8. https://www.cyberok.ru/docs/CyberOK-bitrix_web_14.pdf
  9. https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/research/cortex_xpanse-attack-surface-threat-report
  10. https://csrc.nist.gov/glossary/term/attack_surface
  11. https://censys.com/cve-2022-2185-gitlab-server/
  12. https://help.shodan.io/the-basics/on-demand-scanning#:~:text=at%20le-ast%20once%20a%20week
  13. https://github.com/Hunter-How/Support
  14. https://support.censys.io/hc/en-us/articles/360059603231-Censys-Internet-Scanning-Intro
  15. https://support.censys.io/hc/en-us/articles/360059603231-Censys-Internet-Scanning-Intro
  16. https://netlas.io/#:~:text=based%20on%20product-,versions,-according%20to%20the
  17. https://netlas.io/#:~:text=based%20on%20product-,versions,-according%20to%20the

Наш канал горячее, чем поверхность Солнца!

5778 К? Пф! У нас градус знаний зашкаливает!

Подпишитесь и воспламените свой разум