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

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

Как The PHP Foundation обнаружили RCE-уязвимости PHP2Shell (CVE-2026-109618, CVE-2026-109619) и почему злоумышленники узнали о них раньше срока

Как The PHP Foundation обнаружили RCE-уязвимости PHP2Shell (CVE-2026-109618, CVE-2026-109619) и почему злоумышленники узнали о них раньше срока

Как The PHP Foundation обнаружили RCE-уязвимости PHP2Shell (CVE-2026-109618, CVE-2026-109619) и почему злоумышленники узнали о них раньше срока. Возможность эксплуатации обеих уязвимостей была наглядно продемонстрирована исследователями. Обе уязвимости затрагивают управление памятью и обработку ошибок - ключевые компоненты PHP, поэтому их устранение осложнялось необходимостью сохранить обратную совместимость и производительность, а также избежать изменений во множестве сторонних расширений.

В 2024 году PHP впервые за много лет прошёл внешний аудит безопасности, профинансированный Sovereign Tech Agency и организованный через OSTIF. Аудит провела компания Quarkslab. При устранении одной из выявленных проблем разработчик ядра PHP, работавший по контракту с PHP Foundation, обнаружил первые признаки проблемы OOM, лежащей в основе CVE-2026-109618. Тогда предположили возможность эксплуатации этой проблемы, но конкретные векторы атаки найти не удалось, и внимание переключилось на другие подтверждённые уязвимости с очевидными последствиями.

В мае 2026 года организация создала команду безопасности экосистемы. Ранее The PHP Foundation совместно с Alpha-Omega просканировали код PHP с помощью Claude Mythos от Anthropic. Кроме того, использовали Daybreak Red от OpenAI для проверки сообщений об уязвимостях и эксплоитов, а также сборки с санитайзерами и среды воспроизведения ошибок.

The PHP Foundation обеспечили участие PHP в программе Patch the Planet. 30 июля 2026 года компания Calif начала аудит PHP. 11 августа исследователь Ryan A сообщил об уязвимости, позволяющей удалённо выполнять код без дополнительных условий. Её первопричина совпадала с причиной проблемы OOM, обнаруженной в 2024 году. В тот же день о ней независимо сообщили эксперты OpenAI. Позже OpenAI (18 сентября) и Wiz (24 августа) выявили дополнительные векторы атаки. Аудит PHP также проводили Trail of Bits. Эти сообщения помогли оценить полный масштаб последствий проблемы OOM. С 11 августа её устранение стало главным приоритетом для специалистов The PHP Foundation по безопасности. ИИ помогает проверять сообщения и группировать их по общей первопричине, но все решения принимают люди, которые также участвуют в разработке каждого патча.

Согласованное раскрытие информации об этих уязвимостях проходило успешно до 20 октября (за два дня до запланированной даты выпуска 22 октября). После чего начались проблемы:

🔻 20 октября около 15:00 UTC в сети появились идентификаторы двух CVE с неверным временем выпуска и ошибочной оценкой CVSS 10,0 вместо 9,2. Технические подробности не утекли, поэтому предварительное объявление перенесли на 19:30 UTC, а выпуск исправлений - с 22 на 21 октября, чтобы Linux-вендоры успели подготовить пакеты для обновления.

🔻 20 октября около 20:00 UTC компания Calif случайно опубликовала видео с демонстрацией PoC-а и дополнительными сведениями об уязвимостях. Несмотря на удаление, видео распространили в соцсетях, ускорив разработку и распространение новых PoC-ов 21 октября.

🔻 Рекомендации по снижению рисков, переданные операторам критической инфраструктуры 20 октября около 23:00 UTC, также могли утечь. Команда безопасности PHP отслеживала и проверяла появлявшиеся PoC-и, но до выпуска и публичного раскрытия информации не обнаружила работающих эксплоитов.

🔻 21 октября в 07:41 UTC, более чем за шесть часов до срока, компания Chainguard нарушила эмбарго и опубликовала образы с исправлением. Это позволило злоумышленникам изучить патч до официального выпуска и свело на нет недели работы над согласованным раскрытием уязвимостей. 🤷‍♂️

Возможно, что эти и другие утечки помогли злоумышленникам подготовить эксплоиты заранее: эксперты Amazon зафиксировали попытку эксплуатации PHP2Shell ещё 17 октября, а 21 октября обнаружили новые атаки с нескольких IP-адресов.

Почитываю, что там пишут про Anthropic Claude Mythos

Почитываю, что там пишут про Anthropic Claude Mythos

Почитываю, что там пишут про Anthropic Claude Mythos. От алармизма и восторженных отзывов, что эта вундервафля пачками обнаруживает эксплуатабельные 0-day уязвимости без какого-либо участия человека (и якобы поэтому крайне этичные Anthropic включили режим почтальона Печкина: "я вам её не отдам, у вас документов нету"), всё скатилось к "пирожку с ничем". То есть буквально: в The Register вчера вечером вышла статья "Anthropic's super-scary bug hunting model Mythos is shaping up to be a nothingburger".

Моё мнение по этому поводу: все комментирующие правы! 🙂

🔹 Офигели ли Anthropic со своим бесстыжим маркетингом и нагнетанием необоснованного хайпа? Конечно, да!

🔹 Есть ли подвижки в автоматическом детектировании эксплуатабельных уязвимостей? Безусловно!

Когда CTO Mozilla говорит по поводу 271 уязвимости в Firefox 150, найденных Mythos:

"Мы не увидели ни одной ошибки, которую не смог бы найти высококлассный (elite) исследователь-человек."

Это не критика инструмента, который пока не круче человека. Это суперкомплимент! Вы вообще много высококлассных ресёрчеров знаете? А тех, которые эффективно масштабируются и работают 24/7? 😏 Вот то-то.

Поэтому даже если Mythos - полная ерунда и чистый хайп (в чём я лично сомневаюсь 🤔), расслабляться точно не стоит. "Манхэттенский проект" в области разработки кибероружия уже вовсю идёт и останавливаться не собирается. И там далеко не мифосом единым. Это особенно интересно смотрится в контексте опубликованного на днях манифеста Palantir о милитаризации США (и их сателлитов Германии и Японии), ведущей роли в этом американского бигтеха, новом ИИ-сдерживании (заменяющем сдерживание ядерное). На весь этот надвигающийся мрачняк придётся чем-то отвечать. 🤷‍♂️ И, учитывая разницу в ресурсах и технологическом уровне (включая ИИ) между США и Россией, отвечать придётся как-то асимметрично.

Имхо, для начала неплохо хотя бы прекратить утечку наресёрченных в стране критичных уязвимостей за рубеж. Да-да, кто о чём, а я опять про централизацию репортинга - это важно! Также неплохо бы подумать о том, как хоть в какой-то мере закрыться от цунами низкокачественного нагенерённого кода, в котором искать уязвимости будет особенно просто. Кода, генерируемого, к слову, в основном на сервисах потенциального (или вполне фактического) противника. Что тоже должно поднимать обоснованные вопросики. 😉