Hogyan lehet feltörni egy javítatlan Exchange-kiszolgálót hamis PowerShell-kóddal

Alig két hónappal ezelőtt aggasztó hibahírek jelentek meg: egy pár nulladik napi sebezhetőséget jelentettek be a Microsoft Exchange-ben.

Mint mi tanácsolta annak idején, ezeket a sebezhetőségeket hivatalosan megjelölték CVE-2022 41040- és a CVE-2022 41082-:

[volt] két nulla nap, amelyet [lehet] összeláncolni, és az első hibát távolról használták ahhoz, hogy elegendő lyukat nyissunk a második hiba elindításához, amely potenciálisan lehetővé teszi a távoli kódfuttatást (RCE) magán az Exchange szerveren.

Az első sebezhetőség a problémás és széles körben visszaélt résekre emlékeztetett ProxyShell biztonsági lyuk 2021 augusztusától, mert veszélyes viselkedésre támaszkodott az Exchange Autodiscover funkciójában, írta le a Microsoft mint egy protokoll, ami az „Az Outlook és az EAS [Exchange ActiveSync] kliensek használják postafiókok megkeresésére és csatlakozására az Exchange szolgáltatásban”.

Szerencsére az Autodiscover hibája, amelyet bármely távoli felhasználó kihasználhatott a ProxyShell támadásban, függetlenül attól, hogy bejelentkezett-e vagy sem, több mint egy éve foltozva.

Sajnos a ProxyShell javítások nem tettek eleget ahhoz, hogy lezárják a kizsákmányolást a hitelesített felhasználók előtt, ami az új CVE-2022-40140 nulladik napjához vezetett, ami hamarosan lakonikusan, ha megtévesztően is, szinkronizált ProxyNotShell.

Nem annyira veszélyes, de veszélyes

Nyilvánvaló, hogy a ProxyNotShell közel sem volt olyan veszélyes, mint az eredeti ProxyShell, tekintve, hogy az úgynevezett hitelesített hozzáférést igényelte, így nem volt kitéve bárki, bárhonnan való visszaélésnek.

De gyorsan kiderült, hogy sok Exchange-szerveren bármely felhasználó bejelentkezési nevének és jelszavának ismerete elegendő lenne a hitelesítéshez és a támadáshoz, még akkor is, ha a felhasználónak magának is kétfaktoros hitelesítést (2FA) kell használnia a megfelelő bejelentkezéshez a hozzáféréshez. az e-mailjüket.

Mint a Sophos szakértője, Chester Wisniewski tedd akkor:

Ez egy „közepes hitelesítési sebezhetőség”, ha annak akarod nevezni. Ez vegyes áldás. Ez azt jelenti, hogy egy automatizált Python-szkript nem képes egyszerűen átvizsgálni az egész internetet, és potenciálisan kihasználni a világ minden Exchange-kiszolgálóját percek vagy órák alatt, ahogyan azt a ProxyLogon és a ProxyShell esetében 2021-ben láthattuk. […]

Szüksége van egy jelszóra, de sajnos valószínűleg nem túl nehéz megtalálni az adott Exchange szerveren érvényes e-mail cím és jelszó kombinációt. És lehet, hogy eddig még nem használta ki, mert az Outlook Web Access [OWA] sikeres bejelentkezéséhez szükség van a FIDO-tokenre vagy a hitelesítőjükre, vagy bármely más használt tényezőre.

De ehhez a támadáshoz nincs szükség a második tényezőre. […] A felhasználónév és a jelszó kombinációjának megszerzése meglehetősen alacsony akadály.

Valószínűleg emlékszel rá, hogy sokan közülünk azt feltételezték (vagy legalábbis reméltük), hogy a Microsoft rohanni fog a ProxyNotShell-lyukak kijavítására, tekintettel arra, hogy még két hét van hátra az októberi javítási keddig.

De csalódottan tapasztaltuk, hogy látszólag megbízható megoldás született a vártnál bonyolultabb, és az október jött és ment, a ProxyNotShell-lel csak a megoldások, nem pedig a megfelelő javítások foglalkoztak.

Még a novemberi javítási kedd sem biztosította közvetlenül a szükséges javításokat, bár a javítások ennek ellenére kijött ugyanazon a napon egy Exchange-specifikus biztonsági frissítés részeként, amely külön letölthető és telepíthető:

Kiderült a koncepció bizonyítása

Most, hogy a por leülepedett, és mindenkinek volt ideje kijavítani az Exchange-szervereit (azokat, amelyekről legalábbis nem feledkezett meg), a Zero Day Initiative (ZDI) kutatói, akiknek eredetileg felelősen nyilvánosságra hozták ezeket a sebezhetőségeket, hogy benyújtsák őket Microsoft, magyarázták hogyan lehet kihasználni a hibákat.

A rossz hír, attól függően, hogy miként vélekedik a nyílt kizsákmányolásról, az az, hogy a ZDI csapata most hatékonyan elkészítette a proof-of-concept (PoC) dokumentumot, amely elmagyarázza, hogyan támadják meg az Exchange szervereket.

A jó hír természetesen az, hogy:

• Most már magunk is tanulmányozhatjuk és megérthetjük a hibákat. Ez nemcsak abban segít, hogy az általunk megtett általános óvintézkedések (nem pusztán a javításra korlátozódva) biztosítsák az elvárt védelmet, hanem tájékoztat minket azokról a programozási gyakorlatokról is, amelyeket a jövőben el kívánunk kerülni, ezért Ne essünk csapdába az ilyen jellegű hibák feltárásában a saját szerveroldali kódunkban.
• Most már nincs mentségünk arra, hogy ne alkalmazzuk a javításokat. Ha elhúztuk a lábunkat a frissítéssel, a ZDI magyarázata arra vonatkozóan, hogy miért működik a támadás, egyértelművé teszi, hogy a gyógyítás mindenképpen előnyösebb, mint a betegség.

Hogyan működik?

ZDI-k magyarázat Ennek a sérülékenységnek a lenyűgöző története arról szól, milyen bonyolult lehet összeláncolni az összes olyan részt, amelyre szükség van ahhoz, hogy a sebezhetőséget életképes kihasználássá alakítsd.

Érdemes elolvasni azt is, hogy megértse, miért segíthet a biztonsági résekkel való visszaélés más módjainak feltárásában, amelyek további javításokat kérhetnek, konfigurációs változtatásokat sürgetnek, és olyan új programozási gyakorlatokat népszerűsítenek, amelyek esetleg nem lettek nyilvánvalóak a javítás után. az eredeti lyuk.

A magyarázat szükségképpen bonyolult és meglehetősen technikai jellegű, és egy hosszú lépéssorozaton keresztül vezet előre, hogy a végén elérje a távoli kódvégrehajtást (RCE).

Abban a reményben, hogy könnyebben követheti a magas szintű részleteket, ha úgy dönt, hogy elolvassa a ZDI-jelentést, íme egy remélhetőleg nem túl leegyszerűsített összefoglaló a fordított lépésekkel…

…tehát előre tudni fogja, hogy a történet miért követi az irányt:

• 4. LÉPÉS: Távolról csalja meg az Exchange-t, hogy egy tetszőleges .NET objektumot példányosítson egy tetszőleges inicializálási paraméterrel.

A modern kódolásban an példányosított objektum a szakzsargon szó egy lefoglalt memóriadarabot jelöl, amely automatikusan inicializálódik azokkal az adatokkal és erőforrásokkal, amelyekre használat közben szüksége lesz, és egy adott funkciókészlethez van kötve, amely képes működni rajta. (Példányosítás csak egy divatos szó erre teremt.)

Az objektumokat maga az operációs rendszer is felügyelheti és vezérelheti, hogy elkerülje az olyan típusú memóriahelytelen kezelési hibákat, amelyek gyakoriak az olyan nyelvekben, mint a C, ahol általában magának kell memóriát lefoglalnia, kézzel kell kitöltenie a megfelelő adatmezőket, és ne felejtse el Ha végzett, engedje fel a memóriát és az erőforrásokat, például a hálózati socketeket vagy a lemezfájlokat.

Az objektumokhoz általában egy programozott funkció tartozik, amelyet a konstruktőr, amely automatikusan végrehajtódik egy új objektum létrehozásakor, hogy lefoglalja a megfelelő mennyiségű memóriát és a megfelelő rendszererőforrás-készletet.

Általában egy vagy több paramétert kell átadnia argumentumként a konstruktornak, hogy jelezze, hogyan szeretné konfigurálni az objektumot, amikor elindul.

Egyszerűen fogalmazva, ha példányosít, mondjuk, a TextString objektumot (ezeket a neveket kitaláljuk, de érted) egy olyan paraméter használatával, amely maga egy szöveges karakterlánc, mint pl. example.com:8888...

…valószínűleg egy memóriapuffert kap a szöveg tárolására, inicializálva, hogy ugyanazt az értéket tartalmazza, amelyet átadott, nevezetesen a nyers szöveget example.com:8888.

Ebben az összefüggésben az objektumkonstruktornak adatként átadott szöveges karakterlánc nem jelent azonnal semmilyen nyilvánvaló kiberbiztonsági fenyegetést, amikor távolról elindítja a konstruktort, kivéve a lehetséges szolgáltatásmegtagadást (DoS) azáltal, hogy ismételten nagyobb és nagyobb karakterláncokat kér. próbálja kimeríteni a memóriát.

De ha példányosítana, mondjuk a ConnectedTCPClient objektum ugyanazt a szöveges karakterlánc-paramétert használja example.com:8888, akkor előfordulhat, hogy egy memóriapuffer készen áll az ideiglenes adatok tárolására, valamint az operációs rendszer által lefoglalt hálózati aljzat, amely készen áll az adatcserére a szerverrel. example.com TCP porton keresztül 8888.

Láthatja ott a távoli kódvégrehajtás kockázatát, még akkor is, ha soha nem küld adatot a nyitott socketre, mivel becsapta a kiszolgálót, hogy egy Ön által irányított helyet hívjon haza.

Még az is lehet, hogy talál egy tárgyat, amit mondjuk RunCmdAndReadOutput, ahol a paraméterként küldött szöveges karakterlánc szó szerint egy olyan parancs, amelyet automatikusan le akarunk futtatni, amint az objektum létrejön, így később összegyűjtheti a kimenetét.

Még ha soha nem is állíthatja vissza a parancs kimenetét, egy ilyen objektum példányosítása mégis lehetővé teszi a futtatandó parancs kiválasztását, így általános távoli kódvégrehajtást biztosít, és olyan kockázatot jelent, amelyet csak magának a szerverfolyamatnak a hozzáférési jogai korlátoznak. .

Természetesen a támadás csak akkor lesz ilyen egyszerű, ha eléri az utolsó szakaszt, amit nem szabad megtennie, mert az Exchange szigorú engedélyezési listával rendelkezik, amely megakadályozza, hogy bármilyen régi objektumot válasszon példányosításra.

Elméletileg csak biztonságos vagy alacsony kockázatú objektumok hozhatók létre távolról a PowerShell-en keresztül, így a képzeletünk példányosítható. TextString fent, vagy a SimpleIntegerValue, elfogadhatónak tekinthető, míg a ConnectedTCPClient vagy RunCmdAndReadOutput biztosan nem lenne.

De a ZDI kutatói észreveszik, hogy mielőtt az utolsó lépést elindították volna, ezt megtehették:

• 3. LÉPÉS: Távolról csalja meg az Exchange-et, hogy azt gondolja, hogy egy alacsony kockázatú objektum, amely átment a biztonsági teszten, valójában egy másik, az Ön által választott objektum.

Ennek ellenére elvárható, hogy az Exchange még az alacsony kockázatú objektumok távoli létrehozását is megakadályozza, hogy még tovább csökkentse a fenyegetést.

De a kutatók azt találták, hogy képesek:

• 2. LÉPÉS: Távolról rávegye az Exchange használatát PowerShell távoli funkció egy objektum létrehozásához külsőleg vezérelt inicializálási paraméterek alapján.

És ez a ProxyShell-szerű lyuk miatt volt lehetséges, amely csak félig volt foltozva:

• 1. LÉPÉS: Távolról csalja meg az Exchange-et, hogy elfogadjon és feldolgozzon egy kódot tartalmazó webes kérelmet egy érvényes kód becsomagolásával username:password mezőt is a kérésbe.

Még akkor is, ha a kérésben megnevezett felhasználó valójában nem volt bejelentkezve, és valamilyen 2FA folyamaton kell keresztülmennie, hogy hozzáférjen saját postafiókjához, akkor is egy támadó, aki tudta, username:password kombináció elegendő hitelesítési információval rendelkezik ahhoz, hogy rávegye az Exchange-et egy olyan webkapcsolat elfogadására, amely felhasználható a fenti 2–4. lépésben leírt támadási lánc elindítására.

Lazán szólva minden érvényes username:password kombináció megtenné, mivel a „hitelesítésre” egyszerűen azért volt szükség, hogy az Exchange ne utasítsa el a HTTP-kérést.

Mit kell tenni?

Vegye figyelembe, hogy ez a támadás csak akkor működik:

• Ha vannak helyszíni Exchange-kiszolgálói. A Microsoft azt állítja, hogy gyorsan lezárta saját felhőszolgáltatásait, így az Exchange Online-t ez nem érinti. Győződjön meg róla tudja, hol vannak az Exchange szerverei. Még ha most is használja az Exchange Online-t, előfordulhat, hogy továbbra is futnak a helyszíni kiszolgálók, amelyek tévedésből megmaradtak az áttelepítési folyamatból.
• Ha a szerverei nincsenek javítva. Győződjön meg arról, hogy van alkalmazta a 2022-11-08 Exchange szoftverfrissítést nak nek zárja el a sebezhetőségeket amit az exploit megkövetel.
• Ha a szerverei továbbra is elfogadják az alapszintű hitelesítést, más néven örökölt hitelesítést. Győződjön meg arról, hogy van blokkolta az örökölt hitelesítés minden aspektusát így a szerverei nem fogadják el a username:password a fent említett fejléceket, és eleve nem fogad el kockázatos Autodiscover protokoll kéréseket. Ez megállítja a támadókat rávesz egy szervert, hogy elfogadja a csapdába esett objektumok példányosítási trükkjeit, még akkor is, ha a szerver nincs javítva.

Tudod nyomon követni hivatalos megelőzési, helyreállítási és válaszadási tanácsainkból, és a Sophos ügyfelei nyomon követhetik a termékeink által használt fenyegetésészlelési neveket a Sophos X-Ops Twitter hírfolyamán (@SophosXOps).

Új információk jelentek meg a CVE-2022-41040 és a CVE-2022-41082 vonatkozásában: https://t.co/pHUVBjUeDI 1/3

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

---

TOVÁBBI INFORMÁCIÓ AZ EXCHANGE HITELESÍTÉSÉRŐL ÉS az OAUTH2-ről

Paul Ducklinnal és Chester Wisniewskivel
Intro és outro zene szerzője Edith Mudge.

---