Команда 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 слой контекстного анализа, связывающий технические уязвимости с реальными активами, бизнес-процессами и потенциальными последствиями атак.

Ходили вчера семьёй на спектакль "Чиполлино" в Московский театр кукол на Бауманской

Ходили вчера семьёй на спектакль Чиполлино в Московский театр кукол на Бауманской

Ходили вчера семьёй на спектакль "Чиполлино" в Московский театр кукол на Бауманской. И мне в голову пришла следующая аналогия с процессом Управления Уязвимостями.

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

Это мне напомнило выстраивание VM-процесса в организации с около нулевым бюджетом. Так сказать, из опенсорса и палок. VM-процесс в этом случае получается весьма условным, как и домик кума Тыквы: одно название.

Однако, если помните, дальше история в "Чиполлино" развивается таким образом, что за этот домик с кума Тыквы спрашивают как за настоящий дом, на строительство которого требуется разрешение, уплата налога и прочее-прочее.

Так и в случае ИБ: если происходит инцидент, включающий эксплуатацию уязвимости, вопросы к импровизированному VM-процессу, который не обеспечил своевременное выявление и устранение этой критической уязвимости, будут ровно такими же, как к полноценному процессу за много денег. Причём вопросы будут прежде всего к тому, кто такой процесс выстроил, то есть к VM-щику.

Поэтому, как мне кажется, VM-щику не стоит весело поддакивать руководству: "Да чего там делать-то?! Сейчас на Wazuh-е изобразим и норм 😏" или что-нибудь в таком духе.

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

Не стесняйтесь подкладывать себе соломки. В критическую минуту это может вам весьма пригодиться. 😉

Прочитал статью OpenAI про то, как они создали эксплоиты для 948 новых EoP/LPE-уязвимостей в ядре Linux

Прочитал статью OpenAI про то, как они создали эксплоиты для 948 новых EoP/LPE-уязвимостей в ядре Linux

Прочитал статью OpenAI про то, как они создавали эксплоиты для 948 новых EoP/LPE-уязвимостей в ядре Linux. Статья понравилась. 👍 Много занимательных подробностей о том, как у них устроен конвейер, что они делали на каждом этапе, с какими проблемами сталкивались и сколько им это стоило.

По данным OpenAI, было обнаружено 2308 потенциальных уязвимостей ядра Linux, из которых 1724 удалось воспроизвести. В результате они создали 948 эксплойтов для локального повышения привилегий (LPE), позволяющих непривилегированному пользователю получить права root, а также 291 PoC для уязвимостей, связанных с утечкой информации. Общие затраты составили $1 213 430 в кредитах API, или около $1279 на один LPE-эксплойт. После исследования специалисты проверили результаты и передали обнаруженные уязвимости вместе с исправлениями разработчикам. Работа проводилась в рамках программы Patch the Planet.

Испытания проводились на виртуальных машинах со стандартной десктопной ОС, без специально ослабленных настроек. Модель угроз соответствовала условиям Pwn2Own и TyphoonPWN. Для оценки экономической целесообразности OpenAI сопоставили затраты на исследование с размерами вознаграждений на этих соревнованиях - от $20 000 до $70 000 за один эксплойт. По таким расценкам совокупная стоимость 948 эксплойтов составила бы от $18,9 до $66,3 млн - в 16-55 раз больше фактических затрат на исследование.

Также тестирование проводили в адаптированной среде kernelCTF - версии ядра Linux с уменьшенной поверхностью атаки. Там получили 25 PoC для утечек информации и 21 эксплойт для LPE. Вся кампания обошлась примерно в $32 936 в кредитах API.

В конвейере используется несколько специализированных групп AI-агентов:

🔻 Scout (разведка) - исследуют кодовую базу и отбирают участки, представляющие интерес с точки зрения безопасности и доступные непривилегированным пользователям.

🔻 Analyst (анализ) - проводят углублённое исследование отобранных участков кода и выявляют потенциальные уязвимости.

🔻 Triage (верификация) - проверяют достоверность находок, автоматически создавая и запуская PoC в изолированных виртуальных машинах с использованием KASAN (Kernel Address Sanitizer).

🔻 ExploitDev (разработка эксплойтов) - оценивают возможность практической эксплуатации подтверждённых уязвимостей и разрабатывают рабочие эксплоиты. Испытания проводятся в изолированных виртуальных машинах со стандартными механизмами защиты дистрибутивов Linux: SMEP (Supervisor Mode Execution Prevention), SMAP (Supervisor Mode Access Prevention), KASLR (Kernel Address Space Layout Randomization) и HARDENED_USERCOPY. Разработка эксплоитов для повышения локальных привилегий (LPE) включает планирование стратегии эксплуатации, поиск подходящих уязвимых объектов, обход механизмов защиты и выполнение дополнительных технических операций.

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

Интересное в выводах:

🔹 Новая модель обнаружила 948 уникальных эксплуатируемых LPE против 166 у предыдущей.

🔹 Выявлено 10 новых техник эксплуатации. Модели способны не только находить уязвимости, но и разрабатывать новые способы их эксплуатации.

🔹 В 20 из 200 экспериментов модель получила права root через другую уязвимость, а не ту, которую ей поручили эксплуатировать. 🤷‍♂️ Поэтому важно проверять не только результат, но и способ его достижения. 😉

🔹 Более мощным моделям требуется менее сложная оркестрация, итерации повышают качество генерации исправлений.

Почему инцидентов с эксплуатацией 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-адресов и установить обновления безопасности.

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

С Днём народного единства!

С Днём народного единства!

С Днём народного единства! Единство народов - фундамент устойчивости и суверенитета нашей страны, а многообразие - наше главное конкурентное преимущество.

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

Желаю крепкого здоровья, семейного благополучия и успехов во всех начинаниях! Вместе мы - одна команда, способная защитить то, что нам дорого, от любой вражеской нечисти! С праздником!

Я в прошлом посте про взлом Binance предполагал, что у них в инфраструктуре колхоз и адище, а сотрудники творят безответственную дичь, но реальность оказалась даже веселее

Я в прошлом посте про взлом Binance предполагал, что у них в инфраструктуре колхоз и адище, а сотрудники творят безответственную дичь, но реальность оказалась даже веселее

Я в прошлом посте про взлом Binance предполагал, что у них в инфраструктуре колхоз и адище, а сотрудники творят безответственную дичь, но реальность оказалась даже веселее. 🙂

🔻 В сентябре 2026 года через легитимную платформу для поиска работы с инженером-программистом B связался человек, представившийся директором проекта. В профиле инженера был указан опыт работы в Binance, что, вероятно, привлекло внимание злоумышленника. Под предлогом трудоустройства он организовал два этапа собеседования с этим инженером-программистом: сначала с представителем отдела кадров, а затем с человеком, назвавшимся генеральным директором вымышленной компании.

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

Второе собеседование проходило в популярном мессенджере. Ближе к его завершению инженеру B предложили скачать на рабочий компьютер "тестовое задание", которое на самом деле представляло собой репозиторий с вредоносным кодом. Вредоносный код выполнялся в процессе настройки окружения, запуская цепочку несанкционированных действий. Для сокрытия своей активности вредоносная программа использовала сложные методы обфускации и обхода средств защиты. В частности, злоумышленники подменили компонент легитимного инструмента разработки его вредоносной версией, что позволило выполнять команды и устанавливать соединение с внешним сервером, находящимся под их контролем. На момент атаки вредоносная программа не обнаруживалась установленными на компьютере средствами защиты конечных устройств. 👍 Кроме того, злоумышленники предприняли меры по сокрытию своих действий и удалению следов компрометации, существенно осложнив обнаружение инцидента и его последующее расследование. 🙂

🔻 20 октября 2026 года злоумышленник воспользовался скомпрометированным компьютером инженера B и внутренним ИИ-инструментом, чтобы получить доступ к компьютерам инженера DevOps команды Wallet A (про этого уникума пишут, что в июне он скачал подменённый зловредный установщик Homebrew - популярного менеджера пакетов для macOS, но тогда атаку успели обнаружить 😏) и инженера-программиста команды Wallet C. Вскоре злоумышленник обнаружил, что на компьютере инженера DevOps команды Wallet A хранился токен, предоставляющий права на развёртывание контейнеров. 🤷‍♂️

🔻 29 октября с 17:15 до 19:56 злоумышленник получил доступ к компьютеру инженера-программиста C, воспользовался учётными данными, похищенными у инженера DevOps команды Wallet A, и развернул контейнер, из которого запустил вредоносный скрипт для проведения атаки. И заверте…

Какие уроки можно извлечь из этой истории?

🔹 Не запускайте непроверенный код и скрипты из сторонних репозиториев на рабочих устройствах. Особенно если речь идёт о "тестовых заданиях" от левых интервьюеров.

🔹 Не храните критичные секреты на десктопах. Ограничивайте права доступа и сроки действия токенов.

🔹 Контролируйте доступ ИИ-инструментов к данным, системам и выполнению команд.

🔹 Отслеживайте аномальную активность и несанкционированные изменения в системе.

🔹 Инвестируйте в IT и ИБ (особенно, когда миллиардами ворочаете). Не работайте с идиотами или хотя бы пытайтесь их обучать. 😉