Kako vdreti v nepopravljen strežnik Exchange z lažno kodo PowerShell

Pred slabima dvema mesecema je prišlo do zaskrbljujočih novic o hroščih: v Microsoft Exchangeu je bilo objavljenih par ranljivosti ničelnega dne.

Kot smo svetoval takrat, te ranljivosti, uradno označene CVE-2022-41040 in CVE-2022-41082:

[Bila sta] dva ničelna dneva, ki bi ju [lahko] povezali skupaj, pri čemer je bila prva napaka uporabljena na daljavo, da bi odprla dovolj luknje, da bi sprožila drugo napako, ki potencialno omogoča oddaljeno izvajanje kode (RCE) na samem strežniku Exchange.

Prva ranljivost je spominjala na problematično in pogosto zlorabljeno Varnostna luknja ProxyShell od avgusta 2021, ker se je zanašal na nevarno vedenje v Exchangeevi funkciji samodejnega odkrivanja, opisal Microsoft kot protokol, ki je »uporabljajo ga odjemalci Outlook in EAS [Exchange ActiveSync] za iskanje in povezovanje z nabiralniki v Exchangeu«.

Na srečo je bila napaka samodejnega odkrivanja, ki bi jo lahko v napadu ProxyShell izkoristil kateri koli oddaljeni uporabnik, ne glede na to, ali je prijavljen ali ne. popravljeno pred več kot enim letom.

Na žalost popravki ProxyShell niso naredili dovolj, da bi preprečili izkoriščanje preverjenim uporabnikom, kar je privedlo do novega CVE-2022-40140 zero-day, ki je bil kmalu lakonično, čeprav zavajajoče, poimenovan ProxyNotShell.

Ne tako nevarno, a vseeno nevarno

Jasno je, da ProxyNotShell ni bil niti približno tako nevaren kot prvotni ProxyShell, glede na to, da je zahteval tako imenovani overjen dostop, tako da ni bil odprt za zlorabe s strani kogarkoli od koder koli.

Toda hitro se je izkazalo, da bi bilo na mnogih strežnikih Exchange poznavanje prijavnega imena in gesla katerega koli uporabnika dovolj, da bi prešel kot preverjen in izvedel ta napad, tudi če bi ta uporabnik sam moral uporabiti dvostopenjsko avtentikacijo (2FA) za pravilno prijavo za dostop njihov e-poštni naslov.

Kot Sophosov strokovnjak Chester Wisniewski stavi ob uri:

To je "ranljivost vmesne avtentikacije", če temu tako želite reči. To je mešan blagoslov. To pomeni, da avtomatizirani skript Python ne more samo pregledati celotnega interneta in potencialno izkoristiti vsakega strežnika Exchange na svetu v nekaj minutah ali urah, kot smo videli, da se je zgodilo s ProxyLogon in ProxyShell leta 2021. […]

Potrebujete geslo, vendar iskanje kombinacije e-poštnega naslova in gesla, veljavne na katerem koli strežniku Exchange, na žalost verjetno ni preveč težko. In morda do danes še niste bili izkoriščeni, ker za uspešno prijavo v Outlook Web Access [OWA] potrebujete njihov žeton FIDO ali njihov overitelj ali kateri koli drugi dejavnik, ki ga morda uporabljate.

Toda ta napad ne zahteva drugega dejavnika. […] Samo pridobitev kombinacije uporabniškega imena in gesla je precej nizka ovira.

Kot se verjetno spomnite, smo mnogi domnevali (ali vsaj upali), da bo Microsoft pohitel z odpravo lukenj v lupini ProxyNotShell, glede na to, da sta do oktobrskega torka popravka ostala še dva tedna.

Vendar smo bili razočarani, ko smo ugotovili, da je očitno zanesljiva rešitev bolj zapleteno od pričakovanega, oktober pa je prišel in odšel s ProxyNotShell, ki je bil obravnavan samo z rešitvami, ne pa z ustreznimi popravki.

Tudi novembrski torek popravkov ni neposredno zagotovil potrebnih popravkov, čeprav popravki vseeno prišel ven na isti dan kot del varnostne posodobitve, specifične za Exchange, ki jo je mogoče pridobiti in namestiti ločeno:

Razkrit dokaz koncepta

Zdaj, ko se je prah polegel in so imeli vsi čas, da popravijo svoje strežnike Exchange (vsaj tiste, na katere niso pozabili), so raziskovalci pri Zero Day Initiative (ZDI), ki so jim bile te ranljivosti prvotno odgovorno razkrite za predložitev Microsoft, razložili kako je mogoče hrošče izkoristiti.

Slaba novica, odvisno od vašega mnenja o očitnih razkritjih izkoriščanja, je, da je ekipa ZDI zdaj dejansko zagotovila dokaz koncepta (PoC), ki pojasnjuje, kako napasti strežnike Exchange.

Dobra novica je seveda, da:

• Zdaj lahko hrošče preučujemo in razumemo sami. To nam ne samo pomaga zagotoviti, da bodo splošni previdnostni ukrepi, ki smo jih sprejeli (ne samo omejeni na popravke), verjetno zagotovili zaščito, ki jo pričakujemo, ampak nas tudi obvešča o praksah programiranja, ki se jim bomo v prihodnosti želeli izogniti, zato ne Ne pustimo se ujeti v odpiranje tovrstnih hroščev v naši kodi na strani strežnika.
• Zdaj nimamo več izgovorov, da ne namestimo popravkov. Če smo s posodabljanjem odlašali, razlaga ZDI o tem, zakaj napad deluje, jasno pokaže, da je zdravilo vsekakor bolje kot bolezen.

Kako deluje

ZDI-jev Razlaga te ranljivosti naredi fascinantno zgodbo o tem, kako zapleteno je lahko povezati vse dele, ki jih potrebujete, da ranljivost spremenite v izvedljivo izkoriščanje.

Prav tako je vredno prebrati, da boste lažje razumeli, zakaj lahko kopanje po obstoječem izkoriščanju pomaga odkriti druge načine, kako bi lahko zlorabili ranljivost, kar bi lahko povzročilo dodatne popravke, pozvalo k spremembam konfiguracije in spodbujalo nove programerske prakse, ki morda niso bile očitne samo po popravku. originalna luknja.

Razlaga je nujno zapletena in precej tehnična ter vas vodi naprej skozi dolgo vrsto korakov, da na koncu dosežete oddaljeno izvajanje kode (RCE).

V upanju, da vam bo pomagal lažje slediti podrobnostim na visoki ravni, če se odločite prebrati poročilo ZDI, je tukaj, upajmo, ne preveč poenostavljen povzetek s koraki, navedenimi v obratni smeri ...

... tako da boste vnaprej vedeli, zakaj zgodba vzame smeri, ki jih vzame:

• KORAK 4. Exchange na daljavo preslepite, da ustvari primerek predmeta .NET po vaši izbiri z inicializacijskim parametrom po vaši izbiri.

V sodobnem kodiranju je an instancirani predmet je žargonska beseda za dodeljen kos pomnilnika, ki se samodejno inicializira s podatki in viri, ki jih bo potreboval, medtem ko je v uporabi, in vezan na določen nabor funkcij, ki lahko delujejo z njim. (Ustvari primerek je samo modna beseda za ustvarjajo.)

Objekte lahko upravlja in nadzira operacijski sistem sam, da se izognete vrstam napak pri slabem upravljanju pomnilnika, ki so pogoste v jeziku, kot je C, kjer morate običajno sami dodeliti pomnilnik, ročno izpolniti ustrezna podatkovna polja in ne pozabite sprostite pomnilnik in vire, ki jih uporabljate, kot so omrežne vtičnice ali diskovne datoteke, ko končate.

Objekti imajo na splošno z njimi povezano programsko funkcijo, imenovano a konstruktor, ki se samodejno izvede, ko se ustvari nov objekt, da se dodeli prava količina pomnilnika in pravilen nabor sistemskih virov.

Običajno morate konstruktorju posredovati enega ali več parametrov kot argumente, da označite, kako želite, da je objekt konfiguriran, ko se zažene.

Preprosto povedano, če ustvarite, recimo, a TextString objekt (ta imena si izmišljujemo, vendar razumete) z uporabo parametra, ki je sam besedilni niz, kot je example.com:8888...

...verjetno boste na koncu imeli pomnilniški medpomnilnik, dodeljen za shranjevanje vašega besedila, inicializiran tako, da vsebuje isto vrednost, ki ste jo posredovali, namreč neobdelano besedilo example.com:8888.

V tem kontekstu besedilni niz, posredovan konstruktorju objekta kot podatek, takoj ne predstavlja nobene očitne grožnje kibernetski varnosti, ko sprožite konstruktor na daljavo, razen možne zavrnitve storitve (DoS) z večkratnim zahtevanjem večjih in večjih nizov za poskusite izčrpati spomin.

Ampak, če bi instancirali, recimo, a ConnectedTCPClient objekt z uporabo istega parametra besedilnega niza example.com:8888, lahko na koncu dobite medpomnilnik, pripravljen za shranjevanje začasnih podatkov, skupaj z omrežno vtičnico, ki jo dodeli operacijski sistem in je pripravljena za izmenjavo podatkov s strežnikom example.com prek vrat TCP 8888.

Tam lahko opazite tveganje oddaljenega izvajanja kode, tudi če nikoli ne pošljete nobenih podatkov v odprto vtičnico, glede na to, da ste strežnik pretentali, da je poklical domov na lokacijo, ki jo nadzorujete.

Morda celo najdete predmet, imenovan npr. RunCmdAndReadOutput, kjer je besedilni niz, ki ga pošljete kot parameter, dobesedno ukaz, ki ga želite zagnati samodejno, takoj ko je predmet ustvarjen, tako da lahko pozneje zberete njegov rezultat.

Tudi če nikoli ne morete obnoviti izhoda ukaza, bi samo instanciranje takega objekta kljub temu omogočilo izbiro ukaza za izvajanje, kar bi vam omogočilo generično oddaljeno izvajanje kode in predstavljalo tveganje, omejeno le s pravicami dostopa samega strežniškega procesa. .

Seveda je napad tako enostaven šele, ko pridete do zadnje stopnje, česar pa naj ne bi mogli storiti, ker ima Exchange strog seznam dovoljenih, ki vam preprečuje, da bi izbrali kateri koli stari predmet za primerek.

Teoretično je mogoče prek lupine PowerShell na daljavo ustvariti samo varne objekte ali objekte z nizkim tveganjem, tako da instanciranje našega namišljenega TextString zgoraj ali a SimpleIntegerValue, se lahko šteje za sprejemljivo, medtem ko a ConnectedTCPClient ali RunCmdAndReadOutput zagotovo ne bi bilo.

Toda raziskovalci ZDI opažajo, da bi lahko storili to, preden so sprožili zadnji korak:

• 3. KORAK. Exchange na daljavo preslepite, da misli, da je predmet z nizkim tveganjem, ki je opravil varnostni preizkus, v resnici nek drug predmet po vaši izbiri.

Kljub temu lahko pričakujete, da bo Exchange preprečil oddaljeno ustvarjanje celo objektov z nizkim tveganjem, da bi še bolj zmanjšal grožnjo.

Toda raziskovalci so ugotovili, da bi lahko:

• KORAK 2. Exchange na daljavo preslepite, da bo uporabil svoj PowerShell Remoting funkcija za ustvarjanje predmeta na podlagi parametrov inicializacije, nadzorovanih od zunaj.

In to je bilo mogoče zaradi luknje, podobne ProxyShell, ki je bila le delno zakrpana:

• KORAK 1. Exchange na daljavo preslepite, da sprejme in obdela spletno zahtevo s kodo, tako da zapakirate veljavno username:password polje tudi v zahtevo.

Tudi če uporabnik, imenovan v zahtevi, dejansko ni bil prijavljen in bi moral iti skozi nekakšen postopek 2FA za dostop do lastnega nabiralnika, napadalec, ki je poznal njihov username:password kombinacija bi imela dovolj informacij za preverjanje pristnosti, da bi prevarala Exchange, da sprejme spletno povezavo, ki bi se lahko uporabila za začetek verige napadov, opisane v korakih 2 do 4 zgoraj.

Ohlapno rečeno, vse veljavno username:password kombinacija bi zadostovala, glede na to, da je bila »preverjanje pristnosti« potrebna zgolj zato, da prepreči, da bi Exchange vnaprej zavrnil zahtevo HTTP.

Kaj storiti?

Upoštevajte, da ta napad deluje samo:

• Če imate strežnike Exchange na mestu uporabe. Microsoft trdi, da je hitro zaklenil lastne storitve v oblaku, tako da Exchange Online ni prizadet. Prepričaj se da vedeti, kje so vaši strežniki Exchange. Tudi če zdaj uporabljate Exchange Online, imate morda še vedno delujoče strežnike na mestu uporabe, ki so morda po pomoti ostali v procesu selitve.
• Če vaši strežniki niso popravljeni. Poskrbite, da boste imeli uporabil posodobitev programske opreme Exchange z dne 2022 do zapreti ranljivosti ki jih izkoriščanje zahteva.
• Če vaši strežniki še vedno sprejemajo osnovno avtentikacijo, znano tudi kot stara avtentikacija. Poskrbite, da boste imeli blokiral vse vidike podedovane avtentikacije tako da vaši strežniki ne bodo sprejeli username:password glave, omenjene zgoraj, in sploh ne bo sprejel tveganih zahtev protokola za samodejno odkrivanje. to ustavi napadalce prevare strežnika, da sprejme njihove trike instanciranja ujetih predmetov, tudi če ta strežnik ni popravljen.

Ti lahko spremljate naših uradnih nasvetov za preprečevanje, sanacijo in odzivanje, stranke Sophosa pa lahko spremljajo imena za odkrivanje groženj, ki jih uporabljajo naši izdelki, prek vira Sophos X-Ops Twitter (@SophosXOps).

Objavljene so bile nove informacije o CVE-2022-41040 in CVE-2022-41082: https://t.co/pHUVBjUeDI 1/3

— Sophos X-Ops (@SophosXOps) November 21, 2022

---

VEČ O PREVERJANJU EXCHANGE IN OAUTH2

S Paulom Ducklinom in Chesterjem Wisniewskim
Uvodna in končna glasba avtorja Edith Mudge.

---