Что такое ошибка нулевого дня

Оглавление

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 на инцидент с использованием уязвимостей «нулевого дня».

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

Уязвимость нулевого дня (0day, zero day) — термин, который используется для обозначения не выявленных на стадии тестирования угроз безопасности, уязвимостей, брешей в программном коде, против которых не существует защиты. Изначально они не известны никому: разработчики, антивирусные компании, пользователи не подозревают об их существовании. Об уязвимости нулевого дня становится известно до того, как производитель выпускает обновления; следовательно, у разработчиков есть 0 дней, чтобы устранить изъян. Устройства, на которых установлена уязвимая программа, находятся в зоне риска, а пользователи не имеют возможности защититься.

Обнаружение и распознавание уязвимостей

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

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

Для обнаружения уязвимостей злоумышленники используют различные методы:

• дизассемблирование кода программы и поиск опасных ошибок в коде программного обеспечения;
• fuzz-тестирование или «стресс-тест» для ПО (программное обеспечение обрабатывает большой объем информации, которая содержит заведомо ложные настройки);
• реверс-инжиниринг и поиск уязвимостей в алгоритмах работы ПО.

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

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

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

Защита от уязвимостей нулевого дня и их устранение

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

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

• Sandboxing (песочницу);
• анализ поведения;
• эмуляцию кода;
• эвристический анализ;
• виртуализацию рабочего окружения.

Мир уязвимостей

Здравствуйте, уважаемые Хабраюзеры. Предлагаю вашему вниманию мой вольный перевод довольно интересной статьи, опубликованной Pierluigi Paganini в Infosec Institute (конец 2012 г., однако она нисколько не потеряла своей актуальности и сегодня), посвященной состоянию дел в мире 0day и 1day уязвимостей. Статья не претендует на глубокий технический анализ или оценку этого рынка, а всего лишь делает «краткий» экскурс в этой области, но я думаю, она будет интересна многим. Прошу под кат.

Введение

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

0day уязвимости

В огромном мире уязвимостей, 0day уязвимости это настоящий кошмар для специалистов по безопасности. После любой утечки информации об ошибках и уязвимостях становится невозможным предсказать, где и когда они будут использованы. Это качество делает их идеальным инструментом для разработки кибероружия и правительственных атак. Интерес в поиске неизвестных уязвимостей для распространённых приложений полностью изменил роль хакеров. В прошлом это были люди, которые держались подальше от государства, сегодня индустрия и даже разведывательные агентства запустили полномасштабную кампанию по вербовке кадров в этой сфере.
Прибыль же от уязвимостей может быть получена по разным каналам, начиная от разработчика скомпрометированного приложения, заканчивая правительственными организациями, заинтересованными в уязвимости для проведения кибератак против враждебных государств, уязвимость также может быть продана на чёрном рынке.
Вокруг этой концепции вырос целый рынок в рамках которого скорость любой транзакции является основополагающим фактором. Как только найдена новая ошибка, и существует возможность её эксплуатации, разработчик должен быстро определить потенциальных покупателей, связаться с ними, чтобы договориться о цене и завершить сделку.
Знаменитый эксперт по безопасности Чарли Миллер описал этот рынок в своей статье: “The Legitimate Vulnerability Market: The Secretive World of 0-Day Exploit Sales”, осветив несколько ключевых вопросов:

• Сложность поиска покупателя и продавца;
• Проверка надежности покупателя;
• Сложность демонстрации работоспособности 0day эксплойта без разглашения информации о нём;
• Обеспечение эксклюзивности прав.

Принципиальная проблема для хакера, которому нужно продать уязвимость, заключается в его ловкости сделать это без разглашения слишком большого объема информации о ней. Процесс продажи очень сложен, потому что покупатель хочет убедиться в эффективности эксплойта и теоретически может попросить демонстрацию его наличия. Единственный способ доказать достоверность информации это полностью раскрыть её или продемонстрировать её в каком — то другом виде. Очевидно, раскрытие информации до продажи нежелательно, так как исследователь подвергается риску потерять свою интеллектуальную собственность без компенсаций.
Чтобы удовлетворить эти потребности родились профессиональные брокеры по продаже 0day эксплойтов, которые обеспечивают анонимность каждой из сторон в обмен на комиссию и проводят сделки между покупателями и продавцами.
Третья сторона гарантирует корректную оплату продавцу и конфиденциальность информации об уязвимости. Со стороны покупателя они проверяют информацию, предоставляемую продавцом. Доверенная третья сторона играет важную роль в этих сделках, так как этот рынок крайне нестабильный и характеризуется быстрой динамикой. Одна из наиболее известных фигур на этом рынке Grugq, также в качестве посредников могут выступать и небольшие компании, такие как: Vupen, Netragard, а также оборонный подрядчик Northrop Grumman.
Основатель Netragard Адриэль Дезатоля рассказал журналу Forbes, что он работает на рынке продажи эксплойтов в течение 10 лет, и он наблюдал быстрое изменение рынка, который буквально «взорвался» всего лишь в прошлом году (2011 – прим. переводчика). Адриель говорит, что сейчас есть много покупателей с большими деньгами и что время покупки снизилось с месяца до недель и что он приближается к продаже 12 – 14 0day эксплойтов каждый месяц в сравнении с 4-6 несколькими годами ранее.

Контрмеры и значение быстрого реагирования

Жизненный цикл 0day уязвимости состоит из следующих фаз:

• Уязвимость анонсирована;
• Эксплойт выпущен в открытый доступ;
• Уязвимость обнаружена разработчиком;
• Уязвимость раскрыта публично;
• Обновлены антивирусные сигнатуры;
• Выпущен патч;
• Развертывание патча завершено.

Рисунок 1. Жизненный цикл 0day уязвимости

Факт обнаружения уязвимости нулевого дня требует срочного реагирования. Период между эксплуатацией уязвимости и выпуском патча является решающим фактором для управления безопасностью программного обеспечения. Исследователи Лейла Бильге и Тудор Думитраш из Symanter Research Lab представили своё исследование под названием: “Before We Knew It … An Empirical Study of Zero-Day Attacks In The Real World“ в котором они объяснили, как знание такого типа уязвимостей даёт возможность правительству, хакерам или киберпреступникам взламывать любую цель, оставаясь при этом незамеченными. Исследование показало, что типичная 0day атака имеет среднюю продолжительность в 312 дней и как показано на рисунке 2, публикация информации об эксплойте в свободном доступе повышает число атак в 5 раз.

Рисунок 2 Число атак в зависимости от времени публикации 0day.

Публикация уязвимости порождает серию кибератак, в рамках которых злоумышленники пытаются извлечь выгоду из знания о ней и задержки в выпуске патча. Эти противоправные действия не имеют конкретного происхождения, что делает их сложными для предотвращения. Группы киберпреступников, хактивисты и кибертеррористы могут воспользоваться уязвимостью в различных секторах экономики, и ущерб от их деятельности зависит от контекста, в рамках которого они действуют. Убеждение в том, что уязвимости нулевого дня редко встречаются ошибочно, они встречаются так же, с одним лишь фундаментальным отличием в том, что информация о них не публикуется. Исследования выявили тревожную тенденцию: 60% ошибок идентифицируются как неизвестные и данные подтверждают, что существует гораздо больше 0day уязвимостей, чем прогнозировалось, плюс среднее время жизненного цикла 0day уязвимости может быть недооценено.
Один из самых обсуждаемых вопросов, как реагировать на публикацию 0day уязвимости. Многие эксперты убеждены, что необходимо немедленно раскрывать информацию о ней при этом, забывая, что это обычно является основной причиной для эскалации кибератак, эксплуатирующих эту ошибку. Вторая точка зрения предполагает хранить информацию об уязвимости в секрете, сообщая только компании, которая разработала скомпрометированное приложение. В этом случае, существует возможность контролировать всплеск атак после разглашения информации об уязвимости. Однако существует риск, что компания не сможет справиться с этим и выпустит подходящий патч для ошибки лишь через несколько месяцев после случившегося.

Не только 0day

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

Рисунок 3 – Окно реагирования

От обнаружения к миллионному рынку

Как создать утилиту для эксплуатации уязвимости после её анонса? Процедура проста в сравнении с поиском 0day уязвимостей. После выпуска патча, исследователи и преступники могут определить конкретную уязвимость, используя методику двоичного сравнения (binary diffing technique). Термин «двоичное сравнение» (diff) происходит от имени консольной утилиты, которая используется для сравнения файлов, таким же образом, как и бинарные файлы до и после применения патча. Эта методика довольно эффективна и может применяться для исполняемых файлов Microsoft, потому что компания выпускает патчи регулярно, а идентифицировать код, затронутый патчем в бинарном файле для специалиста является достаточно простой задачей. Парочка самых известных фреймворков для двоичного сравнения: DarunGrim2 и Patchdiff2.
Теперь, когда мы описали 0day и 1day уязвимости, было бы полезно открыть для себя механизмы их коммерциализации. В статье, опубликованной на сайте Forbes, предлагаются цены на 0day уязвимости в продуктах популярных IT-компаний.

Рисунок 4 –Прайс на 0-day уязвимости (Forbes)

Цена на уязвимость зависит от множества факторов:

• Сложность определения уязвимости, зависимая от мер безопасности используемых в компании, которая разрабатывает приложение; чем больше времени необходимо для обнаружения, тем выше стоимость.
• Степень популярности приложения.
• Контекст эксплуатируемого приложения.
• Поставляется ли приложение по умолчанию с операционной системой ?
• Необходимость процесса аутентификации в уязвимом приложении ?
• Есть ли стандартные настройки межсетевого экрана, которые блокируют доступ к приложению ?
• Относится ли приложение к серверной или клиентской части ?
• Является ли взаимодействие с пользователем обязательным для эксплуатации уязвимости ?
• Версия атакуемого ПО. Чем позднее, тем выше прайс.
• Технические особенности: внедрение новой технологии на самом деле может привести к снижению интереса к уязвимости, которая связана с устаревшей технологией.

Trend Micro недавно опубликовало очень интересный доклад о русском underground рынке. Исследование основывалось на данных, полученных из анализа интернет-форумов и сервисов в которых участвуют русские хакеры, таких как: antichat.ru, xeka.ru и carding-cc.com. Они продемонстрировали, что существует возможность приобрести любое ПО и сервис для киберпреступников и мошенничества. В первую десятку вошло создание вредоносного кода и оказание услуг по написанию эксплойтов. Как правило, эксплойты продаются в связке, но они могут быть проданы и по отдельности или сданы в аренду на ограниченный период времени, на рисунке 5 приведены цены на них:

Рисунок 5 – Прайс лист на эксплойт-пакеты и сервисы

Выводы

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