Forwarded from purple shift
Недавно наши пентестеры разбирались с утилитой PEAS для работы с Exchange ActiveSync (EAS) — и наткнулись на интересную проблему. При попытке получить листинг файловых шар через Document Library Access утилита падала с ошибкой 141 (LegacyDeviceOnStrictPolicy). При этом проверка учётных данных через
Оказалось, что раньше PEAS работал без ошибки, потому что серверы не требовали обязательного прохождения процедуры Provisioning. А когда администраторы начали включать строгие политики безопасности на Exchange, серверы стали требовать прохождения этой процедуры.
Provisioning в EAS — это механизм согласования политик безопасности между устройством и сервером через стандартный двухшаговый обмен, где клиент принимает политики безопасности сервера, а сервер в ответ разрешает дальнейшие операции. По итогу сервер выдает PolicyKey — токен доверия для конкретного аккаунта/устройства/сервера. Этот токен меняется при первом подключении нового устройства или когда админы обновляют политики; токен также может меняться от бездействия (длительного отсутствия входа в почту).
То есть без валидного PolicyKey сервер просто отклоняет запросы к данным. Интересный момент: сервер не может реально проверить, применило ли устройство политики — он полностью доверяет клиенту. Достаточно просто пройти протокольный обмен и сказать "да, я всё применил".
Раньше, когда серверы не требовали прохождения Provisioning, утилита PEAS просто отправляла PolicyKey=0. Но теперь это может не работать, поскольку сервер теперь может потребовать валидный токен.
Для решения этой проблемы наши эксперты пропатчили PEAS, добавив автоматический Provisioning перед UNC-операциями. Теперь утилита сначала выполняет двухфазный обмен с сервером, получает валидный PolicyKey и только потом делает запросы к файловым шарам. Дополнительно добавили флаг
Если хочется поглубже понять механизм EAS и исторический контекст утилит, можно посмотреть подробную статью от создателей PEAS, опубликованную ещё в 2016-м. Похоже, что тема всплывает раз в пять лет, и мы как раз подвезли актуализацию.
Что делать защитникам:
Необходимо следить за Microsoft Exchange как за критичным узлом, который зачастую становится "открытой дверью" к почте, файлам и внутренним ресурсам. Поэтому:
— По возможности вырубайте легаси-функциональность (EAS Document Library/UNC и прочие пережитки), сокращайте исключения и совместимость со всем подряд.
— Если отключить нельзя, используйте поведенческий контроль клиентов EAS: проверяйте, что перед доступом к данным всегда есть нормальный двухфазный Provisioning, следите за всплесками Status=141/142 и HTTP 449, смотрите динамику PolicyKey (внезапные смены/реюз между устройствами — знак тревоги).
— Параллельно ужесточайте базовую гигиену: регулярно пересматривайте политики, чистите старые профили и временные исключения, валидируйте сторонние клиенты до продакшена.
— Ограничивайте срок жизни кэшированных PolicyKey и фиксируйте их привязку к аккаунту/серверу/устройству. Тащите всё это в SIEM с привязкой "аккаунт >> устройство >> PolicyKey >> операции". Потому что в Exchange может быть всякое: смешанные политики, странные клиенты, исторические хвосты конфигураций — и это регулярно выстреливает.
Главная мысль: EAS по дизайну доверяет заявлению клиента о принятии политик. Это нормально для протокола, но с точки зрения защиты нельзя опираться только на EAS. Добавляйте поведенческий мониторинг, внешнюю проверку комплаенса (MDM/Intune) и минимизируйте поверхность атаки за счёт отключения ненужного наследия.
--check работала нормально. Оказалось, что раньше PEAS работал без ошибки, потому что серверы не требовали обязательного прохождения процедуры Provisioning. А когда администраторы начали включать строгие политики безопасности на Exchange, серверы стали требовать прохождения этой процедуры.
Provisioning в EAS — это механизм согласования политик безопасности между устройством и сервером через стандартный двухшаговый обмен, где клиент принимает политики безопасности сервера, а сервер в ответ разрешает дальнейшие операции. По итогу сервер выдает PolicyKey — токен доверия для конкретного аккаунта/устройства/сервера. Этот токен меняется при первом подключении нового устройства или когда админы обновляют политики; токен также может меняться от бездействия (длительного отсутствия входа в почту).
То есть без валидного PolicyKey сервер просто отклоняет запросы к данным. Интересный момент: сервер не может реально проверить, применило ли устройство политики — он полностью доверяет клиенту. Достаточно просто пройти протокольный обмен и сказать "да, я всё применил".
Раньше, когда серверы не требовали прохождения Provisioning, утилита PEAS просто отправляла PolicyKey=0. Но теперь это может не работать, поскольку сервер теперь может потребовать валидный токен.
Для решения этой проблемы наши эксперты пропатчили PEAS, добавив автоматический Provisioning перед UNC-операциями. Теперь утилита сначала выполняет двухфазный обмен с сервером, получает валидный PolicyKey и только потом делает запросы к файловым шарам. Дополнительно добавили флаг
--policy-key для переиспользования ключа при массовых операциях, это убирает лишние запросы и уменьшает шум в логах.Если хочется поглубже понять механизм EAS и исторический контекст утилит, можно посмотреть подробную статью от создателей PEAS, опубликованную ещё в 2016-м. Похоже, что тема всплывает раз в пять лет, и мы как раз подвезли актуализацию.
Что делать защитникам:
Необходимо следить за Microsoft Exchange как за критичным узлом, который зачастую становится "открытой дверью" к почте, файлам и внутренним ресурсам. Поэтому:
— По возможности вырубайте легаси-функциональность (EAS Document Library/UNC и прочие пережитки), сокращайте исключения и совместимость со всем подряд.
— Если отключить нельзя, используйте поведенческий контроль клиентов EAS: проверяйте, что перед доступом к данным всегда есть нормальный двухфазный Provisioning, следите за всплесками Status=141/142 и HTTP 449, смотрите динамику PolicyKey (внезапные смены/реюз между устройствами — знак тревоги).
— Параллельно ужесточайте базовую гигиену: регулярно пересматривайте политики, чистите старые профили и временные исключения, валидируйте сторонние клиенты до продакшена.
— Ограничивайте срок жизни кэшированных PolicyKey и фиксируйте их привязку к аккаунту/серверу/устройству. Тащите всё это в SIEM с привязкой "аккаунт >> устройство >> PolicyKey >> операции". Потому что в Exchange может быть всякое: смешанные политики, странные клиенты, исторические хвосты конфигураций — и это регулярно выстреливает.
Главная мысль: EAS по дизайну доверяет заявлению клиента о принятии политик. Это нормально для протокола, но с точки зрения защиты нельзя опираться только на EAS. Добавляйте поведенческий мониторинг, внешнюю проверку комплаенса (MDM/Intune) и минимизируйте поверхность атаки за счёт отключения ненужного наследия.
Forwarded from s0ld13r ch. (s0ld13r)
"Это не баг, а фича" или же backdoor by design pt. 1 😃
Когда мы ищем векторы RCE в инфре, мы привыкли охотиться за сложными CVE. Но иногда дверь оставлена открытой специально - по архитектурным соображениям. Сегодня поговорим про Java Debug Wire Protocol (JDWP)👩💻
🔍 Что это такое?
Это протокол для отладки Java-приложений в реальном времени. Он позволяет смотреть состояние потоков, память и execution flow, не перезагружая приложение. Чтобы его включить, разработчику достаточно добавить одну строку:
🤭 В чем подвох?
Протокол не предусматривает никакой авторизации. Если порт 5005 торчит наружу или доступен во внутренней сети - это легитимный RCE «из коробки».
🤬 Проблема старых инструментов:
Популярный jdwp-shellifier написан на Python 2 и использует только Runtime.exec(). Главный минус - вы не видите вывод команды в консоли (blind execution). Если сеть ограничена и вы не можете кинуть reverse shell или сделать curl на свой сервер, эксфильтрация данных превращается в квест.
Я переписал и проапгрейдил этот инструмент, сделав его современным и более «зубастым» назвав его JDWP Knife.
Ключевые фичи:
• Python 3.6+👩💻
• Интерактивность: Вывод👩💻
• Удобство: Минимум лишних движений при разведке 🕵️♂️
✍️ Примеры использования:
Будьте аккуратны с debug портами в проде, иногда удобство в разработке может привести к компрометации всей инфраструктуры😉
💻 jdwp-knife: https://github.com/s0ld13rr/jdwp-knife
🧢 s0ld13r
Когда мы ищем векторы RCE в инфре, мы привыкли охотиться за сложными CVE. Но иногда дверь оставлена открытой специально - по архитектурным соображениям. Сегодня поговорим про Java Debug Wire Protocol (JDWP)
Это протокол для отладки Java-приложений в реальном времени. Он позволяет смотреть состояние потоков, память и execution flow, не перезагружая приложение. Чтобы его включить, разработчику достаточно добавить одну строку:
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005
Протокол не предусматривает никакой авторизации. Если порт 5005 торчит наружу или доступен во внутренней сети - это легитимный RCE «из коробки».
Популярный jdwp-shellifier написан на Python 2 и использует только Runtime.exec(). Главный минус - вы не видите вывод команды в консоли (blind execution). Если сеть ограничена и вы не можете кинуть reverse shell или сделать curl на свой сервер, эксфильтрация данных превращается в квест.
Я переписал и проапгрейдил этот инструмент, сделав его современным и более «зубастым» назвав его JDWP Knife.
Ключевые фичи:
• Python 3.6+
• Интерактивность: Вывод
env, ls и cat прямо в консоль • Удобство: Минимум лишних движений при разведке 🕵️♂️
# 1. Discover JDWP
echo "JDWP-Handshake" | nc -w3 TARGET 5005
# 2. Identify service
python3 jdwp-knife.py -t TARGET -p 5005 --props
# 3. Extract credentials
python3 jdwp-knife.py -t TARGET -p 5005 --env | grep -iE 'pass|secret|key|token|jdbc|aws'
# 4. Read interesting files
python3 jdwp-knife.py -t TARGET -p 5005 --cat /etc/passwd
Будьте аккуратны с debug портами в проде, иногда удобство в разработке может привести к компрометации всей инфраструктуры
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM