Kompromitacija TLD registra: Kako su napadači došli do lažnih TLS sertifikata za Google bez probijanja njegovih servera

Svet sajber bezbednosti nedavno je potresao ozbiljan incident u infrastrukturi javnih ključeva (PKI) i sistema imena domena (DNS). Napadači su uspeli da pribave kriptografski važeće TLS/SSL sertifikate za Google i druge globalne gigante, a da pri tom nisu morali da hakuju same Google servere niti da kompromituju sertifikaciona tela (CA).

Vezivna karika ove kompromitacije leži u samom vrhu DNS hijerarhije — u registrima nacionalnih domena najvišeg nivoa (ccTLD). Napad je naglasio sistemske ranjivosti savremenog interneta i ponovo pokrenuo rasprave o bezbednosti infrastrukture na kojoj počiva bezbedna HTTPS komunikacija.

Šta se dogodilo?

Incident je u oktobru 2026. godine obelodanio Google-ov tim za bezbednost, a detalje su ubrzo preneli Ars Technica, Help Net Security, SC Media i brojni nezavisni analitičari.

Napadači su preuzeli kontrolu nad registrima tri nacionalna domena (ccTLD):

.gh (Gana)

.sl (Sijera Leone)

.as (Američka Samoa)

Registar TLD-a (Top-Level Domain Registry) predstavlja ključnu bazu podataka i infrastrukturu koja upravlja svim domenima unutar te ekstenzije. Nakon što su upali u sisteme ovih registara, napadači su izmenili autoritativne DNS zapise (Name Server-e) za odabrane domene pod tim TLD-ovima koji pripadaju Google-u i drugim velikim tehnološkim kompanijama.

Pomoću preusmerenog DNS saobraćaja, napadači su izveli Domain Control Validation (DCV) provjeru i od legitimnih sertifikacionih tela zatražili i dobijali važeće TLS sertifikate.

Anatomija napada: Korak po korak

Da bismo razumeli težinu ovog napada, moramo proanalizirati kako funkcioniše izdavanje TLS sertifikata i gde se tačno desio propust.

[ Napadači ] ──( Kompromitacija )──> [ ccTLD Registar (.gh, .sl, .as) ]

                                                     │

                                           (Izmena DNS zapisa)

                                                     ▼

[ Sertifikaciono Telo (CA) ] ──( DCV Izazov )──> [ Lažni DNS Server ]

            │                                        │

    (Provera prošla)                            (Potvrda vlasništva)

            ▼

[ Važeći TLS Sertifikat ] ──( Izdat napadaču )

1. Hakovanje na nivou registra (TLD Registry Compromise)

Svaki internet domen pripada određenom registru (npr. .com vodi Verisign, dok nacionalne ekstenzije poput .rs, .gh ili .as vode lokalne organizacije). Kada kompanija poput Google-a registruje domen kao što je google.com.gh ili google.as, zapisi o tome ko usmerava saobraćaj nalaze se na serverima imena tog registra. Napadači nisu napali Google, već administraciju ovih ccTLD registara, čime su dobili „ključeve od kapije“ za sve domene pod tim ekstenzijama.

2. Preusmeravanje DNS autoriteta

Nakon što su dobili pristup registrima, napadači su promenili delegaciju autoritativnih servera imena za ciljane domene. Na taj način su sav saobraćaj i sve DNS upite za te domene preusmerili na servere pod svojom kontrolom.

3. Zloupotreba DCV procesa (Domain Control Validation)

Sertifikaciona tela (CA) pre izdavanja TLS sertifikata moraju da provere da li podnosilac zahtevaista zaista kontroliše domen. Najčešće metode validacije su:

Postavljanje specifičnog DNS TXT zapisa na serveru imena domena.

Postavljanje specifičnog fajla na HTTP web serveru na koji domen pokazuje.

S obzirom na to da su napadači kontrolisali autoritativni DNS, na DCV izazov koji je uputilo sertifikaciono telo odgovorili su bez ikakvih problema. Iz ugla CA, sve je izgledalo 100% legitimno: zahtev je stigao, DNS je proveren, provera je prošla.

4. Izdavanje važećeg, poverljivog sertifikata

Sertifikaciona tela su izdala potpisane TLS sertifikate za date domene. Ovi sertifikati su bili zakonski i tehnički potpuno ispravni, povezani sa javno priznatim korerenskim (Root) sertifikatima.

Koje su posledice izdatih lažnih sertifikata?

Kada napadač poseduje važeći TLS sertifikat i kontrolu nad DNS-om, može izvesti izuzetno napredne napade koji su nevidljivi za prosečnog korisnika:

Napad čoveka u sredini (Man-in-the-Middle – MitM): Napadač može presretati HTTPS saobraćaj izmedu korisnika i servisa. Pošto je sertifikat važeći, pregledač (browser) neće prikazati nikakvo upozorenje o nebezbednoj vezi (nema crvenog katanca niti upozorenja).

Krađa poverljivih podataka: Lozinke, kolačići sesija (session cookies), API ključevi i lični podaci mogu biti dekriptovani u realnom vremenu na serveru napadača.

Impersonacija servisa (Spoofing): Napadači mogu kreirati identične kopije Google servisa, pristupati e-pošti, finansijskim i drugim osetljivim podacima.

Kako su reagovali Google i industrija?

Srećom, savremeni PKI ekosistem raspolaže mehanizmima detekcije koji su omogućili brzo uočavanje incidenta.

Certificate Transparency (CT) logovi: Sva javna sertifikaciona tela obavezna su da sve izdate sertifikate upišu u javno dostupne, nepromenjive registre (CT logove). Google-ovi automatizovani sistemi za nadzor CT logova primetili su izdavanje neočekivanih sertifikata za njihove domene pod .gh, .sl i .as ekstenzijama i odmah podigli uzbunu.

Ažuriranje Google Chrome-a: Google je ekspresno objavio sigurnosno ažuriranje za svoj preglednik Chrome. Ugrađena je blokada (revokacija/pinning) za identifikovane sporne sertifikate.

Koordinacija sa industrijskom zajednicom: Google je stupio u kontakt sa ostalim proizvođačima pregledača (Firefox, Apple, Microsoft) i sertifikacionim telima kako bi se izdatim sertifikatima oduzela punovažnost (revokacija putem CRL/OCSP) i osiguralo da se zahvaćeni DNS zapisi očiste.

Zbog čega je ovaj incident sistemski alarm?

Stručnjaci za sajber bezbednost naglašavaju da je ovaj slučaj znatno opasniji od uobičajenih hakovanja pojedinačnih sajtova.

Podsećanje na DigiNotar (2011)

Neki mediji i analitičari uporedili su ovaj događaj sa čuvenim slučajevima poput pada holandskog CA DigiNotar 2011. godine. Međutim, postoji ključna razlika: kod DigiNotara je bilo hakovano samo sertifikaciono telo. U incidentu iz 2026. godine, sertifikaciona tela nisu napravila nikakvu grešku u proceduri. Sistem verifikacije je uradio tačno ono za šta je dizajniran — proverio je DNS i izdao sertifikat. Problem je bio u najvišem sloju iznad samih vlasnika domena i CA — u ccTLD registrima.

Problem geografskih i manjih TLD registara

Nacionalni registri manjih država često nemaju bezbednosne budžete, infrastrukturu niti resurse na nivou velikih komercijalnih registara poput Verisign-a (.com) ili PIR-a (.org). Ipak, u globalnoj DNS hijerarhiji, ako napadač kompromituje .as ili .gh, on može kompromitovati bilo koji domen registrovan pod tom ekstenzijom, bez obzira na to koliko je vlasnik domena moćan.

Koje mere zaštite kompanije moraju da preduzmu?

Ovaj incident donosi važne pouke za sve organizacije koje upravljaju domenima i web infrastrukturom:

Aktivno praćenje Certificate Transparency (CT) logova:

Vlasnici domena ne smeju pretpostavljati da će CA uvek uočiti prevaru. Upotrebom alata za monitoring CT logova (poput Cert Spotter-a ili besplatnih servisa poput crt.sh), organizacije dobijaju obaveštenje u realnom vremenu čim se za njihov domen izda bilo kakav sertifikat bilo gde u svetu.

Postavljanje restriktivnih CAA (Certification Authority Authorization) zapisa:

CAA zapisi u DNS-u određuju koja tačno sertifikaciona tela imaju dozvolu da izdaju sertifikate za određeni domen. Iako napadač sa kontrolom nad DNS-om teoretski može obrisati CAA zapis, postojanje i striktno podešavanje ovog zapisa stvara dodatnu prepreku i smanjuje prozor za zloupotrebu kod re-validacije.

Prikivanje sertifikata (Certificate Pinning) u aplikacijama:

Mobilne i desktop aplikacije (kao i pregledači za sopstvene domene) treba da koriste Certificate/Public Key Pinning, gde aplikacija veruje samo unapred definisanim ključevima, a ne bilo kom važećem sertifikatu koji je izdalo bilo koje sertifikaciono telo.

Registarska zaključavanja (Registry Lock):

Za ključne domene treba aktivirati funkciju Registry Lock, koja onemogućava bilo kakve izmene DNS zapisa ili prenos domena bez višefaktorske vanmrežne (offline) verifikacije sa samim registrom.

Zaključak

Incident sa neovlašćenim izdavanjem TLS sertifikata za Google domene kroz kompromitaciju .gh, .sl i .as registara predstavlja podsetnik da je internet bezbedan onoliko koliko je bezbedna njegova najslabija karika.

Iako su Google-ove brze reakcije i ugrađeni mehanizmi nadzora ublažili rizik po krajnje korisnike, događaj je pokazao da zaštita samih web servera više nije dovoljna. Bezbednost domena na nivou TLD registara i neprekidno praćenje PKI ekosistema ostaju ključni prioriteti za očuvanje poverenja u globalnu mrežu.