Внешние угрозы информационной безопасности, как правило, ассоциируются с хакерскими атаками на сетевой периметр, включая сложные целевые атаки на крупные компании и государственные структуры (APT). Недавний пример — взлом Equation Group с последующей публикацией части их инструментария по преодолению сетевого периметра. Как оказалось, многие эксплойты из этого набора использовали давно известные уязвимости, хотя «вишенкой на торте» был 0-Day для SNMP-сервисов (аббревиатура от “Security Not My Problem”). К сожалению, у нас нет полного набора слитых эксплойтов, чтобы целиком оценить масштаб бедствия. Однако мы можем использовать подход от обратного – оценить степень защищенности корпоративных периметров на основе реальной статистики их уязвимостей.
Одно из таких исследований было представлено на конференции PHDays VI в нашем традиционном сборнике Positive Research 2016. В выборку вошло порядка 10.000 доступных адресов и 15.000 уязвимостей, период исследования – два года (2014-2015). Однако надо уточнить, что исследование проводилось только для сетевых периметров с уровнем безопасности выше среднего: то есть рассматривались только компании, где налажены процессы инвентаризации активов и управления уязвимостями (что собственно и позволяет собирать статистику).
Начнем с самой острой темы в опубликованном эксплойт-паке: SNMP 0-Day. Актуальна ли эта угроза? Наше исследование показывает, что да. Вот несколько причин такой ситуации:
- Анализ с использованием honeypot-систем показывает, что сервисы SNMP очень популярны у потенциальных злоумышленников – про доступность этих сервисов уже знает широкий круг хакеров. А кто ещё не знает, без сложностей могут узнать через Shodan.
- SNMP-сервисов очень много, они доступны на большинстве современных сетевых инфраструктур. В частности, мы уже рассказывали, что эксплуатация уязвимостей SNMP позволяет проникнуть в технологические сети операторов связи.
- Многие SNMP-сервисы работают на устаревших версиях ПО. Согласно нашему исследованию, в категории DNS, NTP и SNMP-сервисов каждый десятый — уязвим:
Исходя из этой статистики, можно однозначно оценить опубликованный эксплойт: он очень опасен и может быть использован для преодоления сетевого периметра многих организаций.
Однако остается другой интересный вопрос. Почему в инструментарии Equation Group, который громко назван «полным государственным набором кибероружия», оказалось множество эксплойтов для старых уязвимостей, включая такие, для которых обновления безопасности выпущены более 5 лет назад? Казалось бы, такая крутая хакерская группировка должна активнее использовать новые, неизвестные уязвимости.
Ответ парадоксально прост, если правильно переформулировать вопрос: а зачем хакерским группам тратить свое драгоценное время на 0-Days, если значительная часть систем, доступных через Интернет, не обновлялась годами?
Наше исследование показало, что три четверти всех обнаруженных уязвимостей — старше одного года, 30% уязвимостей — старше 5 лет, а практически каждая десятая уязвимость могла быть исправлена 10 лет тому назад. За исследуемый временной интервал уязвимости были обнаружены на 37% систем.
По клику картинка откроется в полном размере
Таким образом, для успешного проведения атаки нет необходимости в использовании новейших уязвимостей: старые отлично подойдут. Они дешевле, да и хакерской группе раскрыть информацию о эксплуатации старой уязвимости — менее критично, чем “засветить” 0-Day.
Но пока мы рассмотрели только ситуацию с эксплойтами в закрытом инструментарии. А подойдут ли эксплойты от старых уязвимостей из открытых источников, скажем, из MSF? Для ответа на этот вопрос мы выбрали уязвимости со значениями CVSS “High”, доступные на начало периода исследования в тестируемых системах, и сопоставили их с известными эксплойт-паками.
Из этой статистики видно, что на периметрах исследованных компаний встречаются уязвимости, эксплуатация которых вполне возможна с помощью публичных эксплойтов. Однако эта выборка содержит весьма небольшой набор уязвимостей. Действительно ли это означает, что их мало? Как мы говорили ранее, выборка по уязвимостям на предыдущей картинке была сделана только на начальный период исследования, а уровень защищенности периметра никогда не остается одинаковым. Динамику изменений за два года наглядно показывают следующие графики:
По клику картинка откроется в полном размере
Итак, резюме: для преодоления периметров, уровень защищенности которых оценивается выше среднего, не требуется каких-то эксплойтов из закрытых источников, и тем более тайных знаний APT-групп по использованию собственных 0-Day. Достаточно стандартного инструментария.
Как защищаться
С учётом сделанных выводов, мы выделяем следующие основные направления для повышения общего уровня защищенности сетевого периметра:
- Постоянный контроль сетевого периметра компании, результатом которого должно быть оперативное обнаружение сервисов, расположенных на периметре и доступных из сети Интернет.
- Автоматизированный поиск уязвимостей в сервисах, расположенных на периметре. Результатом должно быть выявление уязвимостей и контроль их устранения.
- Устранение лишних сервисов, необходимость размещения которых на периметре не обусловлена никакой объективной необходимостью. К этим категориям сервисов могут относиться NTP, SNMP, сервисы СУБД, административные интерфейсы и другие категории потенциально опасных сервисов.
- Внедрение политики патч-менеджмента, при этом в первую следует уделить внимание системам c уязвимостями, для которых существуют эксплойты в открытом доступе, а также самым уязвимым системам. Остальные системы следует обновлять в соответствии с приоритезацией критичности систем и уязвимостей.
- Использование комплексного подхода к ИБ. Обеспечение безопасности сетевого периметра является основой обеспечения ИБ, однако периметр — не единственный вектор проникновения злоумышленника в инфраструктуру компании.
Полную версию отчета об уровне защищенности корпоративных периметров можно найти здесь
Автор: Владимир Лапшин, руководитель отдела мониторинга информационной безопасности Positive Technologies
Комментарии (9)
shanker
02.09.2016 15:53В тему SNMP на Cisco — интересующимся рекомендую почитать:
Всплеск brute-force атак направленный на легко подбираемые доступные для записи snmp community
В частности, из статьи:
IOS устройства не логируют изменение конфигурации по SNMP, что ведет к совершенно непонятным причинам проблем. Это поведение будет исправлено и по этому поводу уже заведен баг
совершенно не стоит негодовать и писать о том что держать открытой наружу snmp community может только дилетант, автор и сам в курсе. Но, уважаемые друзья, вы бы были удивлены насколько большие, важные и профессиональные люди пострадали, продалжают страдать и как их много оказалось.
cslash
02.09.2016 15:55Если только это не сарказм с иронией, то snmp все же Simple Network Management Protocol ))
для своего времени (времени возникновения) был неплохой инструмент для общения с железками. Зачем сейчас этот хлам тянут??
Может только потому что нет другого столь универсального (что тоже большой вопрос на самом деле)…
ATX250
05.09.2016 14:39Так ведь уже давно есть snmp v3 с этими вашими авторизациями, проверкой целостности данных и шифрованиями. А ещё, в тех же цисках есть замечательная команда, разрешающая SNMP только с определенных адресов (ну или ACL сделать, кому как нравится больше). Или я один такой параноик, который настроил это для локальной сети (SNMP наружу не торчит)?
ptsecurity
06.09.2016 14:43Да, SNMPv3 и доступ только с разрешённых адресов — тоже варианты. Мы про них рассказывали в прошлой публикации по этой теме:
https://habrahabr.ru/company/pt/blog/247355/
shanker
Золотое правило: «Критикуя — предлагай»
Если не рассматривать случай, когда из-за лени\незнания SNMP остался включённым — какие варианты можете предложить для тех, кому SNMP всё же нужен? Его всё же используют для решения некоторых задач. Почему ни слова про ACL? Или Вы считаете, что SNMP можно заменить чем-то другим, более безопасным? Чем тогда?
FairyCake
Одно из решений.
Т.е. следить за периметром и обновлять системы.
ptsecurity
>какие варианты можете предложить
Как верно заметили выше, в конце статьи изложены несколько полезных правил. Кроме того, в статье есть ссылка на наш разбор конкретного кейса: работа по протоколу SNMP с уязвимым сетевым оборудованием HP/H3C и Huawei. В конце этого кейса есть раздел «Как защититься» с некоторыми подробностями по защите — посмотрите:
https://habrahabr.ru/company/pt/blog/247355/
shanker
Странная позиция. Выглядит как: «мы тут часть рекомендаций дали. Но они не все, есть ещё в другой статье. Из той статьи копипастить нам лень. Хотите — сами дочитайте до конца другую статью и найдите ответы»
ptsecurity
И вам тоже большое спасибо.