Растем в VMware от Guest до Host через CVE-2023-20870 + CVE-2023-34044 + CVE-2023-20869
#VMware #CVE #Bluetooth

Исследователь r0keb подробно разобрал и воспроизвел цепочку уязвимостей в VMware Workstation 17.0.0, позволяющую выполнить полноценный Guest-to-Host escape, имея только доступ к гостевой системе.

Техническая суть

Атака включает два этапа.

Первый — memory leak (CVE-2023-20870 и CVE-2023-34044) через неинициализированные USB Request Blocks (URB) в виртуальных устройствах Bluetooth и Mouse. malloc без обнуления + повторное использование LFH-бакетов (0xb0) позволяет гостю утечь указатель на базу vmware_vmx.exe и обойти ASLR.

Второй — stack-based buffer overflow (CVE-2023-20869) в обработчике SDP-пакетов (функции SDPData_ReadElement и последующие memcpy). Специально сформированный SDP_SVC_SEARCH_ATTR_REQ с вложенным атрибутом типа SDP_DE_UINT и переразмеренным полем AttributeIDList (~0x28f байт) вызывает два последовательных переполнения стека, затирающих return-адреса и дающих контроль над RIP.

Эксплуатация

Включить шаринг Bluetooth-устройства с гостем
Через libusb взаимодействовать с виртуальным Bluetooth (VID:0x0e0f, PID:0x0008) и Mouse (PID:0x0003)
Выделять и освобождать URB мыши для заполнения LFH-бакета размером 0xb0
Читать неинициализированную память через control transfer (wLength=0x80) → утечка базы vmware_vmx
Перезагрузить btusb/usbhid модули в госте
Установить L2CAP/SDP-сессию с внешним Bluetooth-устройством (телефон и т.д.)
Отправить crafted SDP-пакет с oversized AttributeIDList (0x28f байт) и SDP_DE_UINT
Выполнить ROP-цепочку на хосте (пример — запуск calc.exe)

Импакт

Полный прорыв изоляции виртуальной машины: из скомпрометированной гостевой ОС атакующий получает arbitrary code execution на хосте с правами процесса vmware-vmx. Это позволяет закрепиться на хосте, похищать данные, атаковать другие ВМ на этом же хосте или использовать машину для последующих атак.

Источник

@poxek | MAX | Блог | YT | RT | VK

Один вопрос эксперту  Kaspersky
#ai #llm #cybersecurity

Если бы мне дали 5 минут с экспертом  Kaspersky, я бы спросил одно: видели ли вы в дикой природе малварь, которую генерила LLM? Не ПОК с какой-то конфы, не демо из пресс релиза, а реальный сэмпл из инцидента. Потому что "AI-угрозы растут" пишут все, а артефакты не показывает никто.

9 апреля в 11:00 МСК можно будет спросить. Kaspersky проводит вебинар про AI в кибербезе, и среди спикеров - Владислав Тушканов (рук. исследований ML) про prompt injection - проблеме 4 года, а закрыть её так и не смогли. Олег Горобец про AI-инструменты для защиты - что работает, а что "AI-powered" только на лендинге. И Андрей Гунькин, старший вирусный аналитик. Человек, который видит малварь каждый день. 

Регистрация: ТЫК

Эскалация привилегий в AWS CodeBuild через CodeConnections
#AWS #IAM #PrivilegeEscalation #CloudSecurity

Исследователь Thomas Preece представил сценарий эскалации привилегий в AWS CodeBuild с использованием CodeConnections. Автор демонстрирует, как атакующий, имея права на управление проектом, может использовать привязанную к нему IAM-роль с избыточными полномочиями. В рамках кейса через конфигурацию проекта задействуется AWS CodeConnections (codestar-connections), что позволяет выполнять произвольный код в доверенном контексте облака.

Технические нюансы

Уязвимость возникает при сочетании трех факторов:

Права на codebuild:StartBuild или изменение конфигурации проекта
Доступ к AWS CodeConnections (codestar-connections)
IAM-роль CodeBuild с расширенными правами (например, доступ к Secrets Manager, STS или S3)

Во время сборки атакующий может модифицировать buildspec или код в репозитории, выполнять произвольные команды внутри build-окружения и использовать временные учетные данные привязанной IAM-роли. CodeConnections выступает доверенным мостом к внешнему репозиторию, упрощая доставку вредоносного кода без прямого вмешательства в инфраструктуру.

Эксплуатация

Получение прав на запуск или модификацию проекта CodeBuild
Подключение или использование существующего CodeConnections и изменение buildspec или кода в репозитории
Запуск билда и выполнение команд в контексте IAM-роли сервиса
Извлечение временных учетных данных для дальнейшего продвижения по облаку

Импакт

Эскалация привилегий внутри AWS-аккаунта. Атакующий получает доступ к чувствительным ресурсам (Secrets Manager, S3 и другим сервисам AWS) и возможность закрепиться в среде. При слабой сегментации прав это может привести к полной компрометации облачной инфраструктуры.

Источник

@poxek | MAX | Блог | YT | RT | VK

Разбор CTF-челленджа от CryptoCat: эксплуатация небезопасной десериализации через Oj.load() в Ruby-приложении
#Ruby #RCE #CTF #RubitMQ

Исследователь представил writeup решения CTF-челленджа YesWeHack Dojo #48: RubitMQ от CryptoCat. В рамках работы он отправил специально сформированный JSON, который при десериализации инжектит встроенный gadget класса Node, позволяющий через аргумент find . -exec добиться RCE и прочитать флаг.

Что примечательно, здесь нет прямого eval/system, поэтому эксплуатация строится через классический Unix-gadget find.

Технические нюансы

Уязвимость связана с использованием Oj.load(payload) без опции :mode => :strict или ограничения допустимых классов. Библиотека Oj по умолчанию допускает десериализацию произвольных Ruby-объектов. Автор использует built-in gadget класса Node (из стандартной библиотеки или зависимостей), который приводит к контролируемому вызову find с флагом -exec. Это позволяет внедрить shell-команду в аргумент -exec, которая выполняется при обработке job.

Эксплуатация

Сформировать malicious JSON с сериализованным объектом класса Node с контролируемым аргументом
В аргументе указать find . -exec <command> \; или эквивалент для получения RCE
Отправить пейлоад в эндпоинт обработки job через RabbitMQ-подобный интерфейс или API
При вызове Oj.load() происходит десериализация → инъекция gadget → выполнение find -exec → запуск произвольной команды

Импакт

RCE на сервере приложения. Атакующий может читать файлы (включая флаг), выполнять произвольные команды, потенциально эскалировать привилегии и полностью скомпрометировать хост.

Источник

@poxek | MAX | Блог | YT | RT | VK

мне нравятся посты Андрея Жукова, как он люблю налюбливать хацкеров. Плюс мне нравится как Бумыч и его команды выстроили превентивную защиту внешки. Собственно может попробовать сделать что-то аналогичное, но против вайб-хакеров? Потому что я вижу явное отставание защиты от этого, особенно больно это ощущается на багбаунти. Может есть кто из компаний, кто хочет воспользоваться моим альтруизмом и попробовать в рамках теста что-то защитить? Можно начать с чего угодно не критичного. Что думаете? Если есть желающие, то вы знаете куда стучаться

Препарация macOS-стилера, работающего in the wild
#macOS #AMOS #Infostealer #Apple #ThreatHunting

Исследователь Pablo Redondo Castro разобрал свежий macOS-стилер (он связывает образец с AMOS Stealer), сделав акцент на обфускации, маскировке под системные компоненты и abuse LoLBin. Изученный семпл рекламировался в интернете и распространялся по сети под видом легитимные обновления ПО.

Пайплайн атаки

Заражение — начинается с curl, декодирующей Base64-закодированный пейлоад и исполняющей его через zsh. Далее загружается loader, который оркестрирует выполнение двух обфусцированных AppleScript.

Обфускация и исполнение — строки разбиты на 400+ переменных и закодированы математическими операциями. Используются три функции деобфускации: вычитание, сложение и вычитание со смещением. Финальные команды собираются динамически и исполняются через osascript.

Defense evasion — стилер завершает процессы Little Snitch, BlockBlock, LuLu, может проверять признаки sandbox/VM и максимально опирается на штатные утилиты macOS.

Закрепление — создается LaunchAgent ~/Library/LaunchAgents/com.apple.mdworker.plist с маскировкой под системный компонент Spotlight. Внутри — inline-обфусцированный AppleScript, запускаемый через /bin/sh -c "osascript -e".

Сбор данных — используются встроенные инструменты: security find-generic-password для доступа к Keychain, кража данных браузеров (Chrome, Safari и др.), 256 hardcoded wallet extension ID, копирование NoteStore.sqlite и медиа Apple Notes, а также пользовательских документов (.pdf, .docx, .key и др.) до 30 МБ.

Privilege & user interaction — используется социнженерия через фейковые системные диалоги для получения пароля. Доступ к TCC и привилегиям администратора достигается через действия пользователя.

Экcфильтрация — данные агрегируются в /tmp, упаковываются через tar -czf и отправляются на C2 по HTTP(S) с помощью curl.

Источник с IOC

@poxek | MAX | Блог | YT | RT | VK

Пост хорошо судя по всему зашел)

Хватит ныть про галлюцинации, бери LLM и пробуй
#pentest #ml #llm #ai #security

Слышу одно и то же: "LLM тупые", "галлюцинируют", "нельзя доверять". Окей. Давай по фактам.

Любой ответ LLM - математическая вероятность. Правильный ты принимаешь молча, неправильный обзываешь "галлюцинацией". Но фронтир модели в среднем точнее тебя в незнакомом домене. Это не мнение.

Что уже работает

AI SAST: Claude нашёл 500+ уязвимостей в продакшн open-source проектах - баги, которые люди не замечали годами. Aardvark от OpenAI - 92% detection rate и 10 CVE. Но это маркетинг скорее всего, есть реальные результаты у знакомых.

Генерация payload: Пентестер не смог раскрутить SQLi. LLM смогла. Верь не верь, но кто-то уже делает пизже

Автономный пентест: Вот тут конечно спорно, я пробовал разные подходы для aka CPT, чисто рой агентов как в XBOW мне не зашёл из-за недетерминированности. Но детерминированный код + AI в некоторых узлах вполне работает.

"А утечки данных через API?"

Справедливо. Для чувствительных проектов - локальные модели: DeepSeek, Qwen, кастомные с HuggingFace. Для остального - облачные Claude Code, OpenAI Codex. Требует бо́льших компетенций? Да. Но и ты вроде не тупой)

Кому можно не париться

Есть процент уникумов, которые находят 0-day на чистой интуиции. Можешь сам оценить - из таких ты или нет. Если нет - LLM даст тебе разрыв, который без нейронок ты просто не получишь.

Но HITL обязателен

LLM мощнее тебя в отдельных задачах, но AI пишет + AI ревьюит + AI деплоит = утопия, которая громко схлопнется. Перепроверяй детерминированно: через код, через ручное ревью. Human In The Loop - не опционально.

Сам использую Claude Code, OpenAI Codex, DeepSeek, Qwen локально, плюс тестирую кучу кастомных моделей с HuggingFace. До сих пор не упёрся в потолок - просто не хватает рук и знаний (это стараюсь курсами компенсировать) всё автоматизировать и проверить на стабильность.

"Не начнёшь ты сейчас - ну окей, начнет другой" © Серёга Похек

Давно назревало написать пост на тему

@poxek | MAX | Блог | YT | RT | VK

Фишинг через современные возможности браузера: фейковый экран блокировки Windows
#Phishing #WebGL #FullscreenAPI #KeyboardLock #RedTeam #BrowserSecurity
Коллеги из CERTITUDE опубликовали интересную технику продвинутого фишинга, использующую современные API браузеров для создания крайне убедительного фейкового экрана блокировки Windows.
Как это работает
> Пользователь совершает одно действие (например, клик по cookie-баннеру), после чего сайт вызывает Element.requestFullscreen()
> Запускается тяжелый WebGL fragment-шейдер с вложенными циклами, который намеренно перегружает GPU и скрывает системное уведомление браузера о переходе в полноэкранный режим
> После кратковременной заморозки шейдер останавливается, и страница занимает весь экран без видимых предупреждений
> Через Google One Tap в скрытых iframe извлекаются реальные аватар и имя пользователя
> С помощью CSS-трюков (border-radius, scale, filter, mix-blend-mode) данные органично встраиваются в фейковый Windows lockscreen
> Активируется Keyboard Lock API, который блокирует клавиатуру (выход требует длительного удержания Esc)
Почему это работает
Современные браузеры предоставляют мощные клиентские API (Fullscreen, WebGL, Keyboard Lock) для легитимных сценариев (игры, immersive-приложения), но с минимальными защитными ограничениями. Fullscreen требует всего одного user gesture, WebGL позволяет запускать ресурсоемкие шейдеры без жестких лимитов, а Same Origin Policy не препятствует визуальному отображению кросс-ориджин контента.
> Источник
@poxek

RCE через ImageMagick: от arbitrary file read до обхода всех политик (0-day)
#ImageMagick #RCE #Ghostscript #RedTeam #0day

Исследователи pwn.ai опубликовали 0-day цепочку в ImageMagick, позволяющую перейти от обычного file upload к полноценному RCE даже при включенных политиках безопасности (default, limited и secure policy). Уязвимость затрагивает большинство стандартных конфигураций и потенциально масштабируется на миллионы систем.

Эксплуатация

Атака построена на комбинации: определение формата по magic bytes, доступ к внутренним coders/protocol handlers (text:, EPSI, EPT) и вызов внешнего delegate — Ghostscript. Это дает arbitrary file read/write и delegate execution через один загруженный файл.

> Атакующий загружает файл с расширением .jpg, но в начале подделывает magic bytes SVG (<?xml). ImageMagick определяет формат по содержимому, а не по расширению, и обрабатывает файл как SVG.
> Через <image xlink:href="text:/etc/passwd"/> или /proc/self/environ, .env достигается arbitrary file read.
> Для записи используется EPSI/PDF/EPT кодеры: они не попадают в блэклист PS/EPS и все равно вызывают Ghostscript.
> Добавление одного \n перед %!PS ломает детект PostScript в ImageMagick, при этом Ghostscript исполняет пейлоад.
> Ghostscript в режиме -dSAFER блокирует exec, но разрешает file I/O — используется для arbitrary file write (вебшелл или реверс шелл).

Атака работает даже в secure-конфигурациях и на актуальных версиях.

> Источник

@poxek

Обход защиты в залоченном UEFI BIOS ноутбуков Dell
#UEFI #BIOS #Dell #RedTeam #HardwareSecurity #BitLocker

Попалась интересная техника обхода защитных механизмов в заблокированном UEFI BIOS ноутбуков Dell. Реализуется через прямой патчинг firmware-образа на уровне SPI flash. По сути это наглядная демонстрация того, что firmware-level модификации остаются мощным вектором атаки даже на «защищенных» корпоративных устройствах.

Что нужно для атаки

> Физический доступ к устройству
> Для анализа и патчинга: flashrom (дамп и прошивка), UEFITool (навигация по образу), IFRExtractor (парсинг IFR-форм) и кастомный Python-патчер (есть в гайде)
> DMAReaper для модификации таблицы DMAR (ACPI)
> PCILeech для проведения DMA-атаки

Атака

> Сначала снимается дамп firmware через flashrom (внутренним способом или с помощью внешнего клипа на SPI-чип).
> Образ открывается в UEFITool, извлекается Setup-модуль, далее через IFRExtractor находится нужное смещение (VarOffset 0x975), где значение «Control Iommu Pre-boot Behavior» меняется с 0x01 на 0x00.
> Модифицированный образ прошивается обратно. После перезагрузки BIOS продолжает отображать защиту как включённую, но фактически IOMMU в pre-boot отключён.
> Далее возможна загрузка в Safe Mode, отключение VBS и проведение DMA-атаки через PCILeech для патчинга памяти и получения SYSTEM-шелла.

Техника позволяет обходить защиту от DMA-атак даже на системах с заблокированным BIOS-паролем и TPM-based BitLocker. Патч сохраняется даже после официальных обновлений BIOS Dell.

> Источник

@poxek

$10k от Google за RCE-баг в Antigravity
#AI #Google #BugBounty #RCE #Antigravity

Antigravity — agentic IDE на базе Gemini, предназначенная для генерации кода, планирования и разработки приложений с участием AI-агента. По сути представляет собой продолжение Windsurf IDE, ранее приобретенной Google. Исследователь обнаружил в Antigravity уязвимость, позволявшую атакующему добиться RCE на системе пользователя и получил за нее вознаграждение в размере $10k.

Эксплуатация

Браузерное расширение Antigravity принимало внешние сообщения через chrome.runtime.onMessageExternal без проверки источника (sender.origin), что позволяло любому сайту взаимодействовать с его API. Ключевое уязвимое действие — SaveScreenRecording в service_worker_binary.js. Атакующий мог отправить специально сформированное сообщение с контролируемыми параметрами:

▪️ action: "SaveScreenRecording"
▪️ za — массив байт (содержимое записываемого файла)
▪️ filename — имя файла
▪️ L — путь к директории

Обработчик без валидации формировал путь вида: %APPDATA%\.gemini\antigravity\brain\<L>\<filename>. За счет path traversal (../ в L и filename) атакующий мог выйти за пределы рабочей директории и добиться записи пейлоада в произвольное место файловой системы.
RCE достигается через arbitrary file write: path traversal позволяет записать пейлоад в Startup, файлы проекта или скрипты Antigravity. При открытии workspace или перезапуске происходит выполнение кода.

Ключевые особенности

▪️ Запись файла происходила даже при ошибке gRPC — отсутствие промежуточных директорий не препятствовало созданию файла.
▪️ Уязвимость не требовала prompt injection — эксплуатация происходила напрямую через механизм внешних сообщений.
▪️ AI-агент мог косвенно инициировать вызов уязвимого действия (например, через сценарии screen recording), но основной вектор — отправка внешнего сообщения.

🔗 Источник (https://www.hacktron.ai/blog/hacking-google-antigravity)

@poxek

Head Mare компрометирует серверы TrueConf и распространяет бэкдор PhantomPxPigeon через подмену клиентских дистрибутивов
#TrueConf #backdoor #RCE #Kaspersky

Специалисты Лаборатории Касперского опубликовали отчет о новой волне кампании группировки Head Mare. Атакующие компрометируют self-hosted серверы видеоконференций TrueConf и заменяют легитимные клиентские установщики на троянизированные версии в директории ClientInstFiles. Пользователи, скачивающие клиент с этих серверов, получают вдовесок ранее неизвестный бэкдор PhantomPxPigeon.

На этапе взлома серверов, по данным Лаборатории Касперского, вероятно, использовалась уже известная уязвимость BDU:2025-10116 (RCE), закрытая вендором в августе 2025 года. Так что под угрозой находится весь непропатченный софт.

PhantomPxPigeon — бэкдор для удаленного выполнения команд и управления хостом через C2. Поддерживает загрузку и исполнение дополнительных пейлоадов, операции с файловой системой и закрепление в системе. Используется в связке с нативными утилитами ОС и легитимными инструментами, что усложняет детект за счет смешивания с обычной административной активностью.

Ключевой индикатор компрометации — отсутствие действительной цифровой подписи у файла установщика TrueConf. Все официальные дистрибутивы подписаны разработчиком.

Подробности и IOC (включая MD5 хэши вредоносных установщиков).

@poxek

Active Directory Certificate Services (AD CS): инфраструктура и методы обнаружения атак
#ADCS #ActiveDirectory #Kerberos #Misconfiguration #EDR

BI.ZONE выпустили огромное исследование по AD CS, по сути целый учебник, начинающийся в базовых знаний по архитектуре корпоративной PKI (CA, шаблоны сертификатов, enrollment, trust chain) и включающий подробное описание сценариев эксплуатации от ESC1 до ESC16.
Ключевой тезис труда: AD CS — это implicit Tier-0 актив, фактически «скрытый доменный администратор». При некорректной конфигурации (что повсеместно) атакующий может получить полный контроль над доменом через выпуск доверенных сертификатов, причем без компрометации паролей, LSASS или NTLM/Kerberos-кредов.

Сертификаты — слабое место

Критическая поверхность атаки — Certificate Templates (ESC1–ESC4 и далее):
▪️ESC1 (SAN abuse) — возможность указать произвольный Subject Alternative Name, дает аутентификацию от имени любого пользователя, включая Domain Admin
▪️ESC2 (Any Purpose / отсутствие EKU) — выпуск универсального сертификата, пригодного для аутентификации
▪️ESC4 (ACL abuse) — модификация шаблонов через права (WriteDACL / GenericAll / WriteOwner) с последующим превращением их в уязвимые
Если Enterprise CA интегрирован с AD, выданный сертификат автоматически доверяется для аутентификации (Kerberos PKINIT, smart card logon). Это означает, что сертификат = полноценный credential внутри домена.Причем для эксплуатации чаще всего достаточно низкопривилегированной учетной записи + доступа к уязвимому шаблону.
▪️Дополнительный фактор риска — избыточные ACL на объектах PKI (Certificate Templates, Enrollment Services, NTAuthCertificates и др.), особенно если права выданы группам уровня Domain Users или Authenticated Users.

Специфика атак

Атаки на AD CS практически включены в цепочки злоупотреблений конфигурацией. Получив доступ к одному слабому месту, атакующий может: модифицировать шаблон (ESC4), сделать его уязвимым под ESC1/ESC2, выпустить привилегированный сертификат или аутентифицироваться как Tier-0 пользователь.

Таким образом, один локальный мисконфиг в PKI перерастает в полную компрометацию домена. Эти атаки особенно опасны тем, что они не требуют эксплуатации memory corruption или RCE, плохо детектируются классическими средствами (нет «шумных» действий вроде dump LSASS) и используют легитимные механизмы инфраструктуры (certificate-based auth).

🔗 Обязательно к прочтению

@poxek

2 полезных ресурса по информационной безопасности и этичному хакингу:

ZeroDay — практические уроки по пентесту, защите сетей и анонимности от действующего специалиста по информационной безопасности.

infosec — ламповое сообщество, которое публикует редкую литературу, курсы и полезный контент для ИБ специалистов любого уровня и направления.

Трансформация рынка интернет-пиратства в России на фоне блокировок и падения выручки
#research #F6

F6 выпустила подробный анализ отечественного рынка интернет-пиратства. Как оказалось, в 2025 году владельцы пиратских сайтов заработали $34,4 млн, что на 5,5% меньше год к году. Это самый низкий показатель за последние десять лет. Пик доходов пришелся на 2018 год ($87 млн) и с тех пор неминуемо падает, как и CPM.

Уходим с сайтов в соцсети

Эксперты связывают падение доходов с падением числа поисковых запросов на пиратские порталы на 5,1%. При этом вырос трафик на легальные онлайн-кинотеатры на 27,6%. Также в 2025 году заблокировано 304,5 тысяч пиратских страниц — больше, чем суммарно за 2022–2024 годы. На фоне всего этого пираты активно осваивают соцсети и видеохостинги как канал распространения пиратского контента. Мессенджеры, наоборот, теряют популярность.

Также пираты

▪️Маскируют URL, вместо названий фильмов используя случайные строки или поддомены
▪️Регистрируют домены, похожие на известные бренды, чтобы выглядеть легитимно
▪️Прячут контент через обфускацию, например, описание фильмов в азбуке Морзе
▪️Используют DLE + AI-рерайт, чтобы обходить фильтры поисковиков
▪️Массово используют дешевые .ru-домены без явной связи с контентом

Сращивание с белым рынком

Согласно отчету, до 89% рекламы на пиратских порталах — легальная, что усиливает «сращивание» с белым рынком. Даже пиратские CDN предлагают вебмастерам выбирать тип отображаемой рекламы в плеере. Например, самый используемый формат рекламы — Content Roll, и во всех изученных пиратских сайтах на нем располагалась только легальная реклама. Количество крупных игроков черной рекламы сокращается, разбавляя пиратские порталы рекламой легальных брендов.

Прогноз

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

@poxek

Не злите белых хакеров: как одно фишинговое SMS привело к пробиву инфраструктуры фишеров
#fishing #story #white_hat #kotolampy_story

Однажды этичный хакер и исследователь киберпреступности Inti De Ceukelaire из ЕС получил фишинговое сообщение, отправленное якобы от имени банка Argenta. Базовый анализ фишинговой страницы вскрыл ряд банальных недостатков, эксплуатация которых привела к обнаружению еще нескольких примитивных уязвимостей.

В итоге исследователю удалось полностью скомпрометировать админ-панель, получить доступ к данным жертв и инфраструктуре. Также выяснилось, что операторами кампании, предположительно, были 18-22 летние студенты из Марокко и Франции, которые не скрывали результаты своей деятельности в соцсетях.
**
**Как проходил пробив

Автор ввел фейковые данные карты, проанализировал запросы через Chrome DevTools и обнаружил обращения к check-action.php и loading.php. В коде loading.php нашел скрытую ссылку на админ-панель и механизм проверки IP через текстовый файл.

Перешел на админ-панель и выяснил, что сессии привязаны только к IP без дополнительных проверок. Через Burp Suite обошел эту логику, имитируя доверенный источник, и получил доступ с правами администратора.

Внутри панели обнаружил функционал для просмотра экрана жертвы, копирования токенов и отправки уведомлений через Telegram (telegramclick.php). С помощью path traversal удалил его и другие файлы уведомлений, после чего операторы перестали получать алерты.

Затем обнаружил WordPress на том же домене, использовавшийся как фасад. Удалил wp-config.php, запустил мастер установки и получил административный доступ.

Напоследок, изменил код фишинговой страницы, из-за чего работала только для IP из Марокко.

Внутри инфраструктуры исследователь обнаружил крайне примитивную реализацию: данные жертв хранились в текстовых файлах, логи указывали на residential IP из Марокко и один университетский из Франции, присутствовал архив argg.zip с исходным кодом, токенами и личными логами, интерфейс для удаленного управления экраном жертвы и жестко заданные IP для блокировок.

Источник

@poxek | MAX | Блог | YT | RT | VK

CrackArmor: ваш AppArmor не так безопасен, как вы думали
#AppArmor #linux #kernel #LPE

Qualys TRU раскопали фундаментальную дыру в AppArmor - LSM, который включен по дефолту в Ubuntu, Debian и SUSE. Не одну уязвимость, а сразу девять. Баги сидят в ядре с версии 4.11 - с 2017 года.

Корень проблемы

Pseudo-файлы для управления AppArmor-профилями (/sys/kernel/security/apparmor/.load, .replace, .remove) имеют права 0666 - world-writable. Прямая запись от непривилегированного пользователя блокируется проверкой при write(), но open() проходит. Классическая confused deputy: открываем файл, делаем dup2() на stdout, запускаем привилегированную программу - и она пишет от нашего имени. Идеальным прокси оказался su -P (pty mode) - через него можно писать полностью контролируемые байты, включая null bytes. Результат: непривилегированный пользователь загружает, заменяет и удаляет произвольные AppArmor-профили.

Что это дает атакующему

➡️ Снятие защиты: удаление профилей для cupsd, rsyslogd и других сервисов одной командой:
su -P -c 'stty raw && echo -n rsyslogd' "$USER" > .remove
➡️ DoS: загрузка пустого (deny-all) профиля для sshd блокирует все SSH-подключения
➡️ Bypass user-namespace restrictions: загрузка userns-профиля обходит все известные ограничения Ubuntu, включая уже запатченные aa-exec, busybox и LD_PRELOAD байпасы
➡️ LPE до root: через комбинацию Sudo + Postfix. Загружаем AppArmor-профиль, который запрещает определенные syscall'ы для Sudo - создаем fail-open ситуацию, и Sudo отдает root

Уязвимости ядра

Помимо confused deputy, через загрузку вредоносных профилей эксплуатируются баги в парсере AppArmor:

▶️ Uncontrolled recursion - stack exhaustion при удалении глубоко вложенных субпрофилей. Kernel panic на x86-64
▶️ Out-of-bounds read - чтение 64KB за пределами 8KB kmalloc-буфера. Утечка kernel pointers, обход KASLR. Подтверждено на Ubuntu 24.04.3 и Debian 13.1
▶️ Use-after-free в kmalloc-192 slab cache - полная эскалация привилегий, работает даже с включенным CONFIG_RANDOM_KMALLOC_CACHES
▶️ Double-free в slab cache от kmalloc-8 до kmalloc-256 - эскалация привилегий, обходит CONFIG_SLAB_BUCKETS

Что делать

Патчить ядро. CVE пока не присвоены: по процессу Linux kernel идентификаторы назначаются через 1-2 недели после попадания фикса в stable release, чтобы дать время на обновление до публичного раскрытия.
Затронуты Ubuntu, Debian, SUSE и производные. Red Hat и Android используют SELinux вместо AppArmor - не затронуты.

🔗 Advisory (https://cdn2.qualys.com/advisory/2026/03/10/crack-armor.txt)
🔗 Блог Qualys (https://blog.qualys.com/vulnerabilities-threat-research/2026/03/12/crackarmor-critical-apparmor-flaws-enable-local-privilege-escalation-to-root)
🔗 Разбор на LWN (https://lwn.net/Articles/1062852/)

@poxek

Обходим аутентификацию в FreshRSS с «полувалидными» паролями
#FreshRSS #AppSec #bcrypt #AuthBypass

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

Если атакующий знает или угадывает первые 72 байта настоящего пароля пользователя, он может сформировать другой пароль, начинающийся с той же последовательности, но содержащий любые дополнительные символы в конце, и пройти аутентификацию.

Баг затронул только ветку edge и так и не попал в прод, но случай все равно показательный.

Принцип аутентификации

FreshRSS вместо отправки пароля пользователя на сервер в открытом виде использует challenge-response схему, в которой bcrypt применяется на стороне клиента. Клиент сначала запрашивает у сервера nonce (случайное одноразовое значение) и salt1 — первые 29 символов сохраненного bcrypt-хэша пользователя (версия алгоритма, cost-factor и соль).

После этого клиент вычисляет:
// bcrypt hash of password (60 chars)
s = bcrypt.hashSync(password, salt1);
// bcrypt hash of nonce + s
c = bcrypt.hashSync(nonce + s, randomSalt);
Затем отправляет значение c (challenge) на сервер, который проверяет его следующим образом:
password_verify($nonce . $hash, $challenge);

То есть сервер повторно вычисляет bcrypt-хэш для строки nonce + hash и проверяет, совпадает ли он с полученным challenge.
Использование nonce защищает схему от replay-атак. Даже если атакующий перехватит hash и challenge, повторно использовать их нельзя.

Как появилась проблема

В октябре 2025 года в FreshRSS внесли изменения, направленные на усиление криптографической схемы аутентификации. В значение nonce вместо шестнадцатеричного SHA-1 (40 символов) начали использовать шестнадцатеричный SHA-256 (64 символа). Поскольку bcrypt учитывает только первые 72 байта входной строки, при вычислении bcrypt(nonce + s) длина nonce начинает влиять на то, какая часть s (то есть bcrypt-хэша пароля) реально участвует в вычислении.

При коротком nonce часть строки, зависящей от пароля, могла обрезаться из-за ограничения bcrypt, что приводило к тому, что разные значения s давали одинаковый результат при вычислении bcrypt(nonce + s). Это позволяло сформировать альтернативный пароль, который проходил проверку аутентификации, хотя не совпадал с исходным.
После изменения длины nonce поведение bcrypt изменилось: значимая часть s, зависящая от пароля, начала полностью помещаться в 72-байтовое окно, поэтому truncation перестала влиять на результат.

🔗 Источник (https://pentesterlab.com/blog/freshrss-bcrypt-truncation-auth-bypass)

🌚 @poxek

"Управляемый бэкдор" в MAX: разбор вирусного фейка от Liberty
#MAX #разбор

Liberty выкатили тред, где называют CDN-сервер мессенджера MAX "модулем удалённого управления". 148K просмотров. Разберём по-взрослому — без эмоций и маркетинга.

Что реально происходит

В начале марта на ntc.party и Хабре разобрали сетевой трафик MAX.

Нашли модуль HOST_REACHABILITY:
➡️ Пингует Telegram, WhatsApp, gosuslugi.ru
и ещё ряд хостов
➡️ Тянет IP-адрес из нескольких чекеров
➡️ Смотрит статус VPN через Android ConnectivityManager API
➡️ Отправляет собранное на api.oneme.ru

Это нашли ребята с Хабра, подтвердили реверсом APK. Вопросы к такой телеметрии — справедливы.

А теперь — фейковая часть

Liberty взяли чужое исследование и докрутили: st.max.ru
— это, мол, "домен удалённого управления, который руководит приложением в вашем смартфоне".
На деле st.max.ru
— CDN для статики. Он указан в документации MAX для разработчиков:
<script src="https://st.max.ru/js/max-web-app.js"></script>
https://dev.max.ru/docs/webapps/bridge
— откройте и проверьте сами.
Liberty называют скачанный 1 МБ "размером с целую книгу" команд. Ок, 1 МБ — это действительно объём небольшой книги. Но это и объём пачки эмодзи, иконок и JS-библиотек. Стандартный набор для мессенджера с
мини-приложениями. Если там "команды" — покажите их. Декодируйте. Распечатайте эту "книгу".

Где пруфы?

Если Liberty перехватили 1 МБ "команд управления" — почему не показали содержимое? Декомпилировали трафик? Расшифровали payload? Показали структуру этих "команд"? Ничего. Только "мы делаем однозначный вывод".

Авторы с Хабра реверсили APK, нашли конкретные классы и методы, показали бинарный протокол с MessagePack-сериализацией. А тут — "мегабайт, значит книга, значит бэкдор". Ну ок.

Feature flags = бэкдор?
Liberty пишут: раз модуль включается не у всех — это "управляемый бэкдор". Feature flags используют все: Google, Apple, Telegram, любое приложение в телефоне. A/B тесты, постепенный rollout — обычная инженерная практика, не заговор.

А что вообще может сделать приложение на телефоне?
Тут стоит напомнить базовую вещь. На современных Android и iOS приложение без явно выданных разрешений не может сделать с устройством ничего критичного. Хотите управлять чужим телефоном? Получите Accessibility Service. Хотите блокировать приложения или стирать данные? Device Administrator privileges. Всё это выдаётся руками пользователя с ОЧЕНЬ явным системным предупреждением.
MAX таких разрешений не запрашивает. Можете проверить в настройках прямо сейчас.

И какого бы я ни был мнения о команде MAX — вряд ли у них, как у NSO Group с их Pegasus, есть свой набор 0day-эксплойтов под обе платформы. Чтобы следить за тем, как вы отправляете показания счётчиков арендодателю квартиры))

Комменты из треда — имба

Уровень "расследования" лучше всего видно по комментариям:
➡️ "вот что мне ответил чат GPT на это" — @ fist_tsif приложил скриншоты ChatGPT. Зачем разбираться самому, если нейросеть рядом.
➡️ "@ grok что может сделать max на айфоне?" — два человека вместо подумать своими мозгами позвали Grok в комменты.
➡️ "Почему нельзя нормальный технический отчёт написать. Вас даже на хабре обоссали бы за такое" — @ cozz777. 343 лайка. Комментарий дороже треда.
➡️ Один пользователь рассказал историю про FlashGet Kids на телефоне знакомой — приложение для родительского контроля, которое имеет легитимное удалённое управление и блокировку приложений. Причём тут MAX — загадка вселенной.

Итог

Телеметрия в любом приложении вызывает вопросы. Но наброс про "Управляемый бэкдор" — совсем разное. Это фантазия пользователей X, которые не показали ни одного расшифрованного payload.

«Номинальный» one-way trust: пробиваемся на ту сторону через Kerberos referrals
#AD #Kerberos #ActiveDirectory #LateralMovement #RedTeam

Считается, что если между доменами в Active Directory настроен one-way trust, то аутентификация возможна только в одном направлении и атакующий не сможет использовать его для атаки в обратную сторону. На практике доверительные отношения могут использоваться для перемещения по инфраструктуре и дальнейшей компрометации других доменов.

Техническая суть
Когда пользователь из одного домена обращается к ресурсу другого домена, механизм Kerberos referral tickets работает следующим образом: клиент получает TGT в своем домене, после чего KDC выдает referral ticket, который используется для получения сервисного тикета в доверенном домене. В результате Kerberos-инфраструктура между доменами начинает обмениваться тикетами и информацией из PAC, включая SID.

Процесс атаки до боли простой

▪️В домене, который доверяет другому домену (trusting domain), ищем Trusted Domain Object (TDO) и извлекаем из него секрет, используемый для поддержания one-way trust.
▪️Этот секрет соответствует паролю междоменной учетной записи вида TRUST_ACCOUNT в trusted domain.
▪️Используя полученный секрет, атакующий может аутентифицироваться в trusted domain как trust-учетка и получить как минимум уровень Domain Users.

🔗Источник (https://offsec.almond.consulting/trust-no-one_are-one-way-trusts-really-one-way.html)
🌚 @poxek

Новогодние страдания, или как я сдавал CPTS в 2026 году

Продолжение мазохизма в лёгкой форме от спеца, который в прошлом посте сдал BSCP, теперь взял выше и сдал CPTS)

Краткий экскурс для тех кто не в теме: CPTS (Certified Penetration Testing Specialist) - это сертификация от HackTheBox, которая проверяет навыки тестирования на проникновение. Просто "прийти и сдать" не получится, для доступа к экзамену необходимо пройти, так называемый, тематический "Job Role Path". Вообще, больше про структуру экзамена можно прочитать в других статьях на Хабре, например, тут или тут.

Автор же написал статью про свои ощущения от сданного курса и Как это было, а в конце даёт советы тем, кто только собирается сдавать)

🔗**++++**Читать нельзя пропустить (запятую ставим сами)

p.s. мой дизайнерский глаз был приятно удивлен оформление статьи

🌚 @poxek | 🌚 blog.poxek.cc | 📺 YT | 📺 RT | 📺 VK | 🌚 Мерч

Закрепляемся в macOS через баги в IPVanish VPN
#IPVanishVPN #macOS #LPE #XPC #PrivilegeEscalation

Приложение IPVanish VPN для macOS содержит критическую уязвимость повышения привилегий, позволяющую любому непривилегированному локальному процессу выполнить произвольный код от имени root. Для эксплуатации достаточно локального доступа к системе, на которой установлен клиент IPVanish.

♾️Технические особенности♾️

Основная проблема заключается в отсутствии аутентификации XPC-клиентов в привилегированном вспомогательном инструменте com.ipvanish.osx.vpnhelper. Любой локальный процесс может установить соединение с этим хелпером и отправлять ему команды.

Уязвимость усиливается двумя дополнительными проблемами:

▪️**Параметр **OpenVPNPath — указывает бинарный файл, который хелпер запускает от имени root через GCDTask. Значение параметра принимается напрямую из XPC-сообщения без проверки пути или подписи кода, что позволяет запускать произвольные файлы от имени root.

▪️Ошибка проверки подписи кода — хелпер-инструмент проверяет подпись только для исполняемых файлов. Неисполняемые скрипты можно скопировать в каталог, принадлежащий root, после чего хелпер меняет им права и выполняет их через механизм OpenVPN hook --up, создавая дополнительный путь выполнения кода.

♾️Эксплуатация♾️

▪️Создать вредоносный shell-скрипт /tmp/ipvanish_exploit.sh с правами 0644 (неисполняемый), чтобы обойти проверку подписи.
▪️Установить XPC-соединение с com.ipvanish.osx.vpnhelper без аутентификации клиента.
▪️Отправить XPC-сообщение с VPNHelperCommand = VPNHelperConnect, указав параметр
OpenVPNPath = /tmp/ipvanish_exploit.sh.
▪️Установить параметры OpenVPNUpScriptPath и OpenVPNCertificatePath на /tmp/ipvanish_exploit.sh, что приводит к вызову copyHelperTool.
▪️Вспомогательный инструмент копирует скрипт в каталог /Library/Application Support/com.ipvanish.osx.vpnhelper/ пропуская проверку подписи (из-за неисполняемого состояния файла) и затем устанавливает права 0500.
▪️После этого хелпер запускает /tmp/ipvanish_exploit.sh от имени root через GCDTask, а затем повторно выполняет его через OpenVPN hook --up.
▪️В качестве доказательства эксплуатации скрипт может создать файл/tmp/ipvanish_pwned_root.txtпринадлежащий root.

🔗Источник

🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK

Поздравляю прекрасных дам с 8 марта!)

Android без -fstack-check: неограниченная рекурсия через Binder RPC + LPE из shell в system_server
#Android #LPE #stackoverflow#BinderRPC

В Android нативный код системных компонентов компилируется без защиты от stack clash, поэтому при глубокой рекурсии указатель стека может перепрыгнуть guard-страницу и попасть в отображенную память ниже стека. В результате стек фактически продолжает расти за пределами охраняемой области, что позволяет обойти защиту при вызове функций с большим стековым фреймом, например, android::incfs::MountRegistry::Mounts::loadFrom(), где используется локальный буфер ~128 КиБ.

Атакующий из контекста shell может использовать вложенные синхронные Binder RPC, чтобы неограниченно увеличивать глубину стека одного потока system_server. После этого вызывается функция с крупным стековым выделением, что приводит к перезаписи сохраненных данных в stack frame, захвату управления и потенциальному LPE из shell в system_server.

♾️****Эксплуатация♾️

▪️Из shell запускаются команды вроде am dumpheap или trace-ipc stop, что приводит к вызову ShellCallback.openFile в system_server.
▪️В реализации openFile рекурсивно инициируются дополнительные shell-команды, углубляя стек до нужного размера.
▪️Ниже текущего положения стека спреятся контролируемые данные (например через Bitmap и IClipboard.setPrimaryClip) в shared memory.
▪️Далее триггерится функция с большим стековым фреймом (например цепочка incremental_service → isFileFullyLoaded → loadFrom()).
▪️Большая аллокация стека перепрыгивает guard region и перезаписывает сохраненный link register (LR) до его восстановления → происходит захват PC (часто наблюдается краш с PC = 0xaaaaaaaa).
▪️Эксплуатация повторяется до успеха (race condition, вероятность ~5–10% на попытку).

Вероятность успешной эксплуатации относительно низкая из-за рандомизации размещения стеков потоков и памяти.

Эксплойт из исследования подтвержден на конкретной сборке Pixel 7 (Android 16).

🔗Источник

🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK

Как только погода чуть более стабилизируется, я возобналю продажи мерчевого худи. Цена останется та же, как в прошлом году )

Ближе к возобновлению продаж будет полноценный анонс

Разбор фейка о фото в МАХ

В телеграм-каналах распространяется фейк о фото в МАХ от пользователя с Пикабу. Не надо быть мидлом пентестером, чтобы понять, что это не реалистичный сценарий атаки -_-

Во время переписки пользователей при передаче медиа контента (фото, видео) файл попадает на внутренние хранилища того сервиса, на который выкладывается. Это делается для того, чтобы пользователь мог открыть изображение или переслать его. Так работают все платформы — от российского МАХ до запрещенных FaceBook и Instagram

Например, https://i.oneme.ru/i?r=BTE2sh_eZW7g8kugOdIm2Not1LVzwMmiSsq_k0ZzTM6Hp5bBJ_5Cu3FMzK9WPICitn8 — используется сложный алгоритм шифрования, который не получится перебрать и получить доступ к чужим файлам. Если не верите, попробуйте сбрутить :)

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

От .winget до reverse shell: новая атака через легитимный менеджер пакетов Microsoft
#WinGet #DSC #InitialAccess #RedTeam #Windows

Еще один способ запуска произвольного PowerShell-кода в Windows через легитимные инструменты. На этот раз используется winget (Windows Package Manager) и его функция Desired State Configuration (на базе PowerShell DSC). При определенных условиях двойной клик по специально сформированному .winget-файлу или self-referencing LNK может позволить обойти Mark of the Web и предупреждения SmartScreen. То есть winget выступает как LOLBIN для начального доступа, загрузки и запуска вредоносного кода под видом легитимной конфигурации системы.

♾️Технические особенности♾️

Атака использует файловую ассоциацию .winget → winget.exe configure "%1" --wait, которая запускает PowerShell Desired State Configuration (DSC v3+). DSC позволяет декларативно выполнять действия через ресурсы вроде: Invoke-WebRequest (скачивание), Archive (распаковка), WindowsProcess / Script (запуск процессов или кода), изменение реестра и переменных среды. Модули DSC автоматически загружаются из PowerShell Gallery в %LOCALAPPDATA%\Microsoft\WinGet\Configuration\Modules. Исполнение происходит через ConfigurationRemotingServer.exe с использованием PowerShell runtime (System.Management.Automation).

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

Эксплуатация

▪️Доставить ZIP с malicious LNK (например через HTML smuggling)
▪️Потенциальная жертва распаковывает архив в %TMP% или Downloads и кликает по LNK
▪️Запускается команда LNK:
cd %TMP%\*update.zip* || cd %HOMEPATH%\Downloads\update
▪️LNK извлекает встроенный конфиг:
more +1349 *.lnk > %TMP%\conf.yml
▪️Открывается decoy-документ start https://attacker/decoy.pdf
▪️При необходимости включается конфигурация winget configure --enable
▪️После этого применяется конфиг:
echo Y | winget configure -f %TMP%\conf.yml
▪️DSC скачивает, распаковывает и запускает полезную нагрузку.

♾️****Импакт ♾️

Позволяет получить первоначальный доступ и закрепиться в корпоративных средах, где Microsoft Store и winget не отключены. Через DSC атакующий может загрузить и выполнить полезную нагрузку, модифицировать систему и запускать код без явного вызова powershell.exe.

♾️****Защита ♾️

▪️Отключить WinGet через GPO
▪️Отключить параметр EnableWindowsPackageManagerConfiguration
▪️Удалить ассоциацию .winget или заблокировать ее через AppLocker / WDAC
▪️Применить WDAC / Application Control для блокировки winget configure

🔗Источник

🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK

«Забытый» баг: TOCTOU в ClientRequest Node.js допускает HTTP request splitting
#NodeJS #HTTP #TOCTOU #CRLF #AppSec #WebSecurity

В реализации ClientRequest в Node.js обнаружен старый логический дефект — TOCTOU позволяет обойти первичную валидацию path и внедрить CRLF-последовательности в строку запроса. Проблема исторически пересекается с мерами, введенными при исправлении CVE-2018-12116 (ограничения на непечатаемые/Unicode-символы).

♾️Технические особенности♾️******
**
При создании запроса через http.request(options) Node.js валидирует options.path (включая запрет \rи \n) для предотвращения инъекций в request line.

При этом есть несколько «но»:

▪️Проверка выполняется при создании объекта ClientRequest и далее может не повторится, зависит от версии Node.js
▪️this.path — обычное изменяемое поле JS-объекта (не заморожено), то есть хранится как обычное JS-свойство
▪️После создания объект может быть изменен сторонним кодом, например, middleware/прокси-логикой
▪️При формировании request line используется текущее значение this.path, повторная строгая валидация зависит от версии Node.js

Если между созданием и отправкой path будет изменен на строку с \r \n, эти символы могут попасть в сетевой трафик, что потенциально приведет к request splitting или header injection (в зависимости от версии).

♾️Эксплуатация♾️

▪️Приложение использует прокси-логику, где path формируется из пользовательского ввода.
▪️В URL закодированы CRLF: /proxy/something%0D%0AHost:%20evil.com%0D%0A...
▪️Библиотека декодирует %0D%0A → \r \n и перезаписывает proxyReq.path = decoded.
▪️Первичная проверка path уже пройдена на «чистом» значении.
▪️При отправке формируется строка вроде: GET /something\r\nHost: evil.com\r\n... HTTP/1.1\r\n...
▪️Downstream-сервер, в зависимости от парсера и конфигурации, может интерпретировать это как инъекцию заголовков или как несколько отдельных запросов.

♾️Импакт♾️

▪️Подмена Host или добавление своего заголовка Authorization
▪️Доступ к внутренним эндпоинтам, например, /admin
▪️Инъекция дополнительных заголовков
▪️Классическое request splitting без обязательной десинхронизации, как при smuggling

🔗Источник

🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK

Всем привет!

Следующий Positive Hack Days Fest пройдет в 2027 году, в этом году киберфестиваля не будет.

**Почему мы приняли такое решение

**Каждый новый PHDays — это вызов для всей нашей команды: сделать его круче, чем он был годом ранее.

Этот PHDays должен был стать 15-м по счету — юбилейным, и поэтому он особенно важен для нас.

Во время подготовки возникли сложности с местом его проведения — в связи с реконструкцией «Лужников» и всех крупных парков, которые могли бы нас принять. Это не позволило бы нам построить все те тематические зоны и полноценно воплотить идеи, которые мы для вас подготовили.

Мы изучили все возможности, но поняли, что в этих условиях сделать великолепно не получится, а на меньшее мы не готовы. Поэтому мы решили взять перерыв и провести юбилейный PHDays в 2027 году — на новой площадке, независимо от внешних факторов. И сделать его таким, каким мы и задумываем.

Спасибо за понимание, ваша команда PHDays

@poxek

⌨️ Грамота о язвимости MCP, лета 7534 от сотворения мира

Язвимость CVE-2026-27896 оценена мудрецами в 7.0 по шкале CVSS, сиречь «Высокая» — брешь изрядная, хотя и не наипагубнейшая.

Суть же вот в чем: функция json.Unmarshal() языка Go сличает поля JSON-грамот без различения больших и малых литер — для нее Method и method суть едино, а уложение JSON-RPC 2.0 требует совпадения точного, до единой буквицы. Выходит несовпадение устава и проверок в коде — стражи промежуточные (WAF, прокси) досматривают грамоты строго по уложению и угрозы не зрят, а MCP Go SDK втихомолку принимает команды замаскированные. На деле же злоумышленник может обойти заставы безопасности меж AI-агентом и MCP-сервером, токмо меняя начертание литер в полях JSON.

И зело важен контекст: сие уже 30-я язвимость в землях MCP с основания протокола в лето 2024-е, а половина оных явилась за последние три месяца — то бишь речь не об одной ошибке, а о хворях системных всего протокола.

От сей конкретной язвимости спасает обновление MCP Go SDK до версии 1.3.1, где парсинг JSON заменили на регистрочувствительный. Однако единым заплатанием беды не одолеть: 36% MCP-серверов действуют вовсе без аутентификации, аки ворота нараспашку.

Аз рекомендую оборону глубокую: взаимное TLS-рукопожатие меж MCP-частями, строгую проверку всех данных от MCP-серверов (AI-агент должен почитать всякий ответ MCP за недоверенный), разделение сетей и заточение серверов в контейнеры. Надлежит вести летопись всех tool calls и выискивать аномалии. А наипаче действенно ныне — убавить число подключенных MCP-серверов и каждый тщательно проверить, ибо всякий новый сервер расширяет рубежи, коих надобно оборонять.

Писано рукою Иннокентия, дьяка приказа кибербезопасности

#red_team #memes

Кратко о влиянии запрета на использование англицизмов 😭

Весеннее обострение для CTF-еров: DUCKERZ Season & RedShift.Eclipse-3
#CTF #infosec #DUCKERZ #МИРЭА

Март стартовал, и сразу два крупных события для тех, кто не прочь поломать что-нибудь легально.

🐥 DUCKERZ - Весенний сезон
На платформе запустили сезонную механику. С 1 марта по 31 мая - новые таски, сезонный рейтинг и борьба за топ-10.
Спонсор сезона - Standoff Bug Bounty.
Призы: Raspberry Pi за первое место + мерч DUCKERZ, а топ 2-10 получат набор мерча Standoff (футболки, худи, брелоки).

👉 Страница сезона 👈

——————

🖥️****** RedShift.Eclipse-3**
13-15 марта пройдёт онлайн-отбор ZeroPlusCTF (task-based, команды 2-4 человека). Лучшие команды попадут в очный финал.

➡️ Регистрация: zeroplus.redshiftctf.ru
➡️ Нет команды? Ищи в чате

16 мая - финал в Москве, Defense CTF на платформе AvoidAttack. Площадка - Колледж программирования и кибербезопасности РТУ МИРЭА (1-й Щипковский пер., 23, стр. 1).
Параллельно с финалом будет очный MeetUp с докладами от спецов из ИБ-компаний. Как это выглядело раньше - тут и тут.

🔗 Подробности: redshiftctf.ru

🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK

Как безобидные entitlements для JIT превратить в примитив обхода macOS-защиты
#macOS #JIT #AppSec #EndpointSecurity

В macOS механизм Hardened Runtime ограничивает выполнение неподписанного кода и изменение прав страниц памяти. Однако для поддержки легитимной динамической генерации кода (JIT в браузерах, Electron и т.п.) Apple ввела специальные entitlements, такие как com.apple.security.cs.allow-jit, разрешающие использование JIT-памяти.

Это создает контролируемое исключение из общей модели W^X: обычные процессы не могут свободно создавать исполняемую память или переключать страницы в RX/RWX, но приложения с соответствующими entitlements получают доступ к механизму MAP_JIT. В результате процесс с такими привилегиями может использовать их не только для JIT-компиляции, но и для выполнения произвольного кода в памяти.

♾️Эксплуатация♾️**
**
▪️Найти подходящее приложение: выбрать процесс с entitlement com.apple.security.cs.allow-jit (или аналогичными allow-unsigned-executable-memory, disable-executable-page-protection).
▪️Получить выполнение кода внутри процесса: через макросы Office, уязвимость в приложении, инъекцию или иной вектор, допустимый в контексте процесса.
▪️Выделить JIT-память: вызвать mmap(..., PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON | MAP_JIT, ...) и получить регион, разрешенный для записи.
▪️Записать шеллкод: скопировать произвольный код или reflective loader в выделенный регион.
▪️Переключить режим защиты: вызвать pthread_jit_write_protect_np(1) — регион становится RX (исполняемым), запись запрещается.
▪️Запустить код: выполнить переход на адрес шеллкод или создать поток через pthread_create(...). Код выполняется с привилегиями текущего процесса.

Произвольный код исполняется полностью в памяти без записи исполняемых файлов на диск и без нарушения механизма code signing, используется легитимный JIT-механизм.

♾️Защита♾️

▪️Не выдавать allow-jit, allow-unsigned-executable-memory, disable-executable-page-protection без необходимости.
▪️По возможности использовать более строгую модель JIT-контроля.
▪️Мониторить использование MAP_JIT, подозрительные mmap/mprotect и вызовы pthread_jit_write_protect_np.
▪️Минимизировать entitlements и применять Hardened Runtime максимально строго.
▪️EDR должен выявлять reflective execution в JIT-регионах и аномальные загрузки dylib.

🔗Источник и PoC

🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK

DeBix** (Деобфускатор Bitrix)**

🔍 Вы знали, что модули Bitrix, поставляемые через Marketplace в демо-режиме, проходят через автоматический обфускатор? (см. Фото)

Встроенный обфускатор переименовывает параметры функций и члены классов в файлах по типу include.php и install.php, что зачастую приводит к ошибкам в работе легитимного кода. Помимо этого, похожий обфусцировонный код встречается и при разборе инцидентов.

Чтобы не тратить часы на ручной разбор base64_decode и переменных вида $__254446073, я собрал DeBix (Deobfuscator Bitrix) — утилиту для восстановления читаемости кода.

Репозиторий проекта:
https://github.com/FaLLenSkiLL1/DeBix

Локальное повышение привилегий в Windows 11 через функцию Microsoft Recall
#Windows #LPE #RCE #EoP #TotalRecall

До января 2026 года в Windows 11 (даже при отключенной функции Microsoft Recall) висела запланированная задача \Microsoft\Windows\WindowsAI\Recall\PolicyConfiguration, выполняемая от имени NT AUTHORITY\SYSTEM. Через COM-интерфейс IFileOperation задача рекурсивно удаляла директории в профиле пользователя по пути: %USERPROFILE%\AppData\Local\CoreAIPlatform.00\UKP\{GUID}. При этом не выполнялась корректная проверка симлинков, junction points и финального разрешенного пути. Это открывало возможность link following атаки.

♾️Эксплуатация♾️

Для атаки достаточно профиля пользователя с минимальными правами.

▪️Низкопривилегированный пользователь создает в своем профиле директорию в целевом пути Recall (GUID-имя).
▪️Через симлинки или junction points + oplock перенаправляет операцию удаления на системный путь (C:\Config.Msi и т.п.).
▪️Обновляет соответствующее состояние WNF, что инициирует выполнение задачи.
▪️Во время удаления oplock позволяет выполнить манипуляцию путем, операция в контексте SYSTEM применяется уже к перенаправленному объекту.
▪️Удаление C:\Config.Msi инициирует MSI rollback, в ходе которого исполняется контролируемый атакующим код от имени SYSTEM.

♾️Статус♾️

В январском обновлении Microsoft переработала логику удаления: отказалась от использования IFileOperation, перешла на низкоуровневые NT API (NtCreateFile, GetFinalPathByHandle, SetFileDispositionInformation) и добавила корректную проверку финального канонического пути перед удалением. В новых версиях задача корректно разрешает реальный путь объекта и блокирует атаки через симлинки, junction points и oplock-манипуляции.

🔗Источник и PoC

🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK