- Регистрация
- 23 Авг 2023
- Сообщения
- 3,969
- Реакции
- 0
- Баллы
- 36
Ofline
Это не PoC, не разбор RFC и не 0day. Это разбор UX-driven атаки на модель доверия OAuth, которая формально не нарушает протокол - и именно поэтому работает.
Коротко о сути (если не хочется читать всю статью)
ConsentFix - атака, при которой пользователь сам отдаёт злоумышленнику код авторизации OAuth. Без вирусов, подмены страниц входа, кражи паролей.
ConsentFix неприятен именно тем, что формально всё работает как задумано. OAuth не нарушен. MFA не сломан. Microsoft ничего не упустил. И всё равно аккаунт утекает. Именно это и делает атаку интересной.
Почему эта атака вообще интересна
Большинство OAuth-атак - это: фишинг логина, AiTM, подмена consent screen, эксплуатация багов реализации.
ConsentFix выбивается из этого ряда. Это атака не на реализацию OAuth, а на его предположения о поведении пользователя.
OAuth implicitly предполагает, что код авторизации не покидает границы клиентского приложения, пользователь не будет вручную оперировать redirect URL.
ConsentFix проверяет, насколько эти предположения соответствуют реальности.
Что в ConsentFix реально нового
По сути, ConsentFix - это ClickFix, но вместо "нажмите Win+R" вам говорят "скопируйте URL из адресной строки". И это внезапно работает.
Где именно OAuth дает трещину
В OAuth Authorization Code Flow предполагается, что код авторизации никогда не покидает границы клиентского приложения.
Для веба это обычно: редирект на backend, обмен кода с token сервером.
Для десктом/CLI всё иначе. Там часто используется редирект на localhost. Примерно так:
http://localhost:1605/?code=...
И тут начинается самое интересное. OAuth не запрещает увидеть этот URL в браузере, скопировать его, вставить куда угодно.
OAuth просто предполагает, что пользовать этого не сделает. ConsentFix как раз проверяет, насколько это предположение надежно.
Критический момент атаки
Ключевая точка компрометации выглядит так - код авторизации становится bearer token в момент, когда пользователь вручную копирует redirect URL.
С этого момента: код можно обменять где угодно, кем угодной, без повторной MFA, без интерактивного логина.
OAuth считает, что аутентификация уже завершена.
Как выглядит атака без страшилок
Редирект на localhost после авторизации. Автор
Обмен токенов. Автор
Пара токенов после обмена. Автор
Почему MFA и PKCE здесь не помогают
MFA
MFA защищает момент аутентификации, а не жизненный цикл кода авторизации или последующий обмен токена.
MFA отработала корректно. OAuth считает пользователя аутентифицированным.
PKCE
PKCE защищает клиента от перехвата кода третьей стороной. Но не защищает пользователя от добровольной передачи кода.
Если атакующий получает код авторизации, то PKCE не дает дополнительной защиты.
First-party приложения
ConsentFix почти всегда использует: Azure CLI, PowerShell, VS Code.
Причины простые: доверие пользователей, разрешены по умолчанию, редко мониторятся и CLI-логин психологически воспринимается как безопасный.
Почему это не просто user error
Часто в таких атаках хочется сказать, что пользователь сам виноват. Формально - да, пользователь вручную скопировал URL. Но с точки зрения модели безопасности это не ошибка пользователя, а несоответствие между ожиданиями протокола и реальным UX.
OAuth допускает user-mediated шаги и implicitly предполагает, что пользователь не будет оперировать кодами авторизации вручную. Современные UX-паттерны - security checks, CAPTCHA-подобные экраны, логин через доверенные first-party приложения - системно размывают эту границу. Пользователя не учат отличать безопасное копирование ссылки от опасного, и протокол не дает ему сигнала, что в этот момент он передает bearer token.
Если безопасность системы зависит от того, что пользователь не скопирует строку из адресной строки браузера - это уже не user error, а предположение уровня проектирования, которое перестало быть надежным.
Что именно получает атакующий
Никакой "сессии" тут нет. Атакующий получается обычный код авторизации и делает обычный подмен токена.
Упрощенный пример:
POST /oauth2/v2.0/token
grant_type=authorization_code
code=...
client_id=...
redirect_url=http://localhost:1605/
Ответ: acces_token, refresh_token, id_token
Как это выглядит в логах
ConsentFix не бесследен. Типичный паттерн в логах: есть интерактивный логин, через пару минут - не интерактивный, тот же SessionId, тот же AppId, другой IP/страна.
Минимальный пример KQL
SignInLogs
| join AADNonInteractiveUserSignInLogs on SessionId, UserPrincipalName, AppId
| where IPAddress != IPAddress1
| where abs(datetime_diff("minute", TimeGenerated, TimeGenerated1)) < 10
Почему подобных атак станет больше
ConsentFix - не хитрый трюк. Это симптом: browser-first security, identify-first архитектур, UX-driven атак.
Чем больше мы упрощаем логин, тем больше атак смещается после логина. И OAuth здесь просто удобная точка опоры.
В сухом остатке. OAuth не сломан. MFA не бесполезна. Но модель логин = безопасность больше не работает. ConsentFix - не конец истории, а начало очень неприятного класса атак.
Иногда делаю заметки в Telegram - в более свободном формате.
Коротко о сути (если не хочется читать всю статью)
ConsentFix - атака, при которой пользователь сам отдаёт злоумышленнику код авторизации OAuth. Без вирусов, подмены страниц входа, кражи паролей.
ConsentFix неприятен именно тем, что формально всё работает как задумано. OAuth не нарушен. MFA не сломан. Microsoft ничего не упустил. И всё равно аккаунт утекает. Именно это и делает атаку интересной.
Почему эта атака вообще интересна
Большинство OAuth-атак - это: фишинг логина, AiTM, подмена consent screen, эксплуатация багов реализации.
ConsentFix выбивается из этого ряда. Это атака не на реализацию OAuth, а на его предположения о поведении пользователя.
OAuth implicitly предполагает, что код авторизации не покидает границы клиентского приложения, пользователь не будет вручную оперировать redirect URL.
ConsentFix проверяет, насколько эти предположения соответствуют реальности.
Что в ConsentFix реально нового
Это не | Это |
AiTM | UX-атака |
Фишинг с использованием кодов устройств(device code phishing) | Browser-native атака |
Классический OAuth фишинг | Атака на границу доверия, а не на код |
Новый 0day |
По сути, ConsentFix - это ClickFix, но вместо "нажмите Win+R" вам говорят "скопируйте URL из адресной строки". И это внезапно работает.
Где именно OAuth дает трещину
В OAuth Authorization Code Flow предполагается, что код авторизации никогда не покидает границы клиентского приложения.
Для веба это обычно: редирект на backend, обмен кода с token сервером.
Для десктом/CLI всё иначе. Там часто используется редирект на localhost. Примерно так:
http://localhost:1605/?code=...
И тут начинается самое интересное. OAuth не запрещает увидеть этот URL в браузере, скопировать его, вставить куда угодно.
OAuth просто предполагает, что пользовать этого не сделает. ConsentFix как раз проверяет, насколько это предположение надежно.
Критический момент атаки
Ключевая точка компрометации выглядит так - код авторизации становится bearer token в момент, когда пользователь вручную копирует redirect URL.
С этого момента: код можно обменять где угодно, кем угодной, без повторной MFA, без интерактивного логина.
OAuth считает, что аутентификация уже завершена.
Как выглядит атака без страшилок
Ты заходишь на сайт (часто через поиск).
Видишь что-то вроде Cloudflare-проверки.
Вводишь рабочий email.
Тебя просят войти, чтобы продолжить.
Открывается настоящий вход в Microsoft.
Ты логинишься, подтверждаешь MFA.
Б��аузер редиректит на localhost.
Сайт говорит: Вставь URL, чтобы закончить проверку.
Редирект на localhost после авторизации. Автор
Обмен токенов. Автор
Пара токенов после обмена. Автор
Почему MFA и PKCE здесь не помогают
MFA
MFA защищает момент аутентификации, а не жизненный цикл кода авторизации или последующий обмен токена.
MFA отработала корректно. OAuth считает пользователя аутентифицированным.
PKCE
PKCE защищает клиента от перехвата кода третьей стороной. Но не защищает пользователя от добровольной передачи кода.
Если атакующий получает код авторизации, то PKCE не дает дополнительной защиты.
First-party приложения
ConsentFix почти всегда использует: Azure CLI, PowerShell, VS Code.
Причины простые: доверие пользователей, разрешены по умолчанию, редко мониторятся и CLI-логин психологически воспринимается как безопасный.
Почему это не просто user error
Часто в таких атаках хочется сказать, что пользователь сам виноват. Формально - да, пользователь вручную скопировал URL. Но с точки зрения модели безопасности это не ошибка пользователя, а несоответствие между ожиданиями протокола и реальным UX.
OAuth допускает user-mediated шаги и implicitly предполагает, что пользователь не будет оперировать кодами авторизации вручную. Современные UX-паттерны - security checks, CAPTCHA-подобные экраны, логин через доверенные first-party приложения - системно размывают эту границу. Пользователя не учат отличать безопасное копирование ссылки от опасного, и протокол не дает ему сигнала, что в этот момент он передает bearer token.
Если безопасность системы зависит от того, что пользователь не скопирует строку из адресной строки браузера - это уже не user error, а предположение уровня проектирования, которое перестало быть надежным.
Что именно получает атакующий
Никакой "сессии" тут нет. Атакующий получается обычный код авторизации и делает обычный подмен токена.
Упрощенный пример:
POST /oauth2/v2.0/token
grant_type=authorization_code
code=...
client_id=...
redirect_url=http://localhost:1605/
Ответ: acces_token, refresh_token, id_token
Как это выглядит в логах
ConsentFix не бесследен. Типичный паттерн в логах: есть интерактивный логин, через пару минут - не интерактивный, тот же SessionId, тот же AppId, другой IP/страна.
Минимальный пример KQL
SignInLogs
| join AADNonInteractiveUserSignInLogs on SessionId, UserPrincipalName, AppId
| where IPAddress != IPAddress1
| where abs(datetime_diff("minute", TimeGenerated, TimeGenerated1)) < 10
Почему подобных атак станет больше
ConsentFix - не хитрый трюк. Это симптом: browser-first security, identify-first архитектур, UX-driven атак.
Чем больше мы упрощаем логин, тем больше атак смещается после логина. И OAuth здесь просто удобная точка опоры.
В сухом остатке. OAuth не сломан. MFA не бесполезна. Но модель логин = безопасность больше не работает. ConsentFix - не конец истории, а начало очень неприятного класса атак.
Иногда делаю заметки в Telegram - в более свободном формате.