Методика тестирования крипто-бирж и крипто-кошельков

Крипто-кошельки и крипто-биржи могут пострадать от хакерских атак (или от глупости пользователей, разработчиков, а также проблем с логикой работы системы). Помочь этому могло бы тестирование для выявления уязвимостей и проблем в логике работы приложения, однако я так и не нашел формализованной методики, в которой было-бы написано на что нужно обращать внимание во время тестирования. Протестировав уже добрый десяток бирж и кошельков, я решил формализовать порядок их тестирования, кому интересно, добро пожаловать под кат.

При проведении тестирования бирж и кошельков, я обратил внимание на их функционирования, и аспекты их тестирования я сформулировал ниже в виде небольшой методике, но всё по порядку.
В первую очередь, нужно понимать, что важно для заказчика? Для заказчика важно, что-бы не были похищены деньги с биржи или кошелька и сохранение персональных данных пользователей. А так как, по факту, каждая биржа или кошелёк, в большинстве своём, представляет собой веб-сайт или веб-приложение, заказчик хочет провести моделирование хакерской атаки, т.е. тестирование Black Box (см. Таблица 1), но для полноты тестирования выбирают чаще проведение тестирования Gray Box (см. Таблица 1).
Для тестирования логики работы нужна тестовая крипто-валюта. А так как у каждой биржи свои ограничения по вводу/выводу средств, то сумма тестовой крипто-валюты должна быть не менее минимально допустимой для вывода и её должно хватить для проведения не менее 5 транзакций покупки-продажи и/или ввода-вывода.

Таблица 1. Типы тестирования в зависимости от предоставляемой информации.

Type	Описание
Black Box	тестирование проводится без привлечения технической команды заказчика
Gray Box	контакт с технической командой заказчика добавление учетных записей, с которых идёт тестирование в “white list” заказчик предоставляет средства (монеты) для тестирования
White Box	полная поддержка заказчиком предоставление исходного кода приложения предоставление логов предоставление доступов разных привелегий предоставление средств (монет) в количестве, необходимом для тестирования

У нас, в Hacken, тестирования на уязвимости проводятся в следующем порядке:

1. Изучение общедоступной информации.
2. Проверка автоматизированными средствами.
3. Проверка в ручном режиме.
4. Написание отчёта.

Особенности тестирования крипто-бирж и крипто-кошельков

1. Тестирование KYC Verification — эта требование большинства крипто-бирж и ICO.

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

• Проверка на возможность загрузки исполняемых файлов на сервер системы
• Проверка на возможность хищения отсканированных документов — брут-форс имён файлов и директорий.
• Проверка неавторизованного доступа к файловой системе сервера.

2. Тестирование ввода-вывода средств

• Проверка правильности округления чисел при вводе-выводе средств.
• Проверка подмены адреса кошелька при вводе-выводе средств (самая простая ошибка — это не проверка кошелька отправителя и получателя, но очень критичная).
• Проверка логики работы при вводе-выводе средств.
• Проверка обхода подтверждения выполнения операции покупки-продажи (код двухфакторной аутентификации, OTP, специального пароля).
• Проверка Race condition уязвимостей при выводе средств.
• Проверка возможности выхода за ограничения ввода/вывода средств.

3. Тестирование покупки-продажи криптовалют (относиться только к биржам)

• Проверка правильности округления чисел при покупки-продажи средств.
• Проверка подмены адреса при покупки-продажи.
• Проверка логики работы при покупки-продажи средств.
• Проверка возможности подмены или модификации ордера на продажу.
• Проверка обхода подтверждения выполнения операции покупки-продажи (код двухфакторной аутентификации, OTP, специального пароля).
• Проверка возможности Race condition при осуществлении операций покупки/продажи.
• Проверка возможности подмены адреса кошельков.

Тестирование веб-части

4. Тестирование процесса регистрации

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

5. Тестирование процесса аутентификации

• Проверки фильтрации параметров при аутентификации.
• Проверка возможности подбора логина и пароля к учётной записи по словарю (защита от перебора).
• Проверка обхода проверки капчи.
• Проверка обхода двухфакторной аутентификации.
• Проверка возможности отключения двухфакторной аутентификации.
• Проверка возможности утечки данных при аутентификации.

6. Тестирование фреймворков и технологий, которые использовались при разработки биржи

Во время проведения тестировании на уязвимости нужно определить технологии и методики (фреймворки), с помощью которых разрабатывались биржи. Таким образом при понимании технологии, с помощью которой разрабатывались кошелек или биржа можно в открытых источниках найти возможный эксплоит или уже найденные уязвимости. Необходимо проверить, что все сторонние библиотеки, фреймворки и софт не имеют публично доступных уязвимостей на момент релиза или корректную настройку систем защиты (например CloudFlare).

7. Тестирование по OWASP

Методология OWASP содержит проверочный лист, который рассматривает все возможные угрозы безопасности для веб-сайта. Таким образом такая проверка позволяет выявить возможные уязвимые места (ну ещё много зависит от прямоты рук опыта и навыков тестировщика)

Чаще всего встречаются:

• Проверка фильтрации параметров на бэк-энде, так-как часто их проверяют только на фронт-энде
• Отсутствие флагов HTTP-запросов, что не является критичным, но может привести к кэшированию паролей или возможности выполнения атаки Clickjacking
• Отсутствие управление сессиями: это может привести к тому, что при хищении cookie или непосредственного доступа злоумышленника к компьютеру или телефону можно будет выполнять операции от валидного пользователя
• Уязвимые версии открытых сервисов
• Использование JSON Web Tokens (JWT), со слабыми алгоритмами шифрования

8. Тестирование API

• Проверка на уязвимости API с помощью написания программного модуля для взаимодействия с API и проверка возможных логических уязвимостей на стороне клиента и API.
• Использовать Swagger для просмотра структуры запроса, это нужно для понимания, что нужно отправлять серверу и таким образом проверять API на уязвимость.

9. Тестирование WebSockets

Софт, который обычно используется для проведения тестирования:

• BurpSuite
• Acunetix
• Zenmap
• Owasp ZAP
• SQLmap

И другие инструменты по мере необходимости.

Заключение:

В данной статье я постарался формализовать и структурировать методику тестированию бирж, которую я применил более чем в 10 случаях тестирования бирж и кошельков. Данную методику мы взяли за основную методику тестирования бирж в компании Hacken. На сегодняшний день отрасль blockchain технологий, децентрализованных решений и криптовалют находится в стадии пиковой популярности. FAQи и методички устаревают значительно быстрее Закона Мура, поэтому статья не претендует на роль исключительного мануала по тестированию крипто бирж, лишь выражает опыт, приобретенный в ходе многократного повторения данной процедуры.