В этой статье мы хотим поделиться с вами случаями, которые происходили у наших заказчиков, и рассказать/показать/ответить на вопрос, почему управление уязвимостями – это почти всегда не про уязвимости, и простого — «мы за вас отфильтруем из 1 000 000 уязвимостей до реально важного минимума» недостаточно.
Кейс #1 «Ой, да мы сами знаем, что у нас всё плохо!»
Объект: модуль удаленного управления (IPMI), установленный на критичных серверах — более 500 шт.
Уязвимость: уровень критичности (CVSS Score) — 7.8
CVE-2013−4786 — уязвимость в протоколе IPMI, позволяющая злоумышленнику получить доступ к хэшам паролей пользователей, что приведет к несанкционированному доступу и потенциальному захвату аккаунта атакующим.
Описание кейса: о самой уязвимости заказчик знал, однако по ряду причин, описанных ниже, дальше «принятия рисков» дело не пошло.
Сложность самого кейса в том, что патчи есть далеко не для всех материнских плат, использующих данный модуль, да и обновлять прошивки на таком большом количестве серверов крайне ресурсоёмко.
Были и альтернативные способы смягчения – списки доступа (ACL) на сетевом оборудовании (очень сложно так как админы сильно распределены и пользуются IPMI откуда придётся) и отключить IPMI, тут, думаю, комментарии излишни (на всякий случай: 500 распределённых серверов регулярно управлять «ногами» ради безопасности никто не будет)
Тут обычно и заканчивается история, однако с нашей стороны был произведён дополнительный анализ уязвимости и стало ясно, что хеш пароля учётной записи возвращается сервером только в случае запроса с существующим на сервере логином, поэтому было принято решение:
1. Изменить идентификаторы учётных записей на сложно подбираемые
Безусловно, это не панацея. И если, не торопясь, чтобы не «светиться», перебирать логины, то рано или поздно его можно будет подобрать. Но скорее всего это займёт достаточно много времени, чтобы успеть реализовать дополнительные меры.
2. Изменить пароль, чтобы хеш пришлось дольше брутить
Ситуация схожая с П.1 – брутить SHA1 хеш 16-ти символьного пароля придётся бесконечно долго.
Как результат, опасная уязвимость, о которой было известно, и которая могла быть легко проэксплуатирована даже Script kiddie, была закрыта минимальными ресурсами.
Кейс #2 «Мы и без вас можем скачать OpenVAS!»
Объект: все маршрутизаторы и коммутаторы внутри компании – более 350 устройств.
Уязвимость: уровень критичности (CVSS Score) — 10.0
CVE-2018-0171 – уязвимость в функционале Cisco Smart Install, эксплуатация которой приводит к изменению конфигурации оборудования, в том числе изменению пароля и пропаже его у легального админа, то есть потере контроля над устройством. Таким образом, злоумышленник получит полный доступ к устройству.
Описание кейса: несмотря на использование нескольких сканеров, в том числе коммерческих, данную уязвимость ни один из них не показал. Возможно, сигнатуры на тот момент были далеки от идеала по данной уязвимости, или сказалась топология сети, так или иначе – прецедент. У нас, как у компании, предоставляющей эту услугу определённое время, есть своя база с реально опасными уязвимостями, которые мы дополнительно проверяем.
Заказчик не пользовался функционалом Smart Install, поэтому само решение, ввиду сложности обновления прошивки (ещё учитывая часть оборудования out-of-date), свелось к предоставлению клиенту списка IP-адресов, по которому скриптом была выключена уязвимая служба.
Как результат, критичная уязвимость на подавляющем большинстве сетевого оборудования, которая могла остаться незамеченной, и в случае атаки бы привела к полной остановке работы всей компании, была исправлена.
Кейс #3 «Если бы хотели, нас бы уже сломали!»
Объект: контроллер домена, почтовый сервер и ряд других критичных для компании устройств/серверов/хостов
Уязвимость: уровень критичности (CVSS Score) — 9.3
CVE-2017-0144 – уязвимость в протоколе SMB, позволяющая осуществить удалённое выполнение произвольного кода на сервере (через группу уязвимостей, в которую входит рассматриваемая, распространялся шифровальщик WannaCry).
Описание кейса: на старте оказания услуг при плановом сканировании была обнаружена критичная уязвимость, единственно возможная рекомендация – ставить обновления ОС. Заказчик согласовал это решение, но по итогам контрольного сканирования уязвимость оставалась. После эскалации ситуации и личной встречи с Заказчиком выяснилось, что причиной послужил человеческий фактор – задача не была выполнена специалистом.
Последствия: в течение нескольких дней в результате игнорирования задачи, на рабочую станцию пользователя попало вредоносное ПО, успешно распространяющееся по сети, была проэксплуатирована данная уязвимость, что привело к выходу из строя контроллера домена.
Как результат, компания понесла большие убытки (работы по восстановлению инфраструктуры заняли несколько месяцев).
В описанных случаях из нашей практики, мы хотели обратить внимание на то, что управление уязвимостями – сложный и не такой однозначный процесс, как может изначально показаться. Управление уязвимостями – это не только про сканеры и выявление критичных для инфраструктуры угроз, это полноценный менеджмент, требующий знаний, опыта и порой нестандартного подхода от специалистов, а также отлаженных процессов внутри компании, которые неразделимы с технической частью.
Дмитрий Головня GolovnyaD
SOC-аналитик, Акрибия