Un certificat TLS configurat greșit expune infrastructura VPN Hangro a Coreei de Nord

Platforma VPN Hangro a Coreei de Nord — folosită pentru a conecta oficiali și reprezentanți comerciali aflați în străinătate cu sisteme din interiorul țării — și-a expus o parte neobișnuit de detaliată din propria infrastructură printr-o greșeală de bază la nivel de certificat.

Ce s-a întâmplat

Un certificat TLS asociat serviciului de management Hangro (port 6006) enumera cinci adrese IP publice: trei în Coreea de Nord și două în Extremul Orient rusesc. Certificatul includea și adresa 100.100.100.170, care aparține unui spațiu NAT de tip carrier-grade și nu ar fi trebuit niciodată să apară într-un certificat public. Publicarea ei a dezvăluit practic o parte din planul de adresare internă al Hangro.

Același certificat de management a apărut pe toate cele cinci gazde — 175.45.176.21, 175.45.176.22, 175.45.176.32 în Coreea de Nord și 188.43.136.115, 188.43.136.116 în Rusia — ceea ce sugerează o infrastructură administrată în comun, deși cercetarea care stă la baza acestor date nu susține existența unui sistem central unic de control.

Analiștii au urmărit și o configurație mai veche a clientului Hangro până la o adresă IP din China, 218.25.43.212, înregistrată cu un contact tehnic asociat unei adrese de e-mail Silibank, mai multe intervale de rețea chinezești fiind legate de aceeași înregistrare. Acest lucru indică o prezență legată de Coreea de Nord în interiorul spațiului de adrese chinezesc — nu o proprietate chineză asupra infrastructurii nord-coreene.

De ce contează

Separat, serviciul mai nou de pe portul 6006 pare construit mai atent decât vechiul strat VPN și de mail al Hangro: finalizează integral un handshake TLS 1.3 și impune un certificat de client. Serviciile mai vechi, de pe porturile 465 și 7443, eșuează complet verificarea semnăturii — fiecare certificat din lanțul Hangro din 2024, inclusiv certificatul rădăcină, eșuează verificarea față de el însuși. Asta indică chei private care nu se potrivesc cu certificatele publice asociate.

În mod normal, un asemenea eșec ar bloca serviciul în orice client TLS funcțional. Însă clientul Hangro are, se pare, încredere în certificatele instalate direct din pachetul de instalare, în loc să valideze corect lanțul de semnătură — astfel platforma continuă să funcționeze, deși configurația certificatelor ar fi respinsă de orice browser, client de mail sau produs de securitate standard.

Nimic din toate acestea nu confirmă că Hangro a fost folosit într-o campanie de intruziune anume. Ce confirmă este o lecție cunoscută: reutilizarea certificatelor, gestionarea slabă a cheilor și metadatele de rețea expuse sunt adesea suficiente pentru a cartografia o infrastructură pe care operatorii au încercat să o țină privată — chiar și atunci când restricționează accesul prin certificate de client și porturi neobișnuite.

Ce e de făcut

• Configurați alerte pentru conexiuni către adresele IP și intervalele de rețea de mai jos și marcați orice hostname legat de Hangro în jurnalele DNS sau proxy.
• Verificați certificatele TLS de pe porturile 6006 și 6008 pentru amprentele listate și tratați orice potrivire ca demnă de investigat.
• Folosiți jurnalele certificate transparency, DNS pasiv și amprentarea handshake-ului pentru a depista infrastructură nouă, dacă operatorii relocă sau extind serviciul.
• Evitați atribuirea bazată pe un singur contact de înregistrare — tratați-l ca pe un singur indiciu într-un ecosistem de infrastructură DPRK mai larg, parțial partajat.

Indicatori cheie

Acest tip de expunere a infrastructurii este exact genul de descoperire pe care un program continuu de monitorizare a suprafeței de atac și a certificate transparency e construit să îl prindă din timp — cu mult înainte ca perimetrul propriu al unui client să fie cel care face greșeala.