В сегодняшней статье мы поделимся результатами более чем годового проекта СайберОК, посвященного анализу защищенности периметра Рунета.
Исследование содержит в себе подробную статистику по некоторым кейсам, аналитические выводы, а также крупные инциденты и опасные уязвимости, выявленные в процессе работы. Особое внимание уделяется не только техническим, но и организационным аспектам реакции на выявленные уязвимости. Помимо этого, в статье приведены технические нюансы, с которыми мы сталкиваемся при реализации подобных масштабных проектов, а также применение таких модных словечек, как LLM, CNN и других, для автоматизации рутины и повышения эффективности работы.
Доклад «Как бы я взломал Рунет» был впервые представлен на международной научно-практической конференции РусКрипто 2024 Игорем Первушиным – руководителем направления создания базы знаний компании CyberOK.
Для того чтобы что-то взломать, надо сначала выяснить: что же оно такое?
Начнем с масштабов количества ресурсов, которые нам необходимо проверить. Мы в СайберОК собрали следующую статистику при помощи системы контроля и информирования о поверхности атак (СКИПА), а также данных других систем класса Attack Surface Management:
Для злоумышленника большая поверхность атаки – это преимущество, потому что чем больше возможностей, тем больше вероятностно, что атака будет успешной.
Далее перед нам встает следующий вопрос: как просеять все это многообразие, чтобы затратить наименьшее количество ресурсов и при этом принести как можно больше «пользы»? Как отсечь все ненужное, чтобы добраться до чего-то драгоценного?
Уже на этапе сканирования портов при помощи нашей технологии СКИПА мы столкнулись с фактом, того, что «не все ASM одинаково полезны». Так, согласно данным на 20.03.24, в Shodan и Censys порт 10050 практически отсутствует, при этом нами было найдено порядка 135 тысяч узлов. На данном порту чаще всего размещается Zabbix agent.
Рис.1 Статистика встречаемости порта 10050 в Рунете в Censys
Рис.2 Статистика встречаемости порта 10050 в Рунете в Shodan
Рис.3 Статистика встречаемости порта 10050 в Рунете в СКИПА
В ситуации, когда цифры только растут, необходимо прибегнуть к магии, которая и оптимизирует процесс сканирования, и позволяет сделать за нас большую часть работы. Расскажу о двух из множества методов, которые мы используем.
Проверка всех TCP-портов в Рунет довольна дорогая процедура как с точки зрения ресурсов, так и с точки зрения времени. Можно ли как-то оптимизировать процесс, чтобы не стучаться во все двери? На данный момент мы улучшаем свой алгоритм по сканированию IP-адресов на основании предсказания сетевых портов, которые встречаются в рассматриваемом сегменте, что позволяет проверять не все 47.5КК IP-адресов на все 65К портов, а только какую-то их часть. И это гипотеза подтверждается. Посмотрим на картинки:
Рис.4 Сравнение кривых метода с предсказанием (желтая) и полного перебора портов (синяя), которые разбиты по ASN-ам
Тут мы видим графики зависимости количества сканируемых портов и приближения к эталону. Верхняя кривая отвечает за статистику, подведенную по группе узлов, нижняя – по всем найденным IP-адресам. Можно заметить, насколько быстрее поднимается верхняя кривая. Данный факт говорит о том, что для некоторых сегментов (в данном случае ASN-ов) можно построить профиль наиболее важных для сканирования портов, которые покроют большую часть сервисов.
Для того, чтобы нам получить статистику, в идеале необходимо провести полное сканирование портов по 65535 портам, что для всего сегмента также является дорогим удовольствием.
Рис.5 Сравнение графиков сканирования всех IP-адресов сегмента (синий) и 10% IP-адресов сегмента (желтый)
На рисунке 5 показано покрытие сетевых портов и сервисов при взятии 10% IP-адресов сегмента. Можно заметить, насколько они совпадают, что подтверждает гипотезу о возможности построения профиля по некоторой части данных.
Если с сетевым сканированием все проще – это просто ресурсы машин, то с написанием правил определения программного обеспечения все сложнее – над этим трудятся наши эксперты. Одной из фаз является пассивное определение, в котором мы используем регулярные выражения. При этом процесс содержит в себе 2 подхода. Первый – использование правил, написанных экспертами, второй – правила, полученные в автоматизированном режиме. При автоматизации используется большая языковая модель, которая натренирована на ответах сервисов, как показано на рисунках 6-7-8. В результате получаем некоторую регулярку с меньшей точностью определения ПО, но при этом сильно экономим ресурсы.
Я, к примеру, никогда не слышал про Ratchet, а вы?
Рис.6 Пример полученного регулярного выражения
Рис.7 Примеры определенного программного обеспечения
Рис.8 Пример кластеризации ресурсов, на основании которого формируется регулярное выражение
Когда наконец все данные собрали и сложности преодолели, приступаем к охоте.
Мы выделили 5 тактик и техник, которые могут быть использованы злоумышленниками при планировании атак с учетом региональных особенностей, потому что не все так однозначно:
Разберем каждый из них на примерах.
Первая тактика, которая может быть нами использована – мониторинг трендовых уязвимостей. Из последнего:
Важно отметить, что помимо стандартных метрик, так как CVSS, важно учитывать и распространённость программного обеспечения. Так, к примеру, уязвимость в ConnectWise, хоть и массово разошлась в информационном поле, но практически не имела влияния на российский сегмент Интернета.
В итоге данная тактика может быть представлена режимом «ждуна», в котором добавление новых проверок в известном ПО происходит довольно быстро и иногда не требует пересканирования, что означает практически моментальный результат.
Рис.9 Ждун вместе с горожанами ожидает прихода широкополосного Интернета в Норильск. А мы ждуним классных вулнов.
Ниже приведена статистика, показывающая, что разные уязвимости оказывают разное влияние и на количество ресурсов, и на потенциальное количество затрагиваемых организаций. Можно сделать вывод, что выход новой критичной уязвимости в GitLab может быть фатален. Про то, как исправляются подобного рода системы, поговорим чуть позднее.
Рис.10 TeamCity (CVE-2024-27198)
Рис.11 GitLab (CVE-2023-5009)
Довольно лакомой целью является типовое для региона программное обеспечение. Вот несколько примеров:
Тут начинает сказываться региональная специфика. Для некоторых уязвимостей нет CVE, и соответственно начинают ломаться инструменты, завязанные на списки CVE. Например, метрика EPSS, основная суть которой заключается в цитируемости уязвимости в международном информационном поле. Для нас критичная уязвимость в 1C-Bitrix – это ужасно, а остальные о ней не слышали.
Рис.12 Уязвимость 1С-Bitrix
Рис.13 Уязвимость Trueconf (CVE-2022-46764)
Если критичность нахождения уязвимостей в 1С-Bitrix для большинства понятна, так как в мае прошлого года очень многих затронула череда взломов и последующей постэксплуатации, то с TrueConf менее прозрачная ситуация. Скорее всего, это был тот класс ПО, на который никто из злоумышленников не обращал внимание, но при этом уязвимость в нем содержалась. Ситуация усугублялась еще и тем, что данное программное обеспечение используется во множестве серьезных организаций.
Стоит также отметить, что несмотря на большое количество найденных уязвимых узлов, каждый из вендоров оперативно уведомлял своих клиентов, что сказалось на статистике устранения угроз. Об этом поговорим далее.
Дополнительным и, возможно, менее очевидным, но от этого не менее массовым, являются атаки на второстепенные ресурсы организаций, такие как веб-камеры, различные хранилища. Очень часто данные устройства практически не обновляются, в результате чего имеют очень старые уязвимости. Мы называем их CVT (Common Vulnerable Technologies).
Приведем примеры таких устройств, упорядоченных по распространённости. В некоторых также указано количество уязвимых устройств (через /):
Когда большинство распространённых низко висящих фруктов сорвано, можно переходить к поиску аномалий на ранее неизвестных портах. Рассмотрим следующие порты с аномалией:
Первая из аномалий была обнаружена, благодаря уязвимости в msmq 2023 года. В ходе сравнения результатов СКИПА с Shodan и Censys было обнаружено, что данный порт не сканируется конкурентами. Стоит отметить, что через некоторое время и они обратили внимание на этот протокол и, как следствие, на порт. Похожим примером является практически отсутствующее определение ПО TrueConf на порту 4307.
Рис.14 Статистика распространённости портов 1801 и 4307 в Shodan и Censys
Рис.15 Статистика распространённости по портам 1801 и 4307 в СКИПА
Но что же скрывается за портом 7547?
Рис.16 Статистика распространённости порта 7547 и продуктов на нем в СКИПА
Возможно, вы удивитесь (мы вот удивились), но порт 7547 является самым распространённым в Рунет. При помощи технологии СКИПА была подведена статистика не только по распространённости этого порта, но и по продуктам, которые на нем располагаются. Преимущественно они связаны с устройствами класса CPE (Customer Premises Equipment) или абонентским оборудованием. Обычно это типовые устройства, предоставляемые провайдерами, и работающие по протоколу CWMP (CPE WAN Management Protocol) (в свою очередь работает на базе HTTP и SOAP). Так как данные устройства являются типовыми, как и их настройка, то любые потенциально найденные уязвимости или мисконфигурации ставят под угрозу сотни тысяч устройств.
Если всех перечисленных выше тактик и техник показалось недостаточно, то свой взор можно обратить на сервисы, которые пользователи Интернета «пытаются» скрыть. Обычно это добавление цифры к стандартному для данного протокола или ПО порту или смена порта на нетипичный в верхнем диапазоне. Для злоумышленника обычно это красный флажок, говорящий о том, что там можно и музыку послушать, и телевизор посмотреть, и зайти туда, где вас возможно не ждут.
Рис.17 Немного примеров ресурсов, которые «пытаются» скрыть
Итак, мы проверили множество подходов, нашли огромное количество уязвимостей, но возникает опрос – что же с этим делать?
Поскольку в нашей практике встречаются различные реакции владельцев ресурсов от: «Немедленно прекратите, я обращаюсь в правоохранительные органы!» до: «Ребята, давайте взаимодействовать вместе для устранения уязвимых сервисов!», то хотелось бы поделиться теми организационными и техническими выводами, к которым мы пришли и подкрепить это статистикой.
Самым типичным случаем является волнообразное исправление программного обеспечения. На графике ниже представлена зависимость количества уязвимых сервисов от времени в продукте Fortinet (fortios). Пики – это выход новых уязвимостей, между которыми наблюдаются спады – периоды их исправления.
Рис.18 Динамика уязвимых сервисов продукта Fortinet(fortios)
Также довольно типичным поведением, которое мы можем проследить на основании продукта Atlassian Confluence, является оперативное исправление продуктов с последующей стагнацией.
Рис.19 Динамика уязвимых сервисов продукта Atlassian Confluence
Более продуктивным как с точки зрения организационных мер, так и с технических было взаимодействие по продукту 1C-Bitrix управление сайтом.
Рис.20 Динамика скомпрометированных и уязвимых сервисов продукта 1C-Bitrix
В ходе мониторинга конце мая предыдущего года была обнаружена кампания, направленная на подмену содержимого множества ресурсов однотипным контентом – это первый пик, отмеченный желтым цветом. Далее при взаимодействии с коллегами из компании 1C-Bitrix нами были обнаружены первые индикаторы компрометации, выраженные в виде размещенных на зараженных сайтах бэкдоров – это второй пик, отмеченный синим цветом. Далее в результате нашего полного сканирования было обнаружено более 8 тысяч уязвимых ресурсов (уязвимости в плагинах vote и htmleditor). Если сравнить соотношение уязвимых (зеленый график) к ресурсам с подтвержденным бэкдором (синий график), то можно оценить количество сервисов, по которым получилось отреагировать до закрепления злоумышленников. Помимо этого, велось плотное взаимодействие с хостерами для оповещения клиентов. Одним из последних возможных побуждений для самых безответственных к обновлению ресурсов было применение ТСПУ, которое дало свои плоды.
Второй пик подтвержденных бэкдоров, которые вы можете заметить – это непрекращающееся взаимодействие с вендором, который был сильно заинтересован в исправлении как можно большого количества своих клиентов.
Работа по данному продукту является показательным применением упорядоченного комплекса организационных и технических мер, который в итоге привел к успешной локализации и исправлению угрозы.
Похожим примером является взаимодействие с компанией TrueConf. На рисунке ниже изображен график зависимости количества уязвимых сервисов от времени.
Рис.21 Динамика уязвимых сервисов продукта TrueConf
В ходе взаимодействия с компанией SolidLab были собраны все уязвимые сервисы, а также потенциально уязвимые версии программного обеспечения. Далее вся информация была передана вендору и по динамике обнаружения мы заметили значительное снижение ресурсов, находящихся под угрозой.
В итоге, проведенное исследование позволяет нам сделать следующие выводы, которые наверняка все знают, но очень важно про них напомнить:
Автор: Игорь Первушин – руководитель направления создания базы знаний компании CyberOK.
Ладно, не доказали. Но мы работаем над этим