Nadogradnja okvira MITRE ATT&CK

 Prošlog tjedna je objavljena značajna nadogradnja – verzija 9 – okvira MITRE ATT&CK, okvira za analizu cyber napada o kojem sam ranije pisao i predstavio na redovitom mjesečnom sastanku ISACA Croatia Chapter. Osim uobičajenih dopuna ili nadogradnji tehnika i sub-tehnika te podataka o napadačkim grupama, verzija 9 uvodi taktike i tehnike napada koje se odnose na tehnologiju kontejnera te značajno nadograđuje taktike i tehnike napada koji se odnose na „Cloud“ tehnologije. No, najznačajnija novost u verziji 9 je novi pristup u opisu i obradi „Data Sources“ informacija.

Prema okviru MITRE ATT&CK, „Data Sources“ su točke ishodišta podataka na temelju kojih je moguće detektirati pojedine tehnike (i sub-tehnike) napada. U pre-v9 verzijama okvira ATT&CK ovi podaci su definirani kao nestrukturirana svojstva pojedinih tehnika i sub-tehnika, a ima ih preko 60. „Data Sources“ informacije su i u takvom obliku izuzetno korisne, osobito za stručnjake i timove koji su fokusirani na tehnike detekcije cyber napada (npr. tzv. „blue team“ grupe). Pomoću ovih informacije moguće je primijeniti dodatne konfiguracijske napore i/ili arhitekturne nadogradnje kako bi se obogatila učinkovitost telemetrijskih podataka neophodnih za detekciju napada. Ipak, iako zamišljeni s dobrom namjenom, realizacija „Data Sources“ informacija u pre-v9 verzijama je zaostajala za drugim komponentama ATT&CK okvira, upravo zbog svoje nestrukturiranosti ali i mjestimične nekonzistentnosti koja je bila rezultat izostanka dobro definiranog modela ove kategorije podataka. Tako na primjer,  „Data Sources“ podacima su označeni i „Process monitoring“ i „Process command-line parameters“ i „Process use of network“, iako se u suštini radi o različitim aspektima informacija koje se generiraju na temelju istih događaja - pokretanja i izvođenja Windows procesa. Drugi primjer je i „Windows event logs“ kao zasebna „Data Sources“ točka iako bi ovu kategoriju bilo bolje definirati kao kanal kroz koji se dostavljaju suštinski „Data Sources“ telemetrijski podaci a ne kao „Data Sources“.

U zajednici koja prati i surađuje na razvoju okvira ATT&CK pojavile su se stoga sugestije za modifikaciju „Data Sources“ informacija. 

Verzija 9 donosi ovu dobrodošlu nadogradnju. Točnije, u ovoj verziji imamo prvu fazu nadogradnje, kroz koju su definirani „Data Sources“ te „data components“ - komponente vezane za pojedini izvor, tj. specifikacija izvora iz kojih moramo prikupljati detekcije podatke, ali sada na strukturiran i normaliziran način. Za sada još uvijek nedostaju konkretni detekcijski podaci koji bi se mapirali za pojedine tehnike napada, no to se očekuje u verziji koja je planirana za listopad. 

Odnos među navedenim dijelovima ovog modela podataka su vidljivi na priloženoj slici, koju sam posudio iz teksta na službenom ATT&CK blogu.  

Također treba napomenuti da su novi „Data Sources“ podaci za sada katalogizirani kroz Github a ne kao objekt unutar ATT&CK okvira. Razlozi su opravdani razvojnim aktivnostima, a uključivanje u ravnopravne ATT&CK objekte je također planirano za listopad. No, bez obzira na prisutan “work-in-progress“ dojam, postojeće dopune mogu značajno olakšati posao svima nama koji smo fokusirani na tehnike detekcije ili na DFIR aktivnosti.

Ranjivost koju treba shvatiti ozbiljno

Prošlo je šest dana od objave podataka o veoma nezgodnoj ranjivosti na Microsoft Exchange serveru, koja zahvaća sve novije verzije ovog servera konfiguriranog tako omogućuje OWA pristup, tj. tako da omogućuju pristup elektroničkoj pošti preko Internet preglednika. Nadam se da su svi koji su takav servis omogućili za pristup iz javnog Internet prostora već primijenili popravak koji je Microsoft objavio 2. ožujka, istog dana kada je i tvrtka Volexity objavila informaciju o ovom nedostatku. Naime, tvrtka Volexity je još od početka siječnja uočila anomalije u korištenju servisa elektroničke pošte u korisnika kod kojih je upotrebi Exchange – velika količina poruka bila je eksfiltrirana na adrese koje nisu povezane s poslovanjem korisnika. Daljnja analiza problema je ukazala na prisutnost tzv. server-side request forgery (SSRF) ranjivosti koja je omogućila izvođenje proizvoljnog koda. Ukratko, mailbox odabranih osoba na mail serveru žrtve bio je kopiran na vanjske servere pod kontrolom napadača. Napadač je morao znati, ovisno od konfiguracije Exchange servera, mail adresu ciljane žrtve ili njegov Active Directory račun, što naravno nije nimalo nepremostiv zadatak. 

No, to nije bilo sve. Ujedno su bile iskorištene i neke druge do tada nepoznate ranjivosti koje su omogućile daljnju eskalaciju inicijalnog proboja. U toj drugoj fazi napadač uspijeva doći u posjed dodatnih informacija o radu Active Directory sustava (u najgorem scenariju, to su podaci o domenskim računima i podacima za autentikaciju). Također, napadač uspijeva kreirati „webshell“ okolinu na Exchange serveru, tj. specifični „backdoor“ program koji mu omogućuje izvođenje proizvoljnih programa na kompromitiranom Exchange serveru. U kombinaciji s podacima s AD sustava, to predstavlja idealnu podlogu za daljnje lateralno kretanje po mreži žrtve.

Ovaj scenarij zvuči izuzetno jednostavan, što se i pokazalo u praksi. Naravno, značajan trud je uložen u otkrivanje ranjivosti i u razvoj exploita, no operativna provedba je bila praktički automatizirana i zato su forenzičke analize provedene nakon objave ranjivosti pokazale oko 30.000 žrtava (to su zadnje informacije dostupne u trenutku pisanja ovog teksta). Ova brojka obuhvaća one servere kod kojih su pronađeni tragovi djelovanja exploita, tek trebamo saznati koliko je korisnika zapravo bilo izloženo i krajnjem djelovanju, tj. krađi mail poruka ili daljnjim aktivnostima napadača na internoj mreži.

Iza napada, kako je objavljeno, stoji kineska cyber-obavještajna grupa Hafnium. Ova se grupa do sada uglavnom bavila preuzimanjem podataka s različitih istraživačkih institucija, sveučilišnih ustanova i instituta raznih profila. Također, registrirano je i djelovanje nekih drugih kineskih grupa za koje nije utvrđeno jesu li u organizacijski ili poslovno povezane. Identificiran je jako veliki broj žrtava među institucijama i agencijama američke vlade, no i među brojnim tvrtkama.

Donekle olakšavajuću okolnost predstavlja činjenica da su mnoge velike korporacije uveliko migrirale na cloud verziju Exchange-a, tj. na mail servis koji pruža Microsoft, a koji nije zahvaćen recentnom ranjivosti koju ovdje opisujem.

No, mjesta za opuštanje nema, čak i ako ste primijenili popravak. Obavezno morate provjeriti jeste li možda prethodno ipak bili kompromitirani. Prema veoma detaljnom upozorenju i uputama za forenzičku analizu koje je uputila važna agencija američke vlade - Cybersecurity and Infrastructure Security Agency (CISA), prava bi se analiza morala temeljiti na pouzdanom forenzičkom postupku i trijaži podataka o incidentu kroz koju bi se trebali pretražiti točke interesa te verificirati prisutnost/odsutnost karakterističnih indikatora kompromisa. Tek jednostavan uvid u sadržaj IIS foldera i vizualno pretraživanje karakterističnih podataka nije dovoljno. Također, i Microsoft je objavio skripte za otkrivanje dijela kompromitiranih podataka.

Bojim se da ovime priča oko Exchange problema nije ni približno gotova, što ponajviše temeljim na činjenici da forenzičke istrage još nisu završene te da prave informacije o opsegu ovo napada tek slijede. Nekoliko je i suštinskih razloga koji idu u prilog ovoj tvrdnji:

• Tek trebamo saznati kada jesu li ovi napadi registrirani i prije siječnja 2021. i jesu li do sada možda iza napada stajale i neke druge cyber grupe koje su birale puno diskretniju taktiku napada.
• Iako se trenutno spominje 30.000 žrtava, radi se o uglavnom američkim žrtvama. Tek moramo saznati koliko su zahvaćene tvrtke/organizacije iz drugih dijelova svijeta.
• Ranjivost je postala dostupna javnosti prošlog tjedna. Iako su se pojavili Proof-of-Concept verzije napada, novi maliciozni „exploit-i“ u trenutku pisanja ovog teksta još nisu dostupni, no samo je pitanje vremena kada će se pojaviti.
• Ranjivosti koje opisujemo u ovom tekstu imaju potencijal za iskorištavanje u slijednom lancu događaja na automatizirani način te mogu poslužiti za razvoj scenarija ransomware napada.
• Tek trebamo saznati kolika je dinamika primjene popravaka, no ako za ilustraciju uzmemo neke druge slučajeve iz bliže povijesti, poznato je da neke organizacije mogu biti veoma lijene u primjeni popravaka (vidi primjer tvrtke Equifax i epohalno neuspješan popravak Struts ranjivosti).

Ukoliko vam bude zatrebala pomoć oko forenzičke analize stanja potencijalnog kompromitiranog servera, pogledajte našu ponudu forenzičkih usluga i javite nam se.

Model zrelosti upravljanja računalnim ranjivostima

 U tekstu koji sam objavio prije, sada već, nešto više od dvije godine (Digitalna transformacija procesa upravljanja ranjivostima) pisao sam o potrebi promjene paradigme procesa upravljanja računalnim ranjivostima. Trend napuštanja tehnike mrežnog skeniranja kao najčešće metode otkrivanja ranjivosti bio je već tada izražen, a razvoj tehnologije i upravljačkih procesa koji su slijedili potvrdili su najave iz teksta.

Dapače, stvari su krenule i korak dalje. Ne samo da su senzori za detekciju ranjivosti – namjenski servisi koji se izvode na samim računalima, postali izvor jednako relevantan kao i rezultati mrežnih skeniranja, a sve češće i značajniji, nego su sustavi za prikupljanje i analizu ranjivosti prerasli ulogu daljinskog upravljača za pokretanje skenova i alata za generiranje izvještaja. 

Kao ilustraciju dajem primjer sustava Qualys, koji je postao bogata analitička platforma u kojoj se bogati telemetrijski podaci sa senzora različitih profila i izvora slijevaju u svojevrsni „data lake“. Normalizirani, obogaćeni i indeksirani podaci o ranjivostima pružaju svojim korisnicima neposrednu i djelotvornu informaciju, bez obzira radi li se o izvještavanju odgovornih osoba, alarmiranju sigurnosnih timova ili pokretanju nužnih remedijacijskih aktivnosti.

Mogućnosti koje pružaju nove funkcije sustava Qualys dobile su nedavno i dobrog pratitelja. Američka organizacija SANS, čije djelovanje ne treba posebno predstavljati kolegama koji rade na području informacijske sigurnosti, objavila je sredinom prošle godine svoj edukativni  poster „CISO Mind Map“ u koje središnje mjesto „Vulnerability Management Maturity Model“. To je detaljna tablica u kojoj su glavne faze procesa upravljanja računalnim ranjivostima opisane s obzirom na stupanj realizacije, pri čemu je zrelost programa klasificirana u pet razina – od „Initial“ do „Optimizing“.  Na svoje će doći ne samo ljubitelji „Maturity Model“ klasifikacija, nego i svako od vas koji pokušava uvesti program upravljanja ranjivostima u svoju organizaciju.

U nastavku prilažem samu tablicu da dokument možete preuzeti na ovom mjestu:

Dokument koji možete preuzeti je tek poster na kojem tablica s „Vulnerability Management Maturity“ modelom zauzima vidljivo mjesto, no svakako nedostaju još neke dodatne upute (ovo nije zamjerka SANS-u, već naprosto činjenica da je dokument podsjetnik ili ako hoćete poziv na pohađanje seminara koje SANS održava na temu procesa upravljanja informacijskom sigurnosti). Stoga bi tu još trebalo dodati da ranjivosti na koje se model odnosi nisu samo bugovi u operativnom sustavu ili u gotovim programskim paketima, već i ranjivosti na aplikativnim sustavima te konfiguracijske manjkavosti. 

Kako krenuti u primjenu ovog modela? Za početak identificirajte gdje se zapravo nalazite unutar ovog modela. Nije isključeno da će se vaša razina zrelosti razlikovati u ovisnosti od faza procesa (imamo pet faza: Prepare, Identify, Analyze, Communicate i Treat). Budite objektivni i realni. Radi te za vlastiti napredak a ne za regulatorno ili revizijsko izvješće. Kada utvrdite svoju razinu zrelosti, postavite cilj kojem želite težiti. Neka to bude u koracima koje realno možete i napraviti.

Kada krenete u implementaciju onda ćete vidjeti da se izvješća, preporuke, dojave i odluke na bogatoj bazi podataka i na vašoj sposobnosti da iz takve baze izvučete sve djelotvorne informacije i polazišta za daljnje akcije. Dobro, ne mislim baš na vašu osobnu sposobnost, već na svojstva sustava unutar kojeg su prikupljeni podaci o ranjivostima. A tu sada dolazimo na funkcije sustava Qualys koji će vam omogućiti unaprjeđenje procesa upravljanja ranjivostima do najviših razina zrelosti predviđenih ovim modelom. 

SolarWinds hack - zbog čega se moramo zabrinuti (nastavak)?

U prethodnom tekstu sam se opisao kontekst pojave SolarWinds hacka (SUNBURST prema FireEye ili Solarigate prema Microsoft) i njegov utjecaj na informacijsku sigurnost, a kako sam najavio, u ovom se tekstu bavim tehničkim detaljima.

Odmah za početak, ova analiza ne uključuje detalje o inicijalnom proboju u tvrtku SolarWinds, s obzirom da za sada nisu objavljeni konačni zaključci analize niti načini kompromitacije aplikacije Orion, no svakako možemo zaključiti da je napadač imao dobru poziciju u procesu razvoja i upravljanja promjenama ove aplikacije.

Moja analiza je bazirana na izvješćima koja su objavila tvrtke Microsoft, FireEye, PaloAlto Networks te agencija Cybersecurity and Infrastructure Security Agency (CISA) američke vlade.

Dakle, krećemo od točke kada je tvrtka korisnik sustava SolarWinds Orion (i buduća žrtva kompromitacije ovog softvera) preuzela nadogradnju objavljenu krajem ožujka ove godine. Nadogradnja, ekstenzije msp, bila je uredno potpisana certifikatom tvrtke SolarWinds i među  komprimiranim modulima je uključivala i modul SolarWinds.Orion.Core.BusinessLayer.dll.

Nakon instalacije nadogradnje, novi moduli, uključujući i prije spomenuti su bili pokrenuti u produkcijskom radu. 

Modul SolarWinds.Orion.Core.BusinessLayer.dll je .NET program koji je standardni dio aplikacije Orion, sa svojim redovitim funkcijama. No, unutar ove funkcije je lukavo smješten poziv za izvođenje backdoor modula: predviđeno je paralelno izvođenje s glavnim programskim modulom, ničim narušavajući očekivane funkcije, a za izvođenje je odabrana metoda koja se redovito pokreće, čime je osigurana persistencija, tj. kontinuirani rad nakon svakog pokretanja aplikacije.

Backdoor kod je u potpunosti sadržan u klasi OrionImprovementBusinessLayer. Tijekom inicijalizacije, maliciozni program provjerava je li istekao rok od 12 do 14 dana od inicijalnog pokretanja (provjerava vrijeme zadnjeg upisa) – dakle predviđene je dvotjedni period mirovanja od inicijalne kontaminacije te provjerava postoje li neki drugi unaprijed predviđeni uvjeti uslijed kojih planirano obustavlja rad (npr. malware prekida izvođenje ako se nalazi u domeni koja uključuje stringove „solarwinds“ odnosno „test“ ili se na sustavu izvode neki procesi karakteristični za sigurnosne programe).

Ukoliko je „zrak čist“, „backdoor“ započinje stvarni život. Namjera mu je povezati se kontrolnim (C2) serverom, prijaviti svoju dostupnost, preuzeti instrukcije sa C2 servera, izvesti ih na mreži žrtve i vratiti rezultate nazad na C2. Dakle, radi se o uobičajenom slijedu akcija kakve izvode „backdoor“ programi. No, vrag je u detaljima. 

Inicijalni C2 server je smješten unutar domene avsvmcloud[.]com, pri čemu je stvarni URL nadopunjen s pseudo-random i random nazivima generiranim iz jedinstvenih parametara vezanih za samu žrtvu. Također, prije povezivanja s C2 serverom, generira se i URI lokacija izborom unaprijed pre-definiranih vrijednosti na način koji neće izazvati sumnju ako bi netko pratio metapodatke o povezivanjima. 

Na koncu, generira se i šalje JSON dokument s parametrima relevantnim za ostvarivanje komunikacijskog kanala.

(Važno je napomenuti: Ova adresa je iskorištena i kao slabost SUNBURST malwarea, odnosno kao „kill-switch“ poluga. Nakon ovog otkrića, Microsoft je blokirao domenu avsvmcloud[.]com, no, ipak, 8 mjeseci prekasno)

Kada je komunikacijski kanal između „backdoor“ programa i C2 servera potvrđen, započinje kontinuirana komunikacija kroz koju operateri koji rade na C2 serveru dostavljaju „backdoor“ programu niz naloga za izvođenje karakterističnih aktivnosti – od prikupljanja osnovnih informacija o operativnom sustavu, mreži datotekama, registry podacima pa do izvođenja specifičnih naredbi.

No, treba naglasiti da je operacija bila sve samo ne rutinska i predvidljiva. U analiziranim slučajevima su otkrivene i mnoge specifičnosti – od dodatnih C2 servera putem kojih su dolazili nalozi za akcije, do iskorištavanja specifičnih ranjivosti ili pokretanja novih malicioznih programa prikladnijih za lateralno kretanje. Opisat će neke od ovih specifičnosti u nastavku. 

Novi C2 serveri: Kada SUNBURST/Solarigate backdoor program pokrene aktivnosti lateralnog kretanja i druge aktivnosti u naprednoj fazi napada, onda se otvara komunikacijski kanal prema alternativnim C2 serverima. Često puta, radi se o domenama koje su registrirane nekoliko godina ranije, u međuvremenu su istekle ali nisu brisane. Na taj način napadač želi ostaviti dojam komunikacije sa domenom pouzdane dugogodišnje reputacije. I korak dalje: zabilježeno je da su napadači komunicirali sa žrtvom preko lokalnog VPS servera, smještenog u istoj zemlji gdje je i žrtva, čime napadač dodatno nastoji pojačati reputaciju. 

TEARDROP dropper: Kako sam spomenuo, u drugoj fazi napada (koja se obično naziva „post-compromise“ aktivnost) su korišteni dodatni „payload“ moduli. SUNBURST uobičajeno koristi PowerShell skripte, no tvrtka FireEye je izdvojila i specifično kreirani „payload“ modul kojeg je nazvala TEARDROP. Radi se o inventivno importiranom programskom kodu (preko lažne  jpg datoteke nad kojom je primijenjena tehnika steganografije) koji su pokreće u radnoj memoriji kao „file-less malware“ a u suštini izvodi backdoor modul komercijalnog programa za penetracijska testiranja Cobalt Strike, naravno opremljenog tehnikama za osiguranje persistencije, prikupljana autentikacijskih podataka i lateralnog kretanja, ali i prilagođenog novom gazdi.

Privilegirane ovlasti: Polazeći od činjenice da sustav Orion ima nadzorne zadaće nad ključnim komponentama informatičke infrastrukture, napadači su zauzeli nekoliko uporišta za dohvat podataka o korisničkim računima, uključujući i mogućnost lateralnog kretanja s privilegiranim ovlastima i prijave na ključne resurse (npr. AD server) s visoko privilegiranim ovlastima. Takve privilegije su omogućile i praktičnu implementaciju tehnike napada poznatu pod imenom „Golden SAML“. Ova tehnika je poznata od 2017. godine ali je ovo prvi zabilježeni slučaj u stvarnom incidentu. U SUNBURST scenarijima, napadači su time ostvarili mogućnost pristupa resursima koji prihvaćaju SAML autentikaciju (tipično „cloud“ resursi), a koji se može naknadno iskorištavati i izvan  konteksta SUNBURST napada.

Svaka tema obuhvaćena ovim tekstom otvara nova područja, a osnovna tema - slučaj SUNBURST/Solarigate – daleko je od toga da je možemo smatrati apsolviranom, ni na tehničkoj niti na političkoj razini.

SolarWinds hack - zbog čega se moramo zabrinuti?

Tijekom mjeseca studenog ili samim početkom prosinca, jedan od zaposlenika američke tvrtke FireEye primio je automatsku dojavu da se nepoznata osoba pokušava prijaviti na VPN sustav tvrtke s nekog novog uređaja. Savjestan zaposlenik je alarmirao nadležnu službu svoje tvrtke, a sve što se dešavalo nakon toga polako je poprimilo razmjere najvećeg cyber napada svih vremena. Pogađate, tema ovog teksta je SolarWinds hack. 

Za početak, možemo li ovaj događaj zaista okarakterizirati kao najveći cyber napad svih vremena? Sjetimo se napada NotPetya iz 2017, koji je na koljena bacio jednu cijelu državu, ali i veliki broj kompanija, bolnica, ustanova različitih profila, uzrokujući gubitke, prema nekim procjenama, preko 10 milijardi dolara (usputna preporuka, svakako pročitajte odličnu knjigu Sandworm o ovom događaju). Zaista, za sada izgleda da SolarWinds hack neće imati takve posljedice kao NotPetya (iako zbog profila žrtava nikad nećemo ni doznati kakav je bio stvarni učinak), no ako bi ocjenjivali "umjetnički dojam" onda je cijela operacija oko SolarWind hacka izvedena na do sada nezabilježeni način, uz dugogodišnju pripremu i angažman velikog broja stručnjaka (da, mislim da je izraz "stručnjak" primjeren), pa zaista zaslužuje oznaku jednog od najvećih napada u povijesti, barem u kategoriji "Najveći doprinos razvoju informacijske sigurnosti". Jer, nedvojbeno, nakon ovog napada se mijenjaju mnoge stvari.

U ovom tekstu ću rezimirati glavne zaključke i pouke ovog slučaja, a u sljedećem ću tekstu opisati tehnički aspekt napada, odnosno ono što se zbivalo ispod površine. Novi detalji o tehnici napada pojavljuju se svakodnevno, tako da nije isključeno da ću o njima pisati i kasnije. 

Kao što znate, inicijalna vijest o napada, tada se još nije spominjao SolarWinds, došla je od tvrtke FireEye što je samo po sebi izazvalo veliku senzaciju, jer se tvrtka FireEye upravo bavi zaštitom od takvih napada u najužem mogućem smislu. Pri tome, priznali su da je napadač ukrao niz interno razvijenih alata koje ova tvrtka koristi za Red Team testiranja.

Nakon nekoliko dana i analize u kojoj je uključio svojih 100 zaposlenika,  FireEye  je objavio da je napad vezan za softver Orion tvrtke SolarWinds. Tvrtka SolarWinds je izuzetno ugledna tvrtka s fokusom na nadzor rada sustava i mreže, a softver Orion omogućuje krovni nadzor i upravljanje različitim komponentama informacijskog sustava. Korišten je u velikom broju svjetskih tvrtki, uključujući i brojne državne institucije, ministarstva i korporativni sektor (među njima i 425 od US Fortune 500). Daljnja istraga je pokazala da je jedan od modula koji se koristi u sustavu Orion (SolarWinds.Orion.Core.BusinessLayer.dll) bio kompromitiran i neovlašteno modificiran, tako da je pored svoje osnovne funkcije, ujedno imao ulogu Trojanca. Modifikacija ovog modula je napravljena u ožujku ove godine a od tada je oko 18.000 korisnika softvera Orion nadogradilo svoj sustav s kompromitiranom verzijom.

Trojanac, koji je dobio ime SUNBURST, mirovao je dva tjedna a nakon toga je ostvario vezu sa svojim komandnim centrom, evoluirao u novi malware koji je dobio ime TEARDROP pa započeo sofisticirano djelovanje, koje je uključivalo, među ostalim, različite tehnike proširenja privilegija, persistencije, lateralnog kretanja i prikrivene povratne veze s komandnim centrom. Zanimljivo, sve korištene tehnike nisu do sada bile registrirane u okviru MITRE ATT&CK koji se upravo ažurira kako bi obuhvatio i ovaj napad. 

Broj žrtava je za sada teško odrediti, spominje se stotinjak organizacija/tvrtki za koje potvrđena kompromitacije, a u opticaju je brojka i od nekoliko stotina žrtava. Većina žrtava je iz Sjedinjenih država, no ne zaostaju ni druga područja.

Pored broja žrtava, za sada nema ni službene potvrde o izvoru napada. Po mnogim indikatorima, radi se o ruskom rukopisu, najvjerojatnije agencije SVR, iako se do sada smatralo da je GRU - vojna obavještajna agencija - sposobnija provesti operaciju ovakvih razmjera.

Za potencijalne žrtve je posebno zabrinjavajuće da hitnom nadogradnjom softvera Orion na korigiranu verziju iz koje je izbačen trojanac, oni neće biti riješeni briga. Pored nadogradnje, moraju provesti forenzičku istragu kroz koju će nastojati dobiti potvrdu da nije bilo kompromisa, odnosno u lošijem scenariju, odrediti u kojem je opsegu i trajanju trojanac djelovao. 

Na ruku, pak,  žrtvama ide činjenica da SUNBURST/TEARDROP nisu osmišljeni tako da djeluju serijski i pandemijski poput "crva" (kao u slučaju NotPetya), već se radi o sofisticiranom napadu kojeg mora voditi uvježbani operater. A znamo da ni najorganiziranije cyber grupe nisu dovoljno ekipirane za operaciju nad svih 18.000 kandidata (nedostatak stručnog kadra pogađa i njih). Stoga se pokretač napada fokusirao samo na one od posebnog interesa. 

Ovo je možda definitivna potvrda da tradicionalni antivirsni sustavi ali ni napredni antimalware sustavi nove generacije kao ni EDR sustavi nisu rješenja kojima u potpunosti možete prepustiti brigu o sigurnosti svoje mreže. U slučaju SolarWinds hacka su primijenjene i neke antiforenzičke tehnike i tehnike izbjegavanja sustava detekcije, tako da ćemo svakako morati obogatiti i tehnike neposredne neautomatizirane ("ručne") detekcije.

Događaj je pokazao i potrebu za dosljednom primjenom procesa za odgovaranje na sigurnosne incidente u svakoj organizaciji/tvrtki. U ovom slučaju, već od pojave prvih izvještaja u javnom prostoru ili indikatora na svojim sustavima, korisnici kompromitiranog softvera su morali provesti inicijalnu istragu koja je trebala obuhvatiti cyber trijažu, analizu ključnih indikatora na postavkama operativnog sustava i pretragu radne memorije (TEARDROP je "fileless malware" tako da njegove tragove nećemo pronaći na čvrstim diskovima). U okviru incident management procesa svakako treba proraditi na mjerama forenzičke pripremljenosti za prikupljanje prije spomenutih podataka, za inicijalnu trijažu ovih podataka, ali i na uvođenju učinkovitih mjera nadzora, naročito nad aktivnostima računalne mreže.

Na koncu, na sve nas će posebno djelovati ključni uzrok ovog incidenta. 

Koliko god smo bili dosljedni na primjeni svih preventivnih mjera cyber higijene, ovom napadu nismo mogli izbjeći jer ključni sudionik, tvrtka SolarWinds, očigledno nije bila dosljedna u cyber higijeni (iako još ne znamo sve detalje kako je došlo do inicijalnog prodora u njihovu tvrtku). Podsjetimo se slučaja NotPetya: i tada je jedan od ključnih uzroka bio kompromitiran komercijalni softver, ipak ne takvo ime kao SolarWinds pa to, izgleda, nije izazvalo potrebnu pozornost.  Ovaj događaj svakako ukazuje da će lanac opskrbe ("supply chain") softverskih (ali i hardverskih) komponenti biti već od danas pod povećalom. A kompromitacija lanca opskrbe je i kompromitacija lanca povjerenja.

U sljedećem nastavku ću nešto više pisati o tehničkom aspektu ovog napada.