Уязвимости нулевого дня: как бороться с неизвестностью

Оглавление

1. Что такое уязвимость нулевого дня
2. Откуда берутся zero-day уязвимости
3. Превентивная защита
4. Профилактическая защита
5. Реагирование на эксплуатацию уязвимости нулевого дня
6. Итоги

«Дикая природа» мира информационной безопасности насыщена самыми разными «хищниками». Некоторые из них страшны, но предсказуемы и угрожают только узкой группе организаций. Другие напротив – давно изучены и надежно защищены практически всеми акторами, которые озаботились своей кибербезопасностью.

Но есть риск, к которому в равной мере может оказаться не готовой и ИБ-ориентированный «бигтех», и вчера образовавшийся стартап: это уязвимости нулевого дня.

В этой статье будут разобраны причины существования 0-day уязвимостей, степень их критичности для функционирования компаний и возможные методы защиты от эксплуатации уязвимостей нулевого дня.

Что такое уязвимость нулевого дня

Уязвимость нулевого дня – это программная или логическая уязвимость информационной системы, которая обнаружена впервые и, на момент получения сведений об этой уязвимости специалистами компании, у них нет готового решения по защите от эксплуатации этой уязвимости.

Главное «оружие» zero-day, которое отличает эту группу от других уязвимостей – это внезапность и неразбериха. На момент выявления уязвимости ИБ-специалисты и разработчики, которые защищают инфраструктуру, оказываются в условиях ограниченности данных: у них есть только отчет от исследователей, которые эту уязвимость обнаружили, и данные ИБ-систем, которые установлены внутри инфраструктуры.

Евгений Грязнов

Ведущий консультант ИБ в компании R-Vision 

Чтобы ответить на это вопрос, для начала следует определиться с терминологией. С точки зрения разработки 0-day ничем не отличается от других уязвимостей. Но особенность 0-day заключается в том, что на устранение этой уязвимости у разработчика было 0 дней. 

Это означает, что против нее еще не созданы защитные меры, а сам производитель ПО узнает об уязвимости только тогда, когда она начинает активно эксплуатироваться в системах клиентов, а в каких-то случаях и сильно позже. При этом с того момента как уязвимость стала публично известна и до момента выпуска и установки исправлений (патчей), может пройти достаточное количество времени, в течение которого 0-day будет активно использоваться злоумышленниками для проведения атак. 

Поскольку не каждая уязвимость представляет реальный риск, то обычно под 0-day понимают еще и уязвимости с высоким рейтингом CVSS (Common Vulnerability Scoring System), в частности, позволяющие удаленное выполнение кода. Для сокращения их количества компании используют техники безопасной разработки (AppSec), такие как фаззинг, статические и динамические анализаторы. Особое внимание следует обращать на своевременное обновление сторонних зависимостей и компонентов, в которых могут быть найдены 0-day. Ярким примером является известная уязвимость Log4j. 

Ситуация дополнительно осложняется тем, что «нулевой день» не обязательно совпадает с днем, когда уязвимость нашли и начали эксплуатировать злоумышленники. Может сложиться ситуация, когда «защитники» начинают работать над «закрытием уязвимости», которая уже месяцами используется хакерами.

Однако, в большинстве случаев ситуация далеко не так критична сразу по нескольким причинам. В первую очередь, потому что большинство уязвимостей zero-day детектируются и устраняются на разных этапах разработки и тестирования перед запуском сервиса.

Александр Буравцов

Директор по информационной безопасности МойОфис

Эффективным способом сокращения 0-day уязвимостей является использование принципов безопасной разработки (SSDLC), которые мы применяем в нашей компании. Такой подход значительно повышает качество наших продуктов, поскольку под контролем оказываются все этапы разработки – от планирования до выпуска релиза.

На стадии создания архитектуры продукта практики SSDLC позволяют избежать использование уязвимых архитектурных паттернов и решений. На этапе разработки обеспечивают контроль безопасности кода и сторонних библиотек с помощью специализированных автоматизированных инструментов и позволяют исправлять уязвимости еще до их включения в основную кодовую базу. В процессе получения бинарных артефактов и подготовки релиза проведение динамического анализа, фаззинга и привлечение внешних команд тестировщиков помогают выявить и устранить то, что было пропущено ранее.

В результате, выпуская продукт, мы можем гарантировать его безопасность. Конечно, ничто не обеспечивает полного исключения уязвимостей, но по нашему опыту подход SSDLC значительно сокращает число потенциальных ошибок.

SSDLC и анализ защищенности не гарантируют того, что в инфраструктуре не осталось «нулевых» уязвимостей. Но для их поиска и детекции злоумышленникам придется обладать как минимум не меньшими компетенциями в области анализа защищенности и пентеста, чем тем, кто проводил проверку и разработку. А таких хакеров очень немного, и большинство из них состоят в APT-группировках.

Вторая причина того, что каждая новая 0-day уязвимость не становится «концом света» для сервиса заключается в том, что далеко не все из них действительно критичны для функционирования инфраструктуры и напрямую ведут к реализации недопустимых событий.

И третья причина – это существование разнообразных методов детектирования и защиты, в том числе и с помощью ИБ-инструментов, которые ориентированы на анализ поведения и поиск аномалий, то есть не опираются на информацию о ранее известных уязвимостях, а ищут маркеры эксплуатации ранее не выявленных.

Дмитрий Пудов

Генеральный директор NGR Softlab

Список таких инструментов достаточно обширен — от специализированных решений до различных аналитических инструментов, которые могут помочь своевременно среагировать на попытки эксплуатации 0-day или выстроить дополнительный эшелон защиты. Вместе с тем сложно говорить о каком-то одном инструменте в контексте 0-day уязвимостей — скорее это комплекс средств, способных на разных этапах развития атаки помочь своевременно ее обнаружить и среагировать. Например, полезными могут быть системы поведенческой аналитики или deception-технологии. Не менее важным аспектом является готовность команды информационной безопасности разбирать последствия успешных атак, с целью сбора необходимых атрибутов используемых техник и последующего предотвращения их применения.

Уязвимости нулевого дня – это довольно опасное явление, которое может привести к серьезным последствиям для компании и пользователей уязвимого сервиса. Однако, важно понимать, что не выявленные уязвимости существуют абсолютно во всех сервисах и компаниях. Если осознать этот факт и планомерно готовиться к тому, что такая уязвимость будет выявлена – риски существенно снизятся.

Откуда берутся zero-day уязвимости

Как было сказано ранее, zero-day – это день, когда данные об уязвимости стали известны разработчику программного обеспечения. Поэтому так важна работа исследователей, которые анализируют поведение хакерских группировок и данные с хакерских форумов – информация о новой уязвимости может появиться там раньше, чем в публичном поле, чем ее выявят «белые» исследователи.

Александр Новиков

Руководитель службы исследований, кибераналитики и развития Группы Т1

Когда 0-day находит «черный» хакер, он не сообщает о ней разработчикам, и о существовании уязвимости специалисты не знают, а следовательно она не может быть учтена в статистике. 

Злоумышленник может написать код, позволяющий воспользоваться уязвимостью – эксплойт. Но совсем необязательно, что он воспользуется им сам – может продать в даркнете, и, может быть, в приватном канале, что максимально снижает количество знающих о наличии 0-day уязвимости. 

Кроме того, после проникновения в сеть злоумышленник может либо сразу же атаковать, либо затаиться и ждать более подходящего времени – что также может увеличить промежуток времени между обнаружением уязвимости и осведомленности о ней. 

В случаях, когда уязвимость находит «белый» хакер, он сообщает о ней разработчику, который выпускает обновление ПО, закрывающее уязвимость, и информация о ней появляется в публичном доступе. 

Если же говорить о конкретных источниках происхождения уязвимостей нулевого дня, то их два:

1. Естественный. В ходе разработки продукта специалисты допустили ошибку или не смогли спрогнозировать сценарий « нецелевой» эксплуатации того или иного элемента кода. Можно сказать, что это человеческий фактор, влияние которого может быть снижено элементами автоматизации и вовлечением большого количества компетентных специалистов, но не может быть снижено до нуля.

2. Искусственный. Сюда можно отнести любые сознательно допущенные уязвимости, появление которых может быть обусловлено корыстными целями конкретного специалиста, недобросовестной конкуренцией или вмешательством иных третьих лиц.

Александр Герасимов 

CISO Awillix 

0-day уязвимости могут быть заложены изначально некоторыми специализированными структурами для достижения своих целей (шпионаж, умная кража данных и тд), или же найдены хакерами хитрые вектора атак, которые основываются как на низкоуровневых особенностях, так и на высокоуровневых. 

Единого рецепта и лекарства от всех атак нет. Как совет — настроить инфраструктуру так, чтобы при необходимости можно было как накатить новое обновление, так и откатиться к старой, не подверженной уязвимостям, версии вашего продукта; мониторить регулярно информацию об уязвимостях и не допускать использования заведомо уязвимых версий.

Также, немаловажен и фактор технического прогресса. Взломостойкость ресурсов и сервисов, которые уже не поддерживаются производителем и не обновляются, будет падать год от года.

Исходя из причин появления уязвимостей нулевого дня можно вывести и три этапа борьбы с ними:

1. Превентивный. Вся совокупность действий по устранению уязвимостей до выхода в публичное пространство.

2. Профилактический. Комплекс проверок, тестирования и анализа на всем протяжении существования сервиса, с целью « опередить» злоумышленников в выявлении уязвимостей.

3. Реактивный. Все действия команды специалистов по реагированию и изучению выявленной уязвимости, оперативному «закрытию» и выпуску (установке) патча обновления, который решает эту проблему.

Виктор Чащин

Операционный директор компании «МУЛЬТИФАКТОР»

Не совсем корректно говорить про сокращение количества zero-day уязвимостей, потому что все найденные ошибки в самом начале и являются уязвимостями нулевого дня, поэтому нужно писать код так, как это завещают руководства по написанию безопасных приложений, тот же широко известный OWASP.

В абсолютном количестве, конечно, больше выявленных уязвимостей на счету "белых", хотя бы просто потому что их больше, и они постоянно занимаются поисками кода в своих проектах. «Черные» же чаще находят нетипичные ошибки, потому что им чаще приходится нетривиально подходить к задаче проникновения в исследуемую инфраструктуру.

На каждом этапе или уровне борьбы с эксплуатацией уязвимостей нулевого дня можно выделить свои практики и рекомендации, которые могут помочь компании как снизить риски обнаружения такой уязвимости злоумышленниками, так и эффективно отреагировать на детектирование такого события.

Превентивная защита

Превентивная защита начинается с осознания того факта, что ни один продукт в цифровой среде не безопасен в принципе. Соответственно, чем больше сервисов использует компания, тем больше потенциальных уязвимостей нулевого дня в них содержится, и тем выше риски.

Соответственно, имеет смысл пройтись «бритвой Оккама» по списку ИС и отказаться от тех, которые дублируют функции друг друга, не вызывают доверия из-за команды разработчиков (что особенно актуально в условиях геополитического кризиса) или просто не выполняют критически важных функций.

Если рассматривать эту проблему с точки зрения разработчика информационной системы или ресурса, то первейшим средством борьбы с уязвимости нулевого дня (и многими другими проблемами ИБ) становится внедрение практик безопасной разработки (SSDLC-подход).

Борис Ларин

Эксперт по кибербезопасности, «Лаборатория Касперского»

Количество 0-day уязвимостей и их возможный эффект можно уменьшить, если вести разработку, придерживаясь практик жизненного цикла разработки защищенного программного обеспечения – Secure Software Development Lifecycle (SSDLC). Одна из наиболее распространенных моделей SSDLC – это MS SDL, разработанная компанией Microsoft. 

Основными этапами этой модели являются: 

• обучение всех задействованных сотрудников основам безопасной разработки; 

• выявление возможных рисков, угроз, и методов их митигаций на этапе дизайна; 

• реализация кода согласно лучшим практикам безопасной разработки (например: запрет на использование небезопасных методов, статический анализ кода до компиляции); 

• верификация скомпилированного кода программного обеспечения (например: фаззинг, проведение пентестов); 

• подготовка плана реагирования на ранее неизвестные угрозы. 

Помимо этого, если продукт разрабатывается с нуля, у разработчиков существует возможность сделать выбор в пользу использования более современных и безопасных для памяти (Memory safe languages) языков программирования (например Rust, Go, и др.). Использование подобных языков не может защитить от всех типов уязвимостей, но спасет от наиболее распространенных уязвимостей, которым подвержены такие языки программирования как C и C++.

Сервис, который изначально создан с пониманием того, что его будут пытаться взломать, а бреши в защите неизбежно найдутся, будет изначально защищен на порядок лучше, чем тот, который создан на стандартном цикле разработки SDLC.

Профилактическая защита

Профилактическая борьба с zero-day уязвимостями частично перекликается с превентивной и заключается в трех аспектах:

• регулярное разноформатное тестирование;

• использование инструментов ИБ, которые могут помочь в выявлении атак с использованием уязвимостей нулевого дня;

• создание регламентов реагирования и их отработка.

Кирилл Романов

Менеджер по развитию бизнеса департамента информационной безопасности «Сиссофт»

Обычно разработка делится на этапы, каждый из которых заканчивается проверкой на наличие уязвимостей. Если раньше проверка производилась вручную, то сейчас за процесс отвечают специализированные программы, например PT Application Inspector. 

Когда продукт уже готов и используется в «боевом» режиме, стоит задуматься об использовании «песочницы», которая эмулирует инфраструктуру клиента. Она помогает проверить, что делает отправленный файл, пытается ли запустить что-то нехорошее. Если да, то он попадет в список блокировок и не сможет причинить вред инфраструктуре.

Разноформатное тестирование подразумевает под собой, в первую очередь, регулярный внутренний и внешний аудит безопасности, привлечение пентестеров, редтимминг и выход на программы bugbounty. 

Если говорить об инструментах кибербезопасности, которые могут помочь в защите от 0-day, то важно понимать, что для их адекватного и эффективного функционирования нужны ИБ-инструменты «первой руки», такие как межсетевые экраны, антивирус, инструменты защиты почтового трафика, анализаторы трафика и ряд других.

Иван Чернов

Менеджер по развитию UserGate (эксперт в сфере информационной безопасности):

Современный ландшафт киберугроз настолько разнообразен и динамичен, что использование одних лишь базовых средств защиты уже не является достаточным шагом к построению полностью защищенной инфраструктуры, хотя бы даже в силу существования такого фактора, как уязвимость нулевого дня. Для того, чтобы «узнать ее в лицо», ты должен быть через нее же и взломан, поэтому логично, что в моменте прикрыться щитом от вредоносной эксплуатации 0-day априори невозможно, на то она и нулевая, то есть впервые появившаяся и никем еще не описанная.

Однако существуют профилактические методы и подходы, применяя которые, можно вовремя обнаружить следы компрометации и попытки эксплуатации даже 0-day, сократить поверхность проникновения атаки и прекратить ее. Метод строится на том, чтобы скрупулезно анализировать данные, искать и находить среди них значимые события, выявлять инциденты и расследовать их, чтобы затем ответственные лица (разработчики и ИБ-шники) эту уязвимость поправили или от нее защитили.

Специально для реализации такой проактивно-превентивной концепции в UserGate разработан собственный инструмент – мониторинг событий безопасности Log Analyzer.

LogAn сочетает в себе функционал SIEM (Security Information and Event Management) и IRP (Incident Response Platform), что предоставляет возможности для сбора логов и событий, поиска инцидентов и реагирования на них.

Очень важно понимать, что SIEM – инструмент сложный. И без должного подхода к классификации знаний ощутимую пользу не даст. Однако набор несложных рекомендаций позволит начать использовать LogAn, который тоже относится к классу SIEM, используя его эффективно, с первых же дней. Мы разработали даже собственные лайфхаки, позволяющие превратить систему из сложного в очень удобный инструмент.

Применительно к zero-day, наибольшую эффективность показывают системы и инструменты, которые направлены на комплексный анализ поведения, таргетирование цепочек атаки (взаимосвязи событий) и поиск аномалий в тех или иных элементах инфраструктуры.

Также, в таких случаях особенно эффективны deception-технологии, которые направлены на то, чтобы спровоцировать злоумышленника на совершение демаскирующего действия. Эти технологии нацелены не на детекцию ВПО или хакерских техник, а на обычные человеческие слабости, которые присущи хакерам любой квалификации.

Касательно регламентов и отработки действий на киберполигонах, главное их преимущество – это развенчание непредсказуемости и неочевидности, которыми часто окружены уязвимости нулевого дня. Разумеется, смоделировать алгоритм действий под конкретную ситуацию такого рода невозможно, но отработка универсальных действий позволяет снизить риск ошибок из-за спешки или стресса.

Реагирование на эксплуатацию уязвимости нулевого дня

В рамках этого раздела критическую важность имеют три аспекта:

1. Осведомленность. Данные о найденной уязвимости 0-day просто не дойдут до компании, если ее специалисты не держат «руку на пульсе» или, хотя бы, не читают сообщения от поставщика ПО.

2. Патч-менеджмент. Важно понимать, что первое обновление от поставщика может как «закрыть» уязвимость, так и оказаться неэффективным. А может и вовсе «наплодить» несколько новых брешей или вызвать сбой в работе всего сервиса.

3. Готовность. Если специалисты имеют опыт реагирования, полученный в ходе киберучений, внятные регламенты и достаточный набор инструментов – с большой вероятностью получится минимизировать потенциальный урон.

Евгений Кравцов

Senior Frontend Developer, SberDevices

Инструменты защиты от эксплуатации уязвимостей 0-day могут включать:

— Мониторинг сети: инструменты, которые обнаруживают неожиданную активность или аномалии, которые могут указывать на попытку эксплуатации 0-day уязвимости.

— Защита от внедрения кода: инструменты, которые предотвращают внедрение нежелательного кода, например, защита от спам-инъекций и атак эксплуатации буфера.

— Защита данных: инструменты, которые защищают данные от несанкционированного доступа или изменения, например, шифрование данных.

— Антивирусы: инструменты, которые обнаруживают и блокируют вредоносное ПО, которое может быть использовано для эксплуатации 0-day уязвимостей.

Важно также помнить о том, что эксплуатация уязвимости нулевого дня, за рядом исключений, не влечет за собой реализацию недопустимого события. И, в большинстве случаев, у специалистов SOC есть время чтобы минимизировать ущерб от атаки. Хотя, разумеется, всегда возможен сценарий с эксплуатацией уязвимости высокого уровня критичности, как и произошло с Log4Shell. 

Итоги

Уязвимости нулевого дня – это не «бог из машины» и не новое явление в кибербезопасности. Они существовали всегда, и свой «страшный» окрас приобрели благодаря тому, что сервисы постоянно совершенствуются, как и уровень экспертизы кибербезопасности компаний. Поэтому хакерам приходится становиться особенно изворотливыми и искать особо не тривиальные способы проникнуть в инфраструктуру.

Вместе с тем, растет и арсенал борьбы с такого рода «черными лебедями», который пополняется не только новыми программными решениями, но и опытом специалистов в ходе предыдущих инцидентов, который позволяет снизить степень хаотичности в реагировании SOC на инцидент с использованием уязвимостей «нулевого дня».

Также, стоит сказать, что единственный надежный способ борьбы с такого рода уязвимостями – это осознание того факта, что система или сервис уязвимы ровно до тех пор, пока они функционируют, а значит и мониторинг защищенности всеми возможными способами должен быть неотъемлемой частью политики информационной безопасности компании.