PURP

MAD Bugs: 21‑летний use-after-free в PHP unserialize() и первый публичный удаленный UAF‑RCE на PHP 8.5.5 Исследователи из Calif обнаружили в PHP use-after-free в unserialize(). Баг живет с PHP 5.1 и затрагивает путь через Serializable. Коллеги создали локальный эксплойт, обходящий disable_functions без зависимости от /proc и жестких оффсетов, а также добились RCE на актуальной PHP 8.5.5. Авторитетно заявляется, что значительную часть аудита кода и генерации эксплойта выполнила Claude, а исследователи занимались архитектурой атаки и верификацией. Суть бага 🔽 Для пользовательских классов, реализующих Serializable::unserialize(), не инкрементируется BG(serialize_lock). Из‑за этого рекурсивный вызов unserialize() делит один и тот же var_hash между внешним и внутренним разбором. При изменении структуры свойств это приводит к use-after-free таблицы свойств: старая arData освобождается, но остается в var_hash и может быть переиспользована под данные атакующего. Эксплуатация 🔽 Локальная цепочка (около 30 срабатываний UAF): ▶️ Задается класс с Serializable::unserialize(), который рекурсивно вызывает unserialize() и меняет свойства, вызывая resize таблицы. ▶️ Формируется пейлоад, многократно триггерящий UAF и дающий контролируемое перезаписывание освобожденной структуры. ▶️ Строятся примитивы: утечка адресов кучи, произвольное чтение (uaf_read). ▶️ Подделывается структура Closure, чтобы через поддельный func.handler (из таблицы функций модуля) вызвать zif_system, обходя disable_functions. Удаленный эксплойт использует тот же UAF в эндпоинте вида unserialize($_REQUEST['cook']); echo serialize(...). Он опирается на Apache prefork (краши воркеров как оракул), на лету парсит ELF libphp (PT_DYNAMIC, .gnu.hash, GOT), находит базу libc и адрес system(). Затем подделывает stdClass, чтобы при serialize() / get_properties_for() вызывался system() с командой из байтов объекта. Импакт 🔽 В итоге memory corruption в unserialize() дает RCE даже при disable_functions и в типичных Docker‑окружениях. При этом эксплуатация требует специфического паттерна кода (класс с Serializable, рекурсивный unserialize() и рост таблицы свойств), что ограничивает практическое применение. Тем не менее, это прикольная демонстрация надежной эксплуатации UAF в PHP 8.x с использованием ИИ для автоматизации низкоуровневой части атаки. Специально выбрал вам картинку из статьи посложнее, чтобы мозг еще больше запутался. 👊 ➡️ Источник #red_team #php #MADBugs #memorycorruption

Жизненно, эксперты

#red_team #memes

@Pr0xProw ты у нас уже звезда или еще нет? Доступы тебе что ли подрезать для профилактики... #blue_team #memes

1-click угон GitHub-токенов через github.dev и баг VS Code Webview 😮 В browser-версии VS Code (github.dev) обнаружена цепочка, позволяющая украсть GitHub OAuth-токен одним переходом по ссылке на специально подготовленный репозиторий. Техника угона строится на комбинации из широких OAuth-прав токена, который GitHub выдает github.dev, бага/особенности VS Code Webview и возможности установки расширения через синтетические keyboard events. Суть бага 🔽 При открытии github.dev GitHub автоматически прокидывает в web-IDE OAuth-токен, чтобы редактор мог работать с GitHub API от имени пользователя. Этот токен не ограничен текущим репозиторием и дает доступ ко всем репозиториям, к которым у пользователя уже есть доступ, включая приватные и organization-репозитории. Webview внутри VS Code умеют пересылать keyboard events в основное окно редактора через message passing, чтобы горячие клавиши работали даже внутри iframe/webview. Эти события можно синтетически подделывать из JavaScript внутри webview. В PoC использовался Jupyter notebook (.ipynb) внутри github.dev. Атака выглядит так 🔽 ▶️ пользователь открывает ссылку вида https://github.dev/... ▶️ вредоносный notebook/webview запускает JavaScript ▶️ JS генерирует цепочку synthetic keyboard events ▶️ через них инициируется установка malicious VS Code extension ▶️ расширение получает доступ к GitHub auth/session context внутри github.dev ▶️ дальше атакующий может читать приватные репозитории, вытаскивать код и пушить изменения от имени жертвы. Если пользователь уже ранее логинился в github.dev и browser storage не очищен, атака укладывается в один клик. ➡️ Подробности и PoC #red_team

Под строгим CSP безопасно? Пфф... нет 🤣 Как выяснилось, даже при запрете скриптов и внешних ресурсов HTML-инъекция все еще позволяет добавить собственную веб-форму на странице логина. Если инъекция происходит в том же origin, где у пользователя сохранены креды, браузерный менеджер паролей может попытаться автозаполнить поля. В Chrome это поведение проявляется особенно ярко, Firefox и Safari ведут себя строже и сильнее зависят от структуры формы и взаимодействия с юзером. Как работает атака 🔽 Форма отправляет данные методом GET, поэтому после клика пользователя логин и пароль могут оказаться в query-строке URL. Сам CSP при этом не блокирует обычную навигацию браузера и не предотвращает утечку URL через Referer, если это допускает referrer policy. ▶️Через HTML-инъекцию добавляется форма с полями email/password на той же странице логина. Менеджер паролей распознает знакомую структуру полей и может подставить сохраненные креды. ▶️Форма отправляется методом GET, поэтому после клика пользователя email/пароль попадают в query-параметры URL. ▶️CSP блокирует скрипты и загрузку внешних ресурсов, но не мешает переходам на другие сайты. Через HTML-инъекцию можно попытаться навязать referrer-policy (<meta name="referrer" content="unsafe-url">) и добавить <meta http-equiv="refresh"> для автоматического перехода на внешний домен. В один клик 🔽 Чтобы уложить атаку в один клик, инжектированная форма должна менять значение уязвимого параметра так, чтобы при следующем запросе он уже интерпретировался как HTML с meta referrer и meta refresh. Пользователь нажимает кнопку один раз, остальное происходит автоматически. Если CSP разрешает inline-CSS, submit-элемент можно растянуть поверх страницы, чтобы практически любой клик пользователя отправлял форму и запускал утечку. ➡️ Подробности #red_team

Так много LPE для Linux в последнее время, что не знаешь, за какую хвататься в первую очередь. Надо было ставить... альт астру ред ос винду! 👊 #red_team

OpenAI и Anthropic на этот репорт о баге отреагировали крайне флегматично, так что я даже не знаю. В целом банальная: 🔵Жестко фильтруйте входящий JSON от клиентов: удаляйте все несанкционированные поля (reasoning.*, encrypted_content и т.п.). 🔵Не раскрывайте конечным пользователям сырую статистику (reasoning_tokens, точный размер encrypted-блобов). 🔵Добавляйте искусственный jitter (шум) ко времени ответа API для защиты от timing-атак. 🔵Избегайте размещения критичных секретов в system prompt, если они могут влиять на ветвление скрытых рассуждений модели. #blue_team

Зашифрованное мышление LLM: реплей reasoning-блобов и утечки через side-channel Нашелся интересный (хоть и муторный в целом) побочный канал утечки информации из внутреннего состояния модели и вашего промпта через объем скрытого рассуждения (reasoning) и время ответа в секрет-зависимых вычислениях. Как отмечает автор сего труда, современные LLM (OpenAI, Anthropic и другие) при использовании API возвращают «скрытый» Chain-of-Thought (CoT) в виде reasoning-блобов — JSON-структур с зашифрованным содержимым в формате base64. Эти блобы предназначены для stateless-режимов: приложение должно просто пересылать их обратно провайдеру в следующих запросах. Блобы представляют собой аутентифицированный шифртекст: ▶️размер зависит от глубины и сложности рассуждений; ▶️любая модификация приводит к ошибке API; ▶️неизменннные блобы успешно реплеятся даже в другой сессии, под другим аккаунтом, а у OpenAI — еще и между разными моделями. Это указывает на использование глобального ключа шифрования/аутентификации. В теории атака может выглядеть следующим образом 🔽 ▶️ Захват — атакующий получает валидный reasoning-блоб, например, из предыдущего ответа API, через утечку логов или путем принудительной генерации через контролируемый запрос. ▶️Инъекция — через пользовательский ввод (например, чат-интерфейс) подается специально сформированный JSON, содержащий захваченный блоб в поле reasoning (или его аналогах), что позволяет обойти клиентскую валидацию. ▶️Реплей — бэкенд-приложение пересылает блоб в следующий запрос к LLM-провайдеру как часть состояния сессии (контекста диалога). ▶️Эксплуатация — провайдер принимает блоб как легитимное продолжение скрытого состояния. Это позволяет манипулировать внутренним контекстом рассуждений модели, выполнять контролируемые тайминг-атаки, измеряя время ответа в зависимости от секретных данных в промпте, а также проводить межсессионные и кросс-пользовательские атаки на приложения с общей (разделяемой) инфраструктурой. Импакт 🔽 Если злоумышленник может внедрять произвольный JSON во входные сообщения (например, через чат-интерфейс), он потенциально способен инжектировать чужие reasoning-блобы, которые провайдер примет как валидные. Это заставит модель продолжить чужое рассуждение в контексте ваших данных. ➡️Источник #red_team #LLM

Тут внезапно @poxek_ai закинул статью на Habr про Zero Trust для AI-агентов По опыту скажу, у многих сейчас архитектура выглядит так: «давайте дадим LLM доступ к CRM, почте, базе и продовым API, а потом попросим ее вести себя нормально». Да-да, очень взрослый security design, все как любит @Lobrigate)) Это почти как хранить ключи под ковриком и называть это UX. В тексте как раз про то, почему агент с инструментами — это уже не просто чатик, а отдельный полноценный участник инфраструктуры со всеми вытекающими. Ему нужны своя идентификация, короткоживущие креды, deny-by-default, allowlist tools, песочница, нормальные логи tool calls и человек на опасных действиях. Короче, если ваш AI-агент может прочитать внутреннюю wiki, дернуть API, отправить наружу файл и никто потом не поймет, кто это сделал, проблема не в том, что модель тупанула, а в том, что вы ей выдали полные права как стажеру в первый день (или как выдали обезьяне автомат). Только на стажера хотя бы можно повесить ответственность, а на агента нет)) ➡️ Читаем. #red_team #AI

На LinuxBlog.io вышло практическое руководство по использованию Nmap в Linux-средах Прям очень хорошая высушенная шпаргалка с консольными командами, покрывающая большинство повседневных задач + упор на инвентаризацию и профилирование систем. Например: 🔵 Быстрое обнаружение активных устройств 🔵 Различные техники сканирования портов, включая скрытое SYN-сканирование и работу с UDP-сервисами 🔵 Определение версий ПО и ОС (OS/Service Detection) для аудита инфраструктуры 🔵 Использование NSE для автоматического поиска уязвимостей, проверки анонимного доступа к FTP и анализа HTTP-заголовков 🔵 Оптимизация скорости сканирования и работа с форматами вывода для последующего парсинга. #blue_team

С этими и другими printer stack багами чаще всего нужно не ждать патча, а сужать поверхность атаки. 🔵 Ограничьте локальный доступ к системам с USB-принтерами, особенно к терминальным серверам, киоскам и общим рабочим станциям. Ключевое условие эксплуатации таких багов — доступ к интерфейсу устройства принтера. 🔵 Отключите или уберите из эксплуатации все ненужные USB-принтеры и связанные с ними device interfaces на серверах и чувствительных хостах. 🔵 Переведите печать там, где это возможно, с локальных USB-устройств на централизованные сетевые принтеры или отдельные print-серверы, чтобы пользовательские сессии не имели прямого контакта с уязвимым USB printer stack. 🔵 Включите application control, например AppLocker или WDAC, чтобы обычные пользователи не могли запускать произвольные утилиты и PoC-код, способные отправлять нестандартные DeviceIoControl в драйверы ядра. Настройте мониторинг на аномалии вокруг подсистемы печати, будут как маркеры грядущего DoS: внезапные BSOD с SYSTEM_SERVICE_EXCEPTION, нестабильность на хостах с USB-принтерами, подозрительные обращения к printer device path из пользовательских процессов. #blue_team

Разбираем классический IOCTL-баг в usbprint.sys  Printer stack в Windows — неиссякаемый источник развлечений. В этот раз отличился штатный драйвер Microsoft для USB-принтеров usbprint.sys. Исследователь опубликовал разбор уязвимости, позволяющей из user-mode отправить ядро в DoS через обычный DeviceIoControl. Отлично подойдет для crash-on-demand на терминальных серверах или киосках, где расшарены USB-принтеры. Суть бага Проблема находится в обработчике USBPRINT_ProcessIOCTL. Как минимум несколько IOCTL (SET_PROTOCOL, SET_PORT_NUMBER и другие) принимают данные из user-mode, но не проверяют SystemBuffer и длину буфера перед чтением. Для METHOD_BUFFERED запросов I/O-менеджер может оставить Irp->AssociatedIrp.SystemBuffer == NULL, если входной и выходной буферы имеют нулевую длину. Однако usbprint.sys продолжает работать с указателем без валидации. В результате при lpInBuffer = NULL и nInBufferSize = 0 драйвер разыменовывает NULL-указатель в kernel-mode. На современных версиях Windows это приводит к STATUS_ACCESS_VIOLATION (0xC0000005) и обычно заканчивается BSOD с SYSTEM_SERVICE_EXCEPTION (0x3B). Самое ироничное в том, что автор драйвера знал, как правильно. В том же диспетчере соседний case 8 делает все по науке (проверяет буфер и возвращает STATUS_INVALID_PARAMETER). Но в трех других кейсах антипаттерн с прямым чтением оставили как есть. ⏳ Microsoft кстати баг не исправила. В компании признали его несрочным и отложили в бэклог для исправления в будущих версиях. ➡️ Подробности #red_team #Windows #DoS

GhostTree: два mklink /J — и Defender слепнет Varonis Threat Labs показали технику GhostTree — как с помощью рекурсивных NTFS junctions можно создать огромное дерево валидных путей. Если сканер прозрачно следует по junction и плохо детектит циклы, он зависает на обходе этой структуры, а пейлоад, лежащий рядом, остается незамеченным. Техника успешно проверена против Windows Defender. В целом потенциально уязвимы все продукты, которые делают рекурсивный обход файловой системы (dir /s, EDR, AV-сканеры и т.д.). В чем суть NTFS junction (точка повторного разбора) создается командой mklink /J. Права админа не нужны — достаточно write access к директории. ▶️ GhostBranch — одна junction, указывающая обратно на родительскую папку → линейная рекурсия ▶️ GhostTree — две дочерние junctions, каждая из которых ссылается на родительскую директорию → формируется бинарное дерево путей При глубине ~126 уровней количество уникальных путей достигает 2¹²⁶ ≈ 8.5 × 10³⁷. Из-за ограничения Windows на длину пути (~260 символов) используют максимально короткие имена папок (обычно односимвольные). Физически на диске — одна папка и один файл. Но для сканера это выглядит как огромное количество отдельных валидных маршрутов. Цепочка атаки ▶️Атакующий получает write access к любой директории (без привилегий) ▶️Создает двумя командами mklink /J рекурсивные junctions — весь эксплойт в двух строках ▶️Кладет пейлоад в родительскую директорию ▶️При рекурсивном сканировании папки EDR/AV зависает в бесконечном обходе дерева ▶️Несчастный пейлоад остается всеми непросканированным и необнаруженным Итог: полноценный defense evasion без каких-либо привилегий. Любой пользователь с write-доступом может временно ослепить сканер EDR/AV. Microsoft сначала закрыла тикет классической отмазкой «обход Defender не пересекает security boundary», но позже все-таки выпустила патч. ➡️ Подробности: Varonis GhostTree #red_team #GhostTree #NTFS #DefenseEvasion

Спокойно, держим руки под столом: «взлом OnlyFans» — это компилят из старых утечек Стихийно по рунету разносится новость о взломе одного популярного сервиса и сливе данных «340 млн записей пользователей», собранных из «внутренних баз данных OnlyFans». Продавец оценил базу данных в 0,313 BTC. Все дают ссылку на Hackread, при этом в самой статье указано, что в ответ на запрос портала продавец честно признался, что не взламывал OnlyFans. База данных была создана им на основе информации, полученной в результате предыдущих утечек данных и сопоставил из с другими утечками и данными из открытых источников, включая взломанные записи с Twitter, Spotify и еже с ними. В компиляте есть имена пользователей, адреса электронной почты, номера телефонов, даты регистрации, количество подписчиков, лайки, статистика загруженного контента, ссылки на профили в социальных сетях и типы аккаунтов, а также поле «карта» с последними четырьмя цифрами платежной карты, привязанной к сервису. Часть информации Hackread смогли проверить и подтвердить, часть — нет. #red_team

В эту пятницу и выходные меня ни на что не будет хватать кроме как на.... https://kiberboloid.ru/trendi/dachnaya-zhizn-kiberbezopasnikov/

Некоторое из статьи: ▶️Flipper Zero и Flipper One работают на разных уровнях протоколов и не заменяют друг друга, то есть это разные категории устройств. ▶️Flipper One — это попытка переосмыслить, чем может быть Linux кибердек. ▶️Коллаба с Collabora, которая активно работает над добавлением поддержки Rockchip RK3576 в мейнлайн-ядро Linux. То есть Flipper One сможет работать сразу на ванильном ядре без закрытого кода и танцев с бубном. ▶️SoC RK3576 поддерживается в мейнлайне почти полностью. ▶️Flipper One работает на двух процессорах: 8-ядерная система-на-чипе RK3576 (GPU Mali-G52 и NPU для запуска локально LLM и других моделей) и 2-ядерный микроконтроллер Raspberry Pi RP2350 (MCU Firmware), который управляет дисплеем, кнопками, тачпадом, светодиодами и подсистемой питания. ▶️Рассказали про Flipper OS немного ▶️Запустили Developer Portal → docs.flipper.net/one ▶️Присоединиться к разработке по ссылке docs.flipper.net/one/how-to-join @Lobrigate, твое любимое — Flipper One будет поддерживать внешние AI-агенты через интеграции. Благодаря встроенному AI-ускорителю Flipper One может запускать LLM локально, без интернета и помогать пользователю работать с устройством, генерировать конфиги и давать полезные подсказки. #red_team

Дождались!

Flipper One — нам нужна ваша помощь Мы наконец готовы рассказать про Flipper One — проект, над которым корпим уже много лет и который несколько раз полностью переделывали с нуля. Это очень сложный проект как экономически, так и технически. Поэтому сегодня мы выходим в паблик не с триумфальным анонсом, а чтобы рассказать все как есть. Скажем честно — нам тупо страшно и нам нужна ваша помощь. https://habr.com/ru/companies/flipperdevices/articles/1033162/