O eroare de semnare în GoBalance permite recuperarea cheilor master ale adreselor .onion

O vulnerabilitate în GoBalance, un instrument de load balancing folosit pe scară largă de serviciile de pe dark web, poate expune cheia privată pe termen lung a unui site .onion folosind doar date publice. Cine recuperează cheia poate prelua adresa .onion a site-ului. Incidentul arată clar că o greșeală mică în codul criptografic poate avea urmări permanente.

Ce s-a întâmplat

GoBalance este o rescriere în Go a instrumentului Onionbalance de la Tor. Distribuie un serviciu ascuns pe mai multe servere, ca acesta să rămână accesibil în timpul atacurilor de tip denial-of-service, și vine inclus în setul anti-DDoS EndGame. Cercetătorii de la Searchlight Cyber au descoperit că GoBalance gestionează greșit cheia de semnare atunci când publică descriptorul serviciului, adică înregistrarea semnată pe care clienții Tor o descarcă pentru a ajunge la o adresă .onion.

Tor păstrează cheia privată Ed25519 a unui serviciu onion într-o formă extinsă de 64 de octeți. Prima jumătate este scalarul secret de semnare. A doua jumătate este valoarea secretă din care se derivă nonce-ul unic al fiecărei semnături. GoBalance transmitea semnatarului doar primii 32 de octeți și îi ignora pe ceilalți. Fără a doua jumătate, nonce-ul nu mai este secret și oricine îl poate calcula. Astfel, un singur descriptor publicat conține suficiente informații pentru a deduce cheia privată.

Pentru că este vorba de cheia master a site-ului, o cheie recuperată nu permite doar o impersonare de moment. Cu ea se pot semna descriptori valizi pentru mult timp de acum înainte, ceea ce înseamnă practic o preluare permanentă a adresei.

Cine este afectat

• Doar GoBalance. Potrivit cercetătorilor, Onionbalance original și Tor nu sunt afectate.
• Doar anumite formate de cheie. Problema apare când cheia master este stocată în formatul propriu al Tor. Cheile generate cu utilitarul de configurare GoBalance folosesc un format care nu este expus.
• Preluări reale. Între 5 și 7 octombrie, ambele adrese .onion ale forumului Dread au fost preluate și redirecționate către un site rival. Administratorii Dread au invocat inițial o eroare proprie, apoi au pus preluarea pe seama vulnerabilității GoBalance. Ei au mai spus că și alte servicii ascunse ar putea fi afectate și că serverele lor nu au fost compromise. Și piața Omega a anunțat că și-a scos adresele offline din cauza acestei erori. Încă nu se știe câte alte servicii au fost lovite.

Stadiul remedierii

La data de 9 octombrie nu exista niciun CVE și niciun aviz oficial din partea Tor Project sau a întreținătorului GoBalance. Dread a anunțat că va publica o versiune corectată. Un cercetător independent a publicat un patch și o dovadă de concept funcțională, care recuperează cheia master dintr-un singur descriptor public. Aceasta a fost testată doar pe chei generate special pentru test. Niciuna dintre ele nu este o versiune oficială, așa că verificați orice patch de la terți înainte de a-l folosi.

De ce contează

Este un exemplu clasic al cât de fragile devin schemele de semnătură când sunt implementate manual. Ed25519 este sigur prin design, dar numai dacă întreaga cheie extinsă ajunge la rutina de semnare. Trunchierea ei anulează garanția fără niciun semn vizibil, până când cheia este deja pierdută. Același tip de eroare poate apărea în orice wrapper personalizat pentru chei de semnare, fie că e vorba de cod de integrare cu HSM, de convertoare de formate de chei sau de instrumente interne, nu doar pe dark web.

Ce trebuie făcut

1. Dacă ați rulat o versiune afectată de GoBalance, considerați cheia compromisă. Un patch nu poate retrage descriptorii deja publicați. Generați o adresă onion nouă și migrați pe ea.
2. Anunțați noua adresă printr-un canal pe care utilizatorii îl pot verifica, de exemplu un mesaj semnat cu o cheie în care au deja încredere, și spuneți-le să nu mai folosească adresa veche.
3. Utilizatorii serviciilor afectate ar trebui să schimbe parolele folosite acolo și pe orice alt site unde le-au refolosit. O adresă nouă trebuie acceptată doar dacă vine cu un anunț semnat.
4. Auditați propriul cod de semnare. Verificați că wrapperele și convertoarele transmit cheia privată completă (inclusiv forma extinsă de 64 de octeți a Ed25519) către biblioteci verificate. Preferați API-urile standard în locul rutinelor de semnare construite manual.
5. Adăugați teste negative. Semnăturile pe mesaje diferite nu trebuie să refolosească niciodată un nonce, iar un test pe vectori de referință cunoscuți detectează trunchierea din timp.

Sursa: cercetare originală Searchlight Cyber, relatată de The Hacker News.