Недавний инцидент с шифровальщиком в компании Rackspace, в результате которого была выведена из строя серверная среда Microsoft Exchange, привлек внимание к часто рискованной авантюре, на которую идут команды безопасности, предпочитая применить обходные пути устранения уязвимостей вместо того, чтобы применить к исправления.
На прошлой неделе компания Rackspace сообщила, что вторжение в среду Exchange-серверов хостинговой компании 2 декабря стало результатом ее решения повременить с применением исправления для уязвимости подделки запросов на стороне сервера (SSRF) в Exchange Server ((CVE-2022-41080), которую Microsoft исправила в ноябре. Эта уязвимость в сочетании с другой ранее раскрытой уязвимостью удаленного выполнения кода (RCE) в Exchange Server - отслеживаемой как CVE-2022-41082 - дает злоумышленникам возможность получить полный контроль над затронутыми серверами.
Отложенные патчи.
По словам директора по безопасности Rackspace Карен О'Райли-Смит, компания воздержалась от применения исправления для дефекта SSRF из-за опасений, что оно может привести к ошибкам аутентификации. Вместо этого Rackspace решила применить обходные меры по устранению уязвимости, которые выпустила компания Microsoft, полагая, что это будет эффективной мерой. О'Рейли-Смит заявил, что в примечаниях Microsoft к CVE-2022-41080 говорится лишь об уязвимости повышения привилегий и ничего не говорится о том, что она является частью цепочки RCE.
Представитель Microsoft сообщил изданию Dark Reading, что на данный момент компании нечего сообщиить по поводу комментариев Rackspace, связанных с патчем для дефекта SSRF, или примечаний, сопровождающих его раскрытие.
Решение Rackspace повременить с исправлением уязвимости не является чем-то необычным, сообщает Джон Бамбенек, главный охотник за угрозами в Netenrich. «Часто обходные пути являются предпочтительными, особенно в случае высокопубличных ресурсов, где существует чувствительность к простою» - заявляет он. По его словам, чем более публичным является приложение, тем чаще организации идут на применение обходных путей устранения уязвимостей вместо обновления среды.
«В большинстве случаев это может быть хорошей ставкой, если меры по снижению риска обоснованы и полны» - отмечает Бамбенек. «Но это требует наличия действительно опытного специалиста, который может читать между строк, чтобы вынести правильное суждение».
В случае с Rackspace стратегия смягчения последствий не сработала, потому что злоумышленник - позже идентифицированный как группа шифровальщиков Play - нашел способ использовать CVE-2022-41080 для запуска дефекта CVE-2022-41082 RCE в своей среде. До этого момента исследователи безопасности наблюдали, как злоумышленники запускали дефект RCE только через другую уязвимость Exchange Server SSRF, отслеживаемую как CVE-2022-41040, в комбинации, известной как ProxyNotShell. Атака вызвала широкомасштабные перебои в обслуживании клиентов Rackspace, многие из которых относятся к малому и среднему бизнесу.
«Rackspace ввела меры защиты в связи с цепочкой ProxyNotShell, раскрытой Microsoft в конце сентября, до появления патчей, что произошло только в ноябре» - рассказал Dark Reading внешний консультант Rackspace.
Когда исправления стали доступны, Rackspace воздержалась от их применения из-за опасений по поводу сообщений о проблемах аутентификации, связанных с исправлениями, а также потому, что у компании уже были приняты соответствующие меры защиты, говорит советник.
«На тот момент не было никаких известных или раскрытых рисков удаленного выполнения кода, связанных с CVE-2022-41080, который CrowdStrike обнаружила в ходе расследования инцидента с Rackspace» - добавляет советник.
Пропуск исправлений безопасности - рискованная затея.
По словам Майка Паркина, старшего технического инженера компании Vulcan Cyber, этот инцидент подчеркивает риски, которым подвергаются организации, когда они слишком полагаются только на средства защиты от эксплуатации уязвимостей.
«Развертывание рекомендованных производителем средств защиты для известной уязвимости не должно быть концом проблемы» - говорит он. «Это то, что вы делаете до тех пор, пока соответствующий поставщик не разработает патч, и вы не сможете его установить».
По словам Паркина, единственный случай, когда можно смягчить последствия и не устанавливать патчи - это когда у поставщика еще нет исправлений для уязвимости или есть какие-то технические причины, по которым организация не может установить ее в целевой среде.
«Будут случаи, когда процедуры управления изменениями задерживают развертывание патча. Но хорошим процессом как с точки зрения управления изменениями, так и с точки зрения безопасности является внедрение патчей как можно быстрее, при этом соблюдая требования стабильности» - сообщает он, добавляя, что это особенно актуально, когда в природе существуют известные эксплойты, нацеленные на определенную уязвимость.
Патчи и устранение уязвимостей в целом остаются серьезной проблемой для организаций. Исследование, проведенное в прошлом году компанией Edgescan, специализирующейся на управлении уязвимостями, показало, что организациям по-прежнему требуется в среднем 60 дней для устранения критических уязвимостей, подобных той, которая подкосила Rackspace.
Исследование показало, что 57% обнаруженных уязвимостей в корпоративных сетях были более двух лет назад, а 17% - более пяти лет назад. Все эти уязвимости имеют действующие эксплойты в природе, и противники, включая государственные хакерские команды и киберпреступные группировки, использовали многие из них.
Сокращение времени до эксплуатации уязвимости.
Ситуация усугубляется тем, что киберпреступники стали гораздо быстрее использовать новые уязвимости, поэтому время между первоначальным раскрытием информации и появлением эксплойта стремительно сокращается.
Эта тенденция подтолкнула Агентство кибербезопасности и защиты инфраструктуры США (CISA) выпустить в ноябре 2021 года директиву, которая требует от всех федеральных гражданских ведомств устранять известные уязвимости в течение определенного - обычно двухнедельного - срока. CISA также выступает за то, чтобы все организации регулярно обращались к своему каталогу известных эксплуатируемых уязвимостей (KEV), чтобы узнать, какие уязвимости используют злоумышленники в реальной жизни, чтобы немедленно устранить их. CISA добавляет новые уязвимости в свой каталог только в том случае, если поставщик уязвимости предлагает исправление или четкие меры по устранению.
Ричард Стиенон, главный аналитик IT-Harvest, говорит, что тот факт, что многим компаниям по-прежнему требуется 60 дней для исправления критических уязвимостей, неудивителен, учитывая сложность задачи, особенно для крупных организаций. По его словам, установка патчей часто связана с запланированными простоями, которые для многих организаций, как правило, приходятся на раннее утро выходных. Задача включает в себя демонтаж всех затронутых серверов, установку патча, перезагрузку и тестирование систем перед их восстановлением.
«Представьте, что вы - крупная компания с 2 000 серверов, которым требуется срочное исправление» - говорит Стиннон. «Конечно, сначала вы примените меры по смягчению последствий. Вы не можете сделать это в тот же день».
Стиннон говорит, что внедрение облачных технологий начало менять процессы управления уязвимостями во многих организациях. В наши дни система, нуждающаяся в исправлении, может быть контейнером или виртуальной машиной. «Теперь процесс заключается в зеркальном отображении производственной системы, внесении исправлений, тестировании и загрузке обновленных экземпляров в производство без простоя».
Источник: https://www.darkreading.com
Иллюстрация: storyset/Freepik
