Уязвимость (компьютерная безопасность)

Хронология уязвимости аппаратного/программного обеспечения от появления до исправления

Уязвимость (исп. vulnerabilidad) — это ошибка или недостаток в информационной системе, который может быть использован для нарушения безопасности системы.

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

Виды

Существуют различные виды уязвимостей в зависимости от их природы:

• Программные уязвимости, например:
  • SQL-инъекция
  • Переполнение буфера
  • Clickjacking
  • Гонки процессов
  • Межсайтовая подделка запроса
  • Межсайтовый скриптинг
• Аппаратные уязвимости
• Уязвимости физического окружения системы
• Ошибки персонала
• Недостатки административных, организационных и защитных процедур
• Уязвимости коммуникационной сети

Предотвращение

Лучшая политика против уязвимостей — их предотвращение на этапе разработки, минимизация количества и облегчение их обнаружения. Для этого был создан жизненный цикл безопасной разработки программного обеспечения (S-SDLC, Secure Software Development Life Cycle), который интегрирует вопросы безопасности во все этапы развития программного обеспечения. Каждый этап жизненного цикла учитывает аспекты безопасности для её максимизации.

Примеры хороших практик для получения ПО с наименьшим количеством уязвимостей:

• Содержать в актуальном состоянии инструменты разработки
• Использовать лучшие практики кодирования
• Определять требования к безопасности
• Удалять из ПО неиспользуемые модули и файлы
• Записывать все события в журнал
• Не выводить пользователю сообщения об ошибках в исходном виде
• Использовать авторизацию в дополнение к аутентификации
• Разделять данные и управляющие инструкции
• Явно проверять все данные
• Идентифицировать чувствительные данные и определять правила их обработки
• Использовать безопасные процедуры обновления
• Стандартная конфигурация должна быть безопасной
• Применять специальные тестовые инструменты для поиска уязвимостей, например:
  • Фаззеры, которые подают случайные данные и анализируют отклик системы
  • Инструменты тестирования безопасности приложений (AST — Application Security Testing):
    • На основе анализа кода (SAST — Static Application Security Testing)
    • На основе анализа выводимых данных при определённых входных данных (DAST — Dynamic Application Security Testing)
    • Инструменты анализа выполнения в реальном времени (RAST — Run-time Application Security Testing)
    • Инструменты интерактивного анализа (IAST — Interactive Application Security Testing)
    • Гибридные инструменты, сочетающие различные стратегии

Этапы жизни уязвимости

В течение жизненного цикла уязвимости можно выделить следующие ключевые этапы:

• Возникновение: на этапе разработки продукта (поставщиком, например разработчиком или сообществом) возникают различные дефекты: ошибки проектирования, реализации и управления. Некоторые из них могут представлять угрозу безопасности продукта и, соответственно, пользователя. Дефект становится уязвимостью, если его можно использовать для несанкционированного доступа, повышения привилегий, отказа в обслуживании или иного способа нарушения безопасности. Недостатки, устранённые до выхода продукта, уязвимостями не считаются.
• Обнаружение: момент, когда становится известно о существовании уязвимости. Если уязвимость заложена преднамеренно, то этапы возникновения и обнаружения совпадают. Обнаружившим считается первый человек или организация, выявившие дефект и установившие его уязвимость; если неизвестно кто это — обнаруживший анонимен.
• Сообщение об уязвимости: происходит после передачи информации о уязвимости другому лицу или организации. Передача бывает публичной (полное раскрытие) или частной (например, среди хакеров). Оригинатором (англ. originator) или раскрывателем (англ. discloser) называют того, кто информирует поставщика. Обнаруживший и раскрывающий могут не совпадать.
• Исправление: происходит, когда поставщик анализирует и устраняет уязвимость, выпуская исправленную версию.
• Публикация: расширение сведений о уязвимости для широкой аудитории.
• Автоматизация эксплуатации: разработка инструмента или скрипта (эксплойт) для автоматического использования уязвимости, что делает её доступной не только экспертам, но и новичкам (script kiddies).
• Исчезновение: число уязвимых систем становится незначительным — из-за снятия продукта с поддержки, выхода исправлений или утраты интереса.

Указанные этапы не всегда следуют строго в этом порядке. Например:

• Публикация и исправление могут совпадать, если уязвимость выявлена самим поставщиком и исправление используется для продвижения продукта.
• Эксплойт может появиться до официального исправления, такие эксплойты называются недельными, лежат в основе атак нулевого дня.
• Если уязвимость создаётся намеренно, этапы возникновения и обнаружения совпадают. Предполагается, что в некоторых системах намеренно закладывались уязвимости, известные отдельным участникам разработки (дверь черного хода, троянская программа). Примеры:
  • В 2007 году правительство США опубликовало стандарт генерации случайных чисел: один из четырёх генераторов (Dual EC DRBG, созданный АНБ) содержал дверь черного хода в виде набора секретных чисел, позволяющих предсказывать выходные значения.
  • Существуют предположения о попытках давления на PGP Corporation для встраивания тайной уязвимости, позволяющей некоторым службам (ФБР, АНБ) расшифровывать сообщения. Для сокрытия такой уязвимости предположительно было усложнено устройство кода PGP, что вызвало переход части пользователей на более старые проверяемые версии и стимулировало появление альтернативного ПО.
  • Предполагается, что FBI мог способствовать внедрению дверь черного хода в OpenBSD.

Поиск уязвимостей и мотивация их раскрытия

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

• Атакующие системы. Используют уязвимости для получения нелегальной финансовой выгоды — напрямую (например, воспользовавшись чужой кредитной картой) или косвенно (продавая украденные данные). Такие исследователи не заинтересованы в раскрытии найденных уязвимостей, чтобы те не были устранены и можно было продолжать использовать их для выгоды.
• Профессионалы ИТ и особенно специалисты по безопасности. Они на законных основаниях изучают системы, часто находят уязвимости и стремятся расскрыть их, чтобы закрепить своё авторство и получить признание. Мотивация таких специалистов:
  • Репутация. Признание первой находки уязвимости важно как для человека (повышает шансы на карьеру, доход), так и для компании (повышает привлекательность для клиентов).
  • Подрыв позиций конкурентов. Компании заинтересованы в выявлении уязвимостей в продуктах соперников, чтобы дискредитировать их и улучшить собственные позиции на рынке.
  • Стимулирование поставщиков к улучшению качества и безопасности продуктов.
  • Самореализация и удовольствие от интеллектуального вызова.
  • Получение вознаграждений от поставщиков или иных структур.

Работа с информацией об уязвимостях

Информацию об уязвимостях получают следующими основными способами:

• Исследование продуктов
• Исследование функционирования зловредных программ, использующих уязвимости
• Получение отчётов и публикаций таких сведений

Два ключевых аспекта в работе с этой информацией:

• Каналы распространения сведений (передача информации)
• Хранение и учёт всей доступной информации (управление информацией)

Передача информации

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

• Не делать ничего
• Воспользоваться уязвимостью для взлома
• Продать сведения заинтересованным лицам — отсюда берёт начало рынок уязвимостей
• Раскрыть информацию публично и широко

Первые три — это различные формы нерубликации, при которых информация не становится достоянием общественности по разным причинам. Публичное раскрытие производится по определённым политикам.

Дата раскрытия

Датой раскрытия считается момент, когда информация об уязвимости впервые появляется в открытом источнике со следующими характеристиками:

• Доступен для всех
• Публикуется независимым и надёжным источником (например, CERT/CC, Security Focus, Secunia, Microsoft Security Bulletin, USCERT, FrSIRT)
• Информация проходит экспертную оценку и содержит достаточные сведения для осознания и оценки риска

Политики раскрытия

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

В мире ИТ и не только (например, в производстве замков) существует дискуссия о допустимости публикации таких сведений.

Существуют три основных политики: не раскрывать, полное раскрытие и промежуточные формы (частичное раскрытие).

Не раскрывать

Политика неразглашения подразумевает сохранение информации в секрете. Такая стратегия приоритетно защищает пользователей от массового использования уязвимости.

Вместо абсолютной секретности возможен частичный доступ (псевдосекрет), например:

• Сообщить поставщику для быстрого исправления
• Делиться сведениями с ограниченным кругом исследователей (хакеров)
• Продать сведения на рынке уязвимостей

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

Полное раскрытие

Основная статья: Полное раскрытие

Полное или массовое раскрытие (англ. full disclosure) — это немедленная публикация всей доступной информации о проблеме безопасности для всего сообщества, включая подробности поиска, перечень уязвимых систем, способы эксплуатации, методы защиты. Такая политика позволяет быстро создать эксплойты, доступные даже неспециалистам (script kiddies).

Частичное раскрытие

Частичное раскрытие (англ. partial disclosure) — компромисс между скрытостью и полным раскрытием. Существуют различные модели и подходы, но задача универсальной политики раскрытия считается нерешённой.

Рынок уязвимостей

Около рынка уязвимостей существует развитая экономическая деятельность. Основной актив — сведения об уязвимостях. Формы бизнеса:

• Покупка/продажа информации (за деньги, услуги, рекламу, через разных посредников, иногда — в виде эксклюзивной или тиражируемой продажи, обычными и многопобедными аукционами)
• Наём исследователей для поиска уязвимостей (специализированные компании, внутренние команды)
• Продажа/подписка на продукты и сервисы: антивирус, IDS, IPS, межсетевой экран
• Поставка инструментов обнаружения или эксплуатации уязвимостей

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

Мотивация

Причины существования рынка:

• Получение финансовой выгоды (главная причина)
• Получение инструмента для защиты или нападения (например, для сетевых и кибервойн)

Участники

Участниками являются:

• Производители информации:
  • Хакеры
  • Исследователи
• Потребители:
  • Государства (сетевая война, кибервойна)
  • Разработчики, продукты которых подвергаются атакам
  • Поставщики средств защиты
  • Злоумышленники
• Посредники

Рынок уязвимостей и производители

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

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

Поэтому производители стараются ограничивать рост рынка, но зачастую вынуждены в нём участвовать (например, организовать конкурсы bug bounty).

Для раскрытия информации без оплаты они предпринимают шаги вроде:

• Упрощение связи для передачи уязвимостей (электронная почта, веб-формы)
• Быстрая реакция на сообщения, сотрудничество с исследователями
• Признание заслуг исследователей (конференции, собственные мероприятия, приглашения)
• Публичная благодарность за сотрудничество

Виды рынка

Существуют два типа рынка: легальный и нелегальный (underground). Их различие определяется законодательством конкретной страны — поэтому спорные сделки нередко происходят в странах с низким уровнем регулирования (Бразилия, Россия, Украина).

Для эффективности легального рынка нужно:

• Привлечь исследователей — для этого выплаты должны быть не ниже «чёрного рынка»; в 2006 году выплаты лицензированных компаний соответствовали трём сделкам на underground-рынке, для самих разработчиков — одной.
• Завоевать доверие исследователей (участие в конференциях вроде Blackhat, DEF CON, RootedCON)
• Завоевать признание отрасли и клиентов (заявление о защите от уязвимостей, сотрудничество в исправлении, публичное признание авторства находки)
• Развивать продукты по защите от неустранённых уязвимостей (подписки, бюллетени, а также ПО: антивирус, IDS, IPS, межсетевой экран)

Недостатки

Ключевые недостатки рынка связаны с раскрытием информации, мотивацией поиска и увеличением стоимости:

Раскрытие информации

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

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

Мотивация поиска уязвимостей

Возможность продажи повышает интерес к поиску, из-за чего растёт совокупное число неустранённых уязвимостей.

Рост цен на уязвимости

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

Примеры

Примеры бизнеса на уязвимостях:

• С самого начала существовал нелегальный рынок (black market/underground), где злоумышленники продают сведения о нераскрытых уязвимостях для взлома, кражи денег, шпионажа, шантажа, «pump and dump», нежелательного adware. Классическим примером underground-сделки была продажа уязвимости Microsoft Windows WMF rendering. На underground-рынке заказывают как отдельные атаки, так и приобретают готовые эксплойты. Контакты происходят через IRC или специальные сайты. При отсутствии публичности продукт часто продают многократно.
• TippingPoint (подразделение 3Com) — поставщик IDS; применяет политику ответственное раскрытие.
• iDefense (компания Verisign) — продаёт доступ к данным об уязвимостях и временным решениям до официального патча, также придерживается ответственной политики.
• Крупные компании проводят «Bug Bounty», выплачивая за найденные уязвимости; такие программы проводили Mozilla, Microsoft, Google, Facebook.
• Многие государства разрабатывают и используют нераскрытые уязвимости с целями защиты и нападения; в 2001 году сообщалось, что более 20 стран обладают такими возможностями.
• Wabisabi Labi предлагал торги (аукционы, эксклюзивные продажи) для сделок по уязвимостям.
• Argeniss, Immunity и GLEG Ltd — небольшие компании с собственными исследователями, продающие подписку на отчёты об уязвимостях (часто не раскрывают найденные дефекты производителям).

Управление информацией

Существует ряд инициатив для учёта сведений об уязвимостях.

Инициативы MITRE

Организация MITRE ведёт каталоги:

• CVE (Common Vulnerabilities and Exposures) — список уязвимостей с уникальным идентификатором,
• CWE (Common Weakness Enumeration) — перечень известных слабых мест,
• CAPEC (Common Attack Pattern Enumeration and Classification) — каталог образцов атак.

Все три тесно взаимосвязаны; к уязвимости приводит слабость в ПО или устройстве, которая используется определённым паттерном атаки. При добавлении новой записи могут быть дополнены связанные каталоги. Связанная инициатива — идентификатор CPE для уникального описания продуктов и платформ.

CVE

Основная статья: Common Vulnerabilities and Exposures

MITRE CVE List (англ. CVE) — каталог, где каждой уязвимости присваивается уникальный идентификатор (CVE-ID). Эта система используется как индустриальный стандарт и другими базами уязвимостей. Помимо идентификатора обычно даётся описание, перечень затронутых версий ПО, возможные решения и способы временного смягчения.

CWE

CWE (Common Weakness Enumeration) — каталог распространённых уязвимостей ПО и устройств, которые могут привести к уязвимости (например, SQL-инъекция (CWE-89), переполнение буфера (CWE-120)). Используется инструментами безопасности для автоматической проверки, а также при анализе, исправлении и предотвращении дефектов. Для каждой слабости даётся CWE-ID и описание.

CAPEC

CAPEC (Common Attack Pattern Enumeration and Classification) — каталог шаблонов атак, описание методов, схем классификации. Пример: паттерн «Эксплуатация доверия клиента» (CAPEC-22) описывает атаку на доверие между клиентом и сервером с использованием аутентификации и контроля целостности. Каждому шаблону присваивается CAPEC-ID, указываются описание, способы смягчения и необходимые ресурсы.

CPE

CPE (Common Platform Enumeration) — формат уникального описания систем, продуктов и платформ, с точным указанием версий, редакций и языков. Используется для чёткого указания затронутых версий продукта.

Пример для Microsoft Internet Explorer 8.* SP? (любая редакция и язык):

wfn:[part="a",vendor="microsoft",product="internet_explorer", version="8.*",update="sp?",edition=NA,language=ANY]

Оценка уязвимостей

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

CVSS

CVSS (Common Vulnerability Scoring System) — открытый стандарт оценки тяжести уязвимостей, разработанный FIRST. Использует шкалу от 1 до 10 и набор публичных метрик (воздействие, эксплуатация, сложность атаки). Эта система применяется NVD и CVE.

CWSS

CWSS (Common Weakness Scoring System) — разработан MITRE и поддерживается правительством США как развитие CVSS. Система учитывает критичность бизнес-процессов, потенциальный контроль злоумышленника (чтение/запись/удаление данных). Используется преимущественно разработчиками ПО для приоритизации во время анализа кода.

На практике ни одна публичная большая база не использует CWSS; в последние годы его распространение сокращается.

Базы данных уязвимостей

Кроме CVE от MITRE, выполняющей функцию идентификатора, существуют и другие базы данных:

• Национальная база данных уязвимостей (NVD, National Vulnerability Database) — база NIST. Использует SCAP и CVSS.
• Vulners Vulnerability Assessment Platform — агрегатор соотнесённых уязвимостей и эксплойтов, поддерживает более 70 источников.
• VulDB — база данных уязвимостей
• CVE Details — агрегатор сведений по CVE
• Vulnerability Notes Database (VND) — база CERT/CC, Университет Карнеги-Меллона
• WPScan Vulnerability Database — база уязвимостей, связанных с WordPress.

Поисковые системы уязвимостей

Возрастающий объём и разнообразие баз стимулировало развитие программных инструментов, автоматизирующих поиск уязвимостей в открытых источниках (часто также ищут и эксплойты). Примеры: Pompem, vFeed, vulnerability-alerter.

Другой подход — загрузка объёмов информации и локальный анализ (например, cve-search).

Известные случаи

Множество секторов, включая здравоохранение, банки и даже правительство США, подвергались крупным инцидентам вследствие сбоев безопасности из-за уязвимостей.

Примеры:

• В июне 2005 года сервер обработки кредитных карт был взломан благодаря ошибке проверки кода, чем нанесён ущерб в 10 000 000 долларов США.
• ФБР пострадало в результате атаки с использованием уязвимого открытого порта на веб-сервере, через который злоумышленник получил учётные данные и другую важную информацию.
• В Windows 98 некоторые пароли можно было прочитать из папок через MS-DOS.

См. также

• Downfall
• Lazy FPU
• Ripple20
• XARA
• Межпротокольная эксплуатация
• Неуправляемая строка формата
• Предварительный захват аккаунта
• Уязвимость Misfortune Cookie

Примечания

Литература

• Andrew Cencini и др., Software Vulnerabilities: Full-, Responsible-, and Non-Disclosure, декабрь 2005.
• Stephen A. Sheperd, Vulnerability Disclosure. How do we define Responsible Disclosure? SANS Institute, апрель 2003.
• Jaziar Radianti и др., Toward a Dynamic Modeling of the Vulnerability Black Market. Faculty of Engineering and Science, Agder University. Октябрь 2006.
• George K. Kostopoulos, Cyberspace and Cybersecurity. CRC Press. 2013.
• Michael Sutton, Frank Nagle, Emerging Economic Models for Vulnerability Research. Proceedings of the Workshop on the Economics of Information Security. 2006.

Ссылки

• CVE: Каталог известных уязвимостей. На англ. языке.
• Vigilance vulnerabilities: Техническая информация об уязвимостях и описания решений (англ.).
• Secuser.com: Французский портал о безопасности ИТ.
• info.corroy.org: Обзорная информация о командах ИБ.
• Netcraft
• NIST SAMAT: Метрика качества ПО и инструмент анализа качества.
• Microsoft: Центр реагирования Microsoft на угрозы безопасности.