Edera
CVE-2025-62518 Shows the Cost of Open Source Abandonware
Edera uncovers TARmageddon (CVE-2025-62518), a Rust async-tar RCE flaw exposing the real dangers of open-source abandonware and supply chain security.
TARmageddon — баг в библиотеке async-tar и ее форках (Rust)
#TARmageddon #devsecops #CVE #Rust #tar
TARmageddon (CVE-2025-62518) — логическая уязвимость в экосистеме async-tar и ее форках tokio-tar и astral-tokio-tar. Парсер ориентируется на значение из ustar-заголовка, которое может быть нулевым, при этом игнорируется или не согласуется PAX-size. В результате реальный блок данных остается в потоке и его заголовки интерпретируются как новые записи внешнего архива.
➡️ Что дает эксплуатация
RCE/hijack сборки — при установке/распаковке пакета атакующий может привести к перезаписи файлов конфигурации сборки, что позволяет перенаправить сборку на вредоносный backend и исполнить код в CI/локальной среде.
Bypass сканеров/supply-chain contamination — сканер проверяет чистый внешний TAR и помечает пакет как безопасный, затем уязвимый распаковщик вносит незадекларированные файлы в результирующий артефакт/deploy.
➡️ Эксплуатация
Создаем внешний TAR, где для одной записи в PAX-extended-header указано size > 0, а в стандартном ustar-заголовке поле размера равно 0 (ustar size хранится в восьмеричном виде).
В теле этой записи лежит вложенный TAR, начинающийся с корректных TAR-заголовков (в PoC помечены как INNER_FILE).
Корректные реализации (например, GNU tar) при распаковке дадут последовательность normal.txt -> blob.bin -> marker.txt, уязвимые парсеры — normal.txt -> blob.bin -> INNER_FILE -> marker.txt.
Появление INNER_FILE в выводе уязвимого парсера — индикатор бага.
➡️ Как защититься
Обновить до патченых версий или заменить на активно поддерживаемую реализацию, например на патч-ветку/форк, рекомендованный исследователями.
Распаковывать архивы в изолированные песочницы, валидировать содержимое против ожидаемого манифеста/контента до переезда в рабочую директорию, запрет перезаписи ключевых файлов и post-extract-сканирование на неожиданные записи.
Идентифицировать проекты, использующие уязвимые библиотеки, и приоритезировать обновления/ремедиацию в supply-chain.
🔗 Источник
🪲 PoC
🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK | ❤️ Мерч
#TARmageddon #devsecops #CVE #Rust #tar
TARmageddon (CVE-2025-62518) — логическая уязвимость в экосистеме async-tar и ее форках tokio-tar и astral-tokio-tar. Парсер ориентируется на значение из ustar-заголовка, которое может быть нулевым, при этом игнорируется или не согласуется PAX-size. В результате реальный блок данных остается в потоке и его заголовки интерпретируются как новые записи внешнего архива.
RCE/hijack сборки — при установке/распаковке пакета атакующий может привести к перезаписи файлов конфигурации сборки, что позволяет перенаправить сборку на вредоносный backend и исполнить код в CI/локальной среде.
Bypass сканеров/supply-chain contamination — сканер проверяет чистый внешний TAR и помечает пакет как безопасный, затем уязвимый распаковщик вносит незадекларированные файлы в результирующий артефакт/deploy.
Создаем внешний TAR, где для одной записи в PAX-extended-header указано size > 0, а в стандартном ustar-заголовке поле размера равно 0 (ustar size хранится в восьмеричном виде).
В теле этой записи лежит вложенный TAR, начинающийся с корректных TAR-заголовков (в PoC помечены как INNER_FILE).
Корректные реализации (например, GNU tar) при распаковке дадут последовательность normal.txt -> blob.bin -> marker.txt, уязвимые парсеры — normal.txt -> blob.bin -> INNER_FILE -> marker.txt.
Появление INNER_FILE в выводе уязвимого парсера — индикатор бага.
Обновить до патченых версий или заменить на активно поддерживаемую реализацию, например на патч-ветку/форк, рекомендованный исследователями.
Распаковывать архивы в изолированные песочницы, валидировать содержимое против ожидаемого манифеста/контента до переезда в рабочую директорию, запрет перезаписи ключевых файлов и post-extract-сканирование на неожиданные записи.
Идентифицировать проекты, использующие уязвимые библиотеки, и приоритезировать обновления/ремедиацию в supply-chain.
Please open Telegram to view this post
VIEW IN TELEGRAM
Как работает Blind LDAP Injection — на примере реального CTF-задания
#Microsoft #AD #LDAP #CTF
Сегодня я предлагаю вместе разобраться с довольно сложным CTF-заданием, посвящённому слепой LDAP-инъекции (Blind LDAP Injection).
Оно будет особенно интересным, ведь его смогли решить всего около 50 человек из примерно 500. Мне удалось получить флаг одним из первых десяти участников — за 2 часа, причём без глубокого опыта работы с LDAP протоколами.
Решение и код лежат также на Github
🔗 Источник
🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK | ❤️ Мерч
#Microsoft #AD #LDAP #CTF
Сегодня я предлагаю вместе разобраться с довольно сложным CTF-заданием, посвящённому слепой LDAP-инъекции (Blind LDAP Injection).
Оно будет особенно интересным, ведь его смогли решить всего около 50 человек из примерно 500. Мне удалось получить флаг одним из первых десяти участников — за 2 часа, причём без глубокого опыта работы с LDAP протоколами.
Решение и код лежат также на Github
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥20
RCE в сетевых принтерах Canon через стандартный механизм печати и TTF-шрифт
#RCE #Canon #принтеры #ThreatHunting
В стандартном сценарии работы с принтерами Canon клиент формирует задачу на печать (print-job) в формате XPS/POSTSCRIPT/PJL, отправляет ее устройству, после чего встроенный парсер XPS/TTF обрабатывает ресурсы: страницы, изображения и шрифты. Встраивание в XPS специально сконструированного TTF-шрифта может вызвать некорректную обработку в прошивке и привести к RCE на устройстве.
➡️ Технические нюансы
• Принтеры принимают задания в формате XPS (ZIP + XML) или по RAW/PJL (порт 9100). XPS поддерживает embedded-ресурсы, включая TTF.
• Уязвимость кроется в обработке таблиц TrueType (head, cmap, maxp, loca, glyf, kern и др.). Парсер не всегда валидирует границы смещения и количество записей, что приводит к out-of-bounds-чтению/записи и потенциальной memory corruption.
• Типичные триггеры: неконсистентные поля numTables/offset/length, аномально большие glyf/loca или специально составленные composite glyphs/instructions.
➡️ Последовательность атаки
• Формируется XPS/print-job с embedded TTF, содержащим неконсистентные поля.
• Отправка job-а на принтер напрямую по TCP/9100 через HTTP(S)/SNMP-интерфейс, SMB или через print-server.
• Устройство распаковывает XPS, парсер TTF проходит таблицы и сталкивается с некорректными полями, что приводит к нарушению работы.
• При управляемой коррумпции памяти возможен захват управления потоком исполнения (RCE) либо DoS.
• При успешном RCE можно попытаться записать модифицированную прошивку, установить C2 или использовать принтер как pivot-точку в сети.
➡️ Последствия
• DoS: падение/перезагрузка принтера или print-server, потеря возможности печати.
• Foothold: при RCE — интерактивный доступ в сеть (мост между VLAN/DMZ) + persistence.
• Утечка данных: доступ к очередям печати, документам, эксфильтрация по сети.
Масштаб риска зависит от доли уязвимых прошивок в парке устройств. Массовая эксплуатация экспонированных принтеров — возможна.
➡️ Как защититься
• Поместить принтеры в отдельный VLAN с ограничением входящих и исходящих соединений.
• Разрешать печать только с доверенных хостов через контролируемый print-server.
• Блокировать/ограничить порт 9100 (RAW/PJL) снаружи и на границе сети.
• Принимать XPS/ZIP через print-server, который проверяет и фильтрует встроенные ресурсы (включая TTF).
• Отключить/фильтровать XPS где это возможно. Если нельзя — сканировать вложенные шрифты на аномалии.
🔗 Источник
🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK | ❤️ Мерч
#RCE #Canon #принтеры #ThreatHunting
В стандартном сценарии работы с принтерами Canon клиент формирует задачу на печать (print-job) в формате XPS/POSTSCRIPT/PJL, отправляет ее устройству, после чего встроенный парсер XPS/TTF обрабатывает ресурсы: страницы, изображения и шрифты. Встраивание в XPS специально сконструированного TTF-шрифта может вызвать некорректную обработку в прошивке и привести к RCE на устройстве.
• Принтеры принимают задания в формате XPS (ZIP + XML) или по RAW/PJL (порт 9100). XPS поддерживает embedded-ресурсы, включая TTF.
• Уязвимость кроется в обработке таблиц TrueType (head, cmap, maxp, loca, glyf, kern и др.). Парсер не всегда валидирует границы смещения и количество записей, что приводит к out-of-bounds-чтению/записи и потенциальной memory corruption.
• Типичные триггеры: неконсистентные поля numTables/offset/length, аномально большие glyf/loca или специально составленные composite glyphs/instructions.
• Формируется XPS/print-job с embedded TTF, содержащим неконсистентные поля.
• Отправка job-а на принтер напрямую по TCP/9100 через HTTP(S)/SNMP-интерфейс, SMB или через print-server.
• Устройство распаковывает XPS, парсер TTF проходит таблицы и сталкивается с некорректными полями, что приводит к нарушению работы.
• При управляемой коррумпции памяти возможен захват управления потоком исполнения (RCE) либо DoS.
• При успешном RCE можно попытаться записать модифицированную прошивку, установить C2 или использовать принтер как pivot-точку в сети.
• DoS: падение/перезагрузка принтера или print-server, потеря возможности печати.
• Foothold: при RCE — интерактивный доступ в сеть (мост между VLAN/DMZ) + persistence.
• Утечка данных: доступ к очередям печати, документам, эксфильтрация по сети.
Масштаб риска зависит от доли уязвимых прошивок в парке устройств. Массовая эксплуатация экспонированных принтеров — возможна.
• Поместить принтеры в отдельный VLAN с ограничением входящих и исходящих соединений.
• Разрешать печать только с доверенных хостов через контролируемый print-server.
• Блокировать/ограничить порт 9100 (RAW/PJL) снаружи и на границе сети.
• Принимать XPS/ZIP через print-server, который проверяет и фильтрует встроенные ресурсы (включая TTF).
• Отключить/фильтровать XPS где это возможно. Если нельзя — сканировать вложенные шрифты на аномалии.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10🔥5
Sliver C2: изучение, демонстрация работы, детект
#sliver #C2 #yara #blue_team #red_team #suricata #wazuh
Sliver C2 - это фреймворк Red Team с открытым исходным кодом, разработанный компанией BishopFox, занимающейся кибербезопасностью, и представляет собой кроссплатформенную среду постэксплуатации. Он используется для выполнения второго этапа выполнения цепочки атак на внутреннюю сеть (когда компьютер жертвы уже был скомпрометирован доступными способами) и является альтернативой такого коммерческого инструмента как CobaltStrike, как утверждают сами производители.
➡️ Архитектура Sliver C2
Архитектура Sliver C2 состоит из трёх частей:
1. Сервер Sliver C2. Является частью исполняемого файла sliver-server, управляет внутренней базой данных, а также запускает и останавливает сетевые прослушиватели. Основным интерфейсом взаимодействия с сервером является интерфейс gRPC, через него реализуются все функции.
2. Клиентская консоль. Это основной пользовательский интерфейс для взаимодействия с сервером Sliver C2.
3. Импланты. Это вредоносный код, нагрузка, (exe, ps1 и т. д.), запускаемая в целевой системе.
🔗 blog.poxek
🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK | ❤️ Мерч
#sliver #C2 #yara #blue_team #red_team #suricata #wazuh
Sliver C2 - это фреймворк Red Team с открытым исходным кодом, разработанный компанией BishopFox, занимающейся кибербезопасностью, и представляет собой кроссплатформенную среду постэксплуатации. Он используется для выполнения второго этапа выполнения цепочки атак на внутреннюю сеть (когда компьютер жертвы уже был скомпрометирован доступными способами) и является альтернативой такого коммерческого инструмента как CobaltStrike, как утверждают сами производители.
Архитектура Sliver C2 состоит из трёх частей:
1. Сервер Sliver C2. Является частью исполняемого файла sliver-server, управляет внутренней базой данных, а также запускает и останавливает сетевые прослушиватели. Основным интерфейсом взаимодействия с сервером является интерфейс gRPC, через него реализуются все функции.
2. Клиентская консоль. Это основной пользовательский интерфейс для взаимодействия с сервером Sliver C2.
3. Импланты. Это вредоносный код, нагрузка, (exe, ps1 и т. д.), запускаемая в целевой системе.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤🔥3
Тачка на прокачку. Эксплуатируем RCE в головном устройстве автомобиля
#car #RCE
Мы изучили безопасность типичного «мозга» китайского автомобиля — SoC со встроенным сотовым модемом. Низкоуровневая ошибка переполнения стека позволила удаленно выполнить код на ранней стадии соединения — до срабатывания защит. Следом мы получили доступ к процессору приложений и смогли запустить произвольный код с максимальными привилегиями — то есть получили полный контроль над бортовым компьютером.
🔗 Источник
🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK | ❤️ Мерч
#car #RCE
Мы изучили безопасность типичного «мозга» китайского автомобиля — SoC со встроенным сотовым модемом. Низкоуровневая ошибка переполнения стека позволила удаленно выполнить код на ранней стадии соединения — до срабатывания защит. Следом мы получили доступ к процессору приложений и смогли запустить произвольный код с максимальными привилегиями — то есть получили полный контроль над бортовым компьютером.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Похек AI (Сергей Зыбнев)
Разбор OWASP TOP10 for LLM Applications
#OWASP #llm #top10
LLM01: Prompt Injection (Инъекция промпта)
Это атака, при которой злоумышленник внедряет в пользовательский запрос (промпт) вредоносные инструкции, которые переопределяют исходные задачи модели и заставляют ее выполнять непредусмотренные действия. Уязвимость занимает первое место из-за исключительной простоты эксплуатации и высокой степени потенциального ущерба. По сути, это напоминает социальную инженерию, только нацеленную на AI.
LLM02: Sensitive Information Disclosure (Раскрытие чувствительной информации)
LLM может непреднамеренно раскрыть конфиденциальные данные, на которых она обучалась или которые получила в текущем контексте диалога. Модель не всегда способна отличить общедоступную информацию от частной.
LLM03: Supply Chain Vulnerabilities (Уязвимости в цепочке поставок)
Уязвимости, связанные со сторонними компонентами, которые используются в LLM-приложении. Это могут быть плагины, датасеты или даже скомпрометированные предобученные модели.
LLM04: Data and Model Poisoning (Отравление данных и модели)
Целенаправленное манипулирование обучающими данными или процессом дообучения модели с целью создания бэкдоров, снижения ее производительности или внедрения определенной предвзятости.
LLM05: Improper Output Handling (Небезопасная обработка вывода)
Эта уязвимость возникает, когда вывод LLM напрямую и без должной проверки передается в другие компоненты системы (например, в frontend для рендеринга или в бэкенд для выполнения). Это аналог классических веб-уязвимостей, таких как XSS или CSRF.
LLM06: Excessive Agency (Чрезмерные полномочия)
Предоставление LLM-агентам слишком широких прав, доступа к инструментам или возможности действовать автономно без надлежащего контроля и подтверждения со стороны человека.
LLM07: System Prompt Leakage (Утечка системного промпта)
Эта атака направлена на то, чтобы заставить LLM раскрыть свой «системный промпт» — набор первоначальных инструкций, определяющих ее поведение: конфигурационную информацию, правила безопасности, а иногда, по неосторожности разработчиков, конфиденциальные данные, такие как API-ключи или внутренние идентификаторы.
LLM08: Vector and Embedding Weaknesses (Слабости векторов и эмбеддингов)
Описание: Атаки на системы Retrieval-Augmented Generation (RAG), которые используют векторные базы данных для поиска релевантной информации.
LLM09: Misinformation (Дезинформация)
Генерация LLM фактически неверной, предвзятой или полностью вымышленной информации, которая при этом выглядит правдоподобно. Хотя это не всегда является результатом злонамеренной атаки, оно представляет собой серьезную проблему, поскольку пользователи склонны доверять авторитетно звучащим ответам машины.
LLM10: Unbounded Consumption (Неограниченное потребление)
Атака, при которой злоумышленник заставляет LLM-приложение выполнять чрезмерно ресурсоемкие операции, что приводит к исчерпанию бюджета на API и/или отказу в обслуживании (DoS).
🔗 Данный пост выжимка моей статьи на Habr, где я для каждой категории расписал сценарий атаки, с примерами промптов, рекомендаций и т.д. Очень советую прочитать всё
Будет вторая часть, про другой OWASP TOP10, ожидайте после праздников)
🌚 @poxek_ai
#OWASP #llm #top10
LLM01: Prompt Injection (Инъекция промпта)
Это атака, при которой злоумышленник внедряет в пользовательский запрос (промпт) вредоносные инструкции, которые переопределяют исходные задачи модели и заставляют ее выполнять непредусмотренные действия. Уязвимость занимает первое место из-за исключительной простоты эксплуатации и высокой степени потенциального ущерба. По сути, это напоминает социальную инженерию, только нацеленную на AI.
LLM02: Sensitive Information Disclosure (Раскрытие чувствительной информации)
LLM может непреднамеренно раскрыть конфиденциальные данные, на которых она обучалась или которые получила в текущем контексте диалога. Модель не всегда способна отличить общедоступную информацию от частной.
LLM03: Supply Chain Vulnerabilities (Уязвимости в цепочке поставок)
Уязвимости, связанные со сторонними компонентами, которые используются в LLM-приложении. Это могут быть плагины, датасеты или даже скомпрометированные предобученные модели.
LLM04: Data and Model Poisoning (Отравление данных и модели)
Целенаправленное манипулирование обучающими данными или процессом дообучения модели с целью создания бэкдоров, снижения ее производительности или внедрения определенной предвзятости.
LLM05: Improper Output Handling (Небезопасная обработка вывода)
Эта уязвимость возникает, когда вывод LLM напрямую и без должной проверки передается в другие компоненты системы (например, в frontend для рендеринга или в бэкенд для выполнения). Это аналог классических веб-уязвимостей, таких как XSS или CSRF.
LLM06: Excessive Agency (Чрезмерные полномочия)
Предоставление LLM-агентам слишком широких прав, доступа к инструментам или возможности действовать автономно без надлежащего контроля и подтверждения со стороны человека.
LLM07: System Prompt Leakage (Утечка системного промпта)
Эта атака направлена на то, чтобы заставить LLM раскрыть свой «системный промпт» — набор первоначальных инструкций, определяющих ее поведение: конфигурационную информацию, правила безопасности, а иногда, по неосторожности разработчиков, конфиденциальные данные, такие как API-ключи или внутренние идентификаторы.
LLM08: Vector and Embedding Weaknesses (Слабости векторов и эмбеддингов)
Описание: Атаки на системы Retrieval-Augmented Generation (RAG), которые используют векторные базы данных для поиска релевантной информации.
LLM09: Misinformation (Дезинформация)
Генерация LLM фактически неверной, предвзятой или полностью вымышленной информации, которая при этом выглядит правдоподобно. Хотя это не всегда является результатом злонамеренной атаки, оно представляет собой серьезную проблему, поскольку пользователи склонны доверять авторитетно звучащим ответам машины.
LLM10: Unbounded Consumption (Неограниченное потребление)
Атака, при которой злоумышленник заставляет LLM-приложение выполнять чрезмерно ресурсоемкие операции, что приводит к исчерпанию бюджета на API и/или отказу в обслуживании (DoS).
Будет вторая часть, про другой OWASP TOP10, ожидайте после праздников)
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥18🔥2👍1
Ловите вкусные баги прошедшей недели
#CVE #RCE #WordPress #Taiga #Veam #WAVLINK
➡️ WP-плагин Tablesome Table – Contact Form DB (CVE-2025-62368, CVSS 9,8) — в функции set_featured_image_from_external_url() отсутствует проверка расширений загружаемых файлов, что позволяет неаутентифицированному удаленному атакующему передать произвольный файл на сервер через механизмы приема данных WPForms, Contact Form 7, Gravity, Forminator, Fluent и т.д. Как результат — unauth RCE и захвата сайта. Эксплуатация не требует привилегий, а также действий от владельца ресурса.
➡️ WP-плагин WooCommerce Designer Pro (CVE-2025-6440, CVSS 9,8) — в функции wcdp_save_canvas_design_ajax отсутствует проверка типа загружаемых файлов. Это позволяет неаутентифицированному атакующему отправить произвольный файл на сервер сайта, например PHP-скрипт. Как результат — RCE в контексте веб-сервера.
➡️ Taiga (CVE-2025-62368, CVE 9,0) — критическая уязвимость в API Taiga (taiga-back) — популярном open-source инструменте управления разработкой. Проблема заключается в ненадежной десериализации данных, поступающих в API. Аутентифицированный удаленный атакующий может отправить специально сформированный объект, который при десериализации приводит к выполнению произвольного кода в контексте процесса Taiga. Как результат — RCE, эскалация полномочий и полный контроль над инстансом.
➡️ Veeam Backup & Replication (CVE-2025-48983, CVSS 9,9) — ошибка в серверном компоненте обработки входящих API/сервис-запросов. Аутентифицированный атакующий может отправить специально сформированные запросы в серверный компонент резервного решения и добиться исполнения произвольного кода на машине сервера резервного копирования. Как итог — возможность выполнять команды в контексте сервиса/системного процесса, управлять заданиями бэкапа и обращаться к хранилищу резервных копий.
➡️ Маршрутизаторы WAVLINK (CVE-2025-61128, CVSS 9,1) — критическая уязвимость в прошивке маршрутизаторов WAVLINK. В обработчике HTTP POST-запроса к /login.cgi обнаружено переполнение буфера при разборе поля Referer/referrer. Это позволяет удаленному неаутентифицированному атакующему послать специально сформированный запрос с чрезмерно длинной и специфической нагрузкой и перезаписать управляющие данные в памяти. Как итог — выполнение произвольного кода в контексте процесса веб-сервера прошивки, захват устройства, установке бэкдоров и перехват трафика.
🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK | ❤️ Мерч
#CVE #RCE #WordPress #Taiga #Veam #WAVLINK
Please open Telegram to view this post
VIEW IN TELEGRAM
BIND 9 Cache Poisoning
#BIND9 #DNS #cachepoisoning #ThreatHunting #IncidentResponse
В 2008 году Дэн Каминский продемонстрировал практическую опасность DNS cache poisoning. Две критические уязвимости в BIND 9 возвращают нас к этой проблеме, напоминая, что отравление DNS-кэша остается реальной угрозой.
Речь о сочетании избыточного доверия BIND к некоторым полям ответов (unsolicited/extra RRs) и предсказуемости генерации псевдослучайных параметров (PRNG):
CVE-2025-40778 — логическая ошибка обработки ответов. В ряде кодовых путей BIND-9 парсер/обработчик принимает RR из секций answer/authority/additional, не связанных с исходным запросом, и помещает эти unsolicited RRset в локальный кэш рекурсивного резолвера. Это позволяет делать инъекции поддельных записей в кеш.
CVE-2025-40780 — ослабление энтропии PRNG, который формирует transaction ID и source port. Резолвер сопоставляет ответы по transaction ID, source port, src/dst IP и таймингу. Если пространство комбинаций сильно сокращено, вероятность корректного угадывания и приема форженного ответа существенно возрастает.
CVE-2025-40780 усиливает эффект CVE-2025-40778
Предсказуемые транзакционные поля повышают вероятность того, что форженный пакет будет сопоставлен с запросом и пройдет в уязвимый кодовый путь, что делает инъекцию в кэш более вероятной.
Масштабы катастрофы
Затронутые версии: ветки BIND-9 от 9.11.0 до 9.21.12. По оценкам CyberPress, было обнаружено порядка ~706 000 уязвимых резолверов, каждый из которых может обслуживать до сотен тысяч клиентов. Компрометация отдельных резолверов дает широкий blast radius для подмены ответов.
🪲 PoC
🔗 Источники
• ISC Security Advisory CVE-2025-40778
• SOC Prime Analysis
• CyberPress Exposure Report
🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK | ❤️ Мерч
#BIND9 #DNS #cachepoisoning #ThreatHunting #IncidentResponse
В 2008 году Дэн Каминский продемонстрировал практическую опасность DNS cache poisoning. Две критические уязвимости в BIND 9 возвращают нас к этой проблеме, напоминая, что отравление DNS-кэша остается реальной угрозой.
Речь о сочетании избыточного доверия BIND к некоторым полям ответов (unsolicited/extra RRs) и предсказуемости генерации псевдослучайных параметров (PRNG):
CVE-2025-40778 — логическая ошибка обработки ответов. В ряде кодовых путей BIND-9 парсер/обработчик принимает RR из секций answer/authority/additional, не связанных с исходным запросом, и помещает эти unsolicited RRset в локальный кэш рекурсивного резолвера. Это позволяет делать инъекции поддельных записей в кеш.
CVE-2025-40780 — ослабление энтропии PRNG, который формирует transaction ID и source port. Резолвер сопоставляет ответы по transaction ID, source port, src/dst IP и таймингу. Если пространство комбинаций сильно сокращено, вероятность корректного угадывания и приема форженного ответа существенно возрастает.
CVE-2025-40780 усиливает эффект CVE-2025-40778
Предсказуемые транзакционные поля повышают вероятность того, что форженный пакет будет сопоставлен с запросом и пройдет в уязвимый кодовый путь, что делает инъекцию в кэш более вероятной.
Масштабы катастрофы
Затронутые версии: ветки BIND-9 от 9.11.0 до 9.21.12. По оценкам CyberPress, было обнаружено порядка ~706 000 уязвимых резолверов, каждый из которых может обслуживать до сотен тысяч клиентов. Компрометация отдельных резолверов дает широкий blast radius для подмены ответов.
• ISC Security Advisory CVE-2025-40778
• SOC Prime Analysis
• CyberPress Exposure Report
Please open Telegram to view this post
VIEW IN TELEGRAM
XWiki под прицелом: CVE-2025-24893 превращает серверы в криптофермы
#CVE #XWiki #RCE #ThreatHunting #SOC #IR
CVE-2025-24893 связана с ошибкой в обработке входных параметров в макросе SolrSearch, благодаря которой неаутентифицированный пользователь может заставить XWiki выполнить произвольный код на сервере. В ряде случаев ввод пользовательских данных попадает в контекст выполнения без должной фильтрации или ограничения возможностей выполняемого кода. Это дает RCE на уровне JVM-процесса XWiki.
CVE-2025-24893 активно эксплуатируется в атаках с целью распространения майнера Monero по меньшей мере с марта 2025 года. Но только сейчас этот баг получил должное внимание и был, наконец, включен в CISA KEV (30 октября). Особенности и детали атаки описали специалисты VulnCheck.
➡️ Грамотный тайминг = обход защиты
Главная особенность кампании — разделение действий на два этапа. Это позволяет сбить с толку системы мониторинга, ищущие последовательные подозрительные действия.
• Этап I — атакующий отправляет HTTP‑запрос к
• Этап II — стартует не менее чем через 20 минут с момента загрузки файла. Отправляется новый запрос с кодом, загружающий два файла: один создает директории, качает майнер
Из-за разрыва по времени защита не связывает два этих этапа. В первом она может посчитать, что речь идет о легитимном единоразовом обновлении софта. Во втором — заметить подозрительную активность, но без контекста не выявить угрозу.
➡️ Масштабы
Поскольку уязвимость затрагивает версии XWiki с 5.3-milestone-2 до 15.10.10 и с 16.0.0-rc-1 до 16.4.0, все организации, не обновившие платформу, находятся в группе риска.
➡️ Сигнатуры и IOC для оперативной детекции
•
• Шаблонные и Groovy-конструкции в параметрах и/или теле запроса. Regex для SIEM/IDS:
• POST/GET к уязвимым путям + тело >1KB + совпадение по шаблонному регексу.
• java/JVM процесс создает дочерние процессы (
• Исходящие соединения на неизвестные IP/домены (особенно нестандартные порты)
• Появление неизвестных файлов с правом исполнения в
🔗 Источник
🪲 PoC
🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK | ❤️ Мерч
#CVE #XWiki #RCE #ThreatHunting #SOC #IR
CVE-2025-24893 связана с ошибкой в обработке входных параметров в макросе SolrSearch, благодаря которой неаутентифицированный пользователь может заставить XWiki выполнить произвольный код на сервере. В ряде случаев ввод пользовательских данных попадает в контекст выполнения без должной фильтрации или ограничения возможностей выполняемого кода. Это дает RCE на уровне JVM-процесса XWiki.
CVE-2025-24893 активно эксплуатируется в атаках с целью распространения майнера Monero по меньшей мере с марта 2025 года. Но только сейчас этот баг получил должное внимание и был, наконец, включен в CISA KEV (30 октября). Особенности и детали атаки описали специалисты VulnCheck.
Главная особенность кампании — разделение действий на два этапа. Это позволяет сбить с толку системы мониторинга, ищущие последовательные подозрительные действия.
• Этап I — атакующий отправляет HTTP‑запрос к
/xwiki/bin/get/Main/SolrSearch с параметром media=rss и внедренным Groovy‑кодом. Код выполняет команду на скачивание файла. Файл скачивается, но не запускается.• Этап II — стартует не менее чем через 20 минут с момента загрузки файла. Отправляется новый запрос с кодом, загружающий два файла: один создает директории, качает майнер
tcrond, устанавливает права, второй — очищает лог, убивает конкурирующие майнеры, запускает tcrond с конфигом.Из-за разрыва по времени защита не связывает два этих этапа. В первом она может посчитать, что речь идет о легитимном единоразовом обновлении софта. Во втором — заметить подозрительную активность, но без контекста не выявить угрозу.
Поскольку уязвимость затрагивает версии XWiki с 5.3-milestone-2 до 15.10.10 и с 16.0.0-rc-1 до 16.4.0, все организации, не обновившие платформу, находятся в группе риска.
•
http.request_path содержит: /SolrSearch, /solr, /xwiki/bin/view, /rest/search.• Шаблонные и Groovy-конструкции в параметрах и/или теле запроса. Regex для SIEM/IDS:
(\$\{[^}]+\}|\@\{[^}]+\}|\<%.*?%>|\b(Runtime\.getRuntime|ProcessBuilder|Class\.forName|new\s+java\.lang)\b)— срабатывание = высокий приоритет.• POST/GET к уязвимым путям + тело >1KB + совпадение по шаблонному регексу.
• java/JVM процесс создает дочерние процессы (
/bin/sh, curl, wget, python, bash).• Исходящие соединения на неизвестные IP/домены (особенно нестандартные порты)
• Появление неизвестных файлов с правом исполнения в
/tmp, /var/tmp, WEB-INF/lib, WEB-INF/classes, каталогах приложения.Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7
Вектор Атаки: TI & TH – Как защитить бизнес и построить карьеру
#подкаст
В новом выпуске подкаста «Обсуждаем Похек» мы погружаемся в мир Threat Intelligence в SOC вместе с Яном Кустовым, техлидом TI из компании К2 Кибербезопасность. Узнайте, как работает киберразведка изнутри: от расследования инцидентов с использованием древних лолбинов до построения гибридных моделей TI. Ян делится реальными кейсами предотвращения фишинговых атак, локализации инцидентов за 4 часа и экономии миллионов благодаря своевременному обнаружению угроз.
Разбираем практические аспекты Threat Intelligence: чем TI отличается от Threat Hunting, как автоматизировать сбор данных из RSS-лент и даркнета, какие навыки нужны аналитику киберугроз, и стоит ли компании строить собственную TI-команду или выбрать сервисную модель. Обсуждаем метрики эффективности TI, роль искусственного интеллекта и машинного обучения в анализе угроз, а также методы противодействия злоумышленников. Особое внимание уделяется источникам threat intelligence фидов и реальным примерам защиты бизнеса от промышленного шпионажа и APT-группировок.
Этот выпуск будет полезен специалистам по информационной безопасности, SOC-аналитикам, руководителям ИБ-департаментов и всем, кто хочет понять, как превентивная кибербезопасность помогает защитить инфраструктуру компании от современных киберугроз.
🔗 Ссылки:
💬 Слушать в Telegram
📹 YouTube
📺 RuTube
💙 VK Видео
🎵 Apple Podcasts
🎵 Яндекс.Музыка
🔤 Mave
💻 К2 Кибербезопасность
Обязательно смотрите/слушайте до конца!
🌚 @poxek | 🌚 Блог | 📺 YT | 📺 RT | 📺 VK
#подкаст
В новом выпуске подкаста «Обсуждаем Похек» мы погружаемся в мир Threat Intelligence в SOC вместе с Яном Кустовым, техлидом TI из компании К2 Кибербезопасность. Узнайте, как работает киберразведка изнутри: от расследования инцидентов с использованием древних лолбинов до построения гибридных моделей TI. Ян делится реальными кейсами предотвращения фишинговых атак, локализации инцидентов за 4 часа и экономии миллионов благодаря своевременному обнаружению угроз.
Разбираем практические аспекты Threat Intelligence: чем TI отличается от Threat Hunting, как автоматизировать сбор данных из RSS-лент и даркнета, какие навыки нужны аналитику киберугроз, и стоит ли компании строить собственную TI-команду или выбрать сервисную модель. Обсуждаем метрики эффективности TI, роль искусственного интеллекта и машинного обучения в анализе угроз, а также методы противодействия злоумышленников. Особое внимание уделяется источникам threat intelligence фидов и реальным примерам защиты бизнеса от промышленного шпионажа и APT-группировок.
Этот выпуск будет полезен специалистам по информационной безопасности, SOC-аналитикам, руководителям ИБ-департаментов и всем, кто хочет понять, как превентивная кибербезопасность помогает защитить инфраструктуру компании от современных киберугроз.
Обязательно смотрите/слушайте до конца!
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥9
CVE-2025-11953 — unauth RCE из-за уязвимой зависимости в React Native
#CVE #RCE #PoC #developer #dev #metro #react #ReactNative
Metro Development Server, используемый в React Native CLI, по умолчанию слушает все сетевые интерфейсы (
На Linux и macOS open вызывает команды
Проблема связана с тем, что React Native CLI запускает Metro Development Server, который использует уязвимый open-пакет для обработки
Уязвимый пакет:
Уязвимые версии: 4.8.0 — 20.0.0-alpha.2
CVSS: 9.8
➡️ Последовательность атаки
- Атакующий отправляет специально сформированный POST-запрос
- Metro сервер, доступный из внешней сети, принимает запрос.
- Введенные данные передаются в функцию open(), вызывающую системные команды без защиты.
- Атакующий получает возможность запускать произвольные команды — например, открыть calc.exe или создать файл pwned.txt.
Для проверки уязвимости можно использовать команды
➡️ Рекомендации
- Срочно обновить пакеты до версии 20.0.0 или выше, где уязвимость исправлена.
- Если обновление невозможно, запускать Metro сервер с привязкой к localhost (
- Проводить аудит зависимостей и сканирование цепочек поставок (SBOM) для выявления уязвимых версий и подозрительных модулей.
🔗 Источник
🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK | ❤️ Мерч
#CVE #RCE #PoC #developer #dev #metro #react #ReactNative
Metro Development Server, используемый в React Native CLI, по умолчанию слушает все сетевые интерфейсы (
0.0.0.0), что делает его доступным из внешних сетей. В сервер встроен эндпоинт POST /open-url, который принимает JSON с полем url. Значение этого поля напрямую передаётся в функцию open(url) из npm-пакета open (версия 6.4.0), которая на Windows вызывает cmd.exe без экранирования аргументов, позволяя выполнить произвольные системные команды с полным контролем параметров, например, запуск calc.exe или создание файла htb-easy-lol.txt.На Linux и macOS open вызывает команды
xdg-open и open без использования shell, аргументы передаются как отдельные параметры, поэтому прямой command injection затруднен. Для полноценного удалённого выполнения команд на этих системах требуются дополнительные уязвимости или эксплуатация особенностей URI-схем, таких как запуск локальных файлов через file://.Проблема связана с тем, что React Native CLI запускает Metro Development Server, который использует уязвимый open-пакет для обработки
/open-url, открывая путь к удалённому выполнению кода в среде разработки. Это критично, так как dev-сервер в ряде случаев доступен из внешних сетей и обрабатывает команды без защиты. Признайтесь, делали же проекты на 5 минут и потом это висело месяц в проде?)Уязвимый пакет:
@react-native-community/cli-server-api и @react-native-community/cliУязвимые версии: 4.8.0 — 20.0.0-alpha.2
CVSS: 9.8
- Атакующий отправляет специально сформированный POST-запрос
POST /open-url HTTP/1.1
Host: vulnerable-dev-server:8081
Content-Type: application/json
Content-Length: <length>
{
"url": "calc.exe"
}
- Metro сервер, доступный из внешней сети, принимает запрос.
- Введенные данные передаются в функцию open(), вызывающую системные команды без защиты.
- Атакующий получает возможность запускать произвольные команды — например, открыть calc.exe или создать файл pwned.txt.
Для проверки уязвимости можно использовать команды
npm list @react-native-community/cli-server-api и убедиться в используемой версии.- Срочно обновить пакеты до версии 20.0.0 или выше, где уязвимость исправлена.
- Если обновление невозможно, запускать Metro сервер с привязкой к localhost (
npx react-native start --host 127.0.0.1), чтобы заблокировать доступ извне.- Проводить аудит зависимостей и сканирование цепочек поставок (SBOM) для выявления уязвимых версий и подозрительных модулей.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15🌚5👾2
Рунету быть?
Постановление Правительства Российской Федерации от 27.10.2025 № 1667 "Об утверждении Правил централизованного управления сетью связи общего пользования"
Правительство утвердило правила «централизованного управления» Рунетом. Решения будут совместно принимать Минцифры, РКН и ФСБ. Они смогут вводить:
• Обязательную фильтрацию трафика
• Блокировать ресурсы
• Полную изоляцию Рунета от мировой сети
Новые правила вступают в силу с 1 марта 2026 и до 1 марта 2032 года.
Интересно, что документ датирован 27 октября, а судя по дате на сайте опубликовали его только 6 ноября🌚
🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK | ❤️ Мерч
Постановление Правительства Российской Федерации от 27.10.2025 № 1667 "Об утверждении Правил централизованного управления сетью связи общего пользования"
Правительство утвердило правила «централизованного управления» Рунетом. Решения будут совместно принимать Минцифры, РКН и ФСБ. Они смогут вводить:
• Обязательную фильтрацию трафика
• Блокировать ресурсы
• Полную изоляцию Рунета от мировой сети
Новые правила вступают в силу с 1 марта 2026 и до 1 марта 2032 года.
Интересно, что документ датирован 27 октября, а судя по дате на сайте опубликовали его только 6 ноября
Please open Telegram to view this post
VIEW IN TELEGRAM
💔22
Ловите вкусные баги прошедшей недели
#CVE #RCE #calibre #SQLi #NVIDIA #POS
➡️ Цепочка SQLi в системе управления точками продаж ycf1998 money-pos (CVE-2025-63689, CVSS 10,0) — плохая фильтрация параметра orderby, используемого в SQL-запросах для сортировки данных. Злоумышленник без привилегий и без авторизации может внедрить в этот параметр произвольный SQL-код, что открывает двери для RCE, кражи, изменения или удаления БД, а также полной компрометации системы. Потенциально позволяет атакующему взять под полный контроль POS-устройства. Публичных PoC пока нет.
➡️ calibre (CVE-2025-64486, CVSS 9,8) — критический баг в calibre версий 8.13.0 и ниже, связанный с отсутствием проверки имен файлов при обработке формата FB2 (FictionBook). Позволяет атакующему при помощи специально созданного FB2-файла записывать произвольные файлы в файловую систему, что может привести к выполнению произвольного кода с правами пользователя, под которым запущен calibre. Публичных PoC пока нет.
➡️ RCE в Snipe-IT (CVE-2025-63601, CVSS 9,9) — уязвимость вызвана отсутствием надежной проверки содержимого и структуры загружаемых файлов резервных копий в Snipe-IT. Сервер неправильно обрабатывает архивы, позволяя внедрять и выполнять произвольные файлы и команды при их распаковке, что создает возможность для RCE с правами сервера и полной компрометации системы. Публичных PoC пока нет.
➡️ Установщик NVIDIA NVApp для Windows (CVE-2025-23358, CVSS 8,2) — возникает из-за неправильного управления путями поиска исполняемых файлов и DLL. Позволяет локальному атакующему с низкими правами разместить вредоносный файл в каталоге, который загружается раньше легитимных компонентов, что приводит к выполнению произвольного кода с правами установщика и эскалации привилегий. Публичных PoC пока нет.
➡️ WordPress-плагин Gravity Forms (CVE-2025-12352, CVSS 9,8) — критическая уязвимость, связанная с отсутствием проверки типа загружаемых файлов в функции
🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK | ❤️ Мерч
#CVE #RCE #calibre #SQLi #NVIDIA #POS
copy_post_image(). Позволяет неавторизованному атакующему загрузить на сервер произвольные файлы, включая PHP-скрипты, что при включенной опции allow_url_fopen и активации формы создания постов с полем для файлов приводит к RCE. Есть PoC.Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥9🔥3👍2
Ограничения на длину URL и HTTP-заголовков можно использовать для эскалации XSS уязвимостей и захвата аккаунтов
#XSS #URL #HTTP
Веб-серверы накладывают жесткие лимиты на максимальный размер URL и HTTP-заголовков, при превышении которых возвращаются ошибки 414 или 431. В описываемой атаке сессионные токены передаются через URL или заголовки, и превышение лимитов прерывает редиректы, что позволяет атакующему получить URL с токеном сессии.
➡️ Суть бага
Уязвимость связана с недостаточной фильтрацией URL, заголовков и передачей конфиденциальных данных через URL. Это нарушает обработку запросов и дает доступ к сессионным токенам. Отсутствие адекватной обработки ошибок и плохая архитектура междоменной авторизации усиливают риск полного захвата аккаунта. Проблема осложняется слабой изоляцией сессий и надежным контролем безопасности в редиректах и cookie.
➡️ Сценарии атаки
При ошибке 414:
атакующий находит XSS на двух связанных сайтах с общей системой авторизации,
через XSS формирует URL с максимально длинным параметром возврата,
при редиректе сессионный токен добавляется к URL, превышая лимит,
сервер возвращает ошибку 414, прерывая цепочку редиректов,
атакующий перехватывает URL с токеном для кражи сессии.
При ошибке 431:
на сервере работает middleware, устанавливающий cookie.
атакующий очищает cookie и создает несколько больших cookie для превышения лимита заголовков,
при следующем запросе сервер возвращает ошибку 431, прерывая цепочку редиректов,
токен сессии появляется в URL.
➡️ Как защититься
Не передавать сессионные токены в URL.
Использовать защищенные HttpOnly и Secure куки.
Ограничивать длину URL и заголовков, при превышении лимитов не вызывать ошибки 414/431, а реализовывать безопасные редиректы (например, с кодом 302).
Фильтровать строго разрешенные пути и параметры URL.
Изолировать сессии разных доменов и предотвращать XSS через валидацию и Content Security Policy.
🔗 Источник
🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK | ❤️ Мерч
#XSS #URL #HTTP
Веб-серверы накладывают жесткие лимиты на максимальный размер URL и HTTP-заголовков, при превышении которых возвращаются ошибки 414 или 431. В описываемой атаке сессионные токены передаются через URL или заголовки, и превышение лимитов прерывает редиректы, что позволяет атакующему получить URL с токеном сессии.
Уязвимость связана с недостаточной фильтрацией URL, заголовков и передачей конфиденциальных данных через URL. Это нарушает обработку запросов и дает доступ к сессионным токенам. Отсутствие адекватной обработки ошибок и плохая архитектура междоменной авторизации усиливают риск полного захвата аккаунта. Проблема осложняется слабой изоляцией сессий и надежным контролем безопасности в редиректах и cookie.
При ошибке 414:
атакующий находит XSS на двух связанных сайтах с общей системой авторизации,
через XSS формирует URL с максимально длинным параметром возврата,
при редиректе сессионный токен добавляется к URL, превышая лимит,
сервер возвращает ошибку 414, прерывая цепочку редиректов,
атакующий перехватывает URL с токеном для кражи сессии.
При ошибке 431:
на сервере работает middleware, устанавливающий cookie.
атакующий очищает cookie и создает несколько больших cookie для превышения лимита заголовков,
при следующем запросе сервер возвращает ошибку 431, прерывая цепочку редиректов,
токен сессии появляется в URL.
Не передавать сессионные токены в URL.
Использовать защищенные HttpOnly и Secure куки.
Ограничивать длину URL и заголовков, при превышении лимитов не вызывать ошибки 414/431, а реализовывать безопасные редиректы (например, с кодом 302).
Фильтровать строго разрешенные пути и параметры URL.
Изолировать сессии разных доменов и предотвращать XSS через валидацию и Content Security Policy.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤🔥5🌚3
Cl0p Ransomware эксплуатирует 0-day уязвимость в Oracle E-Business Suite
#Cl0p #ransom #ransomware #suricata #waf #sigma #splunk #blue_team #oracle #C2 #IoC
В мае–июне 2023 года кибергруппа Clop организовала одну из самых резонансных кампаний последних лет: эксплойт уязвимости в популярном ПО для передачи файлов Progress MOVEit привёл к массовой компрометации данных у сотен организаций по всему миру. Это была не локальная утечка — это был сценарий «одна уязвимость → множество жертв»: операторская модель Clop позволила быстро выявлять ценные цели, извлекать гигабайты конфиденциальной информации и ставить перед пострадавшими двоякую дилемму — платить выкуп или рисковать публичной публикацией похищенных данных. Масштаб инцидента, его влияние на цепочки поставок и скорость распространения показали, насколько уязвимы современные централизованные сервисы и как одно скомпрометированной программное решение может стать инструментом «big game hunting». В этой статье мы подробно разберём ход кампании Clop, её последствия для корпоративной безопасности и уроки, которые должны усвоить организации, чтобы снизить риск повторения подобных событий.
CL0P — давняя криминальная группа, работающая в модели ransomware-as-a-service и специализирующаяся на масштабных операциях вымогательства: кража данных, массовые письма руководству и публичное давление через публикацию похищенного. В истории группы — крупные кампании против сервисов для обмена файлами и корпоративных платформ; типичная их тактика сочетает автоматизированное сканирование уязвимых сервисов, тихую эксфильтрацию ценных данных и последующие требования выкупа с угрозой публикации.
С конца августа — начала октября 2025 года исследователи зафиксировали активность против установок Oracle E-Business Suite, а в начале октября появились сообщения о массовых рассылках вымогательных писем руководству и о подтвержденных случаях эксплуатации критической уязвимости CVE-2025-61882. Хронология: первоначальное сканирование и обнаружение уязвимых инсталляций — эксплуатация уязвимости для получения доступа — закрепление присутствия и сбор/эксфильтрация данных — массовая рассылка доказательств похищения и вымогательство.
Модель атаки повторяет устоявшийся паттерн CL0P: автоматизированная разведка интернет-видимых сервисов, эксплуатация уязвимости (unauth RCE или аналогичный вектор) для входа в систему, распространение внутри сети и вытягивание критичных баз и отчётов, затем давление на руководство через публикации и целевые письма (double-extortion). Из-за широкой распространенности затронутого ПО и автоматизации рассылок такой подход позволяет быстро затронуть большое количество организаций и наносит значительные операционные и репутационные потери.
🔗 blog.poxek
🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK | ❤️ Мерч
#Cl0p #ransom #ransomware #suricata #waf #sigma #splunk #blue_team #oracle #C2 #IoC
В мае–июне 2023 года кибергруппа Clop организовала одну из самых резонансных кампаний последних лет: эксплойт уязвимости в популярном ПО для передачи файлов Progress MOVEit привёл к массовой компрометации данных у сотен организаций по всему миру. Это была не локальная утечка — это был сценарий «одна уязвимость → множество жертв»: операторская модель Clop позволила быстро выявлять ценные цели, извлекать гигабайты конфиденциальной информации и ставить перед пострадавшими двоякую дилемму — платить выкуп или рисковать публичной публикацией похищенных данных. Масштаб инцидента, его влияние на цепочки поставок и скорость распространения показали, насколько уязвимы современные централизованные сервисы и как одно скомпрометированной программное решение может стать инструментом «big game hunting». В этой статье мы подробно разберём ход кампании Clop, её последствия для корпоративной безопасности и уроки, которые должны усвоить организации, чтобы снизить риск повторения подобных событий.
CL0P — давняя криминальная группа, работающая в модели ransomware-as-a-service и специализирующаяся на масштабных операциях вымогательства: кража данных, массовые письма руководству и публичное давление через публикацию похищенного. В истории группы — крупные кампании против сервисов для обмена файлами и корпоративных платформ; типичная их тактика сочетает автоматизированное сканирование уязвимых сервисов, тихую эксфильтрацию ценных данных и последующие требования выкупа с угрозой публикации.
С конца августа — начала октября 2025 года исследователи зафиксировали активность против установок Oracle E-Business Suite, а в начале октября появились сообщения о массовых рассылках вымогательных писем руководству и о подтвержденных случаях эксплуатации критической уязвимости CVE-2025-61882. Хронология: первоначальное сканирование и обнаружение уязвимых инсталляций — эксплуатация уязвимости для получения доступа — закрепление присутствия и сбор/эксфильтрация данных — массовая рассылка доказательств похищения и вымогательство.
Модель атаки повторяет устоявшийся паттерн CL0P: автоматизированная разведка интернет-видимых сервисов, эксплуатация уязвимости (unauth RCE или аналогичный вектор) для входа в систему, распространение внутри сети и вытягивание критичных баз и отчётов, затем давление на руководство через публикации и целевые письма (double-extortion). Из-за широкой распространенности затронутого ПО и автоматизации рассылок такой подход позволяет быстро затронуть большое количество организаций и наносит значительные операционные и репутационные потери.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Russian OSINT
cybersecurity-forecast-2026-en.pdf
2 MB
В основе грядущих трансформаций лежит повсеместное внедрение искусственного интеллекта, который станет главным инструментом как для атакующих, так и для защитников. Одновременно с этим, финансово мотивированная киберпреступность и операции государственных субъектов сохранят свой разрушительный потенциал.
Злоумышленники активно осваивают ИИ-сервисы для масштабирования атак, используя большие языковые модели для социальной инженерии и разработки вредоносного ПО. Отчет особо выделяет «инъекцию подсказок» как уже существующую и растущую угрозу, позволяющую манипулировать ИИ-решениями в обход их протоколов безопасности.
Кроме того, аналитики предвидят «смену парадигмы ИИ-агентов», что потребует от организаций создания совершенно новых систем управления цифровыми идентичностями для автономных ИИ-агентов.
По мнению вице-президента Google Threat Intelligence Сандры Джойс: «Мы ожидаем увидеть больше программ-вымогателей и вымогательства. Эта проблема продолжится и усугубится в 2026 году».
1️⃣ Масштабный переход к использованию ИИ-технологий: к 2026 году использование ИИ злоумышленниками станет нормой. Повысится скорость, масштаб и эффективность таких атак.
2️⃣ Рост атак с использованием «prompt injection»: атаки на корпоративные ИИ-системы перейдут от концептуальных эксплойтов к крупномасштабным кампаниям по хищению данных.
3️⃣ Гиперреалистичный вишинг: ИИ-агенты, способные клонировать голос, будут активно использоваться для создания поддельных образов руководителей и ИТ-персонала в целях социальной инженерии.
4️⃣ Риск «теневых агентов»: неконтролируемое использование сотрудниками мощных ИИ-агентов станет критической проблемой, ведущей к утечкам данных, нарушениям комплаенса и краже интеллектуальной собственности.
5️⃣ Доминирование локеров (ransomware): связка использования программ-вымогателей и хищения данных останется
6️⃣ Атаки на виртуализацию: злоумышленники сместят фокус на базовую инфраструктуру виртуализации (гипервизоры), обходя традиционные средства защиты на уровне гостевых систем.
7️⃣ Ончейн-экономика киберпреступности: преступные операции начнут мигрировать на публичные блокчейны для обеспечения устойчивости к попыткам их пресечения.
8️⃣ Эволюция киберопераций России: по мнению Google, прогнозируется смена фокуса от краткосрочных тактических целей к
9️⃣ Приоритеты 🇨🇳Китая: кибероперации будут сосредоточены на шпионаже в секторе полупроводников из-за глобальной конкуренции и экспортных ограничений.
🔟 Финансовые цели 🇰🇵Северной Кореи: Государственные хакеры активизируют атаки на криптовалютные организации, опираясь на прошлые успехи, включая крупнейшую зафиксированную кражу криптовалюты на сумму около $1.5 миллиарда.
ИИ-агенты будут рассматриваться как отдельные
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10❤🔥4🔥3🤯2
Помните gpt-4o и её "дружелюбность"? Теперь это будет gpt-5.1
Спасибо за внимание ᕕ( ᐛ )ᕗ
Спасибо за внимание ᕕ( ᐛ )ᕗ
Forwarded from PURP (Pr0xProw)
Не то чтобы там было что-то критически важное. Но новость то какая!
Несколько дней назад зарубежные издания писали, что Apple развернула обновленный веб-интерфейс AppStore на базе Svelte framework и TypeScript. Как вскоре выяснилось, при деплое в прод компания оставила активными sourcemap-файлы. Это файлы сопоставления между минифицированным кодом и оригинальными исходниками.
Эти sourcemaps (.map) содержат JSON-структуру, позволяющую восстановить исходный код из обфусцированной продакшен-сборки. В штатном режиме они генерируются на этапе build для упрощения отладки. Но из прода должны выпиливаться через соответствующие флаги сборщика (webpack/vite/rollup).
В случае с Apple sourcemaps остались доступны по прямым URL и автоматически загружались браузерными DevTools при открытии вкладки Sources. Это позволило извлечь полную кодовую базу фронтенда:
Извлеченный код был опубликован на GitHub, но быстро удален по требованию DMCA. Так что я нашел вам копию этого репозитория на Codeberg от исследователя JoanVC, первым обнаружившего утечку.
#red_team #Apple
Please open Telegram to view this post
VIEW IN TELEGRAM
Новые CVE в runc позволяют обойти изоляцию контейнера и получить root на хост-системе
#CVE #racecondition #runc #Docker #Kubernetes #root
runc (базовый инструмент запуска контейнеров в Docker и Kubernetes) содержит три критические уязвимости типа race condition. При успешной эксплуатации они позволяют обойти проверки монтирования и записи в системные интерфейсы procfs и sysfs, что открывает возможность выполнения кода с правами root на хосте.
1. CVE-2025-31133 — некорректнаяя обработка maskedPaths позволяет перенаправлять монтируемые пути, обеспечивая доступ к критичным ресурсам хоста и запись в procfs из контейнера. Есть PoC.
2. CVE-2025-52565 и CVE-2025-52881 — гонки при монтировании
➡️ Как проходит атака
1. Атакующий запускает контейнер на уязвимой версии runc с контролем параметров монтирования.
2. Внутри контейнера инициируется серия операций монтирования, специально спроектированных как TOCTOU гонка.
3. В окне гонки злоумышленник подменяет монтируемый источник или вызывает последовательность операций, в результате чего проверки пропускают некорректное примонтирование на
4. После успешной подмены атакующий записывает значения в файлы вроде
🪲 Пример PoC на bash лежит в комментариях.
➡️ Как защититься
1. Срочно обновить runc до версии 1.2.8, 1.3.3, 1.4.0-rc.3 или выше.
2. Включить user namespaces для контейнеров (ограничивает права на запись в procfs).
3. Использовать rootless контейнеры, чтобы минимизировать возможности атак.
4. Ограничить права запуска контейнеров и тщательно аудитировать параметры монтирования.
5. Следить за обновлениями платформ Docker, Kubernetes и runc, применять рекомендованные патчи и конфигурации безопасности.
🔗 Источник
🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK | ❤️ Мерч
#CVE #racecondition #runc #Docker #Kubernetes #root
runc (базовый инструмент запуска контейнеров в Docker и Kubernetes) содержит три критические уязвимости типа race condition. При успешной эксплуатации они позволяют обойти проверки монтирования и записи в системные интерфейсы procfs и sysfs, что открывает возможность выполнения кода с правами root на хосте.
1. CVE-2025-31133 — некорректнаяя обработка maskedPaths позволяет перенаправлять монтируемые пути, обеспечивая доступ к критичным ресурсам хоста и запись в procfs из контейнера. Есть PoC.
2. CVE-2025-52565 и CVE-2025-52881 — гонки при монтировании
/dev/console или /dev/null позволяют обходить механизмы LSM и монтировать защищенные файлы /proc для последующей модификации. Публичных PoC для этих CVE не найдено.1. Атакующий запускает контейнер на уязвимой версии runc с контролем параметров монтирования.
2. Внутри контейнера инициируется серия операций монтирования, специально спроектированных как TOCTOU гонка.
3. В окне гонки злоумышленник подменяет монтируемый источник или вызывает последовательность операций, в результате чего проверки пропускают некорректное примонтирование на
/proc или /sys.4. После успешной подмены атакующий записывает значения в файлы вроде
/proc/sys/kernel/core_pattern или вызывает sysctl-подобные интерфейсы, что приводит к выполнению кода/эскалации на хосте.1. Срочно обновить runc до версии 1.2.8, 1.3.3, 1.4.0-rc.3 или выше.
2. Включить user namespaces для контейнеров (ограничивает права на запись в procfs).
3. Использовать rootless контейнеры, чтобы минимизировать возможности атак.
4. Ограничить права запуска контейнеров и тщательно аудитировать параметры монтирования.
5. Следить за обновлениями платформ Docker, Kubernetes и runc, применять рекомендованные патчи и конфигурации безопасности.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13