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

Почему инцидентов с эксплуатацией 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 в РБК и Российской Газете.

🔹 В новости РБК использовали базовую информацию об оценке критичности уязвимостей по шкале CVSS 4.0, типе уязвимости, затронутых системах и потенциальных последствиях эксплуатации, а также рекомендации по устранению.

🔹А вот в Российской Газете вышла полноценная колонка. 😇 Статья начинается с описания угрозы и оценки её масштаба, включая потенциально затронутые ресурсы в Рунете. Далее рассматриваются влияние уязвимостей на веб-сайты и инфраструктурные продукты, механизм эксплуатации и возможные последствия атак, первые признаки эксплуатации и роль искусственного интеллекта в обнаружении уязвимостей. Завершается материал практическими рекомендациями по защите инфраструктуры, установке обновлений, применению WAF и систем управления уязвимостями, сравнением с Log4Shell и выводом о необходимости защищать всю технологическую цепочку.

Важный момент в том, что эти уязвимости касаются далеко не только сайтов:

Уязвимости CVE-2026-109618 и CVE-2026-109619 затрагивают продукты, использующие PHP, включая межсетевые экраны, системы управления сетевой безопасностью и платформы развёртывания приложений. Их влияние подтвердили Palo Alto Networks для PAN-OS - операционной системы межсетевых экранов, и Panorama - централизованной платформы управления сетевыми устройствами, а также Netgate для pfSense - операционной системы для маршрутизаторов и межсетевых экранов. Разработчики Coolify, платформы для развёртывания и управления приложениями на собственных серверах, подтвердили затронутость всех веток версии 4.x. Cisco и Sophos расследуют возможное влияние уязвимостей на свои продукты.

Весьма приятно, что в финальную версию статьи вошли и упоминания конкретных продуктов Positive Technologies, помогающие защититься от этих уязвимостей:

В более защищенной позиции оказываются компании, которые защищают свой веб-периметр решениями класса WAF (Web Application Firewall). Такие инструменты блокируют нелегитимные запросы извне и попытку эксплуатации уязвимости. Важно, чтобы разработчик WAF смог быстро отреагировать на новую угрозу и занести в продукт знания о ней и логику защиты. Так, например, защита от эксплуатации PHP2Shell появилась в PT AF Cloud, продукте Positive Technologies, автоматически еще до первых каких-либо подтвержденных атак через новую уязвимость.

На фоне появления новых данных об эксплуатации PHP2Shell важно оперативно оценивать, какие системы в инфраструктуре могут быть подвержены риску. Системы управления уязвимостями, например MaxPatrol VM, помогут обратить внимание на эту угрозу: уязвимости PHP2Shell отмечены в продукте как трендовые. Специалисты смогут учитывать их при анализе защищённости инфраструктуры и планировании работ по устранению уязвимостей. Зафиксировать попытки эксплуатации уязвимости могут продукты класса NTA/NDR, например, PT NAD, а также межсетевые экраны нового поколения, такие как PT NGFW.

…

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

В начале сентября коллеги из Cloud Advisor выпустили исследование "Состояние облачной безопасности в России. Анализ защищённости инфраструктур, развёрнутых в российских публичных облаках"

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

В начале сентября коллеги из Cloud Advisor выпустили исследование Состояние облачной безопасности в России. Анализ защищённости инфраструктур, развёрнутых в российских публичных облаках

В начале сентября коллеги из Cloud Advisor выпустили исследование "Состояние облачной безопасности в России. Анализ защищённости инфраструктур, развёрнутых в российских публичных облаках". Cloud Advisor - это вендор отечественного CNAPP (Cloud-Native Application Protection Platform) решения, позволяющего искать на облачных активах (виртуальных машинах и Kubernetes) уязвимости, вредоносный код, секреты и мисконфигурации. Отчёт о состоянии облачной безопасности в России опирается на реальные данные десятков организаций, имеющих не менее 80 виртуальных машин в публичном облаке (Cloud Ru и Yandex Cloud). Всего было проанализировано более 40 000 виртуальных машин. Период исследования - первое полугодие 2026 года.

По уязвимостям результаты следующие:

🔻 83% виртуальных машин имеют уязвимости с CVSS выше 9,0;
🔻 88% организаций имеют на публично доступных машинах уязвимости с CVSS выше 9,0;
🔻 27% организаций до сих пор уязвимы к Log4Shell (CVE-2021-44228);
🔻 42% организаций имеют хотя бы одну виртуальную машину на периметре с ОС, находящейся в статусе EOL (всего EOL-систем в облаках около 9%).

В части Управления Уязвимостями эксперты Cloud Advisor рекомендуют:

🔹 Внедрить регулярное сканирование виртуальных машин и образов контейнеров на уязвимости, используя для этого безагентные cloud native-решения. "Таким образом можно обеспечить 100% покрытие без трудозатрат на установку агентов и настройку SSH-доступов".

🔹 Приоритизировать уязвимости по контексту, а не только по CVSS. Помимо CVSS и наличия эксплойтов рекомендуют учитывать "публичную доступность ресурса, наличие на нём секретов в открытом виде, его права и другие факторы".

🔹 Установить и соблюдать SLA на устранение уязвимостей в зависимости от их критичности. "Без фиксированных сроков CVE накапливаются годами - как это произошло с Log4Shell".

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

В начале августа Qualys представили новые возможности по анализу уязвимостей самописных (First-Party) и опенсурсных приложений

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

В начале августа Qualys представили новые возможности по анализу уязвимостей самописных (First-Party) и опенсурсных приложенийВ начале августа Qualys представили новые возможности по анализу уязвимостей самописных (First-Party) и опенсурсных приложенийВ начале августа Qualys представили новые возможности по анализу уязвимостей самописных (First-Party) и опенсурсных приложений

В начале августа Qualys представили новые возможности по анализу уязвимостей самописных (First-Party) и опенсурсных приложений.

Вот, допустим, есть у вас в организации самописная софтина. Её пилят ваши разрабы. Естественно на основе опенсурса. Возможно ваши апсеки периодически проверяют её SAST-ом/DAST-ом и детектят-исправляют уязвимости. Но ваше VM-решение об этой софтине не знает и, соответственно, уязвимости для неё не детектирует. Более того, даже если вы знаете, что версии этой софтины уязвимых софтов. Причём какие-то софты явно забыли и VM-решения в таких софтах Log4Shell не продетектируют. Как и в вашей доморощенной софтине, которая также использует Log4j. Получается такое детектить надо не от софта, а непосредственно от либы, jar-ники искать и анализировать каким-то сторонним решением. И эта активность тоже, получается идёт мимо вашего дорогущего VM-а. Плохо это? Плохо. Зачем VM брали-то тогда! 🙄😁

Что предлагает Qualys. Во всяком случае то, что я понял из достаточно пространной видяшки и поста.

1. Custom Assessment and Remediation (CAR), о котором я раньше уже писал. Это механизм для добавления собственных скриптовых детектов, в том числе на PowerShell и Python. Написали свой скрипт детекта (например по версиям, которые вам апсеки сказали), добавили в Qualys - получили уязвимые хосты. Такие уязвимости будут иметь QID и с ними можно работать как с уязвимостями, которые продетектил сам Qualys.

2. Runtime Software Composition Analysis (SCA). Это композиционный анализ. Во время сканирования на наличие уязвимостей детектируется не только сам софт и его версия, но и используемые этим софтом библиотеки.

"SCA сканирует уязвимости в компонентах с открытым исходным кодом, разработанных для Java, Go, .Net, Python, Node JS, Rust, Ruby, PHP и других. Добавление SCA расширяет возможности сканирования VMDR, добавляя более 13 000 новых сигнатур, охватывающих более 11 000 CVE."

Фактически это сводится к тому, что Qualys Agent бегает по файловой системе и ищет/анализирует файлики библиотек (в т.ч. Log4j). Это не супер-новшество. Такие детекты я давно видел в Microsoft Defender for Endpoint. Видимо это становится обязательной фичой.

В общем, VM-вендоры, присмотритесь к кейсам! Клиенты VM-вендоров, задавайте им неудобные вопросы! 😉

На днях вышел бюллетень CISA про эксплуатацию уязвимости Log4Shell (CVE-2021-44228) в некоторой американской государственной организации

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

На днях вышел бюллетень CISA про эксплуатацию уязвимости Log4Shell (CVE-2021-44228) в некоторой американской государственной организации. В pdf бюллетене приводится подробное описание атаки. Ознакомился. Мне, конечно, было наиболее интересно собственно про Log4Shell и начальную эксплуатацию.

1. В какой организации произошел инцидент? Непонятно. Это одна из FCEB organizations. Это может быть всем известная NASA, а может быть какая-нибудь Commission of Fine Arts. Но по большей части организации в списке выглядят критично.

2. Когда нашли? В апреле 2022. Предположительное время компрометации - февраль 2022 года.

3. Как нашли? Через ретроспективный контроль трафика с помощью CISA-вской EINSTEIN IDS. Увидели ip-адрес ранее засветившийся в атаках использующих Log4Shell.

4. Как известно Log4Shell (CVE-2021-44228 заведена 10.12.2021) касается кучи продуктов, а что именно поломали? VMware Horizon. Патч вышел 16.12.2021. Детект у Tenable для этой уязвимости (без аутентификации) вышел 07.01.2022. CISA требовали зафиксить все Log4Shell уязвимости до 24.12.2021.

5. Исходя из таймлайна, в сроки CISA (7 дней по факту) уложиться было мало реально. Причем это нужно было сделать ещё до появления нормальных детектов. Но то, что не уложились даже за 1-2 месяца вплоть до успешной атаки злоумышленников это конечно неслабое нарушение. И раз такое в принципе было возможно, CISA видимо не особо контролирует VM процесс в подопечных FCEB организациях, а сроки устранения, которые они спускают через свой Known Exploited Vulnerabilities Catalog видимо по факту не выдерживаются.

Классная была задумка в NVD добавлять лейблы к ссылкам

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

Классная была задумка в NVD добавлять лейблы к ссылкам

Классная была задумка в NVD добавлять лейблы к ссылкам. Чтобы сразу было видно на какой объект ссылаются: почтовая рассылка, бюллетень вендора, бюллетень третьих лиц, патч, а самое ценное - эксплоит. То есть можно было бы только на основе NVD делать достаточно неплохую приоритизацию уязвимостей. Но реальность, к сожалению, грустнее:

1. На простановку лейблов всем так-то пофигу. На скриншоте log4shell. Для части ссылок на packetstorm проставлено, что это эксплоиты. Для части нет. Может это на самом деле не эксплоиты? Да нет, все верно, я обкликал и проверил. Просто ошибка операциониста, который ссылку добавлял.
2. Заинтересован ли кто-то быстро добавить в NVD ссылку на эксплоит, когда он появляется в паблике? Да видимо не особо. Разве что для очень громких уязвимостей.
3. Это общая беда, но в описании CVE могут писать про один тип уязвимости, допустим RCE, а эксплоит будет демонстрировать другую уязвимость, допустим DoS.

Выводы? Спасибо, что хотя бы так и бесплатно. 🙂 Но исключительно на данные из NVD лучше не полагаться.