Kuidas riigikoodi kaaperdamine murdis interneti usaldusahela

Mäletan, kuidas istusin 2011. aastal aknutu andmekeskuses, kui tulid uudised DigiNotari kohta. Sel ajal võimaldas üksainus kompromiteeritud sertifitseerimiskeskus Hollandis ründajatel luua Google'i jaoks võltsitud tõendeid. See tundus kui veebi turvalisust tagava matemaatika fundamentaalne reetmine. Kerime aega edasi 2026. aasta lõppu ja tööstus tegeleb sama õudusunenäo uue versiooniga, kuigi sisenemispunkt on nihkunud. Mitme miljardi dollariline turvaaparaat sai lüüa digitaalse vaste poolt lukksepale, kes varastab väikelinna tööriistapoest peavõtmed.

Google kinnitas hiljuti, et ründajad kaaperdasid kolm riigikoodiga tippdomeeni (ccTLD): .gh (Ghana), .sl (Sierra Leone) ja .as (Ameerika Samoa). Saavutades kontrolli nende nimeruumide üle, muutsid osapooled autoriteetseid DNS-kirjeid konkreetsete väärtuslike sihtmärkide jaoks. See kontroll võimaldas neil mööda minna automatiseeritud valideerimiskontrollidest, mida sertifitseerimiskeskused kasutavad omandiõiguse kontrollimiseks. Tulemuseks oli volitamata TLS-sertifikaatide väljastamine mitmele Google'i domeenile ja teistele suurtele globaalsetele brändidele. See on kaasaegse turvalisuse arhitektuurne paradoks: ettevõte võib kulutada miljoneid nullusaldusele (zero trust) ja riistvaralistele turvavõtmetele, kuid selle digitaalne identiteet jääb ikkagi seotuks kauge registri administratiivse turvalisusega.

Domeenikontrolli möödapääsu mehaanika

Mõistmaks, miks see juhtus, peame vaatama, kuidas veebisait tõestab, kes ta on. Kui organisatsioon taotleb TLS-sertifikaati, peab väljastav sertifitseerimiskeskus (CA) kontrollima, kas taotleja tegelikult kontrollib domeeni. Selle tööstusharu standard on domeenikontrolli valideerimine (Domain Control Validation ehk DCV). CA palub taotlejal sooritada konkreetne ülesanne, näiteks majutada unikaalset faili kindlal URL-il või, mis on tavalisem, luua konkreetne DNS-kirje. Kui CA näeb autoriteetsetes nimeserverites õiget kirjet, väljastab ta sertifikaadi.

Selles intsidendis ei pidanud ründajad Google'isse sisse häkkima. Nad häkkisid TLD infrastruktuuri ennast. Kui nad kontrollisid .gh, .sl ja .as nimeservereid, suunasid nad sihtmärgiks olevate alamdomeenide DNS-kirjed oma serveritele. Kui CA viis läbi automatiseeritud kontrolli, andis ründajate server õige vastuse. CA järgis oma protokolli täiuslikult, kuid ta suhtles petturiga. Süsteem on digitaalne seif, mis töötab ainult siis, kui uksehoidja tegelikult teab, milline päris omanik välja näeb.

Miks brauserite blokid on ajutine lahendus

Google uuendas Chrome'i, et blokeerida need volitamata sertifikaadid viivitamatult. See on reaktiivne meede, mis kaitseb miljoneid kasutajaid, kuid see toob esile süsteemse nõrkuse. Sertifikaadi tühistamise protsess on teadaolevalt aeglane. Traditsioonilised meetodid, nagu sertifikaatide tühistamisloendid (CRL) või veebipõhine sertifikaadi staatuse protokoll (OCSP), ebaõnnestuvad sageli privaatsusprobleemide või võrgu viivituse tõttu. Seetõttu on brauseritootjad liikunud riistvaraliselt kodeeritud mustade nimekirjade poole, et pakkuda kohest kaitset.

Riski seisukohast on see sekkumine vaid plaaster. Google tunnistas, et Chrome'i sekkumised ei kaitse teiste brauserite kasutajaid, samuti ei saa ettevõte olla kindel, et tuvastas kõik mõjutatud domeenid. Kui ründajal on kehtivalt allkirjastatud sertifikaat, mida brauser pole veel blokeerinud, saavad nad läbi viia vahendajaründe (man-in-the-middle). Nad saavad liiklust pealt kuulata, tundlikke andmeid dekrüpteerida ja kuvada ohvrile "turvalist" tabaluku ikooni. Ühenduse terviklikkus on kadunud ja kasutajal pole võimalust vahet teha.

Ettevõtte võrgu tumeaine

DNS on sageli ettevõtte turvalisuse tumeaine. See on nähtamatu, kõikehõlmav ja sageli tähelepanuta jäetud, kuni midagi katki läheb. Paljud organisatsioonid käsitlevad oma TLD-suhteid lihtsa arveldamise küsimusena, mitte kriitilise tähtsusega turvasõltuvusena. Kui registreerite domeeni riigikoodiga tippdomeeni (ccTLD) all, usaldate selle riigi registri turvalisust, nende valitsuse stabiilsust ja nende tehnilist vastupidavust.

Vaadates ohumaastikku, näitab see intsident, et ründajad liiguvad tarneahelas ülespoole. Tugevdatud perimeetri ründamise asemel sihivad nad interneti tuuminfrastruktuuri detsentraliseeritud komponente. Rikkumine TLD tasemel on salajane, sest see ei käivita sisemisi häireid. Organisatsiooni serverid on korras, töötajad ei klõpsa õngitsuslinkidele ja tulemüür on vaikne. Ometi võltsitakse brändi identiteeti mujal.

Sertifitseerimiskeskuse autoriseerimise (CAA) rakendamine

Google soovitab domeeniomanikel vastumeetmena avaldada sertifitseerimiskeskuse autoriseerimise (CAA) DNS-kirjed. CAA-kirje on poliitikadokument, mis ütleb maailmale, millistel konkreetsetel sertifitseerimiskeskustel on lubatud domeenile sertifikaate väljastada. Kui pahatahtlik osapool üritab saada sertifikaati keskuse "A" käest, kuid CAA-kirje loetleb ainult keskuse "B", tuleks taotlus tagasi lükata.

Kuid CAA-kirjed on tõhusad ainult siis, kui need on piiravad ja kui sertifitseerimiskeskused neid austavad. Veelgi olulisem on see, et kui ründaja kaaperdab DNS-i, saab ta lihtsalt CAA-kirje kustutada või seda muuta enne petturliku sertifikaadi taotlemist. Google viitab, et need kirjed võivad takistada ründajatel puhverdatud valideerimisandmete taaskasutamist, kuid need pole imerohi. Need on detailne tööriist, mis lisab ründajale takistusi, kuid tuginevad siiski DNS-i enda terviklikkusele.

Sertifikaatide läbipaistvuse logide (CT logs) tähtsus

Kulisside taga on kõige tõhusam viis sellise tegevuse märkamiseks sertifikaatide läbipaistvuse (Certificate Transparency ehk CT) logid. CT on avalike, ainult lisatavate logide süsteem, mis salvestab iga osaleva CA poolt väljastatud TLS-sertifikaadi. Iga kord, kui teie domeenile luuakse uus sertifikaat, ilmub see nendesse logidesse.

Proaktiivselt rääkides peaks iga turvameeskond neid logisid oma domeenide osas jälgima. Kui ilmub sertifikaat CA-lt, mida te ei kasuta, või ajal, mil te seda ei taotlenud, on tõenäoliselt tegemist käimasoleva kaaperdamisega. Kasutan mitmeid automatiseeritud tööriistu, mis teavitavad mind Signali kaudu hetkel, kui mõnele minu hallatavale varale väljastatakse uus sertifikaat. See forensiline nähtavus on ainus viis tuvastada TLD-taseme kaaperdamine enne, kui see viib massilise andmelekkini.

Õppetunnid DigiNotari ajastust

See intsident on meeldetuletus, et sertifikaadisüsteemil on süsteemsed vead. 2011. aastal oli DigiNotari rikkumine digitaalne pantvangikriis Iraani rahva jaoks, kelle liiklust valitsus võltsitud sertifikaatide abil pealt kuulas. Kuigi praegune TLD kaaperdamine näib olevat suunatud brändidele ja teenustele, on tehniline haavatavus identne. Kasutame detsentraliseeritud maailmas endiselt tsentraliseeritud usaldusmudelit.

Krüpteerimine on purunemiskindel digitaalne seif ainult siis, kui võtmeid käsitletakse täieliku terviklikkusega. Kui neid võtmeid valideeriv infrastruktuur on kompromiteeritud, jääb seifiuks pärani lahti. Ründajad näitasid sel juhul, et võitmiseks pole vaja krüpteerimist murda. Tuleb vaid veenda süsteemi, et olete seifi õigusjärgne omanik.

Praktilised näpunäited turvajuhtidele

Turvalisus seisneb sageli selliste sõltuvuste haldamises, mida te ei kontrolli. Kuigi te ei saa turvata välisriigi TLD-registri infrastruktuuri, saate kontrollida, kuidas teie organisatsioon nendele riskidele reageerib.

• Auditeerige oma domeeniportfelli ja tuvastage, millised domeenid on registreeritud ccTLD-de all, millel on vähem ranged turvaprotokollid.
• Avaldage CAA-kirjed kõigile missioonikriitilistele domeenidele, et piirata, millised asutused saavad tõendeid väljastada.
• Seadistage sertifikaatide läbipaistvuse logide reaalajas jälgimine, et tabada volitamata väljastamine minutitega.
• Võimaluse korral lubage DNS-i turvalaiendid (DNSSEC), et lisada oma DNS-andmetele krüptograafilised allkirjad, muutes kaaperdamise raskemaks.
• Vaadake üle oma intsidentidele reageerimise plaan, et lisada protokoll sertifikaatide kiireks tühistamiseks ja koordineerimiseks brauseritootjatega.

Vastumeetmena tagavad need sammud, et isegi kui TLD-register ebaõnnestub, on teie meeskonnal nähtavus reageerimiseks enne, kui kahju muutub süsteemseks. Eesmärk on liikuda reaktiivsest hoiakust vastupidava (resilient) hoiakuni. Turvalisus ei ole seisund, mille saavutate, vaid protsess, mida hoiate.

Allikad:

• Google Security Blog: Tracking Recent TLD Hijacks and Unauthorized Certificates
• NIST Special Publication 800-15: Minimum Interoperability Requirements for PKI Components
• CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates
• RFC 6844: DNS Certification Authority Authorization (CAA) Resource Record
• MITRE ATT&CK Framework: T1584.001 (Compromise Infrastructure: Domains)

Vastutuse välistamine: See artikkel on mõeldud ainult teavitamiseks ja harimiseks ega asenda professionaalset kübervalveauditit ega intsidentidele reageerimise teenust.