Защита периметра: старые атаки не хуже новых
Внешние угрозы информационной безопасности, как правило, ассоциируются с хакерскими атаками на сетевой периметр, включая сложные целевые атаки на крупные компании и государственные структуры (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
Комментарии (1)
shanker
2 сентября 2016 в 11:21 (комментарий был изменён)
0↑
↓
Устранение лишних сервисов, необходимость размещения которых на периметре не обусловлена никакой объективной необходимостью… SNMP…
Золотое правило: «Критикуя — предлагай»
Если не рассматривать случай, когда из-за лени\незнания SNMP остался включённым — какие варианты можете предложить для тех, кому SNMP всё же нужен? Его всё же используют для решения некоторых задач. Почему ни слова про ACL? Или Вы считаете, что SNMP можно заменить чем-то другим, более безопасным? Чем тогда?
