Это — сиквел моей сногсшибательной первой статьи.
Готов поспорить что каждый веб разработчик сталкивался с фейсбук коннектом или вконтакте логином или аутенфикацией через твиттер. Все это по сути построено на основе OAuth1/2.
Мое мнение заключается в том что мы все ступили не на ту дорожку. OAuth это дорожка в ад (к слову, Эран Хаммер сейчас работает над заменой oauth — oz).
В этой статье я не буду погружаться в модель атаки а перескажу совершенно конкретные уязвимости которые вы можете начать использовать прямо сейчас.
В любой другой ситуации я бы сказал что CSRF на такой незначительной, хоть и state-changing, функции ничего не стоит. Но как только дело касается протоколов построенных на редиректах… Дело в том что в 99 процентов случаев процесс коннекта Site <= Facebook можно запустить загрузив GET /users/connect/facebook те начать процесс самому, без user interaction.
Идея в том, чтобы перелогинеть юзера на Фейсбуке (провайдере) в свой аккаунт, загрузить этот эндпоинт для коннекта, который автоматически подключит аккаунт атакующего к аккаунту жертвы на клиенте, и потом входить в аккаунт жертвы самому.
Фейсбук защищается лишь через проверку реферера:
Это новое воплощение Самой Частой Ошибки (не проверки state) только на более высоком уровне. Мы не подкидываем свой колбэк со своим кодом, а заставляем сам фейсбук вернуть код от вашего аккаунта путем форсированного перелогина. ФБ отказалось это исправлять, так как это ломает совместимость с разными существующими плагинами для фб. VK.com тоже уязвим (этим ребятам даже репортить некуда, посмещище какое то. Даже магазин с фенечками более серьезно относится к безопасности). Этот баг можно использовать на любом сайте с omniauth, django-social-auth, php-sdk и так далее. Исправление — нужно проверять csrf token при загрузке /connect адреса.
Я бы даже сказал сама идея перелогина бросает тень на OAuth — ведь даже с помощью cookie forcing можно полностью заменить cookies жертвы и перелогинеть его на любом Провайдере. Это концептуальная ошибка которую уже никак не исправить.
СР это подписанный запрос с помощью client_secret и создан он… непонятно зачем. Дело в том что это по сути тот же code-flow только code передается в # фрагменте и выпущен он для redirect_uri = "". А значит если украсть signed_request через 302 редирект его можно использовать чтобы зайти как владелец СР на сайте клиента (просто проставить куку fbsr_CLIENT_ID=SR).
Говоря простым языком, если на сайте есть Facebook JS SDK и вы нашли опен редирект (на домене или поддомене) — вы можете угнать любой аккаунт через слитие SR жертвы. И это опять таки не будет исправлено.
Еще один WontFix. В пейпале перед запуском express checkout flow нужно получить request_token отослав все свои параметры и потом уже загружать paypal?token=request_token. Дело в том что вы можете выпустить этот токен для себя, путем фишинга загрузить этот УРЛ на браузере жертвы и убедить его оплатить этот токен (платеж и правда поступит Клиенту) то можно самому перейти по callback?token=token и получить все те деньги что заплатила жертва уже на свой аккаунт. Я проверял это на namecheap.
Это полная копия session fixation в OAuth1. Когда его открыли все провайдеры выключили коннект чтобы запатчить. В нашем же случае Paypal даже не пошевелил ухом. Тк уязвимы опять таки не они, а сайты-клиенты.
Я крайне не рекомендую пользоваться логином через социальные сети. Если же вы вынуждены это реализовывать, постарайтесь прописать максимум проверок и поставить статические колбэки в настройках вашего клиента (hardening — уменьшение поверхности атаки). С багами выше я нашел эксплоиты для угона аккаунта на soundcloud, foursquare, songkick, airbnb, и еще десяток стартапов с соц логинами.
P.S. в яндекс баунти написал как у них угонять аккаунты, но им не сильно интересно поэтому копирую сюда:
1) фиксируем сессию на фейсбуке
2) вызываем у залогиненого в яндексе урл
social.yandex.ru/broker/start?retpath=https%3A%2F%2Fsocial.yandex.ru%2Fhtml%2Fcloser%2Fpromo_closer.html%23ddom%3D&consumer=social&popupName=social_popup&application=&action_if_anonymous=ignore&result_location=fragment&provider=fb&display=popup
3) он автоматом приконектит атакерский фб к паспорту, но к счастью (моему сожалению) надо еще подтвердить auth через него. Немного соц инженерии, грузим
passport.yandex.ru/passport?mode=authentication&retpath=https%3A%2F%2Fsocial.yandex.ru%2Fupdate%3Fprofile_id%3D23177612%26allow_auth%3D1
как видите там ни слова про фейсбук или аккаунты, просто требует ввести пароль, что юзер с удовольствием сделает (side-bug. наверно стоит объяснять для чего спрашивают пароль а то мало ли)
4) теперь можно через атакерский фб войти прямо в яндекс, отконнектить фейсбук, украсть почту и куки — perfect crime
Original post in English.
Готов поспорить что каждый веб разработчик сталкивался с фейсбук коннектом или вконтакте логином или аутенфикацией через твиттер. Все это по сути построено на основе OAuth1/2.
Мое мнение заключается в том что мы все ступили не на ту дорожку. OAuth это дорожка в ад (к слову, Эран Хаммер сейчас работает над заменой oauth — oz).
В этой статье я не буду погружаться в модель атаки а перескажу совершенно конкретные уязвимости которые вы можете начать использовать прямо сейчас.
CSRF на логине
В любой другой ситуации я бы сказал что CSRF на такой незначительной, хоть и state-changing, функции ничего не стоит. Но как только дело касается протоколов построенных на редиректах… Дело в том что в 99 процентов случаев процесс коннекта Site <= Facebook можно запустить загрузив GET /users/connect/facebook те начать процесс самому, без user interaction.
Идея в том, чтобы перелогинеть юзера на Фейсбуке (провайдере) в свой аккаунт, загрузить этот эндпоинт для коннекта, который автоматически подключит аккаунт атакующего к аккаунту жертвы на клиенте, и потом входить в аккаунт жертвы самому.
Фейсбук защищается лишь через проверку реферера:
Это новое воплощение Самой Частой Ошибки (не проверки state) только на более высоком уровне. Мы не подкидываем свой колбэк со своим кодом, а заставляем сам фейсбук вернуть код от вашего аккаунта путем форсированного перелогина. ФБ отказалось это исправлять, так как это ломает совместимость с разными существующими плагинами для фб. VK.com тоже уязвим (этим ребятам даже репортить некуда, посмещище какое то. Даже магазин с фенечками более серьезно относится к безопасности). Этот баг можно использовать на любом сайте с omniauth, django-social-auth, php-sdk и так далее. Исправление — нужно проверять csrf token при загрузке /connect адреса.
Я бы даже сказал сама идея перелогина бросает тень на OAuth — ведь даже с помощью cookie forcing можно полностью заменить cookies жертвы и перелогинеть его на любом Провайдере. Это концептуальная ошибка которую уже никак не исправить.
signed_request
СР это подписанный запрос с помощью client_secret и создан он… непонятно зачем. Дело в том что это по сути тот же code-flow только code передается в # фрагменте и выпущен он для redirect_uri = "". А значит если украсть signed_request через 302 редирект его можно использовать чтобы зайти как владелец СР на сайте клиента (просто проставить куку fbsr_CLIENT_ID=SR).
Говоря простым языком, если на сайте есть Facebook JS SDK и вы нашли опен редирект (на домене или поддомене) — вы можете угнать любой аккаунт через слитие SR жертвы. И это опять таки не будет исправлено.
OAuth1 фиксация Paypal
Еще один WontFix. В пейпале перед запуском express checkout flow нужно получить request_token отослав все свои параметры и потом уже загружать paypal?token=request_token. Дело в том что вы можете выпустить этот токен для себя, путем фишинга загрузить этот УРЛ на браузере жертвы и убедить его оплатить этот токен (платеж и правда поступит Клиенту) то можно самому перейти по callback?token=token и получить все те деньги что заплатила жертва уже на свой аккаунт. Я проверял это на namecheap.
Это полная копия session fixation в OAuth1. Когда его открыли все провайдеры выключили коннект чтобы запатчить. В нашем же случае Paypal даже не пошевелил ухом. Тк уязвимы опять таки не они, а сайты-клиенты.
Вывод
Я крайне не рекомендую пользоваться логином через социальные сети. Если же вы вынуждены это реализовывать, постарайтесь прописать максимум проверок и поставить статические колбэки в настройках вашего клиента (hardening — уменьшение поверхности атаки). С багами выше я нашел эксплоиты для угона аккаунта на soundcloud, foursquare, songkick, airbnb, и еще десяток стартапов с соц логинами.
P.S. в яндекс баунти написал как у них угонять аккаунты, но им не сильно интересно поэтому копирую сюда:
1) фиксируем сессию на фейсбуке
2) вызываем у залогиненого в яндексе урл
social.yandex.ru/broker/start?retpath=https%3A%2F%2Fsocial.yandex.ru%2Fhtml%2Fcloser%2Fpromo_closer.html%23ddom%3D&consumer=social&popupName=social_popup&application=&action_if_anonymous=ignore&result_location=fragment&provider=fb&display=popup
3) он автоматом приконектит атакерский фб к паспорту, но к счастью (моему сожалению) надо еще подтвердить auth через него. Немного соц инженерии, грузим
passport.yandex.ru/passport?mode=authentication&retpath=https%3A%2F%2Fsocial.yandex.ru%2Fupdate%3Fprofile_id%3D23177612%26allow_auth%3D1
как видите там ни слова про фейсбук или аккаунты, просто требует ввести пароль, что юзер с удовольствием сделает (side-bug. наверно стоит объяснять для чего спрашивают пароль а то мало ли)
4) теперь можно через атакерский фб войти прямо в яндекс, отконнектить фейсбук, украсть почту и куки — perfect crime
Original post in English.
