Звіт про тестування на проникнення для централізованої біржі

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

У грудні 2021 року команда Centralized Exchange зв’язалася з Sayfer, щоб провести повне тестування на проникнення в «чорну скриньку» для їхньої веб-додатки та перевірити «білу скриньку» для своєї криптоархітектури.

Перш ніж оцінити вищевказані послуги, ми провели стартову нараду з технічною командою Centralized Exchange і отримали огляд системи та цілей цього дослідження.

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

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

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

Сейфер використовує OWASP WSTG як наш технічний стандарт під час перевірки веб-додатків. Отримавши повне розуміння системи, ми вирішили, які тести 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. Для цього випадку здається, що рішенням може бути перевірка авторизації для кожного запиту.

Це означає, що кожен ключ запиту зможе отримати лише інформаційні панелі свого облікового запису

Слабша автентифікація в альтернативному каналі

Опис

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

Ця вразливість є частиною ланцюга з 2 уразливостей, які дозволили нам отримати контроль над будь-яким обліковим записом за допомогою лише електронної адреси.

У рамках нашого етапу розвідки, коли ми намагаємося знайти ширший вектор атаки, перераховуючи основні цільові підсистеми, ми знайшли інтерфейс адміністратора в субдомене ██████████████████. Можна увійти в інтерфейс адміністратора за допомогою звичайного користувача програми, але майже для всіх мережевих запитів, які ми перевірили під час завантаження головної сторінки, сервер повертає помилку 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 файл. Ці три файли розкривають конфіденційні дані

про архітектуру сервісу. Зловмисник може використовувати цю інформацію, щоб збільшити вектор атаки на ціль.

Пом'якшення

Якщо можливо, видаліть ці файли з публічної служби або запровадьте механізм авторизації, який надає доступ лише привілейованим користувачам.

Відсутній заголовок політики безпеки вмісту

Опис

Політика безпеки вмісту (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-Options

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

• Строгий-Транспорт-Безпека

HSTS — це механізм політики веб-безпеки, який допомагає захистити веб-сайти від атак із пониженням версії протоколу та викрадення файлів cookie. Це дозволяє веб-серверам оголосити, що веб-браузери повинні взаємодіяти з ним лише за допомогою безпечних з’єднань HTTPS, а не через незахищений протокол HTTP.

• Політика реферера

Заголовок Referer — це заголовок запиту, який вказує на сайт, з якого походить трафік. Якщо немає належного запобігання, сама URL-адреса та навіть конфіденційна інформація, що міститься в URL-адресі, потраплятимуть на інший сайт.

• Access-Control-Allow-Origin

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

Пом'якшення

Додавання згаданих вище заголовків до всіх внутрішніх служб.

Перегляньте метафайли веб-сервера на предмет витоку інформації

Опис

Досліджуючи ціль за допомогою DevTool, ми змогли переглянути вихідний код інтерфейсу без будь-яких обфускацій. Ця вразливість виникає через те, що пакети JS постачаються з вихідними картами для виробництва, що дає змогу читати оригінальний вихідний код із коментарями, які можуть розкрити інформацію, наприклад, такий файл paths.ts:

█████████████████████/paths.ts [IMAGE_REDACTED]

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

Пом'якшення

Не відправляйте вихідні карти у виробництво, більшість систем журналювання та відстеження помилок мають думку щодо завантаження вихідних карт у бек-офісну систему. Інший підхід полягав би в тому, щоб обслуговувати вихідні карти лише автентифікованим користувачам через 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 після першої редакції.