S3 Ep102.5: "ProxyNotShell" Exchange-feil – en ekspert snakker [lyd + tekst]

Tidsstempel: 1. oktober 2022 10:05
Kilde node: 1712650

by
Paul Ducklin

IKKE PANIKK ... MEN VÆR KLAR TIL Å HANDLE

Med Paul Ducklin og Chester Wisniewski

Intro- og outromusikk av Edith Mudge.

Klikk og dra på lydbølgene nedenfor for å hoppe til et hvilket som helst punkt. Du kan også lytte direkte på Soundcloud.

Du kan lytte til oss på Soundcloud, Apple Podcasts, Google Podcasts, Spotify, Stitcher og hvor som helst hvor du finner gode podcaster. Eller bare dropp URL til RSS-feeden vår inn i din favoritt podcatcher.

LES TRANSKRIPTET

[MUSIKK MODEM]

AND.  Hei alle sammen.

Velkommen til nok en spesiell mini-episode av Naked Security-podcasten.

Jeg er Paul Ducklin, igjen sammen med min venn og kollega Chester Wisniewski.

Hei, Chet.

CHET.  [FAKE AUSSIE AKSENTE] Goddag, Duck.

AND.  Vel, Chet, jeg er sikker på at alle lytter. hvis de hører på kort tid etter at podcasten kom ut, vet de hva vi skal snakke om!

Og det må være dette dobbeltløpet Microsoft Exchange zero-day som kom ut i vask stort sett den siste dagen i september 2022:

Salgskameratene våre sier: "Å, det er slutten av måneden, det er slutten av kvartalet, det er en hektisk tid ... men i morgen blir alle tilbakestilt til $ 0."

Det kommer ikke til å bli slik denne helgen for systemadministratorer og IT-sjefer!

CHET.  Duck, tror jeg, med de udødelige ordene til den avdøde Douglas Adams, "IKKE FÅ PANIKK" kan være i orden.

Mange organisasjoner er ikke lenger vert for sin egen e-post lokalt på Exchange-servere, så en god del av folk kan ta et dypt pust og la det gå litt tid denne helgen, uten å bli for stresset av det.

Men hvis du kjører Exchange on-premise...

…hvis det var meg, ville jeg kanskje jobbet noen timer overtid bare for å få på plass noen avbøtende tiltak, for å være sikker på at jeg ikke får en ubehagelig overraskelse på mandag eller tirsdag når dette etter all sannsynlighet vil utvikle seg til noe mer dramatisk.

AND.  Så det er CVE-2022-41040 og CVE-2022-41042… det er en munnfull.

Jeg har sett det bli omtalt på Twitter som ProxyNotShell, fordi den har noen likheter med ProxyShell sårbarhet som var den store historien for et drøyt år siden,

Men selv om det har disse likhetene, er det et helt nytt par utnyttelser som lener sammen, og potensielt gir ekstern kjøring av kode – er det riktig?

CHET.  Det er slik det høres ut.

Disse sårbarhetene ble oppdaget under et aktivt angrep mot et offer, og en vietnamesisk organisasjon kalt GTSC avdekket disse to nye sårbarhetene som gjorde det mulig for motstanderne å få tilgang til noen av deres klienter.

Det høres ut som de avslørte ansvarlig disse sårbarhetene til Zero Day Initiative [ZDI] som drives av Trend Micro for ansvarlig rapportering av zero-day sårbarheter.

Og selvfølgelig delte ZDI på sin side all denne etterretningen med Microsoft for litt over tre uker siden.

Og grunnen til at den kommer ut i dag er at jeg tror at den vietnamesiske gruppen...

…det høres ut som de begynner å bli litt utålmodige og bekymret over at det har gått tre uker og at ingen varsler eller råd har gått ut for å hjelpe til med å beskytte folk mot disse påståtte nasjonalstatsaktørene.

Så de bestemte seg for å slå alarmklokkene og la alle få vite at de må gjøre noe for å beskytte seg selv.

AND.  Og for å være rettferdig sa de forsiktig, "Vi kommer ikke til å avsløre nøyaktig hvordan vi kan utnytte disse sårbarhetene, men vi kommer til å gi dere avbøtende tiltak som vi fant effektive."

Det høres ut som om enten utnyttelse alene ikke er spesielt farlig...

…men lenket sammen betyr det at noen utenfor organisasjonen som har muligheten til å lese e-post fra serveren din, faktisk kan bruke den første feilen til å åpne døren, og den andre feilen til å implantere skadelig programvare på Exchange-serveren din.

CHET.  Og det er et veldig viktig poeng å komme med, Duck, at du sa, "Noen som kan lese e-post på serveren din."

Dette er ikke et *uautentisert* angrep, så angriperne må ha litt etterretning om organisasjonen din for å kunne utføre disse angrepene.

AND.  Nå vet vi ikke nøyaktig hva slags legitimasjon de trenger, for på det tidspunktet vi spiller inn dette [2022-09-30T23:00:00Z], er alt fortsatt stort sett hemmelig.

Men fra det jeg har lest (fra folk jeg er tilbøyelig til å tro), ser det ut som om øktinformasjonskapsler eller autentiseringstokener ikke er gode nok, og at du faktisk trenger en brukers passord.

Etter å ha oppgitt passordet, men hvis det var tofaktorautentisering [2FA], utløses den første feilen (den som åpner døren) *mellom punktet der passordet ble oppgitt og punktet der 2FA-kodene ville være Forespurt*.

Så du trenger passordet, men du trenger ikke 2FA-koden...

CHET.  Det høres ut som det er en "midt-autentiseringssårbarhet", hvis du vil kalle det det.

Det er en blandet velsignelse.

Det betyr at et automatisert Python-skript ikke bare kan skanne hele internett og potensielt utnytte alle Exchange-servere i verden i løpet av minutter eller timer, slik vi så skje med ProxyLogon og ProxyShell i 2021.

Vi så tilbakekomsten av ormesyre de siste 18 månedene, til skade for mange organisasjoner.

AND.  "Ormekur"?

CHET.  Ormekur, ja! [LETER]

AND.  Er det et ord?

Vel, hvis det ikke er det, er det nå!

Jeg liker det... jeg kan låne det, Chester. [LETER]

CHET.  Jeg tror dette er mildt sagt ormelig, ikke sant?

Du trenger et passord, men å finne én e-postadresse og passordkombinasjon som er gyldig på en gitt Exchange-server er sannsynligvis ikke så vanskelig, dessverre.

Når du snakker om hundrevis eller tusenvis av brukere ... i mange organisasjoner, har en eller to av dem sannsynligvis dårlige passord.

Og du har kanskje ikke blitt utnyttet til dags dato, fordi for å lykkes med å logge på Outlook Web Access [OWA] krever FIDO-tokenet deres, eller deres autentisering, eller den andre faktoren du måtte bruke.

Men dette angrepet krever ikke den andre faktoren.

Så, bare å anskaffe en kombinasjon av brukernavn og passord er en ganske lav barriere ...

AND.  Nå er det en annen kompleksitet her, ikke sant?

Nemlig det selv om Microsofts retningslinjer sier offisielt at Microsoft Exchange Online-kunder kan si seg fra Blue Alert, det er bare farlig hvis du har on-premise Exchange...

…det er et overraskende antall mennesker som byttet til skyen, muligens for flere år siden, som kjørte både lokale og skytjeneste samtidig under overgangen, som aldri kom seg til å slå av det lokale Exchange-server.

CHET.  Nettopp!

Vi så dette gå tilbake til ProxyLogin og ProxyShell.

I mange tilfeller kom de kriminelle inn i nettverket deres gjennom Exchange-servere som de trodde de ikke hadde.

Som, noen sjekket ikke listen over VM-er som kjører på VMware-serveren deres for å legge merke til at deres migrerende Exchange-servere som hjalp dem under gaffeltrucking av data mellom deres lokale nettverk og skynettverket ...

...var faktisk fortsatt slått på, aktivert og eksponert for internett.

Og verre, når de ikke er kjent for å være der, er det enda mindre sannsynlig at de har blitt lappet.

Jeg mener, organisasjoner som har Exchange går i det minste sannsynligvis ut av deres måte å planlegge vedlikehold på dem med jevne mellomrom.

Men når du ikke vet at du har noe på nettverket ditt "fordi du har glemt", som er veldig enkelt med VM-er, er du i en enda verre situasjon, fordi du sannsynligvis ikke har brukt Windows-oppdateringer eller Exchange-oppdateringer.

AND.  Og Murphys lov sier at hvis du virkelig stoler på den serveren og du ikke tar vare på den ordentlig, vil den krasje bare dagen før du virkelig trenger den.

Men hvis du ikke vet at den er der, og at den kan brukes for dårlig, er sjansen for at den vil kjøre i årevis og år uten problemer i det hele tatt, nok ganske stor. [LETER]

CHET.  Ja, dessverre, det har absolutt vært min erfaring!

Det høres dumt ut, men å skanne ditt eget nettverk for å finne ut hva du har er noe vi vil anbefale deg å gjøre med jevne mellomrom.

Men når du hører om en bulletin som dette, hvis det er et produkt du vet du har brukt tidligere, som Microsoft Exchange, er det et godt tidspunkt å kjøre den interne Nmap skanning...

…og kanskje til og med logge inn shodan.io og sjekk de eksterne tjenestene dine, bare for å være sikker på at alle disse tingene ble slått av.

AND.  Vi vet nå fra Microsofts eget svar at de raser avsted for å få ut oppdateringer.

Når disse lappene dukker opp, bør du bruke dem ganske raskt, ikke sant?

For hvis en patch noen gang vil bli målrettet for omvendt utvikling for å finne ut av utnyttelsen, kommer det til å være noe av denne typen.

CHET.  Ja, absolutt, Duck!

Selv når du har lappet, kommer det til å være et tidsvindu, ikke sant?

Jeg mener, vanligvis Microsoft, for Patch Tuesdays uansett, slipper patchene deres klokken 10.00 stillehavstid.

Akkurat nå er vi i Daylight Time, så det er UTC-7... så rundt 17:00 UTC er vanligvis når Microsoft lanserer patcher, slik at de fleste av deres ansatte har hele dagen til å svare på innkommende forespørsler i Seattle. [Microsoft HQ er i Bellevue, Seattle, WA.]

Nøkkelen her er at det er et slags "løp" på timer, kanskje minutter, avhengig av hvor enkelt dette er å utnytte, før det begynner å skje.

Og igjen, tilbake til de tidligere Exchange-utnyttelsene med ProxyShell og ProxyLogon, fant vi ofte at selv kunder som hadde lappet innen tre, fire, fem dager...

…som for å være ærlig, er noe rask for en Exchange-server, de er veldig vanskelige å lappe, med mye testing involvert for å være sikker på at den er pålitelig før du forstyrrer e-postserverne dine.

Det var nok tid for disse serverne å få nettskjell, cryptominers, alle typer av bakdører installert på dem.

Og så, når den offisielle oppdateringen er ute, trenger du ikke bare handle raskt...

…*etter* du har handlet, er det vel verdt å gå tilbake og sjekke disse systemene grundig for bevis på at de kanskje har blitt angrepet i gapet mellom når oppdateringen ble tilgjengelig og når du var i stand til å bruke den.

Jeg er sikker på at det blir mye samtale om Naked Security og videre Twitter og andre steder, snakker om typene angrep vi ser, slik at du vet hva du skal se etter.

AND.  Mens du kan gå og se etter en haug med hashes av kjent skadelig programvare som allerede har blitt distribuert i et begrenset antall angrep...

... egentlig, poenget er at all slags skadelig programvare er muligheter.

Og så, som jeg tror du sa i siste mini-episode som vi gjorde, er det ikke lenger nok å bare vente på varsler om noe dårlig som har tilfeldigvis dukket opp på dashbordet ditt:

Du må gå proaktivt ut og se, i tilfelle skurker allerede har vært i nettverket ditt og de har lagt igjen noe (som kunne vært der i evigheter!) som du ikke har lagt merke til ennå.

CHET.  Så jeg tror det leder oss mot "Hva gjør vi nå mens vi venter på lappen?"

Bloggen fra Microsoft Security Research Center (MSRC) er utgitt noen avbøtende råd og detaljer ... så mye som Microsoft er villig til å avsløre på dette tidspunktet.

Jeg vil si, hvis du er en ren Microsoft Exchange Online kunde, du er ganske tydelig, og du bør bare være oppmerksom i tilfelle ting endrer seg.

Men hvis du er i en hybrid situasjon, eller du fortsatt kjører Microsoft Exchange lokalt, tror jeg nok det er noe arbeid som er vel verdt å gjøre i ettermiddag eller i morgen tidlig om ikke annet.

Selvfølgelig, på tidspunktet for innspilling, er dette fredag ​​ettermiddag... så, egentlig, når du lytter til dette, "umiddelbart, når du hører det, hvis du ikke allerede har gjort det."

Hva er de beste fremgangsmåtene her, Duck?

En ting du kan gjøre er åpenbart å slå av den eksterne nettilgangen til en oppdatering er tilgjengelig.

Du kan bare slå av IIS-serveren din og så vil det gjøre det!

AND.  Jeg mistenker at mange bedrifter ikke vil være i den posisjonen.

Og Microsoft lister opp to ting de sier … vel, de sier ikke, "Dette vil definitivt fungere."

De foreslår at det i stor grad vil begrense risikoen din.

Den ene er at det er en URL-omskrivingsregel som du kan bruke på IIS-serveren din. (Min forståelse er at det er IIS som godtar den innkommende tilkoblingen som blir til tilgang til Exchange Web Services [EWS].)

Så det er en IIS-innstilling du kan lage som vil se etter sannsynlige utnyttelser av det første hullet, som vil forhindre at PowerShell-utløsningen startes.

Og det er noen TCP-porter du kan blokkere på Exchange Server.

Jeg tror det er port 5985 og 5986, som vil stoppe det som kalles Fjernstyring av PowerShell… det vil stoppe disse useriøse PowerShell-kommandoer for ekstern utførelse av å stikke inn i Exchange-serveren.

Vær imidlertid oppmerksom på at Microsoft sier at dette vil "begrense" eksponeringen din, i stedet for å love at de vet at det fikser alt.

Og det kan være fordi de mistenker at det er andre måter dette kan utløses på, men de har bare ikke helt funnet ut hva de er ennå. [LETER]

Ingen av innstillingene er noe du gjør i Exchange selv.

En av dem er i IIS, og den andre er en slags nettverksfiltreringsregel.

CHET.  Vel, det er nyttig for å komme oss gjennom de neste dagene mens Microsoft gir oss en permanent løsning.

Den gode nyheten er at jeg tror mye sikkerhetsprogramvare, enten det er en IPS som kan være integrert i brannmuren din, eller endepunktsikkerhetsprodukter som du har som beskytter Microsoft Windows Server-infrastrukturen din...

…angrepene for dette, i mange tilfeller (i hvert fall tidlige rapporter), ligner veldig på ProxyLogon, og som et resultat er det uklart om eksisterende regler vil beskytte mot disse angrepene.

De kan, men i tillegg til det, ser det ut til at de fleste leverandører prøver å stramme dem opp litt, for å sikre at de er så klare som mulig, basert på alle indikatorene som for øyeblikket er delt offentlig, slik at de vil oppdage og sende deg varsler hvis disse skulle oppstå på Exchange-serverne dine.

AND.  Det er riktig, Chester.

Og den gode nyheten for Sophos-kunder er at du kan spore Sophos-spesifikke deteksjoner hvis du vil gå og se gjennom loggene dine.

Ikke bare for IPS, enten det er IPS på brannmuren eller endepunktet, men vi har også en haug med atferdsregler.

Du kan spore disse deteksjonsnavnene hvis du vil lete etter dem ... følg det på @SophosXops Twitter-feed.

Ettersom vi får nye deteksjonsnavn som du kan bruke til trusseljakt, publiserer vi dem der slik at du enkelt kan slå dem opp:

CHET.  Jeg er sikker på at vi vil ha mer å si på neste ukes podcast, enten det er Doug som blir med deg igjen, eller om jeg er i gjesteplassen igjen.

Men jeg er ganske sikker på at vi ikke vil klare å legge dette på senga på en stund nå...

AND.  Jeg tror, ​​i likhet med ProxyShell, som Log4Shell, det kommer til å være et ekko som gir gjenklang i en stund.

Så kanskje vi burde si, som vi alltid gjør, Chester:

Til neste gang…

BÅDE.  Hold deg trygg.

[MUSIKK MODEM]

Tidstempel:

Mer fra Naken sikkerhet