Как взломали пул для майнинга Bitcoin

Сегодня веб-сайты работающие с криптовалютами являются очень «вкусной» мишенью для хакеров. И вроде бы их безопасность должна быть на высоком уровне, но нет. это далеко не всегда так. Посмотрите хотя бы на BlockChain Graveiard, где видно как крупнейшие сервисы банкротятся и закрываются в результате хакерских атак. Меня это воодушевило и я решил провести собственное исследование безопасности одного из таких веб-приложений.
ViaBTC Pool — один из крупнейших пулов для совместного майнинга. Выбор был случайным и базировался на диаграмме ниже.

Диаграмма построена на основе рыночной доли самых популярных биткоин-пулов для майнинга по состоянию на 23.09.2017
Сайт не защищен от CSRF атак.
CSRF (англ. Сross Site Request Forgery — «Межсайтовая подделка запроса», также известен как XSRF) — вид атак на посетителей веб-сайтов, использующий недостатки протокола HTTP. Если жертва заходит на сайт, созданный злоумышленником, от её лица тайно отправляется запрос на другой сервер (например, на сервер платёжной системы), осуществляющий некую вредоносную операцию (например, перевод денег на счёт злоумышленника). Для осуществления данной атаки жертва должна быть аутентифицирована на том сервере, на который отправляется запрос, и этот запрос не должен требовать какого-либо подтверждения со стороны пользователя, которое не может быть проигнорировано или подделано атакующим скриптом.

В данном случае, если пользователь веб-приложения посетит вредоносный сайт, то его email изменится на адрес атакующего.

Работает это так:

Пользователь веб-приложения переходит на сайт злоумышленника.
Жертва ничего не подозревает, однако в этот момент на сайт pool.viabtc.com был отправлен запрос на смену email адреса.
Обход двухфакторной аутентификации при входе

Далее была обнаружена критическая уязвимость в реализации двухфакторной аутентификации. Некоторые функции веб-приложения требовали подтверждение вторым фактором аутентификации только во фронтенде. Если отправить запрос непосредственно на бэкенд, то он будет успешно выполнен без надлежащей аутентификации.

Таким образом, атакующий способен отключить двухфакторную аутентификацию при входе, несмотря на то, что он не прошёл ту самую двухфакторную аутентификацию, что, несомненно, является очень удобной фичей.
Полный обход двухфакторной аутентификации

Веб-приложение разрешает использовать два метода подтверждения операций: SMS код или код из Google Authenticator. Но я обнаружил ещё один метод – email код.

Как? Я обратил внимание на процесс подтверждения операции через SMS. Он состоит из запроса на отправку кода и запроса на подтверждение используя полученный код
Цепочка уязвимостей позволяет полностью украсть аккаунт, что, конечно же, критично. Тем не менее уязвимости исправить не сложно:

Внедрить CSRF-токены.
Выполнять проверки на стороне сервера.
Отключить подтверждение через email.

Но если смотреть глубже, эти уязвимости просто симптомы по которым можно диагностировать:

Разработчики не имеют базовых знаний в области безопасности веб-приложений. Как минимум знание заезженного OWASP TOP TEN исключили бы появление столь банальной уязвимости как CSRF.
Разработчики считают, что фронтенд является единственным источником данных для бэкенда веб-приложения и слишком доверяют данным от него. Но это не так: мы можем отправлять прямые запросы на сторону сервера.
Отсутствует строгая политика относительно функционала веб-приложения. Разработчики допустили существование предположительно дебаг функции в продакшн версии веб-приложения.

Главное это не просто исправить те несколько уязвимостей, что обнаружено. Важно смотреть в корень проблемы. Техническая команда должна сделать выводы и постоянно улучшать их знания в области безопасности. Да, возможно эта мысль банальна и очевидна. Но мы каждый месяц наблюдаем громкие заголовки о взломе очередной криптобиржи. Забавно то, что это вроде бы как новые технологии с огромными рисками, миллионы денег, которые могут безвозвратно покинуть ваш кошелёк, но всё те же разработчики, которые не знают что такое CSRF.