Відповідь Nym на аудит безпеки Cure53 (липень 2024)

Вступ

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

У липні 2024 року Nym пройшов незалежний аудит компанії Cure53, берлінської компанії з кібербезпеки, яка має понад 15 років досвіду у проведенні тестів програмного забезпечення та аудити коду. Оцінка охоплювала ключові компоненти, включаючи мобільні та десктопні додатки, VPN-інфраструктуру, реалізацію криптографії та загальну архітектуру системи.

Усі виявлені критичні та високі вразливості були виправлені. Ми наразі чекаємо на відгук від Cure53 щодо нашого звіту та виправлень.

Повний звіт Cure53 опубліковано тут. Ви також можете подивитися доповідь доктора Надіма Кобейсі для OSTIF, в якій він обговорює аудит Nym і надає глибокий технічний аналіз деяких виявлених проблем.

Підсумок аудиту Nym в Cure53

Cure53 провела всебічну оцінку безпеки екосистеми Nym, включаючи тестування на проникнення, аудит вихідного коду та огляд коду. Аудит був зосереджений на оцінці рівня безпеки мобільних та десктопних додатків Nym, бекенд API, програмного забезпечення VPN та інфраструктури, а також криптографії. Команда Nym постійно підтримувала команду Cure53 під час аудиту, забезпечуючи плавну співпрацю та прозорий процес.

Команда Cure53 використовувала стратегію кристального боксу, забезпечуючи повний доступ до вихідного коду, збірок, документації, тестових середовищ і супутніх наукових статей. Аудит, що тривав 56 робочих днів, включав команду з шести старших експертів з кібербезпеки. Робота була поділена на п'ять робочих пакетів (WP):

• Мобільні додатки Nym
• Десктопні додатки Nym
• API для бекенду Nym
• Програмне забезпечення та інфраструктура Nym VPN
• Криптографія Nym

Аудит досяг широкого охоплення в межах визначеного обсягу, виявив 43 знахідки, зокрема 7 вразливостей безпеки – включаючи критичні та високої серйозності проблеми – та 24 загальних слабкостей, які класифікуються як середні або низькі ризики експлуатації та представляють можливості для подальшого зміцнення системи.

Особливо варто зазначити, що програмне забезпечення та інфраструктура NymVPN виявилися в відмінному стані з точки зору безпеки, без виявлених проблем. Cure53 дійшов висновку, що всі досліджувані компоненти мали міцну основу безпеки, демонструючи загалом надійну позицію. Десктопні додатки були оцінені як такі, що перебувають у хорошому стані з точки зору безпеки, значних вразливостей не виявлено. Команда аудиту підкреслила, що загальна реалізація була надійною. Таким чином, бекенд Nym та API були оцінені як перебуваючі в помірному стані з точки зору безпеки. Зокрема, звіт визнав, що кілька критичних вразливостей були ефективно пом’якшені та запобігли, підкреслюючи наш проактивний підхід до безпеки та ретельну реалізацію.

Ключові висновки

WP1: Тестування безпеки Crystal-box та аудит вихідного коду мобільних додатків Nym

У WP1 компанія Cure53 провела як статичний, так і динамічний аналіз разом з тестуванням з відкритим кодом мобільних додатків NymVPN для Android та iOS. Метою було виявити будь-які вади, неправильні налаштування або ризики безпеки в програмах. Загалом, результати виявились менш серйозними, без критичних чи високих ризиків вразливості у системах. Визначені проблеми були переважно середніми, низькими або інформаційними за ступенем серйозності і можуть бути ефективно вирішені в рамках більш широких зусиль щодо зміцнення додатків. Статичний аналіз мав на меті виявити субоптимальні налаштування або неправильні конфігурації в додатках, які можуть призвести до вразливостей. Однак аналіз не виявив жодних високих ризиків.

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

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

Загалом, мобільні додатки продемонстрували хорошу безпекову позицію з мінімальною атакувальною поверхнею. Окрім кількох незначних областей для покращення, таких як неправильне використання рідної безпечної пам'яті додатку iOS (NYM-01-024), значних вразливостей безпеки в додатках не було виявлено.

WP2: Кристальна коробка пентести та аудити вихідного коду для настільних додатків Nym

WP2 зосередився на настільних додатках NymVPN для Windows, Linux та macOS. Команда тестування провела детальний огляд як компонентів фронтенду щодо проблем на стороні клієнта, так і шару комунікації Rust на бекенді. В цілому, настільні програми продемонстрували сильні практики безпеки.

Ключові позитивні висновки включають використання фреймворку React для компонентів фронтенду, що значно зменшує поверхню атаки. Команда не виявила жодних суттєвих вразливостей на стороні клієнта, за винятком дуже специфічного сценарію, коли шкідливий URL-адреси репозиторію може викликати виконання произвольного JavaScript (XSS), якщо на нього натиснути за певних умов. Цю проблему класифіковано як низький ризик, без виявлення чутливих даних чи критичних вразливостей. На стороні сервера зв'язок з демонним процесом через Unix-сокет (Linux) та конвеєр (Windows) був ретельно вивчений, і суттєвих недоліків чи ризиків безпеки не було виявлено.

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

WP3: Кристала-бокс тестування безпеки та аудити вихідного коду до API Nym

WP3 зосередився на API компонентів бекенду Nym, включаючи шлюзи та змішувальні вузли, при цьому виключаючи валідатори. Процес тестування ретельно перевірив механізми серіалізації/десеріалізації, SQL-ін'єкції, аутентифікації та авторизації, вразливості SSRF, атаки за часом та місця виконання коду. Позитивно, бекенд Nym демонструє помірну безпеку, без виявлених вразливостей для безпосереднього виконання коду, ризиків SQLi або проблем SSRF високого ризику, які могли б бути експлуатовані. Механізми автентифікації та авторизації в нашій мережі реалізовані відповідно до безпечних стандартів, ефективно зменшуючи можливі обхідні способи. Хоча компоненти бекенду демонстрували загалом високу безпеку, було виявлено кілька помітних проблем. Серед них два висновки були класифіковані як високої або критичної ступені важкості (NYM-01-027, NYM-01-030 та NYM-01-032), які ми розглянемо далі.

NYM-01-027 WP3: Повторне використання nonce-ключа в AES-CTR у шлюзах Nym (Критично)

Під час огляду вихідного коду репозиторію Nym було виявлено, що комунікація між шлюзом і клієнтами страждає від серйозного криптографічного недоліку. Зокрема, було виявлено, що процедура підключення між шлюзами Nym та клієнтами має наступні дані шифрування комунікації за допомогою AES-CTR і унікального, нестандартного ключа, разом із сталою нульовою nonce. Це, у свою чергу, ставить усе спілкування на ризик, якщо один звичайний витік до атакуючого, Оскільки це дозволяє зловмиснику зламати шифрування за допомогою простих операцій XOR між зашифрованими текстами та просоченим текстом.

Хоча конфіденційність даних, що передаються між клієнтом і шлюзом, під загрозою лише у випадку витоку простого тексту, ми повністю усвідомлюємо серйозність цієї проблеми. Команда Nym оперативно відреагувала, замінивши шифрування AES-CTR на рекомендовану схему AES-GCM-SIV, що значно підвищило безпеку комунікацій у версії 2024.12-aero.

NYM-01-030 WP3: Шлюз пропускає перевірку серійного номера облікових даних (Критично)

Відсутність перевірки номерів серійних свідоцтв на рівні шлюзу не компрометує безпеку системи, оскільки протокол zk-nyms заснований на офлайн e-cash моделі, яка у своїй основі спроектована для виявлення та запобігання повторним витратам. У схемах онлайн-електронних грошей постачальники підтримують постійне з'єднання з центральним органом (наприклад, банком або блокчейном) і перевіряють серійні номери в реальному часі перед прийняттям платежу. Якщо це буде застосовано до NymVPN, це означає, що шлюзи активно перевірятимуть серійні номери облікових даних під час проведення транзакцій. На відміну від цього, офлайн електронні гроші усувають необхідність в постійному з'єднанні — постачальники можуть приймати платежі та здійснювати їх внесення пізніше, з криптографічною гарантією того, що будь-яка спроба подвійного витрачання буде виявлена під час перевірки транзакцій. Протокол zk-nyms дотримується цієї офлайн-моделі електронних грошей, що забезпечує те, що навіть без перевірки локальних серійних номерів на шлюзі, валідатори nym-API все ще можуть виявляти та запобігати повторним витратам, коли квитки перевіряються. Це означає, що перевірка серійного номера на шлюзі не є обов'язковою для безпеки. Однак локальні перевірки на шлюзі можуть забезпечити додатковий рівень раннього виявлення, покращуючи швидкість ідентифікації спроб подвоєного витрачання в межах одного шлюзу. Хоча такі перевірки можуть підвищити ефективність, вони не є необхідними для основної безпеки протоколу. Криптографічні гарантії, вбудовані в протокол zk-nyms, забезпечують надійне виявлення повторних витрат на пізнішому етапі, що дозволяє виявляти та вносити в чорний список будь-яких зловмисників. У результаті перевірки повторного витрачання на шлюзі слід вважати не обов'язковою вимогою безпеки, а додатковим ефективним покращенням.

Більше того, у нашій системі кожен zk-nym обліковий запис має фіксовану дату закінчення терміну дії, що наразі встановлена на один тиждень. Після цього періоду прострочені облікові дані більше не приймаються вузлами входу мережі. Цей механізм закінчення терміну дії додатково обмежує вплив будь-яких спроб подвійних витрат, гарантуючи, що система залишається захищеною навіть без перевірки серійних номерів на рівні шлюзу.

NYM-01-032 WP3: Параметри фільтра Блума дають помилкові спрацьовування (Високий)

Ми відзначаємо, що ця частина коду перебувала в активному розвитку і не використовувалася в додатку NymVPN під час аудиту. Надані параметри були чисто для тестових цілей. Як пояснено в NYM-01-030 WP3, фільтри Блума було додано як додаткову перевірку на повторні витрати. Однак, оскільки наш протокол спочатку обробляє подвійні витрати по-іншому, і фільтри Блума генерували надто багато накладних витрат (оскільки нам потрібно було синхронізувати їх між шлюзами та nym-api), ми вирішили їх видалити.

Окрім цих надзвичайно важливих питань, аудит також виявив кілька вразливостей середнього рівня важкості, зокрема пов'язаних з потенційними векторами атак типу відмова в обслуговуванні (DoS). Ці висновки підкреслюють області, в яких бекенд NymVPN може покращити свою стійкість до перебоїв у службі. Ми плануємо вирішити це в рамках нашої дорожньої карти на 2025 рік.

В цілому, API та компоненти бекенду продемонстрували достойний рівень безпеки, при цьому вразливості в основному були обмежені конкретними випадками або можливостями для зміцнення.

WP4: Тести безпеки Crystal-box та аудити вихідного коду програмного забезпечення та інфраструктури Nym VPN

WP4 включав всебічну оцінку безпеки програмного забезпечення NymVPN, зосереджуючись на:

• Основні функції: обробка протоколів, шифрування, управління мережею, вирішення DNS та реалізація маршрутизації IP, тунельного з'єднання та загальна інтеграція мережевих стеків.
• Інтеграція фронтенду: UI на базі Tauri було оцінено за дизайном, зручністю використання та ефективною інтеграцією з ядром Rust через FFI, а також за специфічною для платформи продуктивністю на Windows, macOS і Linux.
• Ключові заходи безпеки: Безпечне зберігання облікових даних, запобігання витокам, управління ключами та зменшення відомих вразливостей VPN.

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

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

Під час аналізу WP4 не було виявлено жодних вразливостей, і програмне забезпечення NymVPN було підтверджено як таке, що демонструє відмінну безпеку.

WP5: Тестування безпеки Crystal-box і аудити вихідного коду щодо криптографії Nym

WP5 зосередився на ретельній оцінці криптографії, що використовується на платформі Nym. До цього входили ключові компоненти, такі як ящик з кокосами, ящик zk-nyms (еконіміка), протокол Sphinx, протокол Outfox та інші звичайно використовувані криптографічні примітиви. Вихідний код усіх криптографічних схем, написаний повністю на Rust, отримав похвалу за свою чудову організацію, що дозволяє аудиторам швидко ознайомитися з реалізацією.

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

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

NYM-01-009 WP5: обход підпису EC BLS12-381 в бібліотеці Coconut (Критично)

Cure53 зауважив, що функція verify_partial_blind_signature призначена для перевірки часткових сліпих підписів на етапі випуску задачі, не включає в себе всі необхідні перевірки наданого підпису, потенційно нападник дозволяє обійти перевірку підпису використовуючи безкінечні точки на еліптичній кривій. Однак ми хочемо уточнити, що в рамках протоколу Coconut функція, яка перевіряє витрати облікових даних, включає необхідні перевірки та надійно відхиляє недійсні облікові дані. У результаті, враховуючи дизайн протоколу, будь-яка спроба атаки буде безуспішною, оскільки підроблені облікові дані виявляються і відкидаються на наступному етапі. Це забезпечує безпеку та цілісність системи на практиці.

Зважаючи на це, ми визнаємо, що додаткові перевірки, запропоновані Cure53, можуть підсилити надійність цих функцій, якщо вони будуть використовуватися поза специфічним контекстом Coconut. Оскільки наш код є відкритим вихідним кодом, і ми прагнемо забезпечити повторно використовувані компоненти для ширшої спільноти, ми реалізували рекомендовані перевірки підпису для точок безкінечності як додаткову запобіжну міру в випуску 2024.13-magura. Це забезпечує надійне використання функцій в інших контекстах при збереженні найвищих стандартів безпеки.

NYM-01-014 WP5: Часткове обійдення підпису в офлайн eCash (Критично)

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

Проте, як і у випадку з Coconut, ми проактивно впровадили додаткові перевірки підписів, рекомендовані Cure53, в усіх відповідних функціях у версії 2024.13-magura. Хоча ці перевірки не були обов'язковими для забезпечення наявного потоку протоколу, вони підвищили надійність коду та забезпечили можливість надійного повторного використання цих функцій у інших контекстах. Цей підхід підкреслює нашу відданість збереженню високих стандартів безпеки, як для нашої системи, так і для ширшої спільноти відкритого коду.

NYM-01-033 WP5: Підпис фальсифікації схеми Pointcheval-Sanders (Критично)

Cure53 виявив вразливість у нашій реалізації функції підпису в рамках схеми підпису Pointcheval-Sanders. Зокрема, вразливість виникає тому, що в нашій реалізації випадкове значення h у парі підпису (h, s) не вибирається випадковим чином. В результаті, якщо ми підпишемо лише публічні атрибути, підпис може бути підроблений.

Однак важливо підкреслити, що ця вразливість підробки підпису не становить жодного ризику в контексті протоколів Coconut або e-cash. Обидва ці ці протоколи спираються на приватні атрибути за задумом, тому використовують процес сліпого випуску для обчислення підпису. У протоколі сліпої видачі використання зобов'язання до повідомлень як вхідних даних для хеш-функції забезпечує генерування унікальних значень для h різними кортежами повідомлень. У результаті вразливість проявилася б лише у випадку, якщо протоколи Coconut або e-cash використовувалися лише з публічними атрибутами, що не є випадком у мережі Nym. Отже, ризик, виявлений Cure53, не стосується нашої системи, оскільки використовувані протоколи по своїй суті пом'якшують цю проблему.

NYM-01-042 WP5: Неправильна агрегація до недійсних офлайн-електронних підписів (Критично)

Ця проблема схожа на проблеми NYM-01-009 і NYM-01-014, де автономна функція агрегації для підписів може призвести до недійсної підписи, якщо супротивник зможе маніпулювати частковими підписами, щоб отримати точку безмежності. Проте, у протоколах Coconut та e-cash процес перевірки явно відхиляє будь-який підпис, який призводить до безкінечної точки, тому це питання не compromise безпеки чи цілісності будь-якого з протоколів. Тим не менш, відповідно до дій, вжитих для питань NYM-01-009 та NYM-01-014, ми впровадили додаткові перевірки у функцію агрегації, щоб додатково зміцнити нашу кодову базу і запобігти можливому зловживанню в інших контекстах (https://github.com/nymtech/nym/blob/nym-binaries-v2024.13-magura/CHANGELOG.md).

NYM-01-005 WP5: Перевірка точок безмежності не виявляє відкритий текст для ElGamal (Високий)

Поточна реалізація Coconut та електронних грошей не використовує шифрування ElGamal (і воно не використовувалося під час аудиту). Натомість ми використовуємо більш ефективні зобов'язання Педерсена, які не мають тих же ризиків. Отже, проблема, пов'язана з ElGamal, не становила жодних загроз безпеці в нашій існуючій системі. Ми також прибираємо кококосовий ящик, а отже, і схему ElGamal.

Останні слова

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