В августе 2019 года я обнаружил уязвимость в Apples iOS (CVE-2020-3841) во время Red Team Assessment. Мы пытались заманить пользователей для ввода их учетных данных в фишинг-атаке по Wi-Fi. В этом случае iOS / Safari (также затронул macOS) помог нам с функциями автозаполнения. Они оказались багнутыми, но давайте посмотрим, как и почему это работает, и как мы это использовали.
Captive Portal
Captive Portal часто используется, например, для того, чтобы вы приняли условия открытой точки доступа Wi-Fi. Обычно он появляется, как только вы подключаетесь к беспроводной сети. Но это только то, как он развивался - до того, как он появлялся,портал был показан только на первом посещенном вами сайте (или вы были перенаправлены на IP-адрес портала).
Это работает через перенаправление DNS, перенаправление HTTP / перехват уровня 3 (ICMP). В любом случае - как только вы зашли на сайт, вы были перенаправлены на сайт портала / ip. Это изменилось, так как в случае широко распространенного TLS, в случае сайта, защищенного TLS, браузер просто (надеюсь) прервет запрос и покажет предупреждение, поскольку рукопожатие не будет выполнено
Вот почему Microsoft, Google (Android / Chrome), Apple, Mozilla & Co. нашли способ определить, нужно ли вам «входить» через веб-интерфейс в эту сеть. Например, в случае с Apple устройства iOS отправляют GET HTTP-запрос на http://captive.apple.com,чтобы проверить, получает ли он текст «Success».
"captive.apple.com" возвращает "Success"
В случае Firefox этот URI - detectportal.firefox.com:
В обоих случаях браузер знает, что captive portal отсутствует. Если возвращается что-то другое, браузер / ОС знает, что ему нужно посетить этот сайт, потому что трафик явно перехвачен.
Проблема
Но вот первая проблема: эти URI всегда должны быть доступны через HTTP (незащищенные) или, по крайней мере, они быть доступными. Можно трактовать это по-другому, но на данный момент это так. И здесь возникает следующая проблема: все основные поставщики используют по крайней мере в некоторых случаях свой основной домен:
Google: clients3.google.com
Apple: captive.apple.com
Microsoft: teredo.ipv6.microsoft.com
Firefox: detectportal.firefox.com
Почему это проблема?
На данный момент я хочу порекомендовать запись в блоге от Троя Ханта:
Атака
Мы также заметили в Red Team, что, хотя Apple & Co обычно пытается открыть IP, вы можете перенаправить оттуда на «captive.apple.com». Вместо «Success» мы поставляем наш фишинговый портал на этот домен, так как он не защищен HSTS.
Путаница
И здесь у нас был еще один сюрприз: путаница доменов со стороны Apple. Хотя у меня есть учетные данные «apple.com», некоторые (большинство?) пользователей не имеют учетных данных apple.com, а имеют учетные данные icloud.com. Но угадайте что? Apple сделала путаницу, и даже если у вас нет сохраненных учетных данных «apple.com», Safari предлагает учетные данные с «icloud.com»!
Наш первый captive portal - не оптимизирован под фишинг
Safari, похоже, в этом случае пытается использовать учетные данные, хранящиеся для «com.apple ....», что является классическим соглашением о пространстве имен.
Учетные данные iCloud! Теперь нам нужно было оптимизировать это - от классического фишинга с логином до чего-то более похожего на Apple. Поэтому мы разработали новую страницу входа с кнопкой «Войти через Apple» - и некоторые скрытые поля:
Фишинговый портал - не видно скрытых полей
Мы поместили в него два скрытых поля - не сфокусированные. Как только пользователь нажимает кнопку «Войти через Apple», поле «Имя пользователя» становится сфокусированным - для более удобной работы ;-).
Как только пользовательское поле получает фокус, присоединяется SafariAutoFill и предлагает ваши учетные данные iCloud.com - насколько это круто?
Следующий трюк довольно прост: после того, как вы нажмете кнопку (которая на самом деле является Div), отобразится «Вход в систему ...». Если пользователь теперь выбирает свои учетные данные на серой панели автозаполнения, сайт автоматически передает заполненные учетные данные
Плюсы в этой атаке с точки зрения злоумышленников:
Минусы:
В Red Team вы должны (!) поставить client-side фильтр на домене, чтобы не нацеливаться на людей за пределами вашего scope!
Тем не менее, Apple присвоила статус "low risk" этой уязвимости
Но они это исправили. Safari больше не предлагает учетные данные в всплывающем captive-login frame . Итак, каковы основные причины?
Я все еще исследую другие браузеры и операционные системы на случай обнаружения подобных проблем
Captive Portal
Captive Portal часто используется, например, для того, чтобы вы приняли условия открытой точки доступа Wi-Fi. Обычно он появляется, как только вы подключаетесь к беспроводной сети. Но это только то, как он развивался - до того, как он появлялся,портал был показан только на первом посещенном вами сайте (или вы были перенаправлены на IP-адрес портала).
Это работает через перенаправление DNS, перенаправление HTTP / перехват уровня 3 (ICMP). В любом случае - как только вы зашли на сайт, вы были перенаправлены на сайт портала / ip. Это изменилось, так как в случае широко распространенного TLS, в случае сайта, защищенного TLS, браузер просто (надеюсь) прервет запрос и покажет предупреждение, поскольку рукопожатие не будет выполнено
Вот почему Microsoft, Google (Android / Chrome), Apple, Mozilla & Co. нашли способ определить, нужно ли вам «входить» через веб-интерфейс в эту сеть. Например, в случае с Apple устройства iOS отправляют GET HTTP-запрос на http://captive.apple.com,чтобы проверить, получает ли он текст «Success».
"captive.apple.com" возвращает "Success"
В случае Firefox этот URI - detectportal.firefox.com:
В обоих случаях браузер знает, что captive portal отсутствует. Если возвращается что-то другое, браузер / ОС знает, что ему нужно посетить этот сайт, потому что трафик явно перехвачен.
Проблема
Но вот первая проблема: эти URI всегда должны быть доступны через HTTP (незащищенные) или, по крайней мере, они быть доступными. Можно трактовать это по-другому, но на данный момент это так. И здесь возникает следующая проблема: все основные поставщики используют по крайней мере в некоторых случаях свой основной домен:
Google: clients3.google.com
Apple: captive.apple.com
Microsoft: teredo.ipv6.microsoft.com
Firefox: detectportal.firefox.com
Почему это проблема?
- Это означает, что эти корпорации не могут полностью защитить свой домен с помощью HSTS на поддоменах, потому что обнаружение портала не работает больше.
- Все поставщики автоматически открывают домен портала или IP-адрес, чтобы упростить процесс для пользователя - это также облегчает фишинг.
На данный момент я хочу порекомендовать запись в блоге от Троя Ханта:
Ссылка скрыта от гостей
Атака
Мы также заметили в Red Team, что, хотя Apple & Co обычно пытается открыть IP, вы можете перенаправить оттуда на «captive.apple.com». Вместо «Success» мы поставляем наш фишинговый портал на этот домен, так как он не защищен HSTS.
Путаница
И здесь у нас был еще один сюрприз: путаница доменов со стороны Apple. Хотя у меня есть учетные данные «apple.com», некоторые (большинство?) пользователей не имеют учетных данных apple.com, а имеют учетные данные icloud.com. Но угадайте что? Apple сделала путаницу, и даже если у вас нет сохраненных учетных данных «apple.com», Safari предлагает учетные данные с «icloud.com»!
Наш первый captive portal - не оптимизирован под фишинг
Safari, похоже, в этом случае пытается использовать учетные данные, хранящиеся для «com.apple ....», что является классическим соглашением о пространстве имен.
Учетные данные iCloud! Теперь нам нужно было оптимизировать это - от классического фишинга с логином до чего-то более похожего на Apple. Поэтому мы разработали новую страницу входа с кнопкой «Войти через Apple» - и некоторые скрытые поля:
Фишинговый портал - не видно скрытых полей
Мы поместили в него два скрытых поля - не сфокусированные. Как только пользователь нажимает кнопку «Войти через Apple», поле «Имя пользователя» становится сфокусированным - для более удобной работы ;-).
Как только пользовательское поле получает фокус, присоединяется SafariAutoFill и предлагает ваши учетные данные iCloud.com - насколько это круто?
Следующий трюк довольно прост: после того, как вы нажмете кнопку (которая на самом деле является Div), отобразится «Вход в систему ...». Если пользователь теперь выбирает свои учетные данные на серой панели автозаполнения, сайт автоматически передает заполненные учетные данные
Ссылка скрыта от гостей
Плюсы в этой атаке с точки зрения злоумышленников:
- "Sign In" Web Frame открывается автоматически
- Safari предлагает отправить учетные данные icloud
- Вы можете отправить их на icloud.com и использовать NecroBrowser / Muarena для обхода 2-FA
- FaceId в 1 клик, TouchID - в 2
- Учетные данные перехватываются перед вводом пользователя
- Процесс кажется бесшовным
Минусы:
В Red Team вы должны (!) поставить client-side фильтр на домене, чтобы не нацеливаться на людей за пределами вашего scope!
Тем не менее, Apple присвоила статус "low risk" этой уязвимости
Но они это исправили. Safari больше не предлагает учетные данные в всплывающем captive-login frame . Итак, каковы основные причины?
- HSTS на основном домене с субдоменами невозможен, из-за сайта captive portal
- Неразбериха с идентификатором пакета на домене
- Предложение учетных данные для icloud.com в автоматически отображаемой фрейме для captive.apple.com
Я все еще исследую другие браузеры и операционные системы на случай обнаружения подобных проблем
Ссылка скрыта от гостей