Kibernetska varnost in napadi
POTRDILO ZA TUJO DOMENO
Po prevzemu domenske infrastrukture ostaneta dve ločeni nalogi: obravnava že izdanih potrdil in omejitev nadaljnjega izdajanja po povrnitvi DNS.
Google je 6. oktobra 2026 opisal prevzeme domenske infrastrukture v vrhnjih domenah .gh, .sl in .as. Napadalci so spremenili avtoritativne zapise sistema domenskih imen oziroma DNS ter pridobili nepooblaščena potrdila HTTPS za več Googlovih domen in domene drugih organizacij. Po Googlovi navedbi njegovi sistemi niso bili kompromitirani, pri izdajateljih prizadetih potrdil pa ni imel razloga domnevati nepravilnega ravnanja. [1]
Po takšnem posegu je razumljiv prvi cilj: domeno spet usmeriti na pravo infrastrukturo. Toda povrnitev DNS še ne prekliče potrdila, izdanega med prevzemom. Pri izdajatelju lahko ostane tudi veljavna avtorizacija, nastala ob prejšnjem preverjanju domene, ki jo je pod določenimi pogoji mogoče uporabiti za novo naročilo. [1, 2] S tem se posledice incidenta razširijo prek časa, v katerem je napadalec spreminjal zapise.
Pot do izdaje vodi skozi DNS
DNS med drugim določa, kam vodi spletno domensko ime, vsebuje pa tudi podatke za druge naloge. Pri izdaji potrdil se lahko uporablja za dokazovanje nadzora nad domeno: izdajatelj zahteva objavo določene vrednosti in preveri, ali jo prosilec zna objaviti na pravem mestu. Pri tem uporablja avtoritativne odgovore, torej odgovore infrastrukture, pristojne za podatke zadevne domene. Dostop do te infrastrukture lahko vpliva na izdajo potrdila, četudi prvotni spletni strežnik ostane nedotaknjen. [3]
Pri domensko preverjenem oziroma DV-potrdilu izdajatelj preverja učinkovit nadzor nad domenskim imenom. Pri tem mu ni treba preverjati dejanske identitete osebe ali organizacije, ki potrdilo naroča. Protokol ACME omogoča avtomatizacijo preverjanja in izdaje, tako da pridobivanje ter obnavljanje potrdil potekata brez vsakokratnega ročnega posredovanja. [2]
Konkreten primer je DNS-01. Prosilec objavi zahtevano vrednost v zapisu TXT pod imenom _acme-challenge.<domena>, izdajatelj pa preveri ujemanje. Let’s Encrypt pojasnjuje tudi možnost delegiranja takšnega preverjanja v drugo cono DNS. Ponudnik, ki upravlja zapise, in registrar, pri katerem je domena registrirana, sta lahko različni organizaciji. [3] Pooblastila za delegirano preverjanje so del tega nadzora, četudi jih v računu za upravljanje spletnega gostovanja ne vidimo.
V poenostavljenem, hipotetičnem primeru napadalec za nekaj časa pridobi možnost spreminjanja ustreznih odgovorov DNS. Z novim parom ključev zaprosi za potrdilo in prek DNS opravi zahtevano preverjanje. Če izpolni še druge pogoje izdajatelja, lahko dobi potrdilo za domensko ime podjetja, čeprav naročila ni oddalo podjetje. Zasebni ključ izvirnega spletnega strežnika pri tem ni potreben, saj potrdilo povezuje domeno z drugim javnim ključem. [2, 3] Googlova objava ne navaja vseh uporabljenih metod preverjanja, zato ta primer ni rekonstrukcija natančne izvedbe opisanih napadov. [1]
Za uporabo potrdila pri lažnem predstavljanju mora napadalec doseči še, da se uporabnik poveže z njegovim strežnikom. Odjemalec preverja ujemanje imena storitve s potrdilom in druge pogoje zaupanja. Pri avtentikaciji s potrdilom v TLS 1.3 strežnik s podpisom dokaže tudi posedovanje pripadajočega zasebnega ključa. [4, 5] Pridobljeno potrdilo samo zase ne dokazuje preusmeritve ali prestrezanja prometa.
Kaj ostane, ko se povezave vrnejo
Ko so zapisi DNS popravljeni, lahko nove povezave znova dosežejo predvideno storitev. Če napadalec do svojega strežnika ne more več pripeljati povezave, mu posedovanje potrdila ne zagotovi nadaljnjega dostopa do uporabniškega prometa. Pri izdajatelju pa potrdilo s tem še ni preklicano, zato ostane predmet obravnave tudi po povrnitvi DNS. [1, 2]
Pri izdajatelju je lahko za napadalčev račun še vedno shranjena veljavna avtorizacija, nastala ob uspešnem preverjanju nadzora nad domeno. V protokolu ACME je takšno stanje ločeno od posameznega potrdila. RFC 8555 predvideva, da se pri naročilu upoštevajo tudi avtorizacije, opravljene ob prejšnjih naročilih ali v predhodnem postopku. [2]
Napadalec bi lahko med prevzemom uspešno opravil preverjanje, novo naročilo pa oddal šele po povrnitvi DNS. Če bi izdajatelj še smel uporabiti veljavno avtorizacijo in bi naročilo prestalo aktualne kontrole izdaje, ponovno spreminjanje DNS ne bi bilo nujno potrebno. Avtorizacija ima svoj rok veljavnosti, RFC 8555 pa predvideva tudi njeno deaktiviranje in preklic. Možnost nadaljnjega izdajanja je časovno omejena ter odvisna od pravil izdajatelja in kontrol ob novem naročilu. [2]
Organizacija pri tem ne more izhajati samo iz podatkov svojega običajnega računa za izdajo potrdil. Napadalec je lahko uporabil drug račun, avtorizacija ACME pa je vezana na račun, s katerim je bilo preverjanje opravljeno. [2] Pri izdajatelju je treba razjasniti, katera naročila temeljijo na spornem preverjanju, ali je to še veljavno in kateri ukrep preprečuje njegovo nadaljnjo uporabo. Odgovor o preklicu posameznega potrdila naj bo v evidenci ločen od odgovora o stanju avtorizacije.
Dovoljeni izdajatelj še ne določa računa
Zapisi CAA omogočajo imetniku domene določiti, kateri izdajatelji smejo zanjo izdajati potrdila. Izdajatelj jih preverja kot del postopka pred izdajo, brskalnik pa jih po RFC 8659 ne uporablja za preverjanje že izdanega potrdila. Nova politika CAA ne razveljavi potrdila, ki je že bilo izdano. [6]
Podjetje in napadalec imata lahko vsak svoj račun pri istem izdajatelju. Dovoljenje temu izdajatelju zato še ne določa, kateri račun sme zahtevati potrdilo. Parameter accounturi omogoča omejitev izdaje na določen račun, validationmethods pa omejitev metod, s katerimi se sme preverjati nadzor nad domeno. [7]
Učinkovitost obeh parametrov je odvisna od podpore izdajatelja. Standard izrecno opozarja, da je skrbnik ne sme predpostaviti zgolj zato, ker je parameter zapisal v DNS. [7] Let’s Encrypt oba parametra dokumentira in podpira. Pri njem je URI računa določen spletni naslov z identifikatorjem računa, zato v politiko ne vpisujemo poljubnega imena iz svoje evidence, temveč ustrezni URI izdajatelja. [8]
Praktična past je dodajanje strožjega zapisa ob obstoječega, ki istemu izdajatelju še vedno dovoljuje izdajo brez omejitve na račun. Več zapisov CAA z lastnostjo issue pomeni alternativna dovoljenja. Če eden dovoljuje izdajo brez takšne omejitve, drugi, strožji zapis tega dovoljenja ne odvzame. [6, 8] Pregledati je treba celoten ustrezni nabor pravil, saj prisotnost novega parametra v eni vrstici še ne pove, kaj dopuščajo preostale.
Po povrnitvi DNS lahko ustrezna politika pri podprtem izdajatelju omeji izdajo na odobrene račune in s tem prepreči naročila drugih računov na podlagi prejšnjega preverjanja. [7] Med aktivnim prevzemom ima takšna zaščita mejo: če napadalec spreminja tudi odgovore za CAA, lahko poseže v objavljeno politiko. [6]
Omejitev na račun zahteva poznavanje dejanske izdaje. Potrdila lahko za organizacijo obnavljajo ponudnik gostovanja, upravljavec dostavnega omrežja ali druga storitev, vsak s svojim računom. Pred spremembo je treba ugotoviti, kateri računi morajo ostati dovoljeni, in preveriti običajno obnovitev. Napačno določena politika lahko zavrne tudi legitimno zahtevo, na kar opozarja RFC 8657. [7]
Pomembne so tudi poddomene. Pri iskanju pravil CAA je odločilen najbližji ustrezni zapis, zato lahko poddomena uporablja drugačno politiko od nadrejene domene. [8] Omejitve na vrhu domene niso zadosten podatek o pravilih za vsako posamezno storitev. Pri domeni, ki jo uporabljajo različni ponudniki, lahko prav takšna razlika pojasni, zakaj je eno naročilo dovoljeno, drugo pa zavrnjeno.
Kaj lahko pokaže javni dnevnik
Pri iskanju nepričakovanih izdaj pomaga Certificate Transparency oziroma CT. Javni dnevniki omogočajo vpogled v potrdila in predpotrdila, nadzorni sistemi pa spremljajo nove zapise za izbrane domene. Predpotrdilo vsebuje podatke o predvidenem potrdilu, vendar ima posebno razširitev, zaradi katere ga odjemalec ne sprejme kot običajno strežniško potrdilo. Njegova vloga je del postopka evidentiranja izdaje. [9]
Google priporoča spremljanje celotnega portfelja domen, tudi parkiranih in regionalnih. [1] Seznam samo trenutno najbolj obiskanih spletnih strani lahko izpusti imena, za katera je še vedno mogoče naročiti potrdilo. Pri pregledu organizacije je zato pomembna evidenca domen, ki jih upravlja, ne zgolj seznam aktivnih spletnih storitev.
Zapis v CT sam ne dokazuje, da je bilo potrdilo nameščeno na strežniku ali uporabljeno v povezavi z uporabnikom. Opozori na izdajo oziroma predpotrdilo, ki ga je treba povezati z naročilom. Tudi nepričakovan zapis lahko pripada legitimnemu zunanjemu ponudniku, ki za organizacijo obnavlja potrdila.
Za obravnavo opozorila je koristno povezati domensko ime, javni ključ, izdajatelja, čas in vrsto zapisa s podatki o naročilu. Pri izdajatelju se razjasnijo okoliščine naročila in preverjanja, upravljavec storitve pa potrdi, ali izdaja pripada dogovorjenemu obnavljanju. Takšna razdelitev vprašanj prepreči, da bi splošna potrditev ponudnika gostovanja veljala tudi za vsa druga potrdila iste domene. Za ugotavljanje dejanske uporabe bi potrebovali še dokaze o strežniku ali povezavah, pri predpotrdilu pa podatek o stanju končnega potrdila.
Časovna primerjava zahteva nekaj previdnosti. Potrdilo ima obdobje veljavnosti, zapis v dnevniku svoj čas, izdajatelj pa podatke o naročilu in preverjanju. Teh časov ni smiselno združiti v eno samo oznako začetka dogodka. Pri pregledu morebitne izdaje po povrnitvi DNS je posebno pomembno, kdaj je bilo opravljeno preverjanje, na katerem novo naročilo temelji. [2, 9]
Google je v opisanih incidentih nepooblaščena potrdila blokiral v Chromu z mehanizmom CRLSets ter z izdajatelji sodeloval pri njihovem preklicu. Opozoril je, da ne more zagotoviti odkritja vseh prizadetih domen in da posegi v Chromu ne zagotavljajo zanesljive zaščite drugih odjemalcev. [1] Dokumentacija Chromiuma CRLSets opisuje kot način hitrega blokiranja potrdil v nujnih primerih. [10]
Tri različna stanja istega incidenta
Ob koncu obravnave se združijo tri evidence. Prva opisuje poseg v DNS in ponovno vzpostavitev upravljanja, druga nepooblaščena potrdila in njihovo obravnavo pri izdajateljih. Tretja zajema avtorizacije in omejitve nadaljnjega izdajanja. Njihovi časovni poteki se ne končajo nujno hkrati, zato tudi odgovori o stanju incidenta ne morejo temeljiti na enem samem preizkusu povezave.
V poročilu je smiselno za vsako prizadeto ime povezati čas povrnitve DNS, ugotovljena nepooblaščena potrdila in potrjene omejitve nadaljnje izdaje. Kar pri izdajatelju še ni razjasnjeno, ostane odprta ugotovitev z določenim odgovornim za nadaljnjo obravnavo. Tako je razvidno, na podlagi katerih podatkov je posamezen del incidenta zaključen in kaj še čaka na odgovor.
EVIDENCE PROFILE
Dokazni profil članka
Profil pokaže vrsto dokazne podlage in omejitve osrednjega argumenta.
Viri
- 01PRIMARY DOCUMENTATIONChrome Secure Web and Networking TeamChrome’s Response to Recent ccTLD Registry Hijacks
6. oktober 2026.
Odpri vir ↗ - 02STANDARDBarnes, R., Hoffman-Andrews, J., McCarney, D., in Kasten, J.RFC 8555: Automatic Certificate Management Environment (ACME)
Marec 2019; zlasti razdelki 1, 2, 7.1.3, 7.1.4, 7.1.6, 7.5, 7.5.2 in 8.4.
Odpri vir ↗ - 03PRIMARY DOCUMENTATIONLet’s EncryptChallenge Types
Dokumentacija, posodobljena 12. februarja 2026; razdelek DNS-01 challenge.
Odpri vir ↗ - 04STANDARDSaint-Andre, P., in Salz, R.RFC 9525: Service Identity in TLS
November 2023; zlasti razdelek 6.
Odpri vir ↗ - 05STANDARDRescorla, E.RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
Avgust 2018; zlasti razdelka 4.4.2 in 4.4.3.
Odpri vir ↗ - 06STANDARDHallam-Baker, P., Stradling, R., in Hoffman-Andrews, J.RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record
November 2019; zlasti razdelki 1, 3 in 5.
Odpri vir ↗ - 07STANDARDLandau, H.RFC 8657: Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding
November 2019; zlasti razdelki 3, 4 in 5.2–5.8.
Odpri vir ↗ - 08PRIMARY DOCUMENTATIONLet’s EncryptCertification Authority Authorization (CAA)
Dokumentacija, posodobljena 4. oktobra 2026.
Odpri vir ↗ - 09PRIMARY DOCUMENTATIONCertificate TransparencyHow CT Works
Dokumentacija o potrdilih, predpotrdilih in spremljanju dnevnikov.
Odpri vir ↗ - 10PRIMARY DOCUMENTATIONThe Chromium ProjectsCRLSets
Dokumentacija o blokiranju potrdil v Chromu.
Odpri vir ↗