V petek, 11. junija, je naše krovno podjetje IPM Group prejelo e-poštno sporočilo NIL, slovenskega ponudnika oblačnih rešitev in rešitev kibernetske varnost z naslovom »Opozorilo glede informacijske varnosti«. Kot piše v e-pošti, je bila zlonamerna koda podpisana z digitalnim potrdilom izdanim na naše ime. Kasneje je bilo ugotovljeno, da je napaka najverjetneje povezana z vrzeljo overjanja podjetij za izdajo digitalnih potrdil Sectigo.
Tehnično ozadje
Digitalna potrdila uporabljajo protokol, imenovan PKI (infrastruktura javnih ključev), ki zagotavlja matematični algoritem za generiranje dveh dolgih številk oziroma tako imenovanih ključev. Eden je javni, drugi pa zasebni ključ.
Hitra predstava: javni ključ lahko samo kriptira, zasebni pa lahko dela oboje. Ker ključa nista zmožna istih funkcionalnosti, spada tak mehanizem v družino asimetrične kriptografije.
Podpisnik podpiše dokument z zasebnim ključem, ki je vedno varno shranjen. Podpisani dokument se zgosti z zasebnim ključem in ti šifrirani podatki se imenujejo digitalni podpis. Javni ključ pa je edina stvar, ki lahko obnovi izvirni dokument. Velja obratno; podpisan dokument z javnim ključem podpisnika je mogoče dešifrirati samo z zasebnim ključem podpisnika.
Da zagotovimo verigo zaupanja, uvedemo overitelja potrdil (CA) za varno ustvarjanje/izdajanje/upravljanje ključev.
Zakaj uporabljati digitalne podpise? Z uporabo metodologije PKI digitalni podpisi uporabljajo mednarodno, dobro razumljeno, na standardih temelječo tehnologijo, ki pomaga tudi pri preprečevanju ponarejanja ali sprememb dokumenta po podpisu ali kriptiranju.
Digitalno potrdilo tako postane elektronski dokument, ki ga izda overitelj potrdil (CA). Vsebuje javni ključ za digitalni podpis in določa identiteto, povezano s ključem, na primer ime organizacije. Potrdilo služi kot zagotovilo, da javni ključ pripada določeni organizaciji, pri tem pa CA služi kot porok. Zato mora digitalna potrdila izdati zaupanja vreden organ, čas njihove veljavnosti pa je omejen.
Težava nastane pri izdajatelju potrdil, kjer se veriga zaupanja konča. Podjetje se mora za izdajo ključa vedno OVERITI. Postopki overjanja pa so pogosto poslovna skrivnost, zato je bil naš prvi sum pomanjkljiv sistem overjanja.
Vpliv
Prvotno priporočilo NIL je bilo, da izvedemo notranji sistemski varnostni pregled, kar smo tudi storili. Naša notranja infrastruktura vsebuje Cynet IDS, ki ni pokazal sumljive dejavnosti. Po nadaljnji preiskavi dnevnikov samih notranjih omrežnih naprav (router) je bilo potrjeno, da ni prišlo do “on-premise” vdora in da je bil ves promet v omrežju znotraj pričakovanih parametrov.
Negativni vpliv incidenta je večinoma povezan z morebitno škodo ugleda podjetja, saj je bila zlonamerna datoteka naložena na VirusTotal in je ime podjetja navedeno kot eden od podpisnikov. Ravno iz tega razloga smo se odločili za javno objavo poročila o incidentu, v upanju, da s tem širimo zavedanje o tovrstnih grožnjah, ki se lahko pripetijo vsaki organizaciji.
Odziv
Odziv na incident je prvi opazil NIL in nas o tem obvestil preko info maila. Incident je bil nato predan vodji tehnološkega razvoja, ki je uspel uskladiti komunikacijo med nami in NIL, ta pa je nato uspešno sprožil preiskavo.
Isto uro je pregledal dnevnike notranje opreme in ugotovitve Cyneta, vendar ni ugotovil sumljive dejavnosti. Ponovili smo raziskavo in potrdil, da ni prišlo do uhajanja podatkov v zadnjem času. Poleg tega smo preverili celovitost naših programskih storitev; tako smo zagotovili, da so vsi varnostni popravki posodobljeni in da je izvorna koda pravilno shranjena na oddaljeni platformi za gostovanje Git. Nazadnje smo preverili vsa razvojna potrdila, njihov obstoj in veljavnost ter povečali varnost njihove hrambe.
Naše podjetje pri podjetju Sectigo nikoli ni zahtevalo potrdila za podpis programske opreme. Po posredovanju podjetja NIL je Sectigo potrdilo postavil na CRL (Certificate Revocation List), kar je bila zadnja interakcija med zabeleženim incidentom. Več informacij od podjetja nismo prejeli.
Kot zadnje dejanje je NIL incident prijavil na SI-CERT.
Kaj smo se naučili?
Na žalost za mala in srednje velika podjetja v teh primerih ni mogoče storiti veliko, najboljša rešitev je, da se obrnejo na izdajatelja digitalnega potrdila in zahtevajo, da se potrdilo premakne v CRL.
Pri tovrstnih incidentih sta najpomembnejša koraka okrepljen pregled sistema oz. izvora težave in prednostno obravnavati nastali dogodek. Notranji strokovnjaki za informacijsko tehnologijo in kibernetsko varnost morajo v čim krajšem času ugotoviti ali je prišlo do uhajanja podatkov, in če je tako, za odziv na grožnjo uporabiti pravilne ukrepe.
– Peter Aleksander Bizjak, vodja razvoja aplikacij in certificirani etični heker
