Hoe een niet-gepatchte Exchange-server te hacken met malafide PowerShell-code

Iets minder dan twee maanden geleden kwam er verontrustend bugnieuws naar buiten: een paar zero-day-kwetsbaarheden werden aangekondigd in Microsoft Exchange.

Zoals wij destijds geadviseerd, deze kwetsbaarheden, officieel aangewezen CVE-2022-41040 en CVE-2022-41082:

[waren] twee zero-days die [zou kunnen] aan elkaar worden geketend, waarbij de eerste bug op afstand werd gebruikt om genoeg gat te openen om de tweede bug te activeren, die mogelijk externe code-uitvoering (RCE) op de Exchange-server zelf mogelijk maakt.

De eerste kwetsbaarheid deed denken aan de lastige en wijdverspreide ProxyShell-beveiligingslek van augustus 2021, omdat het afhankelijk was van gevaarlijk gedrag in Exchange's Autodiscover-functie, beschreven door Microsoft als een protocol dat is "gebruikt door Outlook- en EAS [Exchange ActiveSync]-clients om mailboxen in Exchange te vinden en er verbinding mee te maken".

Gelukkig werd de foutieve Autodiscover-functie die kon worden misbruikt in de ProxyShell-aanval door elke externe gebruiker, of deze nu was ingelogd of niet, meer dan een jaar geleden gerepareerd.

Helaas deden de ProxyShell-patches niet genoeg om de exploit af te sluiten voor geverifieerde gebruikers, wat leidde tot de nieuwe CVE-2022-40140 zero-day, die al snel laconiek, zij het misleidend, werd nagesynchroniseerde ProxyNiet Shell.

Niet zo gevaarlijk, maar toch gevaarlijk

Het is duidelijk dat ProxyNotShell lang niet zo gevaarlijk was als de originele ProxyShell, gezien het feit dat het zogenaamde geverifieerde toegang vereiste, dus het stond niet open voor misbruik door zomaar iedereen, waar dan ook.

Maar al snel bleek dat op veel Exchange-servers het kennen van de aanmeldingsnaam en het wachtwoord van een gebruiker voldoende zou zijn om als geverifieerd door te gaan en deze aanval uit te voeren, zelfs als die gebruiker zelf tweefactorauthenticatie (2FA) zou moeten gebruiken om correct in te loggen om toegang te krijgen hun e-mail.

Zoals Sophos-expert Chester Wisniewski zet het destijds:

Het is een "mid-authentication-kwetsbaarheid", als je het zo wilt noemen. Dat is een gemengde zegen. Het betekent wel dat een geautomatiseerd Python-script niet zomaar het hele internet kan scannen en mogelijk elke Exchange-server ter wereld binnen enkele minuten of uren kan exploiteren, zoals we zagen gebeuren met ProxyLogon en ProxyShell in 2021. […]

Je hebt een wachtwoord nodig, maar het vinden van een combinatie van e-mailadres en wachtwoord die geldig is op een bepaalde Exchange-server is helaas waarschijnlijk niet zo moeilijk. En misschien bent u tot nu toe niet uitgebuit, want om succesvol in te loggen bij Outlook Web Access [OWA] is hun FIDO-token vereist, of hun authenticator, of welke tweede factor u ook gebruikt.

Maar deze aanval heeft die tweede factor niet nodig. […] Alleen al het verkrijgen van een combinatie van gebruikersnaam en wachtwoord is een vrij lage drempel.

Zoals u zich waarschijnlijk herinnert, gingen velen van ons ervan uit (of hoopten in ieder geval) dat Microsoft zich zou haasten om een ​​oplossing te vinden voor de ProxyNotShell-gaten, aangezien er nog twee weken waren tot de patch-dinsdag van oktober.

Maar we waren teleurgesteld toen we ontdekten dat er blijkbaar een betrouwbare oplossing was complexer dan verwacht, en oktober kwam en ging met ProxyNotShell alleen geadresseerd door tijdelijke oplossingen, niet door de juiste patches.

Zelfs de patchdinsdag van november bood niet direct de benodigde fixes, hoewel de patches toch uitgekomen op dezelfde dag als onderdeel van een Exchange-specifieke beveiligingsupdate die afzonderlijk kan worden opgehaald en geïnstalleerd:

Proof-of-concept onthuld

Nu het stof is neergedaald en iedereen tijd heeft gehad om hun Exchange-servers te patchen (degene die ze in ieder geval niet vergeten zijn), onderzoekers van Zero Day Initiative (ZDI), waaraan deze kwetsbaarheden oorspronkelijk op verantwoorde wijze werden bekendgemaakt voor onderwerping aan Microsoft, hebben uitgelegd hoe de bugs kunnen worden misbruikt.

Het slechte nieuws, afhankelijk van uw mening over openlijke openbaarmakingen van exploits, is dat het ZDI-team nu effectief een proof-of-concept (PoC) heeft geleverd waarin wordt uitgelegd hoe Exchange-servers moeten worden aangevallen.

Het goede nieuws is natuurlijk dat:

• We kunnen de bugs nu zelf bestuderen en begrijpen. Dit helpt ons niet alleen om ervoor te zorgen dat de algehele voorzorgsmaatregelen die we hebben genomen (niet alleen beperkt tot patchen) waarschijnlijk de bescherming bieden die we verwachten, maar informeert ons ook over programmeerpraktijken die we in de toekomst willen vermijden, dus we don laat u niet verstrikt raken in het openen van dit soort bugs in onze eigen server-side code.
• We hebben nu geen excuses meer om de patches niet toe te passen. Als we onze voeten hebben gesleept met updaten, maakt de uitleg van ZDI over waarom de aanval werkt duidelijk dat de remedie absoluut te verkiezen is boven de ziekte.

Hoe het werkt

ZDI's uitleg van deze kwetsbaarheid zorgt voor een fascinerend verhaal over hoe complex het kan zijn om alle onderdelen aan elkaar te koppelen die nodig zijn om van een kwetsbaarheid een levensvatbare exploit te maken.

Het is ook de moeite waard om te lezen om u te helpen begrijpen waarom het graven in een bestaande exploit kan helpen om andere manieren te onthullen waarop een kwetsbaarheid kan worden misbruikt, mogelijk aanleiding geeft tot extra patches, aandringt op configuratiewijzigingen en nieuwe programmeerpraktijken promoot die misschien niet voor de hand liggend waren door het repareren het originele gat.

De uitleg is noodzakelijkerwijs gecompliceerd en behoorlijk technisch, en leidt u door een lange reeks stappen om aan het eind de uitvoering van externe code (RCE) te bereiken.

In de hoop u te helpen de details op hoog niveau gemakkelijker te volgen als u besluit het ZDI-rapport te lezen, volgt hier een hopelijk niet al te vereenvoudigde samenvatting met de stappen in omgekeerde volgorde...

…zodat je van tevoren weet waarom het verhaal de richting uitgaat die het volgt:

• STAP 4. Bedrieg Exchange op afstand om een ​​.NET-object naar keuze te instantiëren, met een initialisatieparameter naar keuze.

In moderne codering, een geïnstantieerd object is het jargonwoord voor een toegewezen stuk geheugen, automatisch geïnitialiseerd met de gegevens en bronnen die het nodig heeft terwijl het in gebruik is, en gekoppeld aan een specifieke set functies die erop kunnen werken. (Instantiëren is gewoon een mooi woord voor en je merk te creëren .)

Objecten kunnen worden beheerd en bestuurd door het besturingssysteem zelf, om geheugenfouten te helpen voorkomen die vaak voorkomen in een taal als C, waarbij u doorgaans zelf geheugen moet toewijzen, de relevante gegevensvelden met de hand moet invullen en niet moet vergeten om maak het geheugen en de bronnen vrij die u gebruikt, zoals netwerksockets of schijfbestanden, wanneer u klaar bent.

Objecten hebben over het algemeen een programmatische functie die eraan is gekoppeld, a genoemd aannemer, die automatisch wordt uitgevoerd wanneer een nieuw object wordt gemaakt om de juiste hoeveelheid geheugen en de juiste set systeembronnen toe te wijzen.

Gewoonlijk moet u een of meer parameters als argumenten aan de constructor doorgeven om aan te geven hoe u wilt dat het object wordt geconfigureerd wanneer het wordt gestart.

Simpel gezegd, als je bijvoorbeeld a TextString object (we verzinnen deze namen, maar je snapt het wel) met behulp van een parameter die zelf een tekenreeks is, zoals example.com:8888...

... je zult waarschijnlijk eindigen met een geheugenbuffer die is toegewezen om je tekst op te slaan, geïnitialiseerd zodat deze dezelfde waarde bevat die je hebt ingevoerd, namelijk de onbewerkte tekst example.com:8888.

In die context vormt de tekenreeks die als gegevens wordt doorgegeven aan de objectconstructor niet onmiddellijk een duidelijke cyberbeveiligingsdreiging wanneer u de constructor op afstand activeert, behalve een mogelijke denial of service (DoS) door herhaaldelijk om steeds grotere tekenreeksen te vragen. probeer het geheugen uit te putten.

Maar als je zou instantiëren, laten we zeggen, a ConnectedTCPClient object met dezelfde tekenreeksparameter van example.com:8888, zou u kunnen eindigen met een geheugenbuffer die klaar is om tijdelijke gegevens op te slaan, samen met een netwerksocket toegewezen door het besturingssysteem dat klaar is om gegevens uit te wisselen met de server example.com via de TCP-poort 8888.

U kunt daar het risico van de uitvoering van externe code zien, zelfs als u nooit gegevens naar de open socket kunt sturen, aangezien u de server hebt misleid om naar huis te bellen naar een locatie die u beheert.

Misschien vind je zelfs een object genaamd, laten we zeggen, RunCmdAndReadOutput, waarbij de tekenreeks die u als parameter verzendt, vrij letterlijk een opdracht is die u automatisch wilt uitvoeren zodra het object is gemaakt, zodat u de uitvoer later kunt verzamelen.

Zelfs als u de uitvoer van de opdracht nooit kunt herstellen, kunt u met het instantiëren van een dergelijk object toch een opdracht kiezen om uit te voeren, waardoor u generieke externe code kunt uitvoeren en een risico met zich meebrengt dat alleen wordt beperkt door de toegangsrechten van het serverproces zelf .

Natuurlijk is de aanval pas zo eenvoudig als je eenmaal in de laatste fase bent, wat je niet zou moeten kunnen doen, omdat Exchange een strikte toelatingslijst heeft die voorkomt dat je een oud object kiest om te instantiëren.

In theorie kunnen alleen veilige objecten of objecten met een laag risico op afstand worden gemaakt via PowerShell, zodat het instantiëren van onze denkbeeldige TextString hierboven, of een SimpleIntegerValue, kan als acceptabel worden beschouwd, terwijl a ConnectedTCPClient of RunCmdAndReadOutput zou het zeker niet zijn.

Maar de ZDI-onderzoekers merken dat voordat ze de laatste stap activeerden, ze dit konden doen:

• STAP 3. Bedrieg Exchange op afstand door te denken dat een object met een laag risico dat de veiligheidstest heeft doorstaan, in feite een ander object van uw keuze is.

Toch zou je kunnen verwachten dat Exchange het op afstand maken van zelfs objecten met een laag risico verhindert, om de dreiging nog verder te minimaliseren.

Maar de onderzoekers ontdekten dat ze:

• STAP 2. Bedrieg Exchange op afstand om het te gebruiken PowerShell Remoting functie om een ​​object te maken op basis van initialisatieparameters die extern worden beheerd.

En dat was mogelijk vanwege het ProxyShell-achtige gat dat slechts semi-gepatcht was:

• STAP 1. Bedrieg Exchange op afstand om een ​​webverzoek met code te accepteren en te verwerken door een geldig username:password veld ook in het verzoek.

Zelfs als de gebruiker die in het verzoek wordt genoemd niet daadwerkelijk is ingelogd en een soort 2FA-proces moet doorlopen om toegang te krijgen tot zijn eigen mailbox, kan een aanvaller die zijn username:password combinatie zou genoeg authenticatie-informatie hebben om Exchange te misleiden om een ​​webverbinding te accepteren die zou kunnen worden gebruikt om de aanvalsketen te starten die wordt beschreven in de stappen 2 tot 4 hierboven.

Losjes gesproken, elke geldige username:password combinatie zou volstaan, gezien het feit dat de "authenticatie" eenvoudigweg nodig was om te voorkomen dat Exchange het HTTP-verzoek van tevoren afwijst.

Wat te doen?

Merk op dat deze aanval alleen werkt:

• Als u on-premises Exchange-servers hebt. Microsoft claimt zijn eigen clouddiensten snel op slot te hebben gedaan, waardoor Exchange Online niet wordt geraakt. Zorg ervoor dat je weten waar uw Exchange-servers zijn. Zelfs als u nu Exchange Online gebruikt, zijn er misschien nog on-premises servers actief, misschien per ongeluk overgebleven van uw migratieproces.
• Als uw servers niet gepatcht zijn. Zorg dat je hebt de Exchange-software-update van 2022-11-08 toegepast naar sluit de kwetsbaarheden af dat de exploit vereist.
• Als uw servers nog steeds basisauthenticatie accepteren, ook wel legacy-authenticatie genoemd. Zorg dat je hebt blokkeerde alle aspecten van verouderde authenticatie zodat uw servers de username:password headers die hierboven zijn genoemd, en accepteren in de eerste plaats geen riskante Autodiscover-protocolverzoeken. Deze houdt aanvallers tegen een server misleiden om hun boobytrap-trucs voor het instantiëren van objecten te accepteren, zelfs als die server niet is gepatcht.

Je kunt bijhouden van ons officiële preventie-, herstel- en responsadvies, en Sophos-klanten kunnen de namen van bedreigingsdetectie die door onze producten worden gebruikt, volgen via de Sophos X-Ops Twitter-feed (@SophosXOps).

Er is nieuwe informatie gepubliceerd over CVE-2022-41040 en CVE-2022-41082: https://t.co/pHUVBjUeDI 1/3

— Sophos X-Ops (@SophosXOps) 21 november 2022

---

MEER INFORMATIE OVER EXCHANGE-AUTHENTICATIE EN OAUTH2

Met Paul Ducklin en Chester Wisniewski
Intro en outro muziek door Edith Mudge.

---