Архив рубрики: Темы

Команда Vulners представила новый AI-продукт - Cube

Команда Vulners представила новый AI-продукт - CubeКоманда Vulners представила новый AI-продукт - CubeКоманда Vulners представила новый AI-продукт - CubeКоманда Vulners представила новый AI-продукт - CubeКоманда Vulners представила новый AI-продукт - CubeКоманда Vulners представила новый AI-продукт - CubeКоманда Vulners представила новый AI-продукт - CubeКоманда Vulners представила новый AI-продукт - CubeКоманда Vulners представила новый AI-продукт - Cube

Команда Vulners представила новый AI-продукт - Cube. Это платформа для контекстного анализа результатов сканирования на наличие уязвимостей, которая сопоставляет технические находки с данными об инфраструктуре и бизнес-процессах организации.

В основе работы Cube лежат три слоя:

📥 Evidence Layer - принимает отчёты существующих сканеров: Nessus, OpenVAS, Qualys, Rapid7 InsightVM, Acunetix и других. Платформа обрабатывает находки и сопоставляет их с реальными инфраструктурными активами.

🗺️ Context Layer - обогащает результаты информацией об инфраструктуре. Для этого используются архитектурная документация, схемы, задачи в таск-трекере, сведения об облачной среде, системах и бизнес-процессах. На их основе платформа восстанавливает модель инфраструктуры: формирует CMDB, строит граф сети и определяет взаимосвязи между компонентами. Это позволяет определить, какой актив затронут, насколько он доступен потенциальному атакующему и какие бизнес-функции от него зависят.

🧠 Decision Layer - использует методологию CISA SSVC (Stakeholder-Specific Vulnerability Categorization) для определения приоритетов устранения. В отличие от CVSS, оценивающего техническую критичность уязвимости, SSVC использует дерево принятия решений, учитывающее условия эксплуатации и возможные последствия для организации.

В модели CISA SSVC предусмотрено четыре итоговых статуса:

🟢 Track - уязвимость остаётся в стандартном процессе Vulnerability Management. Её отслеживают и устраняют в рамках обычных сроков обновления ПО.

🟡 Track* - требуется более пристальное наблюдение за уязвимостью и пересмотр оценки при появлении новых обстоятельств.

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

🔴 Act - требуется эскалация на уровень руководства и координация действий между подразделениями. Формируется согласованный план реагирования, привлекаются необходимые участники, а уязвимость устраняется как можно скорее.

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

Пользователь Cube получает несколько типов результатов:

🎯 Risk Cases - сгруппированные находки с оценкой критичности и бизнес-последствий.

🛤️ Attack Paths - потенциальные пути атак между активами с использованием MITRE ATT&CK.

🛡️ Threat Profile - общую картину угроз и состояния инфраструктуры.

📋 Обоснования решений - с привязкой к исходным отчётам, оценкам и инфраструктурным данным.

Например, уязвимость с CVSS 9.8 на изолированном внутреннем build-сервере может получить более низкий приоритет, чем уязвимость с CVSS 7.5 на публичном платёжном шлюзе. Во втором случае потенциальные последствия для бизнеса существенно выше.

Важно отметить, что платформа развёртывается в собственной инфраструктуре заказчика (on-premises), который самостоятельно выбирает языковую модель с API, совместимым с OpenAI API или Anthropic API. Это может быть, например, модель от Яндекса или Сбера, а также собственная LLM, развёрнутая на GPU-серверах организации. Таким образом, Cube не привязывает заказчика к конкретному AI-провайдеру. Vulners не взимает плату за использование токенов - заказчик самостоятельно контролирует расходы на выбранную LLM. По оценке Vulners, для инфраструктуры среднего масштаба бюджет на использование модели составляет около $1 000 в месяц.

По сути, Cube добавляет к традиционному Vulnerability Management слой контекстного анализа, связывающий технические уязвимости с реальными активами, бизнес-процессами и потенциальными последствиями атак.

Почему инцидентов с эксплуатацией PHP2Shell так мало?

Почему инцидентов с эксплуатацией PHP2Shell так мало?

Почему инцидентов с эксплуатацией PHP2Shell так мало? С самого начала PHP2Shell сравнивали с громкой уязвимостью Log4Shell (CVE-2021-44228). Однако механизмы эксплуатации этих уязвимостей существенно различаются. В случае Log4Shell злоумышленникам достаточно было отправить короткий фрагмент текста уязвимому приложению. Если приложение записывало этот текст в журнал, атака срабатывала. Один и тот же текст работал практически против любой уязвимой цели без изменений. Поэтому злоумышленники могли запускать массовые атаки, и многие из них оказывались успешными. Уязвимости PHP2Shell устроены иначе. Эксплуатация зависит от состояния кучи памяти (heap), используемого менеджера процессов, повторного использования рабочих процессов и особенностей размещения памяти в конкретной сборке. Поэтому эксплуатировать PHP2Shell не так просто, как Log4Shell.

Чтобы оценить реальную эксплуатабельность, эксперты Tenable с 24 по 29 октября выставили пять уязвимых PHP-сайтов в Интернет. Они зафиксировали массовые попытки эксплуатации PHP2Shell, но ни один ханипот в итоге не был взломан. 🤷‍♂️

В ходе анализа эксплоитов эксперты Tenable пришли к выводу, что повреждение памяти действительно существует и одним из последствий может быть раскрытие содержимого памяти. Однако добиться выполнения кода на конкретной цели сложно, причём метод эксплуатации уникален для каждой цели. Для успешного удалённого выполнения кода экспертам Tenable потребовался эксплойт, настроенный под конкретную среду, включая сборку PHP, SAPI, расширения и конфигурацию среды выполнения ("extensions and runtime configuration"). Пейлоад, работающий в одной лабораторной конфигурации, не подходит автоматически для другого дистрибутива или другой конфигурации пула PHP-FPM.

Эксперты Tenable подчёркивают, что отсутствие доказательств простой массовой эксплуатации не делает уязвимость безвредной. Злоумышленник, нацелившийся на конкретную систему, может создать подходящий эксплойт (тем более сейчас, используя AI-инструменты). Массовые атаки по сценарию Log4Shell менее вероятны, кроме систем с одинаковыми сборками, например сетевых устройств, где эксплойт достаточно настроить один раз.

Всё это не значит, что PHP2Shell можно игнорировать: условия для эксплуатации существуют, а целевые атаки на PHP-приложения вполне вероятны. Рекомендуется обновиться до PHP 8.5.12, 8.4.27, 8.3.36 или 8.2.35 либо установить исправленные пакеты дистрибутива. Для неподдерживаемых веток следует запланировать переход на актуальную версию PHP, а пока ограничить доступ из Интернет и применить меры защиты на уровне конфигурации. Для сетевого оборудования используйте исправленные сборки производителя или рекомендованные им временные меры защиты.

Рекомендуемая последовательность: сначала обновить или изолировать сетевые устройства, открытые интерфейсы управления и системы с неподдерживаемыми версиями PHP. Остальные PHP-системы обновлять по графику критических обновлений. И не забывайте о других уязвимостях, которые могут представлять более высокий риск для вашей инфраструктуры. 😉

Что там слышно по инцидентам, связанным с эксплуатацией PHP2Shell, спустя две недели?

Что там слышно по инцидентам, связанным с эксплуатацией PHP2Shell, спустя две недели?

Что там слышно по инцидентам, связанным с эксплуатацией PHP2Shell, спустя две недели? Когда 21 октября разработчики PHP готовились к релизу версий PHP с исправлением PHP2Shell (CVE-2026-109618, CVE-2026-109619), эксперты прогнозировали, что буквально через 15 минут после публикации обновления начнутся массовые атаки на уязвимые серверы. Эксперты Amazon даже сообщали о попытках эксплуатации за четыре дня до выхода патчей. На фоне этих новостей некоторые организации забили тревогу. В нескольких странах правительственные сайты и сервисы были отключены в качестве меры предосторожности.

И вот прошли две недели. Согласно данным Censys, из 46 миллионов PHP-сервисов, использующих уязвимые версии, примерно 29 миллионов по-прежнему не обновлены. Исследователи отмечали большое количество попыток эксплуатации. Новые эксплоиты продолжали появляться один за другим. Когда я готовил отчёт по октябрьскому Linux Patch Wednesday, фиксировалось более 470 ссылок на репозитории с эксплоитами PHP2Shell!

И что в итоге по реальным инцидентам?

🔻 Первое сообщение об инциденте, связанном с эксплуатацией этой уязвимости, появилось 23 октября от экспертов Palo Alto Networks. Однако через два дня, 25 октября, они отозвали это заявление. 🤷‍♂️

🔻 Убедительное подтверждение эксплуатации PHP2Shell в реальных атаках появилось только 24 октября. Серверы-ловушки, запущенные Аделем Карими из Perplexity и работавшие на PHP 8.4.26, зафиксировали успешные атаки с двух IP-адресов. Наблюдаемая цепочка эксплуатации соответствовала CVE-2026-109618. Однако на сервере-ловушке исследователя использовался модуль Apache mod_php - конфигурация, наиболее удобная для злоумышленников.

🔻 Технологическая компания Dream Group сообщила 26 октября о компрометации 25 межсетевых экранов и серверов управления в США, Японии, на Тайване и в Южной Корее. Три из них находились в инфраструктуре, предположительно связанной с государственными ведомствами США. Злоумышленники использовали PHP2Shell в сочетании с Fragnesia (CVE-2026-46300) - майской LPE-уязвимостью ядра Linux. Получив полный административный контроль, они смогли извлечь пароль служебной учётной записи LDAP, похитить список пользователей и групп, полную конфигурацию сети и закрытые ключи. В тот же день уязвимости PHP2Shell были добавлены в CISA KEV. Через два дня, 28 октября, в CISA KEV добавили и Fragnesia. Изначально эксперты Dream Group не называли производителя скомпрометированных устройств, однако в обновлении от 29 октября появилось уточнение, что речь идёт об устройствах Palo Alto Networks. По данным Dream Group, из примерно 19 000 обнаруженных устройств злоумышленники отобрали 240 потенциальных целей, из которых успешно скомпрометировали 24 межсетевых экрана. Позже они также взломали внутренний сервер управления. Palo Alto Networks подтвердили атаки на интерфейсы управления, доступные из Интернет. Компания призвала клиентов закрыть публичный доступ к этим интерфейсам, разрешить подключение только с доверенных внутренних IP-адресов и установить обновления безопасности.

Вот пока и вся раскладка по инцидентам. 🤷‍♂️ Не густо, учитывая всеобщие апокалиптические ожидания. А вот почему ожидания так серьёзно разошлись с реальностью - тема отдельная. 😉

Видеозапись моего выступления на Positive Security Day 15 октября под названием "Отделить зёрна от плевел: подходы к автоматизированной оценке опасности уязвимостей"

Видеозапись моего выступления на Positive Security Day 15 октября под названием "Отделить зёрна от плевел: подходы к автоматизированной оценке опасности уязвимостей". В выступлении я рассказал о существующих методах оценки и приоритизации уязвимостей (CVSS, методике ФСТЭК, KEV-каталогах, EPSS, SSVC и Tenable VPR), рассмотрел трендовые уязвимости 2026 года и представил методику PVSS от Positive Technologies, применяемую в том числе для отбора трендовых уязвимостей.

Таймстемпы:

00:00 Приветствие
00:43 Всё возрастающие объёмы появления новых CVE в реестрах NVD/CVEorg, Microsoft Patch Tuesday и Linux Patch Wednesday
02:28 Common Vulnerability Scoring System (CVSS 3.0, 3.1, 4.0), статистика использования версий стандарта и проблемы его субъективности на примере CVE-2026-20963 и CVE-2026-56164
05:39 Методика ФСТЭК для оценки уровня опасности уязвимостей программных, программно-аппаратных средств (от 30 июня 2025 года)
06:51 Каталоги известных эксплуатируемых уязвимостей: CISA KEV, VulnCheck KEV, EUVD KEV
08:04 Exploit Prediction Scoring System (EPSS) и достоверность его прогнозов
09:19 Stakeholder-Specific Vulnerability Categorization (SSVC)
10:13 Tenable VPR - пример проприетарной системы оценки критичности уязвимостей
12:13 Трендовые уязвимости по версии Positive Technologies
12:55 Трендовые уязвимости 2026 года по состоянию на 1 октября
16:07 Positive Vulnerability Scoring System (PVSS)
17:50 Использование PVSS для отбора трендовых уязвимостей
19:48 Выводы

Видео также доступно на YouTube.

Про уязвимость Denial of Service - Android "SMS of Death" (CVE-2026-58882)

Про уязвимость Denial of Service - Android SMS of Death (CVE-2026-58882)

Про уязвимость Denial of Service - Android "SMS of Death" (CVE-2026-58882). Уязвимость позволяет удалённо нарушить работу мобильной связи на Android-смартфоне с помощью специально сформированного SMS-сообщения. Для эксплуатации не требуется взаимодействие с пользователем (zero-click). Для атаки используется WAP Push - специальный тип бинарного SMS, предназначенный для автоматической передачи служебной информации или ссылок на мобильный контент. Такое сообщение обрабатывается системными компонентами Android автоматически и не отображается во входящих. Жертва не видит ни само сообщение, ни номер отправителя. Проблема связана с некорректной проверкой длины заголовка в функции WapPushOverSms.decodeWapPdu. При обработке вредоносного WAP Push-сообщения значение длины приводится к знаковому целому без проверки границ и становится отрицательным (-2147483648). Android пытается создать массив такого размера, возникает необработанное исключение NegativeArraySizeException, и аварийно завершается системный процесс com.android.phone. В результате обрываются активные звонки, в том числе экстренные, а связь пропадает на 1-2 секунды на каждое сообщение.

Оператор повторно доставляет неподтверждённые сообщения, поэтому сбои могут повторяться. По данным исследователя Марка Блащика (Mark Blaszczyk), одно сообщение могло вызывать перебои со связью продолжительностью до недели, а около 20 сообщений - надолго блокировать работу смартфона. Тестирование проводилось на Pixel 9 и нескольких Samsung Galaxy.

В худшем случае возникает цикл перезагрузок. Один из пользователей описал его на Android 12: устройство перезагружалось примерно каждые 90 секунд (срабатывала защита RescueParty) и показывало в recovery запрос на стирание данных. Исследователь предупреждает, что неопытный пользователь может в итоге сделать сброс к заводским настройкам. Однако в описанном случае сброс не потребовался: проблемные сообщения удалили через Android Debug Bridge (ADB). Этот способ требует технических знаний и доступа к компьютеру. Другой workaround - переставить SIM-карту в не-Android телефон, чтобы SMS-сообщения были подтверждены.

⚙️ Исследователь сообщил Google о проблеме 5 мая 2026 года, но Google закрыли отчёт как не относящийся к безопасности. Однако патч всё же вошёл в октябрьское обновление Android 14-17. Само исправление не добавляет проверку длины: оно перехватывает исключение и удаляет проблемное сообщение. В октябрьском бюллетене Google уязвимость не упомянута. По словам участника проекта GrapheneOS, CVE войдёт в ноябрьский бюллетень, который на 1 ноября ещё не вышел. Поэтому патч-уровень 2026-10-01 может не гарантировать защиту. Устройства на Android 12 и 13 остаются уязвимыми, т.к. для них исправление не было выпущено.

🛠 Исследователь опубликовал 29 октября технический анализ и PoC-эксплоит на GitHub.

👾 Сообщений о реальных атаках пока нет.

Октябрьский Linux Patch Wednesday

Октябрьский Linux Patch Wednesday

Октябрьский Linux Patch Wednesday. Всего 4946 уязвимостей. Для сравнения, в сентябре было 2653. Рост на 86%! В Linux Kernel на этот раз 1954 уязвимости, в Chromium - 814. Вместе они составляют 56% от общего количества уязвимостей.

Для шести уязвимостей есть признаки эксплуатации в реальных атаках:

🔻 RCE - PHP "PHP2Shell" (CVE-2026-109618, CVE-2026-109619). PHP - популярный язык программирования, используемый для разработки веб-приложений. Уязвимость CVE-2026-109618 связана с некорректной обработкой нехватки памяти (OOM) и позволяет удалённо выполнить произвольный код при получении приложением специально сформированного запроса. Уязвимость CVE-2026-109619 связана с использованием устаревшего состояния глобальных данных после освобождения памяти (use-after-free) и также позволяет удалённо выполнить произвольный код при получении специально сформированного запроса. Пакеты с исправлениями в Linux-дистрибутивах начали выпускать в день раскрытия уязвимостей 21 октября. На GitHub доступны более 470 ссылок на публичные эксплоиты. Обе уязвимости были добавлены в CISA KEV 26 октября.

🔻 SFB - Linux Kernel "PwnEscape" (CVE-2026-99999). Уязвимость в сетевом стеке ядра Linux. Злоумышленник внутри гостевой виртуальной машины KVM может повредить память ядра хост-системы. Это позволяет раскрыть содержимое памяти хоста или вызвать его аварийное завершение. Исследователи продемонстрировали полноценный побег из гостевой системы на хост. Пакеты с исправлениями в Linux-дистрибутивах начали выпускать с 16 октября. Публичные эксплоиты появились на GitHub также с 16 октября. Уязвимость была добавлена в VulnCheck KEV 19 октября.

🔻 RCE - WordPress (CVE-2026-87902). WordPress - популярная система управления контентом (CMS, Content Management System), используемая для создания сайтов и блогов. Уязвимость позволяет неаутентифицированному злоумышленнику добиться удалённого выполнения произвольного кода на сервере при определённых условиях. Публичные эксплоиты доступны на GitHub с 22 сентября. Уязвимость была добавлена в CISA KEV 25 сентября. Пакеты с исправлениями уязвимости появились в Debian 28 сентября.

🔻 XSS - WordPress "Comment2Shell" (CVE-2026-93485). Уязвимость позволяет неаутентифицированному злоумышленнику внедрить JavaScript-код через специально сформированный комментарий, который выполняется в браузере пользователя при просмотре страницы. При просмотре комментария администратором, злоумышленник может перехватить его сессию и добиться выполнения произвольного кода на сервере. Уязвимость была добавлена в VulnCheck KEV 18 сентября. Публичные эксплоиты доступны на GitHub с 22 сентября. Пакеты с исправлениями в Debian доступны с 28 сентября.

🔻 AFR - Gradio (CVE-2026-28414). Gradio - библиотека Python для быстрого создания интерфейсов машинного обучения. Уязвимость позволяет неаутентифицированному злоумышленнику читать произвольные файлы на сервере Windows при использовании Python 3.13 и выше, даже если в Gradio включена аутентификация. Публичный эксплойт опубликован 27 февраля. Уязвимость была добавлена в VulnCheck KEV 31 мая. Пакеты с исправлениями в ALT Linux доступны с 1 октября.

Ещё для 335 уязвимостей пока нет признаков эксплуатации в реальных атаках, но есть публичные эксплоиты. Из них можно выделить:

🔸 EoP - Linux Kernel (CVE-2026-98260). Уязвимость типа Use-After-Free в механизме POSIX CPU timers позволяет локальному непривилегированному пользователю повысить привилегии до root-а. Исследователь v4bel продемонстрировал получение root shell на Ubuntu 26.04 с ядром 7.0.0-30-generic в рамках проекта Infinity Core. Также заявлена возможность выхода из контейнерной изоляции и повышения привилегий на Android. Пакеты с исправлениями доступны с 15 октября. Публичный эксплойт опубликован на GitHub 17 октября.

🔸 RCE - Pillow (CVE-2026-112900). Pillow - библиотека Python для обработки изображений. Злоумышленник может загрузить EPS-файл для выполнения произвольного кода на сервере. Пакеты с исправлениями в Debian доступны с 21 октября. Публичные эксплоиты доступны на GitHub с 23 октября.

🗒 Полный отчёт Vulristics (ZIP; 1.7 mb)

StopPhish опубликовали исследование о тенденциях в развитии мошеннических схем (с моим комментарием)

StopPhish опубликовали исследование о тенденциях в развитии мошеннических схем (с моим комментарием)

StopPhish опубликовали исследование о тенденциях в развитии мошеннических схем (с моим комментарием). В исследование вошли 5 083 публикации, для которых удалось найти первоисточники. Период исследования - с 1 января 2022 года по 30 июня 2026 года.

📈 Наблюдается устойчивый рост количества публикаций (публ.) и разновидностей мошеннических схем (разн.)

2022 год - 389 публ., 135 разн.
2023 год - 718 публ., 254 разн.
2024 год - 1 292 публ., 517 разн.
2025 год - 1 868 публ., 763 разн.
Первое полугодие 2026 года - 816 публ., 428 разн.

Каналы первоначального контакта

📱 Телефонные звонки - 3 171 публ. (62,4%).
💬 Мессенджеры - 814 публ.
🌐 Социальные сети - 219 публ.
✉️ Электронная почта - 144 публ.

Популярные предлоги и сценарии обмана

💰 Перевод на "безопасный счёт" - 193 разн.
🔓 Сообщение о взломе аккаунта - 120 разн.
📦 Покупка, доставка или возврат - 117 разн.

Чего добиваются мошенники

🔑 Получение кода подтверждения - 247 разн.
🔗 Переход по ссылке или открытие сайта - 203 разн.
💸 Перевод денег - 302 разн.

Психологические приёмы

💰 Страх потерять деньги - 1 863 публ.
⚖️ Страх уголовного преследования - 1 272 публ.
🏦 Доверие к авторитету известной организации - 1 171 публ.
⏱️ Создание ощущения срочности - 500 публ.

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

💵 Снимать наличные.
💳 Оформлять кредиты.
🥇 Покупать золото.
🚚 Передавать деньги и семейные ценности курьерам или другим участникам схемы.

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

Мой комментарий:

"Александр Леонов, ведущий эксперт Positive Technologies, отмечает: даже регулярное антифишинговое обучение не исключает человеческих ошибок. Поэтому организация должна быть готова к ситуации, когда сотрудник всё-таки откроет опасную ссылку, передаст данные или запустит вредоносный файл.

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

Подробнее об этом я писал в посте об эшелонированной защите.

Главные выводы для ИБ организаций

🎓 Обучение сотрудников необходимо, но само по себе не гарантирует защиту от атак.
🛡️ Защита должна включать проверку входящих сообщений, обновление и харденинг рабочих станций и другой IT-инфраструктуры, ограничение привилегий и мониторинг подозрительной активности.
🔍 При расследовании важно восстанавливать всю цепочку действий злоумышленников, а не только искать первоначальный источник атаки.
💳 Необходимо контролировать финансовые процессы, изменение реквизитов, выдачу доступов и подтверждение срочных платежей.
🚨 Организация должна иметь план реагирования на инциденты и восстановления инфраструктуры.