Итак, я посетил ViaBTC Pool — один из крупнейших пулов для совместного майнинга. Выбор был случайным и базировался на диаграмме ниже.
Диаграмма построена на основе рыночной доли самых популярных биткоин-пулов для майнинга по состоянию на 23.09.2017
Я зарегистрировал аккаунт, привязал телефон и подключил двухфакторную аутентификацию через Google Authenticator. Также была включена опция “Authenticate When Sign In ViaBTC” (2fa при входе).
Вот так безопасно выглядел аккаунт потенциальной жертвы:
Поехали!
1. Сайт не защищен от CSRF атак.
CSRF (англ. Сross Site Request Forgery — «Межсайтовая подделка запроса», также известен как XSRF) — вид атак на посетителей веб-сайтов, использующий недостатки протокола HTTP. Если жертва заходит на сайт, созданный злоумышленником, от её лица тайно отправляется запрос на другой сервер (например, на сервер платёжной системы), осуществляющий некую вредоносную операцию (например, перевод денег на счёт злоумышленника). Для осуществления данной атаки жертва должна быть аутентифицирована на том сервере, на который отправляется запрос, и этот запрос не должен требовать какого-либо подтверждения со стороны пользователя, которое не может быть проигнорировано или подделано атакующим скриптом.
В данном случае, если пользователь веб-приложения посетит вредоносный сайт, то его email изменится на адрес атакующего.
Работает это так:
- Пользователь веб-приложения переходит на сайт злоумышленника.
- Жертва ничего не подозревает, однако в этот момент на сайт pool.viabtc.com был отправлен запрос на смену email адреса.
- Злой хакер тут же получает письмо на свою почту для подтверждения операции.
- После перехода по ссылке в письме злоумышленник видит:
Великолепно! Почта успешно привязалась и атакующий автоматически залоггинился в аккаунте жертвы. Но влажные фантазии нашего воображаемого хакера о несметных криптобогатствах прервёт тот самый редирект «ту хоум». Да, это окно втрого шага аутентификации (2fa при входе, помните?):
2. Обход двухфакторной аутентификации при входе
Далее была обнаружена критическая уязвимость в реализации двухфакторной аутентификации. Некоторые функции веб-приложения требовали подтверждение вторым фактором аутентификации только во фронтенде. Если отправить запрос непосредственно на бэкенд, то он будет успешно выполнен без надлежащей аутентификации.
Таким образом, атакующий способен отключить двухфакторную аутентификацию при входе, несмотря на то, что он не прошёл ту самую двухфакторную аутентификацию, что, несомненно, является очень удобной фичей.
Смотрите сами:
- Атакующий использует запрос ниже для отключения 2fa при авторизации.
- Злоумышленник переходит на главную страничку, но теперь аутентификация не запрашивается.
Что ещё можно было сделать отправляя запрос непосредственно на сервер? Давайте вспомним первую уязвимость, где браузер жертвы сам отправил запрос на смену email’a. Если пользователю необходимо изменить email, то фронтед запросит подтверждение через второй фактор аутентификации. Но если отправлять запрос напрямую, то подтверждение не требуется! Из за такого недостатка безопасности атакующий и смог изменить email используя CSRF.
На данном этапе, атакующий получил доступ в аккаунт и к его конфиденциальной информации. Но такие важные операции, как, например, смена пароля всё ещё защищены двухфакторной аутентификацией.
3. Полный обход двухфакторной аутентификации
Веб-приложение разрешает использовать два метода подтверждения операций: SMS код или код из Google Authenticator. Но я обнаружил ещё один метод – email код.
Как? Я обратил внимание на процесс подтверждения операции через SMS. Он состоит из запроса на отправку кода и запроса на подтверждение используя полученный код. Выглядит это так:
«В этом запросе было бы неплохо изменить “sms” на “email”», – подумал я.
А здесь логично “sms_code” на “email_code”.
Ну что сказать, ловкость рук и никакого мошенничества!
Да, у атакующего нет доступа к SMSкам жертвы. И да, у него нет доступа к аккаунту Google Authenticator жертвы. Но у него есть доступ к email’у (он был привязан к аккаунту благодаря CSRF).
Итак, финальные шаги:
- Злоумышленник отправляет запрос на получение кода подтверждения для операции перепривязки аккаунта Google Authenticator.
- Получает код на email.
- Подтверждает операцию используя email код.
- Изменяет второй фактор аутентификации на свой.
Вот таким нехитрым образом злоумышленник завладел аккаунтом обычного пользователя веб-приложения.
Заключение
Цепочка уязвимостей позволяет полностью украсть аккаунт, что, конечно же, критично. Тем не менее уязвимости исправить не сложно:
- Внедрить CSRF-токены.
- Выполнять проверки на стороне сервера.
- Отключить подтверждение через email.
Но если смотреть глубже, эти уязвимости просто симптомы по которым можно диагнозировать:
- Разработчики не имеют базовых знаний в области безопасности веб-приложений. Как минимум знания заезженного OWASP TOP TEN исключили бы появление столь банальной уязвимости как CSRF.
- Разработчики считают, что фронтенд является единственным источником данных для бэкенда веб-приложения и слишком доверяют данным от него. Но это не так: мы можем отправлять прямые запросы на сторону сервера.
- Отсутствует строгая политика относительно функционала веб-приложения. Разработчики допустили существование предположительно дебаг функции в продакшн версии веб-приложения.
Главное это не просто исправить те несколько уязвимостей, что я обнаружил. Важно смотреть в корень проблемы. Техническая команда должна сделать выводы и постоянно улучшать их знания в области безопасности. Да, возможно эта мысль банальна и очевидна. Но мы каждый месяц наблюдаем громкие заголовки о взломе очередной криптобиржи. Забавно то, что это вроде бы как новые технологии с огромными рисками, миллионы денег, которые могут безвозвратно покинуть ваш кошелёк, но всё те же разработчики, которые не знают что такое CSRF. Я всё.
Timeline
- 13.12.2017 — Reported.
- 14.12.2017— Accepted.
- 15.12.2017 — Fixed. Заплатили вознаграждение.
Комментариев нет:
Отправить комментарий