Что там слышно по инцидентам, связанным с эксплуатацией 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 и ИБ (особенно, когда миллиардами ворочаете). Не работайте с идиотами или хотя бы пытайтесь их обучать. 😉

Видеозапись моего выступления на 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.

Попался на глаза мем "объясните Управление Уязвимостями своими словами" - перевёл его в виде комикса

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

Попался на глаза мем объясните Управление Уязвимостями своими словами - перевёл его в виде комикса

Попался на глаза мем "объясните Управление Уязвимостями своими словами" - перевёл его в виде комикса. В целом, типичный процесс Управления Уязвимостями в организации (с точки зрения VM-щика, естественно 🙂) - это разгребание постоянных косяков:

🔻 в работе инструментов детектирования уязвимостей (в принципе неподдерживаемое ПО и типы активов, фолсы, баги);

🔻 в качестве информации об уязвимостях (вроде эксплуатируется - но фиг знает как, где и кем; вроде эксплойт есть, но фиг знает, что конкретно он делает и при каких условиях работает);

🔻 в состоянии проверяемой инфраструктуры и понимании того, из чего она состоит, как НА САМОМ ДЕЛЕ функционирует и что в ней критично;

🔻 в безответственности формально ответственных за состояние инфраструктуры людей;

🔻 в отсутствии интереса со стороны руководства (пока не настанет полнейший карачун).

Это утомительное бесконечное бодание с аргументацией вроде "мы не будем ничего обновлять, это может нам что-то сломать" - при полном отсутствии плана тестирования, оценки рисков или конкретных шагов по устранению проблемы. 😖

И руководству следовало бы, конечно, задаваться не вопросом "Насколько мы защищены?" (здесь и сейчас), а гораздо более важным: "Понимаем ли мы, какими активами располагаем, какие риски с ними связаны, знаем ли, кто несёт за них ответственность и насколько эффективно ими управляют?" Так, чтобы Управление Уязвимостями перестало быть задачей одного несчастного технаря, практически не имеющего рычагов воздействия на решения, принимаемые в организации, и стало частью корпоративного управления…

Но это, конечно, уже что-то из области фантастики. 😅👽

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

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

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

По поводу ночных ложных оповещений о ракетно-ядерном нападении через мобильные приложения и соответствующие системы в России и в сопредельном вражеском государстве. Ничего удивительного в этом нет. Любые IT-системы, любые приложения содержат уязвимости, и их можно взломать. 💯

Если для государственного заказчика рассылка такого рода массовых ложных уведомлений является недопустимым событием, значит, вероятность его наступления следует снижать различными методами: выстраивание процесса Управления Уязвимостями, харденинг, SDLC, (авто)пентесты, мониторинг инцидентов и так далее. На всё это необходимо выделять ресурсы. Если ресурсы на это не выделяются и рассылка ложных сообщений не считается недопустимым событием, то чего удивляться, если подобные инциденты периодически происходят? 🤷‍♂️

По поводу, собственно, сути таких оповещений. Учитывая начавшиеся ещё в 90-х годах процессы, приведшие к сокращению подлётного времени, а также рассекреченные документы о нацеливании натовских ракет, лично у меня нет иллюзий, что получится надёжно укрыться от трайдентов и минитменов в час X. Максимум - если получится до подвала спуститься. 🙂 Так что в этой печальной ситуации остаётся только надеяться, что наши не спасуют и реализуют принцип "око за око, зуб за зуб" в максимальном объёме. 😉🕊

Про уязвимость 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.

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