Fsecurity | HH
Open in Telegram
👾 Канал про КБ и пентест Наш Discord: https://discord.gg/Eg8aDS7Hn7 ✉️ По сотрудничеству: @OxHaskar 🍩 Поддержать: https://www.donationalerts.com/r/xackapb
Show more2 073
Subscribers
-124 hours
+57 days
+1230 days
Posts Archive
2 073
Repost from purple shift
Уязвимость React2Shell (CVE-2025-55182) была раскрыта в начале декабря и наделала немало шума — поскольку затрагивает серверные компоненты React (RSC), которые используются во многих веб-приложениях.
Уязвимость оценивается как максимально опасная (CVSS 10.0) и уже активно эксплуатируется в дикой природе злоумышленниками, в том числе APT-группами.
React2Shell позволяет атакующему незамысловатым http-запросом получить удаленное выполнение кода на уязвимых серверах без всякой аутентификации. Минимально жизнеспособный эксплойт:
{
0: {
status: "resolved_model",
reason: -1,
_response: {
_prefix: "console.log('RCE')//",
_formData: { get: "$1:then:constructor" },
},
then: "$1:then",
value: '{"then":"$B"}',
},
1: "$@0",
}
Эта уязвимость особенно критична из-за практически полного отсутствия артефактов. React не фиксирует происходящее, а у большинства из доступного будет лишь набор HTTP-логов, собираемых прокси.
Теоретически можно попытаться анализировать память процесса в поисках характерных сигнатур, но соотношение TP/FP будет крайне низким. В реальности в основном будем видеть нерелевантный трафик от сканеров и автоматических ботов, вместо того чтобы получать чёткие индикаторы эксплуатации уязвимости.
Сейчас атакующие активно перебирают весь спектр механизмов запуска процессов в Node.js:
- exec() - spawn() - execSync() - spawnSync()Отсутствие единых стандартов журналирования в современных фронтенд-фреймворках создаёт дополнительные трудности для расследований. В результате успешная эксплуатация может оставаться незамеченной до тех пор, пока не проявятся косвенные признаки: аномальное поведение Node.js-процессов или подозрительные сетевые соединения. На практике после успешной эксплуатации мы фиксируем один из вариантов (см. скриншот в начале поста): — однострочная последовательность команд, — закодированный в Base64 reverse shell, — есть вариант in memory shell, встречали и его. В основном фиксируем вариации команд для установок различных майнеров и приложений удаленного управления (RMM). Что делать? С точки зрения защиты: — Пропатчить все уязвимые React / Next.js приложения до безопасных версий (19.0.1, 19.1.2, 19.2.1 и выше; Next.js с обновлённым RSC). — Включить правила по обнаружению и предотвращению эксплуатации модифицированных RSC HTTP-запросов на периметре (WAF/IDS). С точки зрения мониторинга: — Отслеживать аномальные процессы от node. — Отслеживать сработки WAF/IDS-решений на попытки эксплуатации этой уязвимости. — Ретроспективно проверить активность на хостах с node.
2 073
Repost from RedTeam brazzers
"Как новый год встретишь, так его и проведешь!"
Все началось на новогодние праздники... В начале 2025 года (да, пост немного задержался))) ...
Ко мне в гости приехал мой хороший друг и программист @octet8 (спасибо тебе!). И в один прекрасный день я показал ему свой ldap_shell, рассказал про боль и главную проблему инструмента: инструмент изначально создавался как автономная версия модуля ntlmrelayx, и все написанные командлеты были методами класса LdapShell. Было очень легко просто скопировать готовый метод и перенести его в ntlmrelayx и получить больше опций при проведении ntlm relay атаки...
Но это несло и целую кучу проблем: контрибьютерам было сложно и непонятно, куда дописывать свои атаки, код разрастался... и один класс занимал уже тысячи строк кода, каждый раз при добавлении нового функционала приходилось вручную менять вывод команды help. В какой-то момент это все вышло из-под контроля, и так продолжаться дальше не могло. Поэтому мой друг помог мне переписать ядро инструмента и построить по-настоящему модульную архитектуру. В таком виде инструмент увидел свет в апреле этого года!
В конце 2025 года я не знаю людей, которые не используют в своей работе ИИ - новая архитектура как нельзя лучше подошла для интеграции с ИИ при разработке своих модулей.
Все модули аккуратно лежат в папке ldap_modules, каждый модуль имеет общий шаблон, в котором описываются основные составляющие модуля (такие как справка, пример использования модуля, класс ModuleArgs, использующий pydantic для описания и валидации аргументов модуля и его типов, а также метод
__call__, содержащий основную логику модуля и т.п.).
Если у вас возникает проблема с написанием модуля - вы можете посмотреть, как описаны подобные модули.
А теперь давайте поговорим про ИИ и его роль. ИИ очень любит понятный и небольшой контекст, а также любит делать небольшие файлики с кодом. Например, вам захотелось сделать модуль, который меняет конкретные биты в UAC - сделать это можно достаточно удобно из PowerShell, но если под рукой только Linux, то данная задача уже не выглядит так просто. Но на самом деле все проще, чем может показаться). В Cursor у меня уже был загружен проект ldap_shell, я открыл новый чат, перетащил ему в контекст папку и описал, что мне надо редактировать побитово атрибут userAccountControl, и о чудо! С первого раза и без единой ошибки был сгенерирован модуль uac_modify, который сразу работал и делал то, что я хочу. Данный модуль я решил оставить в неизменном виде именно так, как мне его сгенерил ИИ с первого раза :)
Теперь вы видите, как это стало легко и понятно, теперь вы можете очень удобно перенести свои костыли в аккуратный интерфейс ldap_shell или автоматизировать то, что выглядело ранее сложно и требовало пляски с бубном вокруг LDAP. Создавайте свои модули, делитесь ими и становитесь контрибьютерами!!! Лучшие модули я буду добавлять в инструмент.