Таинственные EASM и где они обитают. Часть 2. Как ты?
Полный текст исследования опубликован здесь.
В первой части мы рассмотрели основные возможности 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-системами.
Рисунок 2. Инфографика системы Shodan для поля vuln
Рисунок 3. Инфографика системы Shodan для поля vuln.verified
Рисунок 4. Инфографика системы Netlas для поля cve.name
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! Подписывайтесь на наш Хабр, чтобы не пропустить обновления.
Автор: Пушкин Максим, специалист направления развития экспертизы CyberOK.
