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

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

Итак, я посетил ViaBTC Pool — один из крупнейших пулов для совместного майнинга. Выбор был случайным и базировался на диаграмме ниже.

image
Диаграмма построена на основе рыночной доли самых популярных биткоин-пулов для майнинга по состоянию на 23.09.2017

Я зарегистрировал аккаунт, привязал телефон и подключил двухфакторную аутентификацию через Google Authenticator. Также была включена опция “Authenticate When Sign In ViaBTC” (2fa при входе).

Вот так безопасно выглядел аккаунт потенциальной жертвы:

image

Поехали!

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

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

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

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

    image
  3. Злой хакер тут же получает письмо на свою почту для подтверждения операции.

    image
  4. После перехода по ссылке в письме злоумышленник видит:

    image

Великолепно! Почта успешно привязалась и атакующий автоматически залоггинился в аккаунте жертвы. Но влажные фантазии нашего воображаемого хакера о несметных криптобогатствах прервёт тот самый редирект «ту хоум». Да, это окно втрого шага аутентификации (2fa при входе, помните?):

image

2. Обход двухфакторной аутентификации при входе

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

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

Смотрите сами:

  1. Атакующий использует запрос ниже для отключения 2fa при авторизации.

    image
  2. Злоумышленник переходит на главную страничку, но теперь аутентификация не запрашивается.

    image

Что ещё можно было сделать отправляя запрос непосредственно на сервер? Давайте вспомним первую уязвимость, где браузер жертвы сам отправил запрос на смену email’a. Если пользователю необходимо изменить email, то фронтед запросит подтверждение через второй фактор аутентификации. Но если отправлять запрос напрямую, то подтверждение не требуется! Из за такого недостатка безопасности атакующий и смог изменить email используя CSRF.

На данном этапе, атакующий получил доступ в аккаунт и к его конфиденциальной информации. Но такие важные операции, как, например, смена пароля всё ещё защищены двухфакторной аутентификацией.

3. Полный обход двухфакторной аутентификации

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

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

image

«В этом запросе было бы неплохо изменить “sms” на “email”», – подумал я.

image

А здесь логично “sms_code” на “email_code”.

Ну что сказать, ловкость рук и никакого мошенничества!

image

Да, у атакующего нет доступа к SMSкам жертвы. И да, у него нет доступа к аккаунту Google Authenticator жертвы. Но у него есть доступ к email’у (он был привязан к аккаунту благодаря CSRF).

Итак, финальные шаги:

  1. Злоумышленник отправляет запрос на получение кода подтверждения для операции перепривязки аккаунта Google Authenticator.

    image
  2. Получает код на email.

    image
  3. Подтверждает операцию используя email код.

    image
  4. Изменяет второй фактор аутентификации на свой.

    image

Вот таким нехитрым образом злоумышленник завладел аккаунтом обычного пользователя веб-приложения.

Заключение


Цепочка уязвимостей позволяет полностью украсть аккаунт, что, конечно же, критично. Тем не менее уязвимости исправить не сложно:

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

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

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

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

Timeline


  • 13.12.2017 — Reported.
  • 14.12.2017— Accepted.
  • 15.12.2017 — Fixed. Заплатили вознаграждение.

UPD: Заплатили 1 BTC. По курсу на тот момент около 18 000$.
Поделиться публикацией

Похожие публикации

Комментарии 28
    +17
    Астрологи объявили неделю хакинга.
    Количество атак на пулы увеличилось вдвое.
      0
      Почему автора комментария заминусовали? Автор статьи показал, что в местах где крутятся деньги можно получить хорошее вознаграждение (правда можно и отгрести проблем, но это уже другая история).
      +17
      14.12.2017— Accepted.
      15.12.2017 — Fixed. Заплатили вознаграждение.

      один день на фикс и выкатку его в прод + вознаграждение — это вам не отечественные гос структуры
        +1
        Потому что «крупнейшие сервисы банкротятся и закрываются в результате хакерских атак», поэтому и реакция такая. Если бы в госструктурах тоже была прямая зависимость зарплаты от работы структуры, то и реакция была бы аналогичная.
        +1
        А сколько хоть заплатили то? или тайна покрытая мраком?
          +29
          Заплатили 1 BTC. На тот момент это было 18к$, а сейчас… Ой, давайте не будем об этом.
            +6
            И конечно же, вы не вывели этот 1 ВТС в то время? =)
              +8
              Ну он же попросил:
              Ой, давайте не будем об этом.
              явно не спроста.
          +5
          Автор, хороший стиль изложения — все по сути и четко описано. Было бы интересно почитать/увидеть еще другие твои публикации. Ну и успехов в поиске:)
            0
            Спасибо. Если интересно, то можете заглянуть в мой блог — там есть парочка статей. Ссылка в профиле.
              0
              Извините, но я не вижу ссылку на ваш блог в профиле. Поделитесь, пожалуйста.
                0
                Это моя ошибка — неверно настроил приватность профиля. Посмотрите сейчас. И да, благодарю что сообщили!
                0
                Слишком мало постов в блоге. Я остался доволен и недоволен одновременно :)
                  0

                  Кстати да, очень интересно излагаете суть!
                  Вчера наткнулся на Ваш блог через поисковик, а сегодня уже тут увидел статью.
                  Также доволен и недоволен одновременно.
                  Годные посты, но мало!:D
                  Желаю вдохновения в данном труде.
                  С уважением, $UserName :)

                0

                Спасибо за активность и поиск уязвимостей.

                  +1
                  А full disclosure уязвимости пул одобрил? :)
                    +5
                    Я честно пытался получить благославление на то чтобы данная статья увидела свет, но, как говорится, молчание было мне ответом. Вы ведь помните мудрость про молчание и знак согласия?
                    0
                    Спасибо за статью. Какими инструментами пользуетесь для работы? Я вот немогу выбрать линукс distro for pentest, можете посоветовать что-то на эту тему? Интересно чем ползуются профи.
                      +1
                      Профи пользуются головой.
                        +1
                        Спасибо за инфу, но я обращался к автору.
                        +1
                        Основные инструменты рекомендую посмотреть у Сергея Белова. По поводу дистрибутива ничего нового и оригинального не скажу — использую Kali Linux.
                          0
                          Thanks. Посмотрел ваш бложик. С Люкософтом прям классика. Автору респект)
                        0

                        Для поиска изначальных уязвимостей от которых отталкивались использовался какой то сканер по типу nemesida scanner или что то другое?

                          0
                          А как JavaScript код был «отдан» жертве?
                            +1

                            Жертвой и был автор. А вообще СИ.

                            0
                            У автора не возникал соблазн перейти на темную сторону?
                              +1
                              «Джедаи служат другим, а не властвуют над ними, во благо Галактики.»
                              –1

                              можете меня минусовать, но я снимаю шляпу и просто завидую такому умному и грамотному человеку. За это можно все отдать… чтоб столько знать.

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое