Отчет о тестировании на проникновение для централизованной биржи

Резюме управления

Команда Centralized Exchange связалась с Sayfer, чтобы провести полное тестирование черного ящика на проникновение в свое веб-приложение и проверку белого ящика для своей криптоархитектуры в декабре 2021 года.

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

За период исследования в 4 недели мы обнаружили 10 уязвимостей в системе. Наиболее опасными уязвимостями оказались SQL-инъекции и недостатки в бизнес-логике.

Воздействие на систему имеет решающее значение, поскольку злоумышленник может использовать некоторые из этих уязвимостей, чтобы воспользоваться преимуществами системы, либо изменив свою роль пользователя на «super_user» с помощью SQL-инъекции, либо злоупотребив системой и похитив деньги с централизованной биржи. с помощью механизма обновления системы 30s.

Методология оценки безопасности

Сайфер использует ОВАСП ВСТГ в качестве нашего технического стандарта при рассмотрении веб-приложений. Получив полное представление о системе, мы решили, какие тесты OWASP необходимы для ее оценки.

Результаты оценки безопасности

Небезопасное сохранение приватных ключей MPC

Описание

Централизованные биржи страдают от некачественной практики управления ключами. Есть много примеров таких случаев, когда ключи были утеряны или украдены, что привело к потере сервисом всех средств кошелька или полной блокировке средств.

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

Есть 3 ключа, которые используются в рамках подписи ключа MPC. 1 хранится на физически защищенной машине. Остальные 2 хранятся на том же выделенном компьютере в GCP.

Для защиты этих машин предпринято несколько мер безопасности, но проблема связана с распределением: если машина, развернутая на GCP, будет скомпрометирована, злоумышленник может подписать любую транзакцию из холодного кошелька.

Это опасное и чувствительное место, где многие потерпели неудачу в прошлом, поэтому следует строго следовать передовым методам.

риска

Используйте стороннюю службу хранения для управления горячими кошельками и хранилищами. Мы будем рады порекомендовать одного из наших партнеров.

Эти сервисы управляют MPC и управлением ключами за вас, а другие дополнительные уровни безопасности делают использование таких сервисов лучшим выбором для централизованных обменов.

SQL-инъекция

Описание

Атака с внедрением SQL включает вставку или «внедрение» частичного или полного SQL-запроса во входные данные, которые передаются от клиента в веб-приложение. Успешная атака с внедрением SQL-кода может считывать конфиденциальные данные из базы данных, изменять данные базы данных (вставлять/обновлять/удалять), выполнять операции администрирования базы данных (например, закрытие СУБД), восстанавливать содержимое заданного файла в файловой системе СУБД или записывать файлы в файловую систему и, в некоторых случаях, отдавать команды операционной системе.

Посмотрите на график transaction конечная точка, мы смогли злоупотребить more Параметр запроса URL для внедрения вредоносной полезной нагрузки SQL:

/api/transactions?size=10&more=te');INJECTION_PAYLOAD

Полезная нагрузка, которую мы использовали, была:

/api/transactions?size=10&sort=time,DESC&more=te');SELECT+CASE+WHEN+(substring(versio n(),12,2)+%3d+'10')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END%3b — Что в данном случае проверяет, является ли работающий экземпляр Postgres версией 10 или нет.

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

риска

Уязвимость SQL-инъекций легко исправить, но трудно смягчить. Необходим сильный линтинг или реализация правил компиляции, обеспечивающих будущие изменения.

Устранение уязвимостей SQL-инъекций обычно выполняется в соответствии с выбранной структурой, что означает, что разработчик никогда не должен объединять строки в полный оператор SQL.

Каждый пользовательский ввод должен быть обработан в исполнителе SQL, а не использоваться как простая строка запроса SQL.

Для получения дополнительной информации о совершенстве SQL-инъекций см. SQL IШпаргалка по предотвращению инъекций.

Небезопасные прямые ссылки на объекты

Описание

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

Мы обнаружили, что API █████████ позволяет злоумышленнику просматривать информацию панели управления других пользователей, включая все финансовые данные этого пользователя.
Уязвимость основана на параметре идентификатора панели мониторинга, который представляет собой угадываемое целое число. Пример запроса для одной информационной панели (для информационной панели, которая не принадлежит текущему пользователю):

GET ████/dashboard/827371 HTTP/1.1

Host: ██████████████████

api-key: ██████████
…

Это указывает на то, что /dashboard/DASHBOARD_ID конечная точка не проверяет авторизацию для запрошенного ресурса. Злоумышленник, прошедший проверку подлинности, может очистить каждую панель инструментов, содержащую информацию о средствах пользователей и прошлых транзакциях.

риска

Существует несколько способов смягчить уязвимости IDOR, в этом случае кажется, что решением может быть проверка авторизации для каждого запроса.

Это означает, что каждый ключ запроса сможет получить только информационные панели своей учетной записи.

Более слабая аутентификация в альтернативном канале

Описание

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

Эта уязвимость является частью цепочки из двух уязвимостей, которые позволили нам завладеть любой учетной записью, используя только адрес электронной почты.

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

[IMAGE_REDACTED]

Мы перепроектировали файл пакета main.js, который содержит интерфейсный код для приложения, и нашли все потенциальные конечные точки, с которыми может взаимодействовать администратор.

Мы могли использовать только конечную точку api/updateUser. Конечная точка позволяла нам редактировать электронную почту любого пользователя, тем самым мы могли сбросить пароль жертвы и завладеть учетной записью.

[IMAGE_REDACTED]

риска

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

Кроме того, в админке есть механизм авторизации, но это выходит за рамки данного проекта.

Проверка метафайлов веб-сервера на предмет утечки информации

Описание

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

• ████████████████████████.gitignore
• ██████████████████████████████/docker-compose.yml
• ████████████████████████/swagger-ui.html

[IMAGE_REDACTED]

[IMAGE_REDACTED]

[IMAGE_REDACTED]

Мы обнаружили три типа файлов, которые могут нанести вред службам ████████. .gitignore, swagger-ui и docker-compose.yml файл. Эти три файла раскрывают конфиденциальные данные

об архитектуре сервиса. Злоумышленник может использовать эту информацию для увеличения вектора атаки на цель.

риска

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

Отсутствует заголовок Content Security Policy

Описание

Политика безопасности контента (CSP) — это дополнительный уровень безопасности, который помогает обнаруживать и смягчать определенные типы атак, включая межсайтовые сценарии (XSS) и атаки с внедрением данных.

Мы не нашли заголовка CSP ни в одном из ответов сервера.

[IMAGE_REDACTED]

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

Базовая политика CSP должна, по крайней мере, описывать домены из белого списка по умолчанию для статических файлов (таких как скрипты, изображения и CSS). И frame-ancestors для предотвращения клик-джек-атак.

Дополнительная информация:

1. https://cspvalidator.org/
2. https://csp-evaluator.withgoogle.com/

риска

Добавление Content-Security-Policy: [policy] на каждый ответ, где загрузка внешних ресурсов может быть опасной

Мы настоятельно рекомендуем использовать его и протестировать сначала с вариантом «Только для отчетов», чтобы проверить свою политику перед выпуском ее в производство:

Content-Security-Policy-Report-Only: [policy]

Тестирование заголовков безопасности

Описание

1. Браузеры поддерживают множество заголовков HTTP, которые могут повысить безопасность приложений для защиты от различных распространенных атак. Заголовки обмениваются между веб-клиентом (обычно браузером) и сервером, чтобы указать связанные с безопасностью детали связи HTTP.

При просмотре заголовков безопасности ████████ отсутствует следующее:

• Параметры X-Content-Type

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

• Строгий-Transport-Security

HSTS — это механизм политики веб-безопасности, который помогает защитить веб-сайты от атак с понижением версии протокола и перехвата файлов cookie. Это позволяет веб-серверам объявлять, что веб-браузеры должны взаимодействовать с ним только с использованием безопасных HTTPS-соединений, а не через небезопасный протокол HTTP.

• Реферер-Политика

Заголовок Referer — это заголовок запроса, указывающий сайт, с которого пришел трафик. Если не будет надлежащего предотвращения, сам URL-адрес и даже конфиденциальная информация, содержащаяся в URL-адресе, будут переданы на сайт из другого источника.

• Доступ-Контроль-Разрешить-Происхождение

Заголовок имеет значение «*», которое предоставляет API для каждого веб-сайта, это может быть нежелательным результатом.

риска

Добавление упомянутых выше заголовков ко всем внутренним службам.

Проверка метафайлов веб-сервера на предмет утечки информации

Описание

При исследовании цели с помощью DevTool мы смогли просмотреть исходный код внешнего интерфейса без какой-либо обфускации. Эта уязвимость возникает из-за того, что пакеты JS поставляются с исходными картами для производства, которые позволяют читать исходный код с комментариями, которые могут раскрывать информацию, например следующий файл paths.ts:

██████████████████████/paths.ts [ИЗОБРАЖЕНИЕ_УДАЛЕНО]

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

риска

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

Веб-сервер отпечатков пальцев

Описание

Хотя открытая информация о сервере сама по себе не обязательно является уязвимостью, это информация, которая может помочь злоумышленникам использовать другие уязвимости, которые могут существовать. Большинство конечных точек не раскрывают никакой информации о сервере через заголовки HTTP или страницы ошибок.
Используя следующий неправильно сформированный HTTP-запрос, мы смогли получить отпечаток сервера Nginx через ответ 400.
GET /v2 HTTPMALFORMED/1.1
Host: ██████████████████
Accept: */*

Тело ответа:
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx 1.14.0</center>
</body>
</html>

риска

Существуют разные способы скрыть заголовки веб-сервера, наиболее часто используемые методы:

1. Обратные прокси-серверы, которые стоят между глобальным интернетом и внутренним
2. Настройте каждый веб-сервер для удаления этих заголовков.

Приложение A. Исправления оценки безопасности

Будет обновлено командой Sayfer после первой редакции.