S3 Ep102.5: „ProxyNotShell” Exchange-hibák – egy szakértő beszél [Hang + szöveg] PlatoBlockchain Data Intelligence. Függőleges keresés. Ai.

S3 Ep102.5: „ProxyNotShell” Exchange-hibák – egy szakértő beszél [Hang + szöveg]

Időbélyeg: 1. október 2022. 10:05

by
Paul Ducklin

NE PÁNIKULJ… DE LÉGY KÉSZ A CSELEKVÉSRE

Paul Ducklinnal és Chester Wisniewskivel

Intro és outro zene szerzője Edith Mudge.

Kattintson és húzza az alábbi hanghullámokat, hogy bármelyik pontra ugorjon. Te is hallgatni közvetlenül a Soundcloudon.

Tovább hallgathatsz minket Soundcloudon, Apple Podcastok, Google Podcastok, Spotify, Fűzőgép és bárhol, ahol jó podcastok találhatók. Vagy csak dobd le a RSS hírfolyamunk URL-je a kedvenc podcatcheredbe.

OLVASSA EL AZ ÍRÁST

[ZENEI MODEM]

KACSA.  Helló mindenki.

Üdvözöljük a Naked Security podcast újabb különleges miniepizódjában.

Paul Ducklin vagyok, akihez ismét csatlakozott barátom és kollégám, Chester Wisniewski.

Szia Chet.

CHET.  [HAMIS AUSSIE ACCENT] Jó napot, Duck.

KACSA.  Nos, Chet, biztos vagyok benne, hogy mindenki hallgat. Ha nem sokkal a podcast megjelenése után hallgatják, tudja, miről fogunk beszélni!

És ennek két csövűnek kell lennie A Microsoft Exchange nulladik napja ami nagyjából 2022 szeptemberének utolsó napján jelent meg a mosásban:

Értékesítőink azt mondják: „Ó, hónap vége van, negyed vége, őrült idő van… de holnap mindenki visszaállítja a 0 dollárt.”

Ez nem így lesz ezen a hétvégén a rendszergazdáknak és az informatikai vezetőknek!

CHET.  Kacsa, azt hiszem, a drágán elhunyt Douglas Adams halhatatlan szavaival élve, "NE ESSEN PÁNIKBA" rendben lehet.

Sok szervezet már nem tárolja saját e-mailjeit az Exchange-kiszolgálókon, így az emberek jó része vesz egy mély lélegzetet, és hagyja, hogy elteljen egy kis idő ezen a hétvégén anélkül, hogy túl stresszes lenne emiatt.

De ha az Exchange on-premise programot futtatja…

…ha én lennék a helyemben, esetleg túlóráznék, csak azért, hogy néhány enyhítő intézkedést bevezethessek, hogy ne érjen kellemetlen meglepetés hétfőn vagy kedden, amikor ebből minden valószínűség szerint valami több lesz. drámai.

KACSA.  Tehát ez CVE-2022 41040- és a CVE-2022 41042-… ez elég nagy falat.

Láttam, hogy a Twitteren így emlegetik ProxyNotShell, mert van némi hasonlósága a ProxyShell a sebezhetőség, amely alig több mint egy éve volt a nagy történet,

De bár megvannak a hasonlóságok, ez egy teljesen új exploit pár, amely összeláncol, és potenciálisan távoli kódfuttatást tesz lehetővé – igaz?

CHET.  Így hangzik.

Ezeket a sebezhetőségeket egy áldozat elleni aktív támadás során fedezték fel, és a GTSC nevű vietnami szervezet feltárta ezt a két új sebezhetőséget, amelyek lehetővé tették, hogy az ellenfelek hozzáférjenek néhány ügyfeleikhez.

Úgy hangzik, mintha felelősségteljesen nyilvánosságra hozták volna azokat a sebezhetőségeket a Trend Micro által működtetett Zero Day Initiative [ZDI] kezdeményezéshez, amely felelős a nulladik napi sebezhetőségek jelentéséért.

És természetesen a ZDI ezt az összes információt megosztotta a Microsofttal, valamivel több mint három héttel ezelőtt.

És az oka annak, hogy ma jelenik meg, az az, hogy szerintem a vietnami csoport…

…úgy tűnik, kezdenek egy kicsit türelmetlenkedni és aggódni amiatt, hogy már három hét telt el, és nem érkezett figyelmeztetés vagy tanács, hogy megvédjék az embereket ezekkel az állítólagos nemzetállami szereplőkkel szemben.

Ezért úgy döntöttek, megkongatják a vészharangot, és tudatják mindenkivel, hogy tenniük kell valamit saját maguk védelmében.

KACSA.  És az igazság kedvéért óvatosan azt mondták: "Nem fogjuk elárulni, hogy pontosan hogyan lehet kihasználni ezeket a sebezhetőségeket, de olyan enyhítéseket fogunk nyújtani, amelyeket hatékonynak találtunk."

Úgy tűnik, hogy önmagában egyik kizsákmányolás sem különösebben veszélyes…

…de összeláncolva, ez azt jelenti, hogy valaki a szervezeten kívül, aki képes az e-maileket a szerverről olvasni, valóban felhasználhatja az első hibát az ajtó kinyitására, a második hibát pedig arra, hogy lényegében rosszindulatú programokat telepítsen az Exchange-kiszolgálóra.

CHET.  És ez nagyon fontos szempont, Kacsa, amit mondtál, "Valaki, aki el tudja olvasni az e-maileket a szerverén."

Ez nem *hitelesítetlen* támadás, ezért a támadóknak bizonyos intelligenciákkal kell rendelkezniük a szervezetről ahhoz, hogy sikeresen végrehajtsák ezeket a támadásokat.

KACSA.  Nem tudjuk pontosan, hogy milyen hitelesítő adatokra van szükségük, mert amikor ezt rögzítjük [2022-09-30T23:00:00Z], még minden nagyrészt titkos.

De abból, amit olvastam (olyan emberektől, akiket hajlamos vagyok hinni), úgy tűnik, hogy a munkamenet-cookie-k vagy a hitelesítési tokenek nem elég jók, és valójában szükség lenne egy felhasználói jelszóra.

A jelszó megadása után azonban, ha kéttényezős hitelesítés volt [2FA], akkor az első hiba (ami kinyitja az ajtót) aktiválódik *a jelszó megadásának pontja és a 2FA kódok megadásának pontja között. kért*.

Tehát kell a jelszó, de nem kell a 2FA kód…

CHET.  Úgy hangzik, mintha ez egy „közepes hitelesítési sebezhetőség”, ha így 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 láttuk 2021-ben.

Láthattuk, hogy az elmúlt 18 hónapban visszatért a férgek, sok szervezet kárára.

KACSA.  „Wormage”?

CHET.  Wormage, igen! [NEvet]

KACSA.  Ez egy szó?

Nos, ha nem, akkor most van!

Ezt szeretem… lehet, hogy kölcsönkérem, Chester. [NEvet]

CHET.  Szerintem ez enyhén féreghajtó, nem?

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.

Ha több száz vagy több ezer felhasználóról beszél… sok szervezetben, egy vagy kettő közülük valószínűleg rossz jelszavakkal rendelkezik.

É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.

Tehát a felhasználónév és a jelszó kombinációjának megszerzése meglehetősen alacsony akadály…

KACSA.  Itt van egy másik bonyolultság, nem?

Mégpedig azt, hogy bár A Microsoft irányelve hivatalosan azt mondja, hogy a Microsoft Exchange Online ügyfelei leállhatnak a Blue Alerttől, ez csak akkor veszélyes, ha van helyszíni Exchange…

…meglepően sok ember vált át a felhőre, valószínűleg több évvel ezelőtt, és az átállás során egyszerre futtatta a helyszíni és a felhőszolgáltatást, és soha nem jutott el a helyszíni kikapcsoláshoz Exchange szerver.

CHET.  Pontosan!

Ezt láttuk a ProxyLoginra és a ProxyShellre visszatérve.

A bűnözők sok esetben olyan Exchange-szervereken keresztül jutottak be a hálózatukba, amelyekről azt hitték, hogy nem rendelkeznek.

Például valaki nem ellenőrizte a VMware-szerverén futó virtuális gépek listáját, hogy észrevegye, hogy a migráló Exchange-szerverei, amelyek segítették őket az adatoknak a helyszíni hálózata és a felhőhálózat közötti átvitel során…

…még mindig be voltak kapcsolva, engedélyezve voltak, és elérhetők voltak az interneten.

És ami még rosszabb, ha nem tudják, hogy ott vannak, még kevésbé valószínű, hogy foltozzák őket.

Úgy értem, azok a szervezetek, amelyek rendelkeznek Exchange szolgáltatással, valószínűleg mindent megtesznek, hogy rendszeresen ütemezzenek karbantartást rajtuk.

De ha nem tudja, hogy van valami a hálózatán, „mert elfelejtette”, ami nagyon egyszerű a virtuális gépekkel, még rosszabb helyzetben van, mert valószínűleg nem telepített Windows vagy Exchange frissítéseket.

KACSA.  És Murphy törvénye azt mondja, hogy ha valóban támaszkodik arra a szerverre, és nem vigyáz rá megfelelően, akkor az összeomlik egy nappal azelőtt, hogy valóban szüksége lenne rá.

De ha nem tudod, hogy ott van, és rosszra is lehet használni, akkor valószínűleg elég nagy az esélye annak, hogy évekig, évekig és évekig minden probléma nélkül működni fog. [NEvet]

CHET.  Igen, sajnos, minden bizonnyal ez a tapasztalatom!

Hülyén hangzik, de azt javasoljuk, hogy rendszeresen ellenőrizze a saját hálózatát, hogy megtudja, mi van.

De minden bizonnyal, ha egy ilyen közleményről hall, ha egy olyan termékről van szó, amelyet korábban használt, például a Microsoft Exchange-et, akkor itt az ideje, hogy futtassa ezt a belsőt. Nmap szkennelés...

…és talán még bejelentkezni is shodan.io és ellenőrizze a külső szolgáltatásokat, hogy megbizonyosodjon arról, hogy mindezt kikapcsolták.

KACSA.  A Microsoft saját válaszából most már tudjuk, hogy őrjöngve igyekeznek kiszedni a javításokat.

Amikor ezek a foltok megjelennek, jobb, ha nagyon gyorsan felhelyezi őket, nem igaz?

Mert ha bármilyen javítást valaha is megcéloznak a visszafejtésre, hogy kitalálják a kizsákmányolást, az valami ilyesmi lesz.

CHET.  Igen, feltétlenül, Kacsa!

Még ha foltozod is, lesz egy időablak, igaz?

Úgy értem, tipikusan a Microsoft, egyébként a javítási keddekre, csendes-óceáni idő szerint délelőtt 10.00 órakor adja ki a javításait.

Jelenleg a nyári időszámításban járunk, tehát UTC-7… szóval, 17:00 UTC körül a Microsoft általában kiadja a javításokat, így a legtöbb munkatársnak egész nap áll rendelkezésére, hogy aztán válaszoljon a bejövő lekérdezésekre Seattle-ben. [A Microsoft központja Bellevue-ban, Seattle, WA.]

A kulcs itt az, hogy órák, esetleg percek „versenye” van, attól függően, hogy mennyire könnyű ezt kihasználni, mielőtt megtörténik.

És ismét, visszatérve a korábbi Exchange-kihasználásokhoz a ProxyShell és a ProxyLogon segítségével, gyakran azt tapasztaltuk, hogy még azok az ügyfelek is, akik három, négy, öt napon belül javítottak…

…ami, hogy őszinte legyek, kissé gyors egy Exchange-kiszolgálóhoz, nagyon nehéz javítani őket, sok teszteléssel kell megbizonyosodni arról, hogy megbízható-e, mielőtt megzavarná az e-mail szervereket.

Ez elég volt ahhoz, hogy a szerverek megkapják webhéjak, cryptominers, mindenféle hátsóajtó telepítve rájuk.

És így, amikor a hivatalos javítás megjelenik, nem csak gyorsan kell cselekednie…

…*miután* cselekszik, érdemes visszamenni, és alaposan átvizsgálni ezeket a rendszereket, hátha találtak bizonyítékot arra nézve, hogy esetleg megtámadták őket abban a résben, amikor a javítás elérhetővé vált, és amikor fel tudta helyezni azt.

Biztos vagyok benne, hogy rengeteg beszélgetés lesz még a Naked Security-ről és a többiről Twitter és más helyeken, az általunk tapasztalt támadások típusairól beszélünk, hogy tudja, mire kell figyelnie.

KACSA.  Miközben kereshet egy csomó ismert rosszindulatú program kivonatát, amelyeket már korlátozott számú támadás során elterjesztettek…

…valójában a lényeg az, hogy mindenféle rosszindulatú program lehetőség.

És így, ahogy azt hiszem, mondtad a utolsó mini epizód amit megtettünk, már nem elég csak arra várni, hogy az irányítópulton megtörtént valami rosszról értesítsenek:

Proaktívan ki kell menned, és meg kell nézned, hátha már voltak csalók a hálózatodban, és nem hagytak maguk után valamit (ami már régen ott lehetett!), amit még nem vettél észre.

CHET.  Szóval szerintem ez elvezet minket ahhoz, – Mit tegyünk most, amíg a javításra várunk?

Megjelent a Microsoft Security Research Center (MSRC) blogja néhány enyhítő tanács és részletek… amennyit a Microsoft hajlandó most nyilvánosságra hozni.

Azt mondanám, ha tiszta vagy Microsoft Exchange Online Ügyfél, nagyjából tisztában vagy, és csak oda kell figyelned, ha a dolgok megváltoznak.

De ha hibrid helyzetben van, vagy még mindig a helyszíni Microsoft Exchange szolgáltatást futtatja, úgy gondolom, hogy van néhány munka, amelyet érdemes elvégezni ma délután vagy holnap reggel, ha mást nem.

Természetesen a felvétel időpontjában péntek délután van… szóval, amikor ezt hallgatod: „Azonnal, amikor meghallod, ha még nem tetted meg.”

Mik a legjobb gyakorlatok itt, Duck?

Nyilvánvalóan egy dolog, amit tehetünk, csak kikapcsolni a külső webes hozzáférést, amíg elérhető nem lesz egy javítás.

Egyszerűen leállíthatja az IIS-kiszolgálót, és az megteszi!

KACSA.  Gyanítom, hogy sok cég nem lesz ebben a helyzetben.

És a Microsoft felsorol két dolgot, amit mondanak… nos, nem mondják, "Ez biztosan működni fog."

Azt sugallják, hogy ez nagyban korlátozza a kockázatot.

Az egyik az, hogy létezik egy URL-újraírási szabály, amelyet alkalmazhat az IIS-kiszolgálón. (Úgy értem, hogy az IIS fogadja el a bejövő kapcsolatot, amely az Exchange Web Services [EWS] hozzáférésévé válik.)

Tehát van egy IIS beállítás, amely megkeresi az első lyuk valószínű kihasználását, ami megakadályozza a PowerShell aktiválását.

És vannak olyan TCP-portok, amelyeket blokkolhat az Exchange kiszolgálón.

Azt hiszem, ez az 5985-ös és 5986-os port, ami leállítja az ún PowerShell távoli… leállítja, hogy ezek a hamis PowerShell távoli végrehajtási parancsok bekerüljenek az Exchange-kiszolgálóba.

Ne feledje azonban, hogy a Microsoft azt állítja, hogy ez „korlátozza” az expozíciót, nem pedig azt ígéri, hogy tudják, hogy mindent megjavít.

És ez azért lehet, mert azt gyanítják, hogy ez más módokon is kiváltható, de még nem jöttek rá teljesen, hogy mik is azok. [NEvet]

Magában az Exchange-ben egyik beállítást sem kell elvégezni.

Az egyik az IIS-ben van, a másik pedig valamilyen hálózati szűrési szabály.

CHET.  Nos, ez hasznos ahhoz, hogy átvészeljük a következő néhány napot, miközben a Microsoft végleges javítást ad nekünk.

A jó hír az, hogy szerintem sok biztonsági szoftver, legyen szó akár a tűzfalba integrált IPS-ről, akár a Microsoft Windows Server infrastruktúráját védő végponti biztonsági termékekről…

…az erre irányuló támadások sok esetben (legalábbis a korai jelentések szerint) nagyon hasonlítanak a ProxyLogonhoz, és ennek eredményeként nem világos, hogy a meglévő szabályok védelmet nyújtanak-e ezekkel a támadásokkal szemben.

Lehetséges, de ezen túlmenően úgy tűnik, hogy a legtöbb szállító megpróbálja egy kicsit szigorítani, hogy a lehető legjobban készen álljanak az összes jelenleg nyilvánosan megosztott mutató alapján, hogy észleljék és riasztásokat küld, ha ezek előfordulnának az Exchange-kiszolgálókon.

KACSA.  Ez így van, Chester.

A Sophos ügyfelei számára pedig jó hír, hogy nyomon követheti a Sophos-specifikus észleléseket, ha át akarja nézni a naplóit.

Nem csak az IPS-hez, legyen az a tűzfalon lévő IPS vagy a végpont, hanem egy csomó viselkedési szabályunk is van.

Nyomon követheti ezeket az észlelési neveket, ha keresni szeretné őket… kövesse ezt a @SophosXops Twitter hírfolyam.

Mivel új észlelési neveket kapunk, amelyeket a fenyegetésvadászathoz használhat, közzétesszük őket, hogy könnyen megkereshesse őket:

CHET.  Biztos vagyok benne, hogy lesz még mondanivalónk a jövő heti podcastban, akár Doug csatlakozik-e hozzátok, akár ismét én vagyok a vendégülés.

De egészen biztos vagyok benne, hogy ezt most egy darabig nem fogjuk tudni lefeküdni…

KACSA.  Úgy gondolom, a ProxyShellhez hasonlóan, mint a Log4Shellhez, még sokáig visszhang lesz.

Szóval talán jobb lenne, ha azt mondanánk, mint mindig, Chester:

A következő alkalomig…

MINDKÉT.  Maradj biztonságban.

[ZENEI MODEM]

Időbélyeg:

Még több Meztelen biztonság