Архив метки: CVE

Аналитики Rapid7 зафиксировали эксплуатацию уязвимости обхода аутентификации в PAN-OS GlobalProtect и Prisma Access (CVE-2026-0257)

Добавить комментарий

Аналитики Rapid7 зафиксировали эксплуатацию уязвимости обхода аутентификации в PAN-OS GlobalProtect и Prisma Access (CVE-2026-0257)

Аналитики Rapid7 зафиксировали эксплуатацию уязвимости обхода аутентификации в PAN-OS GlobalProtect и Prisma Access (CVE-2026-0257). PAN-OS GlobalProtect - это система удалённого защищённого доступа от Palo Alto Networks, позволяющая сотрудникам подключаться к корпоративной сети через Интернет и работать так, как будто они находятся внутри организации. Она встроена в операционную систему PAN-OS, которая работает на сетевых устройствах (межсетевых экранах) Palo Alto Networks. Prisma Access - это облачный сервис от Palo Alto Networks, обеспечивающий защищённый удалённый доступ пользователей и применение корпоративных политик безопасности без необходимости развёртывать собственные VPN-шлюзы и периметровые устройства.

13 мая 2026 года компания Palo Alto Networks опубликовала бюллетень безопасности по CVE-2026-0257 - уязвимости обхода аутентификации со средней критичностью, затрагивающей PAN-OS и Prisma Access с настроенными GlobalProtect portal или gateway, включёнными authentication override cookies и определённой конфигурацией сертификатов. Успешная эксплуатация этой уязвимости позволяет удалённому неаутентифицированному атакующему установить VPN-соединение через шлюз GlobalProtect на уязвимом устройстве.

Команда Rapid7 MDR выявила успешную эксплуатацию у многочисленных клиентов, однако не обнаружила признаков успешного латерального перемещения с этих устройств. Самая ранняя зафиксированная дата эксплуатации - 17 мая 2026 года. По состоянию на 29 мая 2026 года данная уязвимость была добавлена в каталог известных эксплуатируемых уязвимостей CISA KEV.

Аналитики Rapid7 настоятельно рекомендуют рассматривать эту уязвимость как критическую. Обход аутентификации в корпоративном VPN-устройстве, доступном с внешнего периметра, может иметь серьёзные последствия для затронутых организаций. Следует в срочном порядке установить исправление, предоставленное вендором.

Инфосистемы Джет выложили "Результаты тестирования решений для управления уязвимостями" по новой версии методики (3.0)

Добавить комментарий

Инфосистемы Джет выложили Результаты тестирования решений для управления уязвимостями по новой версии методики (3.0)

Инфосистемы Джет выложили "Результаты тестирования решений для управления уязвимостями" по новой версии методики (3.0). Тестировали следующие продукты:

🔸 MaxPatrol VM v. 2.8 (27.6)
🔸 SecurityVision VM v. 5.0.1773849508
🔸 ScanFactory v. 7.21.9
🔸 R-Vision VM v. 6.2
🔸 AlphaSense v. 4.57.08.04

В отличие от тестирования по второй версии методики, здесь отсутствуют RedCheck и Vulns io VM. Возможно их добавят позже.

Оценка проводилась по 12 группам требований:

⚙️ Нефункциональные требования. Автоматическое и оффлайн обновление базы уязвимостей, открытый доступ к базе, централизованное управление, агентское сканирование и работа с хостами, поддержка изолированных сегментов и распределенной установки компонентов, мультиязычность, мультитенантность, а также соответствие требованиям ФСТЭК и включение в реестр отечественного ПО.

📱 Мобильный сканер. Наличие портативного (мобильного) сканера с возможностью переноса результатов в основную инсталляцию и формирования отчетов.

🗺️ Управление активами. Интерактивная карта сети, управление активами (динамические группы, поиск, карточки), скоринг и дедупликация активов, тегирование, хранение истории изменений, патч-менеджмент и выполнение административных команд на активах.

🧠 Настройка общих правил и логики системы. Управление задачами на устранение уязвимостей с назначением ответственных и SLA, сквозной поиск, фильтрация и сортировка по активам и уязвимостям, настройка оповещений о сканированиях, патч-менеджмент и автоматическое обновление атрибутов уязвимостей (критичности, сроков устранения и рекомендаций по устранению).

📊 Функционал визуализации и отчетности. Визуализация данных через настраиваемые виджеты и дашборды, создание и планирование отчетов, расширенная кастомизация интерфейса и объектов.

💻 Поддерживаемые типы активов для сканирования. Поддержка сканирования операционных систем (Windows, Linux и отечественных ОС), сетевого и серверного оборудования, СУБД и серверного ПО, а также поддержка периферийных устройств, промышленных систем (ICS/SCADA) и контейнеров.

🔗 Возможности интеграции. Документированный API с управлением доступом через ключи, встроенный мониторинг работоспособности (health-check) и интеграции с внешними системами мониторинга, поддержка доменной аутентификации, интеграции с Service Desk/ITSM и с SIEM, получение данных об активах из смежных систем и отправка оповещений.

🛡️ Управление сканированием и уязвимостями. Кастомизация карточки и тегирование уязвимостей, планирование и управление сканированиями (расписания, профили, ретроскан, исключения, технологические окна, пауза, клонирование), настройка правил и параметров сканирования, проверка доступности и учетных записей, в том числе брутфорс с пользовательскими словарями и несколькими типами учетных записей, управление исключениями, прогресс в реальном времени, расширенная работа с уязвимостями (CVE/CWE/БДУ, CVSS v2–v4 и кастомные метрики, скоринг, дедупликация, эксплуатируемость, вероятность использования, наличие эксплойтов, путь атаки, трендовость), а также рекомендации, внешние ссылки и методики ФСТЭК и НКЦКИ, плюс оповещения о событиях системы.

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

🌐 Сканирование веб-ресурсов. Аутентификация в веб-приложениях, сканирование веб-ресурсов (поиск поддоменов, скрытых файлов и директорий), режимы имитации и активной атаки, а также обнаружение широкого спектра уязвимостей (инъекции, CSRF, загрузка файлов и доступ к ФС, клиентские атаки, редиректы, слабая криптография, небезопасные security headers, утечки информации, cookie и сессионные уязвимости, memory corruption).

🔐 Безопасность. Настраиваемая ролевая модель, управление парольной политикой (сложность, история, минимальная длина, срок действия), блокировка учетных записей после неудачных попыток входа, шифрование критичных данных с поддержкой пользовательских ключей и создание/восстановление из резервных копий.

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

Возможные значения для каждого требования: ✅ Да, ❌ Нет, Частично. За исключением "Производительность и эффективность" → "Скорость добавления новых уязвимостей в базу уязвимостей решения…", где указывается значение в часах. По некоторым требованиям доступны 💬 комментарии вендоров.

Работа была проделана, вне всяких сомнений, большая и основательная. 🔥 Но, как и в случае тестирования по первой версии методики, мне не хватает оценки качества детектирования. Большая часть этой функциональности скрывается за пунктом "Поддержка сканирования ОС: Windows Server, Windows, AlmaLinux, Ubuntu, Debian" с галочкой у всех вендоров и без каких-либо комментариев. А ведь там самое интересное, ради чего, собственно, пользователи и покупают САЗы. Очень хотелось бы гораздо большей детализации поддерживаемых типов активов и подробного сравнения результатов детектирования на стендах с детализацией до конкретных CVE-шек, чтобы была видна разница в реализованной логике детектирования. Возможно, когда-нибудь и это сделают. 🙂

На прошлой неделе CISA запустили публичную форму "номинации новых KEV"

Добавить комментарий

На прошлой неделе CISA запустили публичную форму номинации новых KEV

На прошлой неделе CISA запустили публичную форму "номинации новых KEV". Форма предназначена для безопасной подачи информации об уязвимостях, эксплуатируемых в атаках, для их включения в каталог CISA KEV. В целом это изменение выглядит позитивно, но с оговорками:

🟢 Плюсы: CISA могут получить более быстрый и более структурированный поток данных об уже эксплуатируемых уязвимостях, что может ускорить их проверку и добавление в KEV. Это особенно важно, поскольку исследование и эксплуатация уязвимостей сейчас сильно ускорились, в том числе за счёт использования AI.

🔴 Минусы: появляется зависимость от качества поступающей информации, а также возникает дополнительная нагрузка на её проверку со стороны аналитиков CISA. Если валидация будет слабой, достоверность каталога KEV снизится, если слишком строгой, может снизиться скорость наполнения каталога. А ведь ради увеличения скорости всё это и затевается.

А возможно, это первый шаг в сторону децентрализации процесса классификации уязвимостей как эксплуатируемых. Появятся какие-нибудь KNA - KEV Nominating Authorities, по аналогии с CVE CNA? 🤔 Посмотрим. 🙂

Для добавления уязвимости нужны:

🔹 CVE-ID
🔹 Рекомендации по устранению
🔹 Подтверждения эксплуатации

Сначала нужно ответить да/нет на вопросы:

🔹 Есть ли доказательства того, что CVE уязвимость, о которой вы сообщаете, активно эксплуатируется или эксплуатировалась в прошлом?
🔹 Считаете ли вы, что эта уязвимость затрагивает несколько вендоров или продуктов?

Затем нужно заполнить текстовые поля:

🔹 CVE-ID, о котором вы сообщаете (пожалуйста, ещё раз проверьте, что CVE-ID указан правильно)
🔹 Доказательства эксплуатации
🔹 Ссылка на патч или меры по устранению

На странице содержится предупреждение: "Не отправляйте в этой форме секретную или конфиденциальную информацию".

Последнее поле опционально: "Пожалуйста, предоставьте любую дополнительную информацию, которую вы хотите добавить. Не указывайте в этой форме персональные данные. Если у вас есть дополнительные доказательства, которые вы хотите предоставить, свяжитесь с нами напрямую по электронной почте kev@cisa.dhs.gov. Если у вас есть конфиденциальная информация для отправки, пожалуйста, сначала согласуйте с нами, чтобы мы могли организовать безопасную передачу данных."

Для отправки заявки нужно пройти reCAPTCHA. Авторизация не требуется. В случае успеха показывают сообщение: "Благодарим вас за время, потраченное на прохождение этого опроса. Ваш ответ был записан."

На прошлой неделе западные ИБ-шники активно обсуждали очередное заявление руководителей NIST NVD, что "у них лапки", и они будут обогащать ещё меньше уязвимостей

1 комментарий

На прошлой неделе западные ИБ-шники активно обсуждали очередное заявление руководителей NIST NVD, что у них лапки, и они будут обогащать ещё меньше уязвимостей

На прошлой неделе западные ИБ-шники активно обсуждали очередное заявление руководителей NIST NVD, что "у них лапки", и они будут обогащать ещё меньше уязвимостей. Хотя, казалось бы куда уж меньше. 😏 Суть обращения, опубликованного NIST 15 апреля, в том, что из-за резкого роста числа CVE они меняют подход к ведению National Vulnerability Database: вместо анализа всех уязвимостей база переходит на риск-ориентированную модель. Полноценно обогащаться будут только приоритетные уязвимости:

🔥 уже эксплуатируемые (из каталога CISA KEV) - обещают обрабатывать за сутки
🏛️ относящиеся к ПО, используемому в госсекторе США (федеральным правительством)
🛠️ относящиеся к критическому ПО, определённому в Executive Order 14028

Остальные CVE останутся в базе, но получат низкий приоритет и будут долго оставаться без детального анализа. При этом NVD отказываются от дублирования CVSS-оценок (если CVSS пришёл от CNA, ему будут доверять, а свой CVSS рассчитывать не будут), будут реже перерабатывать записи, по которым изменилась ситуация, и фактически законсервируют накопившийся бэклог, чтобы сосредоточиться на наиболее опасных уязвимостях ценой снижения полноты и единообразия данных по остальным.

В целом, у меня такие новости вызывают сплошные фейспалмы. 🤦‍♂️ От NIST, которые, по-видимому, разогнали всех адекватных IT/ИБ-специалистов и превратились в синекуру для бюрократов, тратящих огромное финансирование непонятно на что. От CISA, которые не могут навести порядок в базовом ИБ-сервисе, критичном и для США, и для мира в целом. От американской администрации, которая тратит совершенно астрономические суммы на дикие геополитические прожекты, но совершенно не заботится о том, что происходит (разваливается) у них дома. MAGA? Лол, что? 😅

Ну а в практическом плане это означает, что если вы полагаетесь ТОЛЬКО на бесплатную NVD, то совершаете фатальную ошибку. Адекватность этой базы год от года стремительно снижается. Учитывайте альтернативные источники: Vulners, DBugs, VulnCheck, GCVE, БДУ ФСТЭК и прочие. Единственной мировой базы уязвимостей больше нет.

Ниже привожу полный перевод сообщения NIST.
Читать далее →

VulnCheck (Vulnerability Intelligence вендор и CNA) выстроили занимательный конвейер регистрации CVE-идентификаторов для активно эксплуатирующихся уязвимостей через взаимодействие с мониторинговой организацией Shadowserver

Добавить комментарий

VulnCheck (Vulnerability Intelligence вендор и CNA) выстроили занимательный конвейер регистрации CVE-идентификаторов для активно эксплуатирующихся уязвимостей через взаимодействие с мониторинговой организацией Shadowserver

VulnCheck (Vulnerability Intelligence вендор и CNA) выстроили занимательный конвейер регистрации CVE-идентификаторов для активно эксплуатирующихся уязвимостей через взаимодействие с мониторинговой организацией Shadowserver. Такой конвейер работает без участия вендоров уязвимого ПО и особенно полезен для регистрации уязвимостей в продуктах вендоров, которые по каким-то причинам совсем не инициируют регистрацию CVE или делают это со значительной задержкой (например, в случае некоторых вендоров из Китая).

Схема процесса:

🔎 Обнаружение эксплуатации: Shadowserver Foundation фиксируют, что для конкретной уязвимости наблюдается эксплуатация вживую, при этом CVE-идентификатор у уязвимости отсутствует.

🧪 Проверка информации: VulnCheck валидируют информацию и подтверждают, что для уязвимости ранее действительно не было зарегистрировано CVE.

📚 Сбор источников: собираются все релевантные публичные источники по уязвимости, включая, при наличии, патчи и репорты CERT-ов, государственных агентств и записи из альтернативных баз уязвимостей.

🆔 Публикация CVE: после подтверждения уязвимости ей присваивается CVE-идентификатор с привязкой к году первоначального раскрытия (например, CVE-2021-4473, если уязвимость была раскрыта в CNVD в 2021 году). В качестве CNA выступают сами VulnCheck.

📡 Распространение: опубликованный CVE-идентификатор передаётся обратно в Shadowserver для использования в детектировании, а также добавляется в VulnCheck KEV. Дополнительно рассылаются уведомления подписчикам по email и Slack.

VulnCheck приводят примеры заведённых по такому процессу уязвимостей:

🔻 CVE-2026-22679 - уязвимость удалённого выполнения команд без аутентификации в Weaver (Fanwei) E-cology 10.0. Первые признаки эксплуатации зафиксированы Shadowserver Foundation 31.03.2026.

🔻 CVE-2021-4473 - уязвимость внедрения команд в Tianxin Internet Behavior Management System. Первые признаки эксплуатации зафиксированы Shadowserver Foundation 01.06.2024.

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

🇷🇺 В российском контексте подобный подход можно было бы использовать для ускоренного заведения уязвимостей в БДУ ФСТЭК по факту их эксплуатации без активного участия в процессе регулятора и вендоров уязвимого ПО. Но для этого нужно фактически выдать некоторым российским Vulnerability Intelligence организациям полномочия по заведению идентификаторов БДУ, фактически аналогичные CNA, что, конечно, имеет свои плюсы и минусы. 🤔

Прочитал статью "NVD больше не успевает за реальностью: взгляд R-Vision на пересмотр роли NIST"

Добавить комментарий

Прочитал статью NVD больше не успевает за реальностью: взгляд R-Vision на пересмотр роли NIST

Прочитал статью "NVD больше не успевает за реальностью: взгляд R-Vision на пересмотр роли NIST". Очередная рефлексия на статью CYBERSECURITY DIVE про то, что у NIST-а лапки. 🙂 Имхо, ключевой тезис в статье R-Vision вот этот:

"Для нас качество базы измеряется не количеством CVE, а:

- скоростью реакции;
- полнотой покрытия реальных технологий;
- способностью адаптации под инфраструктуры заказчиков."

С одной стороны, соглашусь, что простое покрытие CVE-шек в текущей ситуации, когда идентификаторы могут заводиться на мусор, а на критичные уязвимости могут не заводиться, перестаёт быть единственным фактором, определяющим качество детектирования VM-решений. Всё стало сложнее. 💯

Но с другой стороны, сравнение баз VM-решений пересечением наборов CVE-идентификаторов всё ещё позволяет эффективно подсвечивать разницу в ТЕКУЩИХ возможностях детектирования и, при необходимости, обсуждать её с VM-вендорами. 😏 Аналогично можно сравниваться и по БДУ-идентификаторам. 😉

Американское VM-ное комьюнити переваривает статью по итогам квартальной встречи NIST ISPAB о перспективах NIST NVD

2 комментария

Американское VM-ное комьюнити переваривает статью по итогам квартальной встречи NIST ISPAB о перспективах NIST NVD

Американское VM-ное комьюнити переваривает статью по итогам квартальной встречи NIST ISPAB о перспективах NIST NVD. Если коротко: NIST не может и не хочет обогащать все уязвимости в NVD, у них лапки. 🐾

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

🔹 Обогащать теперь стараются преимущественно уязвимости из CISA KEV, уязвимости в ПО, используемом федеральными агентствами, и ПО, которое NIST определяет как критическое. То есть фактически работают по схеме БДУ ФСТЭК. Может, у ФСТЭК и подглядели. 😉

🔹 Спят и видят, как бы передать все функции по обогащению на сторону CNA. Полная децентрализация и бесконтрольность приведёт к ещё более замусоренным данным, но на это всем пофиг. 😏

🔹 При этом к CISA Vulnrichment и GCVE относятся критически. 🤷‍♂️🙂