Полный текст исследования опубликован здесь.
В первой части мы рассмотрели основные возможности EASM и их географическое покрытие. Далее мы сравним функции поиска и анализа информации, предоставляемые разными системами.
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-системами.
1.5.2 Насколько «врут» ASM’ы
Очевидно, что при оценке уровня защищённости узла гораздо важнее качество, а не количество. Было проведено исследование, показывающее насколько точным является определение уязвимостей в ASM-системах.
Из всех уязвимостей, отмечаемых системой Shodan как vuln_verified=True, были выбраны критичные, активно эксплуатируемые в последние несколько лет и определяемые на узлах в РФ.
В качестве одного из источников таких уязвимостей был выбран ресурс CISA (Cybersecurity & Infrastructure Security Agency) «Known Exploited Vulnerabilities Catalog». Для того, чтобы проверить является ли узел действительно уязвимым, использовались активные сетевые проверки, которые не оказывают вредоносного воздействия, но, при этом, определяют уязвимость с высокой степенью достоверности.
Для каждой такой уязвимости в Shodan были выполнены запросы типа «country:RUvuln:{CVE-….-….} vuln_verified=True». Для результатов, которые вернул сервис, запускалась соответствующая активная проверка. После этого подсчитывалось количество результатов до её запуска и после. Результаты представлены в Таблице 10.
Для Netlas проводился аналогичный эксперимент.
В Criminal IP информация об уязвимостях сетевого сервиса отражается в поле vulnerability. На момент проведения исследования, ни одна уязвимость из списка, подготовленного нами для этого эксперимента, не была обнаружена в поле vulnerability.
Таким образом можно сделать вывод, что качество выявления уязвимостей в современных ASM оставляет желать лучшего. Большое количество ложно-положительных срабатываний не позволяет сфокусироваться на устранении наиболее актуальных проблем.
Скоро увидимся в заключительной части 3! Подписывайтесь на наш Хабр, чтобы не пропустить обновления.
Пушкин Максим
Cпециалист направления развития экспертизы CyberOK
Ссылки:
