После публикации нашей статьи «CSRF в Umbraco CMS», мы получили несколько сообщений с вопросами, которые касались процесса получения CVE. В данной статье рассматривается, как правильно поступить в том случае, когда вендор отказывается присваивать индекс CVE найденной в его продукте уязвимости.
Работа с обнаруженными уязвимостями производится в три основных этапа:
После обнаружения уязвимости в продукте необходимо составить подробный отчет для вендора и найти контакты для обращения. Если у вендора есть контакты по вопросам безопасности продукта и публичные ключи шифрования, тогда можно сразу направить письмо, которое будет содержать зашифрованный отчет. Это оптимальный для исследователя вариант. Однако так бывает не всегда. Поэтому, если нет отдельных контактов по безопасности (и ключей шифрования), приходится начинать переписку через какие-либо общие адреса. Первым письмом необходимо сообщить о выявлении уязвимости, запросить контакты ответственных за безопасность и информацию о том, как можно отправить отчёт в защищённом виде. Впрочем, иногда представители вендора могут попросить прислать отчёт без всякого шифрования.
В каждом письме стоит указывать дедлайн, после которого состоится публичное разглашение сведений об уязвимости (не более 4 месяцев со дня первого контакта).
Это позволит опубликовать ее даже в том случае, если вендор не станет отвечать на письма (сразу или после некоторого времени).
Публичное раскрытие в каждом конкретном случае может производиться по-разному: всё зависит от критичности и масштабности найденной уязвимости. Но это выходит за рамки данной статьи.
Отчет содержит следующие разделы:
Чаще всего вендор идет на контакт и через некоторое время сообщает, в какие сроки уязвимость планируется исправить. Совместно определяется и дата публичного раскрытия, которая может отличаться от указанного ранее дедлайна. Иногда опубликовать информацию можно раньше, но в большинстве случаев вендор просит дать больше времени.
Именно на этом этапе необходимо получить идентификатор CVE, чтобы добавить его к публикации.
Рассмотрим процесс более подробно.
Идентификатор по идее должен присваивать разработчик уязвимого продукта. Но так происходит не всегда. В таких случаях исследователь сможет получить CVE самостоятельно. Для этого потребуется зайти на сайт и найти там следующую форму:
В типе запроса необходимо выбрать «Request a CVE ID» и заполнить все поля.
У MITRE отличный FAQ, который поможет с заполнением формы.
После заполнения на указанный адрес электронной почты приходит автоматический ответ, который содержит номер запроса. Его можно и нужно будет использовать в дальнейшей коммуникации:
Спустя сутки может быть получен и идентификатор CVE:
Победа! Информацию об уязвимости можно публиковать со всеми надлежащими подробностями, включая идентификатор CVE.
Задавайте вопросы и делитесь своим опытом в комментариях и в нашей группе на Facebook!
Работа с обнаруженными уязвимостями производится в три основных этапа:
- Уведомление вендора
- Подтверждение и исправление найденной уязвимости
- Публичное раскрытие информации
После обнаружения уязвимости в продукте необходимо составить подробный отчет для вендора и найти контакты для обращения. Если у вендора есть контакты по вопросам безопасности продукта и публичные ключи шифрования, тогда можно сразу направить письмо, которое будет содержать зашифрованный отчет. Это оптимальный для исследователя вариант. Однако так бывает не всегда. Поэтому, если нет отдельных контактов по безопасности (и ключей шифрования), приходится начинать переписку через какие-либо общие адреса. Первым письмом необходимо сообщить о выявлении уязвимости, запросить контакты ответственных за безопасность и информацию о том, как можно отправить отчёт в защищённом виде. Впрочем, иногда представители вендора могут попросить прислать отчёт без всякого шифрования.
В каждом письме стоит указывать дедлайн, после которого состоится публичное разглашение сведений об уязвимости (не более 4 месяцев со дня первого контакта).
Это позволит опубликовать ее даже в том случае, если вендор не станет отвечать на письма (сразу или после некоторого времени).
Публичное раскрытие в каждом конкретном случае может производиться по-разному: всё зависит от критичности и масштабности найденной уязвимости. Но это выходит за рамки данной статьи.
Отчет содержит следующие разделы:
- Заголовок (название уязвимости)
- Продукт, в котором была обнаружена уязвимость
- Версия (или версии) уязвимых продуктов
- Оценка степени угрозы по шкале CVSS (и/или просто от low до critical)
- Дата обнаружения
- Описание уязвимости
- Пример эксплуатации (Proof of Concept)
- Рекомендации для исправления
- Контактные данные исследователя
Чаще всего вендор идет на контакт и через некоторое время сообщает, в какие сроки уязвимость планируется исправить. Совместно определяется и дата публичного раскрытия, которая может отличаться от указанного ранее дедлайна. Иногда опубликовать информацию можно раньше, но в большинстве случаев вендор просит дать больше времени.
Именно на этом этапе необходимо получить идентификатор CVE, чтобы добавить его к публикации.
Рассмотрим процесс более подробно.
Идентификатор по идее должен присваивать разработчик уязвимого продукта. Но так происходит не всегда. В таких случаях исследователь сможет получить CVE самостоятельно. Для этого потребуется зайти на сайт и найти там следующую форму:
В типе запроса необходимо выбрать «Request a CVE ID» и заполнить все поля.
У MITRE отличный FAQ, который поможет с заполнением формы.
После заполнения на указанный адрес электронной почты приходит автоматический ответ, который содержит номер запроса. Его можно и нужно будет использовать в дальнейшей коммуникации:
Спустя сутки может быть получен и идентификатор CVE:
Победа! Информацию об уязвимости можно публиковать со всеми надлежащими подробностями, включая идентификатор CVE.
Задавайте вопросы и делитесь своим опытом в комментариях и в нашей группе на Facebook!
