Kuidas häkkida paigatamata Exchange'i serverit võltsitud PowerShelli koodiga

Veidi vähem kui kaks kuud tagasi avaldati murettekitavaid veauudiseid: Microsoft Exchange'is teatati paarist nullpäeva haavatavusest.

Nagu me soovitas toona, need haavatavused on ametlikult määratud CVE-2022-41040 ja CVE-2022-41082:

[oli] kaks nullpäeva, mida [sai] kokku aheldada, kusjuures esimest viga kasutati eemalt, et avada piisavalt auk, et käivitada teine ​​viga, mis potentsiaalselt võimaldab Exchange'i serveris endas koodi kaugkäivitamist (RCE).

Esimene haavatavus meenutas tülikat ja laialdaselt kuritarvitatud ProxyShelli turvaauk 2021. aasta augustist, kuna see tugines ohtlikule käitumisele Exchange'i automaattuvastusfunktsioonis, kirjeldas Microsoft protokollina, mis on "kasutavad Outlooki ja EAS-i [Exchange ActiveSynci] kliendid Exchange'i postkastide otsimiseks ja nendega ühenduse loomiseks".

Õnneks oli Autodiscoveri tõrge, mida iga kaugkasutaja, olenemata sellest, kas ta oli sisse logitud või mitte, ProxyShelli rünnakus ära kasutada. lapitud rohkem kui aasta tagasi.

Kahjuks ei aidanud ProxyShelli plaastrid autenditud kasutajate ärakasutamise sulgemiseks piisavalt, mis viis uue CVE-2022-40140 nullpäevani, mis oli peagi lakooniliselt, kui eksitavalt, dubleeritud ProxyNotShell.

Mitte nii ohtlik, aga ohtlik siiski

On selge, et ProxyNotShell polnud kaugeltki nii ohtlik kui algne ProxyShell, arvestades, et see nõudis nn autentitud juurdepääsu, nii et see ei olnud avatud kuritarvitamiseks ükskõik kelle poolt.

Kuid kiiresti selgus, et paljudes Exchange'i serverites piisaks iga kasutaja sisselogimisnime ja parooli teadmisest, et läbida autentimine ja rünnak, isegi kui see kasutaja peaks ise kasutama kahefaktorilist autentimist (2FA), et juurdepääsuks korralikult sisse logida. nende email.

Nagu Sophose ekspert Chester Wisniewski pane see sellel ajal:

See on "keskmise autentimise haavatavus", kui soovite seda nii nimetada. See on segane õnnistus. See tähendab, et automatiseeritud Pythoni skript ei saa lihtsalt skannida kogu Internetti ja potentsiaalselt ära kasutada iga Exchange'i serverit maailmas mõne minuti või tunniga, nagu nägime ProxyLogoni ja ProxyShelli puhul 2021. aastal. […]

Teil on vaja parooli, kuid ühe Exchange'i serveris kehtiva e-posti aadressi ja parooli kombinatsiooni leidmine pole kahjuks liiga keeruline. Võimalik, et teid pole siiani ära kasutatud, sest Outlook Web Accessi [OWA] edukaks sisselogimiseks on vaja nende FIDO-märki või autentimist või mis tahes teist tegurit, mida te kasutate.

Kuid see rünnak ei nõua seda teist tegurit. […] Lihtsalt kasutajanime ja parooli kombinatsiooni hankimine on üsna madal takistus.

Nagu te ilmselt mäletate, eeldasid paljud meist (või vähemalt lootsid), et Microsoft kiirustab ProxyNotShelli auke parandama, kuna oktoobri plaastri teisipäevani on jäänud veel kaks nädalat.

Kuid olime pettunud, kui avastasime, et ilmselt oli usaldusväärne lahendus oodatust keerulisem, ja oktoober tuli ja läks, kuna ProxyNotShell oli lahendatud ainult lahenduste, mitte korralike paikade abil.

Isegi novembrikuine plaastri teisipäev ei andnud vajalikke parandusi, kuigi paigad tuli siiski välja Samal päeval Exchange-spetsiifilise turvavärskenduse osana, mida saab eraldi tuua ja installida:

Ilmnes kontseptsiooni tõestus

Nüüd, kui tolm on maha vajunud ja kõigil on olnud aega oma Exchange'i servereid lappida (vähemalt need, mida nad pole unustanud), teatasid Zero Day Initiative'i (ZDI) teadlased, kellele need haavatavused algselt vastutustundlikult avalikustati. Microsoft, on selgitanud kuidas vigu ära kasutada.

Halb uudis, olenevalt teie arvamusest avaliku kasutamise avalikustamise kohta, on see, et ZDI meeskond on nüüd tõhusalt esitanud kontseptsiooni tõendi (PoC), mis selgitab, kuidas Exchange'i servereid rünnata.

Hea uudis on muidugi see:

• Nüüd saame vigu ise uurida ja mõista. See mitte ainult ei aita meil kõigil tagada, et võetud üldised ettevaatusabinõud (mitte ainult lappimisega) tagaksid tõenäoliselt ootuspärase kaitse, vaid teavitavad meid ka programmitöö praktikatest, mida soovime tulevikus vältida, nii et Ärge sattuge meie enda serveripoolses koodis seda tüüpi vigade avamisse.
• Meil pole nüüd vabandusi plaastrite mittepanemiseks. Kui oleme värskendamisega venitanud, annab ZDI selgitus, miks rünnak toimib, selgeks, et ravi on kindlasti parem haigusele.

Kuidas see töötab?

ZDI-d selgitus Sellest haavatavusest loob põneva loo sellest, kui keeruline võib olla kõigi vajalike osade aheldamine, et muuta haavatavus elujõuliseks ärakasutamiseks.

Seda tasub lugeda ka selleks, et mõistaksite, miks olemasolevasse ärakasutamisse süvenemine võib aidata avastada muid haavatavuse väärkasutamise viise, mis võib nõuda täiendavaid paigad, nõuda konfiguratsiooni muutmist ja edendada uusi programmeerimisvõtteid, mis ei pruugi olla ilmnenud juba pärast parandamist. originaalne auk.

Seletus on paratamatult keeruline ja üsna tehniline ning viib teid läbi pikkade sammude seeria, et saavutada lõpuks koodi kaugkäivitus (RCE).

Lootuses aidata teil ZDI aruannet lugeda lihtsamini kõrgetasemelisi üksikasju järgides, on siin loodetavasti mitte liiga lihtsustatud kokkuvõte koos vastupidises järjekorras loetletud sammudega…

…nii et sa tead juba ette, miks see lugu võtab selle suuna:

• 4. SAMM. Peidake Exchange'il eemalt teie valitud .NET-objekti instantseerimiseks teie valitud lähtestamisparameetriga.

Kaasaegses kodeerimises on an instantseeritud objekt on žargooniline sõna eraldatud mälutüki jaoks, mis initsialiseeritakse automaatselt andmete ja ressurssidega, mida see kasutamise ajal vajab, ning on seotud konkreetse funktsioonide komplektiga, mis saab sellega töötada. (Instantseerige on lihtsalt väljamõeldud sõna looma.)

Objekte võib hallata ja juhtida operatsioonisüsteem ise, et aidata vältida selliseid mälu valesti haldamise vigu, mis on levinud sellistes keeltes nagu C, kus tavaliselt peate ise mälu eraldama, käsitsi täitma asjakohased andmeväljad ja pidage meeles kui olete lõpetanud, vabastage mälu ja kasutatavad ressursid (nt võrgupesad või kettafailid).

Objektidega on üldiselt seotud programmiline funktsioon, mida nimetatakse a konstruktor, mis käivitatakse automaatselt uue objekti loomisel, et eraldada õige mälumaht ja õige komplekt süsteemiressursse.

Tavaliselt peate konstruktorile argumendina edastama ühe või mitu parameetrit, et näidata, kuidas soovite objekti käivitamisel konfigureerida.

Lihtsamalt öeldes, kui instantseerite näiteks a TextString objekt (me mõtleme need nimed välja, aga saate aru), kasutades parameetrit, mis ise on tekstistring, näiteks example.com:8888...

...saate tõenäoliselt lõpuks oma teksti hoidmiseks eraldatud mälupuhvri, mis on initsialiseeritud nii, et see sisaldab sama väärtust, mille sisestasite, nimelt toorteksti example.com:8888.

Selles kontekstis ei kujuta objektikonstruktorile andmetena edastatud tekstistring konstruktori eemalt käivitamisel kohe mingit ilmset küberjulgeoleku ohtu, välja arvatud võimalik teenuse keelamine (DoS), küsides korduvalt suuremaid ja suuremaid stringe. proovige mälu ammendada.

Aga kui te instantseeriksite, ütleme näiteks a ConnectedTCPClient objekti, mis kasutab sama tekstistringi parameetrit example.com:8888, võite saada ajutiste andmete hoidmiseks valmis mälupuhvri ja operatsioonisüsteemi eraldatud võrgupesa, mis on valmis serveriga andmeid vahetama. example.com üle TCP-pordi 8888.

Näete seal koodi kaugkäitamise riski, isegi kui te ei saa kunagi avatud pistikupesasse andmeid saata, kuna olete petnud serverit helistama koju teie juhitavasse asukohta.

Võite isegi leida objekti, mida nimetatakse näiteks RunCmdAndReadOutput, kus parameetrina saadetav tekstistring on sõna otseses mõttes käsk, mida soovite kohe objekti loomisel automaatselt käivitada, et saaksite selle väljundit hiljem koguda.

Isegi kui te ei saa kunagi käsu väljundit taastada, võimaldab lihtsalt sellise objekti käivitamine teil siiski valida käivitatava käsu, mis annab teile üldise koodi kaugkäitamise ja kujutab endast ohtu, mida piiravad ainult serveriprotsessi enda juurdepääsuõigused .

Loomulikult on rünnak nii lihtne alles siis, kui jõuate viimasesse etappi, mida te ei tohiks teha, sest Exchange'il on range lubade loend, mis takistab teil valida eksemplarimiseks mis tahes vana objekti.

Teoreetiliselt saab kaugjuhtimisega PowerShelli kaudu luua ainult turvalisi või madala riskitasemega objekte, nii et meie kujutlusvõime TextString eespool või a SimpleIntegerValue, võib pidada vastuvõetavaks, samas kui a ConnectedTCPClient või RunCmdAndReadOutput kindlasti ei oleks.

Kuid ZDI teadlased märkavad, et enne viimase sammu käivitamist said nad seda teha:

• 3. SAMM. Püüdke end eemalt meelitada mõttele, et ohutustesti läbinud madala riskiastmega objekt on tegelikult mõni muu teie valitud objekt.

Sellegipoolest võite eeldada, et Exchange takistab isegi madala riskiga objektide kaugloomist, et ohtu veelgi minimeerida.

Kuid teadlased leidsid, et nad võivad:

• 2. SAMM. meelitage Exchange'i kaugjuhtimisega kasutama PowerShelli kaugjuhtimine funktsioon objekti loomiseks, mis põhineb väliselt juhitavatel lähtestamisparameetritel.

Ja see oli võimalik tänu ProxyShelli sarnasele augule, mis oli ainult poolpaigatud:

• 1. SAMM. Peidake Exchange'il kaugjuhtimisega koodiga veebipäring vastu võtma ja töötlema, pakkides kehtiva päringu username:password välja ka päringusse.

Isegi kui taotluses nimetatud kasutaja ei olnud tegelikult sisse logitud ja peaks oma postkastile juurdepääsuks läbima mingisuguse 2FA protsessi, ründaja, kes teadis oma username:password kombinatsioonil oleks piisavalt autentimisteavet, et meelitada Exchange'i vastu võtma veebiühendust, mida saaks kasutada ülaltoodud sammudes 2–4 kirjeldatud rünnakuahela käivitamiseks.

Vabalt öeldes, mis tahes kehtiv username:password kombinatsioon sobiks, arvestades, et "autentimist" oli vaja lihtsalt selleks, et takistada Exchange'i HTTP-päringu tagasilükkamist.

Mida teha?

Pange tähele, et see rünnak töötab ainult:

• Kui teil on kohapealsed Exchange'i serverid. Microsoft väidab, et lukustas oma pilveteenused kiiresti, seega Exchange Online'i see ei mõjuta. Veenduge, et teie teada, kus teie Exchange'i serverid asuvad. Isegi kui kasutate praegu Exchange Online'i, võivad teil endiselt töötada kohapealsed serverid, mis võib-olla on teie migratsiooniprotsessist kogemata jäänud.
• Kui teie serverid on parandamata. Veenduge, et olete rakendas Exchange'i tarkvaravärskenduse 2022-11-08 et sulgege haavatavused mida ärakasutamine nõuab.
• Kui teie serverid aktsepteerivad endiselt põhiautentimist, mida nimetatakse ka pärandautentimiseks. Veenduge, et olete blokeeris kõik pärandautentimise aspektid nii et teie serverid ei aktsepteeri seda username:password ülalmainitud päised ja ei aktsepteeri riskantseid automaattuvastusprotokolli taotlusi. See peatab ründajad meelitades serverit aktsepteerima nende lõksus olevate objektide leidmise trikke, isegi kui see server pole paigatud.

Võite jälgi meie ametlikest ennetus-, heastamis- ja reageerimisnõuannetest ning Sophose kliendid saavad jälgida meie toodetes kasutatavaid ohutuvastusnimesid Sophos X-Opsi Twitteri voo kaudu (@SophosXOps).

CVE-2022-41040 ja CVE-2022-41082 kohta on avaldatud uus teave: https://t.co/pHUVBjUeDI 1/3

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

---

LUGEGE LISATEAVE EXCHANGE AUTENTIMISE JA OAUTH2 KOHTA

Koos Paul Ducklini ja Chester Wisniewskiga
Intro ja outro muusika autor Edith Mudge.

---