Microsoft je 3. marca ob 06:35 po srednjeevropskem času (v Seattlu je bil takrat še 2. marec) objavil opozorilo o več kritičnih ranljivostih njihovega Exchange strežnika. Šlo je za več 0-day ranljivosti, kar pomeni, da so bile znane (in se tudi izkoriščale) na omrežju še preden je za to vedel Microsoft in vsekakor še preden so bili na voljo popravki. To je pomenilo, da so vsi Exchange strežniki v tistem trenutku bili izpostavljeni potencialnim napadom.
Microsoft s svojim produktom Exchange omogoča upravljanje elektronske pošte, skupnih koledarjev, opravil in imenikov, ponuja pa se kot enovita rešitev za (predvsem) poslovna okolja.
Koliko Exchange strežnikov najdemo?
Na SI-CERT smo seveda takoj začeli pripravljati obvestilo (glej SI-CERT 2021-01) ter ga nekaj ur kasneje objavili na spletnem mestu in družbenih omrežjih. Odločili smo se tudi, da bomo opravili pregled slovenskega internetnega prostora. Cilj je bil najti vse ranljive strežnike, poiskati kontakte skrbnikov in jih še posebej opozoriti o nujnosti namestitve varnostnih popravkov. Pregled je seveda moral biti neinvaziven in nam po možnosti omogočiti ločitev ranljivih od neranljivih strežnikov. Prve številke na Shodanu so se nam zdele nekoliko nizke, zato smo se odločili, da sken opravimo tudi sami. Tu pa so se porodila sledeča vprašanja: “Kje jih bomo iskali? Kako velik pravzaprav je slovenski naslovni prostor?”
Naslovni prostor
Naslovni prostor lahko sestavimo iz podatkov o alociranih blokih IPv4 (lahko pa bi predelali tudi celotno RIPE bazo). Ko zberemo naslovni prostor, moramo nato oceniti, koliko časa bo pregled zahteval. Zaporedno pregledovanje seveda odpade, saj bi za en sam sken porabili več dni. Postopek moramo paralelizirati in uporabiti posebna orodja, ki so temu namenjena (Zmap in Zgrab). Zavedamo se tudi, da je “trkanje na vrata” (poskušanje, ali so vrata/port odprta) poceni, povezovanje na strežnik in pridobivanje informacij preko HTTP ali SMTP poizvedb pa zamudno (v okviru pregleda celotnega slovenskega prostora). Zato delamo po korakih: najprej vsi HTTPS strežniki (ki jih je slabih 50.000), potem pa moramo med njimi najti MS Exchange strežnike.
Določanje ranljivih strežnikov
Naslednje vprašanje je, ali znamo razločiti med ranljivimi strežniki in tistimi, ki to niso. V dneh po Microsoftovi objavi smo morali sami ugotavljati, kaj deluje in kaj ne. V EU Mreži CSIRT (CSIRTs Network) smo tako na koncu vseeno prišli do “recepta”, ki je iz različice nameščenega strežnika znal povedati, ali je ranljiv ali ne. Ta (številka verzije) pa je razvidna iz lokacije favicon datoteke na strežniku; nahaja se v mapi, ki razkrije različico strežnika.
Takšno iskanje pa je dalo tudi lažno pozitivne rezultate. Mapa je namreč oblike major.minor.X, za potrditev pa potrebujemo polno različicomajor.minor.X.Y. Vseeno smo šli v akcijo obveščanja, saj smo sklenili, da je bolje obvestiti nekoga, ki je problem že odpravil, kot pa da odlašamo. Kmalu pa je Microsoft objavil nmap skripto za bolj natančno identifikacijo ranljivih strežnikov.
Rezultati
Vseh MS Exchange strežnikov (ki smo jih uspeli najti, seveda) je nekaj čez 1000. Skozi potek reševanja tega incidenta smo spremljali, kako potekajo nadgradnje in v več valovih razpošiljali obvestila z navodili, kako preveriti, ali je morda strežnik že zlorabljen. Potek nadgradenj slovenskih strežnikov iz perspektive SI-CERT je prikazan spodaj, viden je tudi preklop na bolj zanesljivo metodo določanja ranljivosti.
Trkanje na stranska vrata
Že od začetka smo na SI-CERT opozarjali, da je lahko zloraba Exchange strežnika s pridobitvijo administratorskih pravic le prvi korak v napadu. Pričakovali smo, da bodo storilci najprej namestili stranska vrata (backdoor), s katerimi bodo lahko izvajali poljubne ukaze na zlorabljenem strežniku, nato pa nadaljevali z iskanjem Active Directory strežnika na omrežju, ki bi jim omogočil širši napad. Kot eno od možnosti smo seveda pričakovali zagon izsiljevalskega virusa in ohromitev celotne organizacije. Ko so storilci res začeli nameščati stranska vrata, smo v CSIRT skupnosti zložili skupaj indikatorje zlorabe (Indicators of Compromise), ki so nam omogočili med ranljivimi strežniki najti tudi tiste, do katerih so storilci že prišli.
Od nekaterih skrbnikov zlorabljenih strežnikov smo dobili povratna poročila o še več najdenih zlonamernih skriptah, s katerimi smo lahko dopolnili te indikatorje zlorabe, kar je nam (in našim kolegom v skupnosti) omogočilo še boljše iskanje uspešnih vdorov.
Zaključek
Iskanje zlorabljenih sistemov, ki smo ga opisali zgoraj, najde odtise že znanih, tistih najbolj pogostih vdorov. Ranljivi strežniki, ki jih storilci na tarčo vzamejo v ciljanih napadih, so lahko deležni posebej prilagojenih orodij, za katere še nimamo ustreznih indikatorjev zlorabe. Zato je bilo najbolj pomembno, da se je natančne preglede opravilo pri izvajalcih bistvenih storitev. Skrbniki so tam opravili nadgradnje zelo hitro po objavah ranljivosti. Po naših opažanjih največji delež MS Exchange strežnikov predstavljajo mala in srednja podjetja ter manjši javni zavodi, zato je prav tudi tam razmišljati o ciklih nadgradnje in odzivanju na incidente.
Sodelovanje v Mreži CSIRT nam je omogočilo hitrejše odzivanje zaradi izmenjevanja izsledkov preiskav, indikatorjev zlorab in receptov pri obravnavi tega incidenta. Enako smo veseli tudi povratnih informacij skrbnikov prizadetih strežnikov, ki nam pomagajo izboljšati postopke s povratnimi informacijami in dopolniti sezname indikatorjev. V konkretnem incidentu pa smo pogrešali boljšo pripravljenost Microsofta kot proizvajalca strežnika, v katerem so bile 0-day ranljivosti odkrite. Predhodna najava teh po varnih kanalih na SI-CERT in drugim pristojnim CSIRT skupinam v EU in drugje bi omogočila boljši odziv in hitrejšo sanacijo težave.