Sådan hackes en ikke-patchet Exchange-server med useriøs PowerShell-kode

For knap to måneder siden kom nogle bekymrende fejlnyheder: et par nul-dages sårbarheder blev annonceret i Microsoft Exchange.

Som vi rådgivet dengang, disse sårbarheder, officielt udpeget CVE-2022-41040 , CVE-2022-41082:

[var] to nul-dage, der [kunne] være kædet sammen, hvor den første fejl blev brugt eksternt til at åbne nok af et hul til at udløse den anden fejl, som potentielt tillader fjernudførelse af kode (RCE) på selve Exchange-serveren.

Den første sårbarhed mindede om den besværlige og meget misbrugte ProxyShell sikkerhedshul fra tilbage i august 2021, fordi den var afhængig af farlig adfærd i Exchanges Autodiscover-funktion, beskrevet af Microsoft som en protokol altså "bruges af Outlook- og EAS [Exchange ActiveSync]-klienter til at finde og oprette forbindelse til postkasser i Exchange".

Heldigvis var den autodiscover-fejlfunktion, der kunne udnyttes i ProxyShell-angrebet af enhver fjernbruger, uanset om den er logget ind eller ej, lappet for mere end et år siden.

Desværre gjorde ProxyShell-patcherne ikke nok til at lukke udnyttelsen af ​​for godkendte brugere, hvilket førte til den nye CVE-2022-40140 nul-dag, som snart var lakonisk, om end vildledende, døbt ProxyNotShell.

Ikke så farligt, men farligt alligevel

Det er klart, at ProxyNotShell ikke var nær så farligt som den originale ProxyShell, da det krævede det, der er kendt som autentificeret adgang, så det var ikke åbent for misbrug af bare hvem som helst hvor som helst.

Men det viste sig hurtigt, at på mange Exchange-servere ville det være nok at kende enhver brugers logonnavn og adgangskode til at blive godkendt og aktivere dette angreb, selv hvis denne bruger selv skulle bruge tofaktorautentificering (2FA) for at logge ordentligt på for at få adgang til deres e-mail.

Som Sophos-ekspert Chester Wisniewski Læg det på det tidspunkt:

Det er en "mid-autentificeringssårbarhed", hvis du vil kalde det det. Det er en blandet velsignelse. Det betyder, at et automatiseret Python-script ikke bare kan scanne hele internettet og potentielt udnytte enhver Exchange-server i verden i løbet af få minutter eller timer, som vi så ske med ProxyLogon og ProxyShell i 2021. […]

Du har brug for en adgangskode, men at finde én e-mailadresse og en adgangskodekombination, der er gyldig på en given Exchange-server, er nok ikke så svært, desværre. Og du er måske ikke blevet udnyttet til dato, fordi for at kunne logge ind på Outlook Web Access [OWA] kræver det deres FIDO-token eller deres autentificering, eller hvilken anden faktor du måtte bruge.

Men dette angreb kræver ikke den anden faktor. […] Bare det at anskaffe en kombination af brugernavn og adgangskode er en ret lav barriere.

Som du sikkert husker, antog mange af os (eller håbede i det mindste), at Microsoft ville skynde sig for at få en løsning til ProxyNotShell-hullerne, da der stadig var to uger til oktobers Patch Tuesday.

Men vi var skuffede over at opdage, at en pålidelig løsning tilsyneladende var mere kompleks end forventet, og oktober kom og gik med ProxyNotShell rettet kun af løsninger, ikke af korrekte patches.

Selv novembers Patch Tuesday leverede ikke direkte de nødvendige rettelser, selvom programrettelserne kom alligevel ud samme dag som en del af en Exchange-specifik sikkerhedsopdatering, der kunne hentes og installeres separat:

Proof-of-concept afsløret

Nu hvor støvet har lagt sig, og alle har haft tid til at patche deres Exchange-servere (dem, de ikke har glemt i hvert fald), har forskere ved Zero Day Initiative (ZDI), som disse sårbarheder oprindeligt var ansvarligt afsløret for til indsendelse til Microsoft, har forklaret hvordan fejlene kan udnyttes.

De dårlige nyheder, afhængigt af din mening om åbenlyse afsløringer af udnyttelse, er, at ZDI-teamet nu effektivt har leveret et proof-of-concept (PoC), der forklarer, hvordan man angriber Exchange-servere.

Den gode nyhed er selvfølgelig, at:

• Vi kan nu selv studere og forstå fejlene. Dette hjælper ikke kun os alle med at sikre, at de overordnede forholdsregler, vi har taget (ikke blot begrænset til patching), sandsynligvis vil give den beskyttelse, vi forventer, men informerer os også om programmeringspraksis, som vi ønsker at undgå i fremtiden, så vi ikke ikke blive fanget i at åbne fejl af denne slags i vores egen server-side kode.
• Vi har nu ingen undskyldninger tilbage for ikke at anvende plastrene. Hvis vi har slæbt fødderne med at opdatere, gør ZDIs forklaring på, hvorfor angrebet virker, det klart, at kuren absolut er at foretrække frem for sygdommen.

Sådan fungerer det

ZDI'er forklaring af denne sårbarhed giver en fascinerende fortælling om, hvor komplekst det kan være at kæde alle de dele sammen, du skal bruge for at gøre en sårbarhed til en levedygtig udnyttelse.

Det er også værd at læse for at hjælpe dig med at forstå, hvorfor grave i en eksisterende udnyttelse kan hjælpe med at afsløre andre måder, hvorpå en sårbarhed kan blive misbrugt, potentielt anmode om yderligere programrettelser, opfordre til konfigurationsændringer og fremme ny programmeringspraksis, der måske ikke var indlysende blot fra at rette det originale hul.

Forklaringen er nødvendigvis kompliceret og ret teknisk og leder dig fremad gennem en lang række trin for at opnå remote code execution (RCE) til sidst.

I håbet om at hjælpe dig med at følge detaljerne på højt niveau lettere, hvis du beslutter dig for at læse ZDI-rapporten, er her et forhåbentlig-ikke-for-forenklet resumé med trinene anført i omvendt rækkefølge...

…så du ved på forhånd, hvorfor historien tager den retning, den gør:

• TRIN 4. Narre Exchange på afstand til at instansiere et .NET-objekt efter eget valg med en initialiseringsparameter efter eget valg.

I moderne kodning, en instansierede objekt er jargonordet for en tildelt del af hukommelsen, initialiseret automatisk med de data og ressourcer, den skal bruge, mens den er i brug, og knyttet til et bestemt sæt funktioner, der kan fungere på den. (Instantiér er bare et fancy ord for skabe.)

Objekter kan administreres og kontrolleres af selve operativsystemet for at hjælpe med at undgå den slags hukommelsesfejl, der er almindelige i et sprog som C, hvor du typisk selv skal allokere hukommelse, udfylde de relevante datafelter i hånden og huske at frigiv den hukommelse og de ressourcer, du bruger, såsom netværksstik eller diskfiler, når du er færdig.

Objekter har generelt en programmatisk funktion forbundet med dem kaldet a konstruktør, som automatisk udføres, når et nyt objekt oprettes for at allokere den rigtige mængde hukommelse og det korrekte sæt af systemressourcer.

Normalt skal du sende en eller flere parametre som argumenter til konstruktøren for at angive, hvordan du ønsker, at objektet skal konfigureres, når det starter.

Kort sagt, hvis du instansierer f.eks. en TextString objekt (vi laver disse navne op, men du forstår) ved hjælp af en parameter, der i sig selv er en tekststreng som f.eks. example.com:8888...

… du vil sandsynligvis ende med en hukommelsesbuffer tildelt til at holde din tekst, initialiseret, så den har den samme værdi, som du sendte ind, nemlig den rå tekst example.com:8888.

I den sammenhæng udgør tekststrengen, der sendes som data til objektkonstruktøren, ikke umiddelbart nogen åbenlys cybersikkerhedstrussel, når du fjernudløser konstruktøren, bortset fra et muligt lammelsesangreb (DoS) ved gentagne gange at bede om større og større strenge for at prøv at udtømme hukommelsen.

Men hvis du skulle instansiere f.eks. en ConnectedTCPClient objekt ved hjælp af den samme tekststrengparameter som example.com:8888, kan du ende med en hukommelsesbuffer klar til at opbevare midlertidige data sammen med en netværkssocket tildelt af operativsystemet, der er klar til at udveksle data med serveren example.com over TCP-porten 8888.

Du kan se risikoen for fjernudførelse af kode der, selvom du aldrig får sendt nogen data til den åbne stikkontakt, da du har narret serveren til at ringe hjem til et sted, som du kontrollerer.

Du kan endda finde et objekt kaldet f.eks. RunCmdAndReadOutput, hvor den tekststreng, du sender som parameter, bogstaveligt talt er en kommando, du vil køre automatisk, så snart objektet er oprettet, så du kan samle dets output senere.

Selvom du aldrig kommer til at gendanne outputtet af kommandoen, ville bare instansiering af et sådant objekt alligevel lade dig vælge en kommando, der skal køres, hvilket giver dig generisk fjernudførelse af kode og udgør en risiko, der kun er begrænset af adgangsrettighederne til selve serverprocessen .

Selvfølgelig er angrebet kun så nemt, når du kommer til det sidste trin, hvilket du ikke skal kunne gøre, fordi Exchange har en streng tilladelsesliste, der forhindrer dig i at vælge et hvilket som helst gammelt objekt at instansiere.

I teorien er det kun sikre objekter eller objekter med lav risiko, der kan oprettes eksternt via PowerShell, så instansiering af vores imaginære TextString ovenfor, eller en SimpleIntegerValue, kan anses for acceptabel, mens en ConnectedTCPClient eller RunCmdAndReadOutput ville bestemt ikke være.

Men ZDI-forskerne bemærker, at før de udløste det sidste trin, kunne de gøre dette:

• TRIN 3. Fjernt narre Exchange til at tro, at et objekt med lav risiko, der har bestået sikkerhedstesten, faktisk er et andet objekt efter eget valg.

Alligevel kan du forvente, at Exchange forhindrer fjernoprettelse, selv af objekter med lav risiko, for at minimere truslen endnu mere.

Men forskerne fandt ud af, at de kunne:

• TRIN 2. Fjerntryg Exchange til at bruge sin PowerShell Remoting funktion til at oprette et objekt baseret på initialiseringsparametre styret eksternt.

Og det var muligt på grund af det ProxyShell-lignende hul, der kun var semi-lappet:

• TRIN 1. Narre Exchange eksternt til at acceptere og behandle en webanmodning med kode ved at pakke en gyldig username:password også i anmodningen.

Selvom brugeren, der er navngivet i anmodningen, faktisk ikke var logget ind og skulle gennemgå en form for 2FA-proces for at få adgang til deres egen postkasse, var en angriber, der kendte deres username:password kombination ville have nok godkendelsesoplysninger til at narre Exchange til at acceptere en webforbindelse, der kunne bruges til at starte angrebskæden beskrevet i trin 2 til 4 ovenfor.

Løst sagt, enhver gyldig username:password kombination ville gøre, givet at "godkendelsen" var nødvendig simpelthen for at forhindre Exchange i at afvise HTTP-anmodningen på forhånd.

Hvad skal jeg gøre?

Bemærk, at dette angreb kun virker:

• Hvis du har lokale Exchange-servere. Microsoft hævder at have låst sine egne cloud-tjenester hurtigt, så Exchange Online er ikke berørt. Vær sikker på at du ved, hvor dine Exchange-servere er. Selvom du nu bruger Exchange Online, har du muligvis stadig lokale servere kørende, måske tilbage ved en fejl fra din migreringsproces.
• Hvis dine servere ikke er patchede. Sørg for at du har anvendte Exchange Software Update af 2022-11-08 til lukke sårbarhederne som udnyttelsen kræver.
• Hvis dine servere stadig accepterer Basic Authentication, også kendt som legacy-godkendelse. Sørg for at du har blokerede alle aspekter af ældre godkendelse så dine servere vil ikke acceptere username:password overskrifter nævnt ovenfor, og accepterer ikke risikable Autodiscover-protokolanmodninger i første omgang. Dette stopper angriberne narre en server til at acceptere deres booby-fangede objekt-forekomsttricks, selvom den server ikke er patchet.

Du kan holde styr på af vores officielle rådgivning om forebyggelse, afhjælpning og reaktion, og Sophos-kunder kan holde styr på trusselsdetektionsnavnene, der bruges af vores produkter, via Sophos X-Ops Twitter-feed (@SophosXOps).

Nye oplysninger er blevet offentliggjort vedrørende CVE-2022-41040 og CVE-2022-41082: https://t.co/pHUVBjUeDI 1/3

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

---

LÆR MERE OM EXCHANGE-GODKENDELSE OG OAUTH2

Med Paul Ducklin og Chester Wisniewski
Intro og outro musik af Edith Mudge.

---