So hacken Sie einen ungepatchten Exchange-Server mit betrügerischem PowerShell-Code

Vor knapp zwei Monaten wurden einige besorgniserregende Fehlernachrichten bekannt: In Microsoft Exchange wurden zwei Zero-Day-Schwachstellen bekannt gegeben.

Wie wir damals geraten, diese Schwachstellen, offiziell benannt CVE-2022-41040 und CVE-2022-41082:

[waren] zwei Zero-Days, die miteinander verkettet [könnten], wobei der erste Fehler aus der Ferne verwendet wurde, um eine ausreichende Lücke zu öffnen, um den zweiten Fehler auszulösen, der möglicherweise die Remote-Code-Ausführung (RCE) auf dem Exchange-Server selbst ermöglicht.

Die erste Schwachstelle erinnerte an die lästigen und weithin missbrauchten ProxyShell-Sicherheitslücke von August 2021, weil es sich auf gefährliches Verhalten in der Autodiscover-Funktion von Exchange stützte, von Microsoft beschrieben als ein Protokoll, das ist „wird von Outlook- und EAS [Exchange ActiveSync]-Clients verwendet, um Postfächer in Exchange zu finden und sich mit ihnen zu verbinden“.

Glücklicherweise war die Autodiscover-Fehlfunktion, die beim ProxyShell-Angriff von jedem Remote-Benutzer, ob angemeldet oder nicht, ausgenutzt werden konnte vor mehr als einem Jahr gepatcht.

Leider reichten die ProxyShell-Patches nicht aus, um den Exploit für authentifizierte Benutzer zu schließen, was zum neuen CVE-2022-40140 Zero-Day führte, das bald lakonisch, wenn auch irreführend, synchronisiert ProxyNotShell.

Nicht so gefährlich, aber trotzdem gefährlich

Natürlich war ProxyNotShell bei weitem nicht so gefährlich wie das ursprüngliche ProxyShell, da es einen sogenannten authentifizierten Zugriff erforderte und daher nicht von irgendjemandem von überall missbraucht werden konnte.

Aber es stellte sich schnell heraus, dass auf vielen Exchange-Servern die Kenntnis des Anmeldenamens und des Kennworts eines beliebigen Benutzers ausreichen würde, um als authentifiziert zu gelten und diesen Angriff durchzuführen, selbst wenn dieser Benutzer selbst die Zwei-Faktor-Authentifizierung (2FA) verwenden müsste, um sich ordnungsgemäß für den Zugriff anzumelden ihre E-Mail.

Als Sophos-Experte Chester Wisniewski Leg es damals:

Es ist eine „Mid-Authentication-Schwachstelle“, wenn Sie es so nennen wollen. Das ist ein gemischter Segen. Es bedeutet jedoch, dass ein automatisiertes Python-Skript nicht einfach das gesamte Internet scannen und möglicherweise jeden Exchange-Server der Welt innerhalb von Minuten oder Stunden ausnutzen kann, wie wir es bei ProxyLogon und ProxyShell im Jahr 2021 gesehen haben. […]

Sie brauchen ein Passwort, aber leider ist es wahrscheinlich nicht allzu schwierig, eine Kombination aus E-Mail-Adresse und Passwort zu finden, die auf einem bestimmten Exchange-Server gültig ist. Und Sie wurden bisher möglicherweise nicht ausgenutzt, denn um sich erfolgreich bei Outlook Web Access [OWA] anzumelden, benötigen Sie ihr FIDO-Token oder ihren Authentifikator oder welchen zweiten Faktor Sie auch immer verwenden.

Aber dieser Angriff erfordert diesen zweiten Faktor nicht. […] Nur eine Kombination aus Benutzername und Passwort zu erwerben, ist eine ziemlich niedrige Hürde.

Wie Sie sich wahrscheinlich erinnern, gingen viele von uns davon aus (oder hofften zumindest), dass Microsoft sich beeilen würde, einen Fix für die ProxyNotShell-Löcher zu finden, da es noch zwei Wochen bis zum Patchday im Oktober waren.

Aber wir waren enttäuscht, als wir feststellten, dass es anscheinend eine zuverlässige Lösung gab komplexer als gedacht, und der Oktober kam und ging, wobei ProxyNotShell nur durch Problemumgehungen und nicht durch richtige Patches behoben wurde.

Selbst der Patch Tuesday im November hat die benötigten Fixes nicht direkt bereitgestellt, obwohl die Patches kam trotzdem raus am selben Tag als Teil eines Exchange-spezifischen Sicherheitsupdates, das separat abgerufen und installiert werden konnte:

Proof-of-Concept enthüllt

Jetzt, da sich der Staub gelegt hat und jeder Zeit hatte, seine Exchange-Server zu patchen (zumindest diejenigen, die er nicht vergessen hat), haben Forscher der Zero Day Initiative (ZDI), denen diese Schwachstellen ursprünglich zur Einreichung zur Verfügung gestellt wurden, verantwortlich gemacht Microsoft, habe erklärt wie die Bugs ausgenutzt werden können.

Die schlechte Nachricht ist, abhängig von Ihrer Meinung zu offenkundigen Offenlegungen von Exploits, dass das ZDI-Team nun effektiv einen Proof-of-Concept (PoC) vorgelegt hat, der erklärt, wie man Exchange-Server angreift.

Die gute Nachricht ist natürlich:

• Wir können die Fehler jetzt selbst studieren und verstehen. Dies hilft uns allen nicht nur sicherzustellen, dass die von uns getroffenen allgemeinen Vorsichtsmaßnahmen (die nicht nur auf das Patchen beschränkt sind) wahrscheinlich den Schutz bieten, den wir erwarten, sondern informiert uns auch über Programmierpraktiken, die wir in Zukunft vermeiden möchten, also verzichten wir darauf Lassen Sie sich nicht dazu verleiten, Bugs dieser Art in unserem eigenen serverseitigen Code zu öffnen.
• Wir haben jetzt keine Ausreden mehr, die Patches nicht anzuwenden. Wenn wir uns mit der Aktualisierung geschleppt haben, macht die Erklärung von ZDI, warum der Angriff funktioniert, deutlich, dass die Heilung der Krankheit definitiv vorzuziehen ist.

So funktioniert's

ZDIs Erklärung dieser Schwachstelle ist eine faszinierende Geschichte darüber, wie komplex es sein kann, alle Teile zu verketten, die Sie benötigen, um eine Schwachstelle in einen praktikablen Exploit zu verwandeln.

Es lohnt sich auch zu lesen, um zu verstehen, warum das Untersuchen eines vorhandenen Exploits dazu beitragen kann, andere Möglichkeiten aufzudecken, wie eine Schwachstelle missbraucht werden könnte, wodurch möglicherweise zusätzliche Patches veranlasst, Konfigurationsänderungen erzwungen und neue Programmierpraktiken gefördert werden, die möglicherweise nicht durch die Behebung offensichtlich waren das ursprüngliche Loch.

Die Erklärung ist notwendigerweise kompliziert und ziemlich technisch und führt Sie durch eine lange Reihe von Schritten, um am Ende die Remote Code Execution (RCE) zu erreichen.

In der Hoffnung, Ihnen zu helfen, den allgemeinen Details leichter zu folgen, wenn Sie sich entscheiden, den ZDI-Bericht zu lesen, ist hier eine hoffentlich nicht zu vereinfachte Zusammenfassung mit den Schritten in umgekehrter Reihenfolge…

… damit Sie im Voraus wissen, warum die Geschichte diese Richtung einschlägt:

• SCHRITT 4. Bringen Sie Exchange remote dazu, ein .NET-Objekt Ihrer Wahl mit einem Initialisierungsparameter Ihrer Wahl zu instanziieren.

In der modernen Codierung ist an instantiiertes Objekt ist das Fachjargonwort für einen zugewiesenen Speicherblock, der automatisch mit den Daten und Ressourcen initialisiert wird, die er benötigt, während er verwendet wird, und an einen bestimmten Satz von Funktionen gebunden ist, die damit arbeiten können. (Instanziieren ist nur ein schickes Wort für erstellen.)

Objekte können vom Betriebssystem selbst verwaltet und gesteuert werden, um die Art von Fehlern bei der Speicherverwaltung zu vermeiden, die in einer Sprache wie C üblich sind, wo Sie normalerweise Speicher selbst zuweisen, die relevanten Datenfelder von Hand ausfüllen und sich daran erinnern müssen Geben Sie den Speicher und die Ressourcen frei, die Sie verwenden, wie Netzwerk-Sockets oder Festplattendateien, wenn Sie fertig sind.

Objekten ist im Allgemeinen eine programmatische Funktion namens a zugeordnet Konstruktor, die automatisch ausgeführt wird, wenn ein neues Objekt erstellt wird, um die richtige Menge an Speicher und die richtigen Systemressourcen zuzuweisen.

Normalerweise müssen Sie einen oder mehrere Parameter als Argumente an den Konstruktor übergeben, um anzugeben, wie das Objekt zu Beginn konfiguriert werden soll.

Einfach ausgedrückt, wenn Sie beispielsweise a instanziieren TextString Objekt (wir erfinden diese Namen, aber Sie bekommen die Idee) mit einem Parameter, der selbst eine Textzeichenfolge ist, wie z example.com:8888...

… werden Sie wahrscheinlich mit einem Speicherpuffer enden, der für Ihren Text reserviert ist, der so initialisiert ist, dass er denselben Wert enthält, den Sie übergeben haben, nämlich den Rohtext example.com:8888.

In diesem Zusammenhang stellt die als Daten an den Objektkonstruktor übergebene Textzeichenfolge nicht sofort eine offensichtliche Cybersicherheitsbedrohung dar, wenn Sie den Konstruktor aus der Ferne auslösen, außer einem möglichen Denial of Service (DoS), indem Sie wiederholt nach immer größeren Zeichenfolgen fragen versuchen, die Erinnerung zu erschöpfen.

Aber wenn Sie beispielsweise a instanziieren würden ConnectedTCPClient Objekt, das denselben Textzeichenfolgenparameter von verwendet example.com:8888, haben Sie möglicherweise einen Speicherpuffer, der bereit ist, temporäre Daten zu speichern, zusammen mit einem vom Betriebssystem zugewiesenen Netzwerk-Socket, der bereit ist, Daten mit dem Server auszutauschen example.com über TCP-Port 8888.

Sie können dort das Risiko der Remote-Code-Ausführung sehen, selbst wenn Sie niemals Daten an den offenen Socket senden können, da Sie den Server dazu verleitet haben, einen von Ihnen kontrollierten Standort anzurufen.

Vielleicht finden Sie sogar ein Objekt namens, sagen wir, RunCmdAndReadOutput, wobei die Textzeichenfolge, die Sie als Parameter senden, buchstäblich ein Befehl ist, den Sie automatisch ausführen möchten, sobald das Objekt erstellt wird, damit Sie seine Ausgabe später erfassen können.

Selbst wenn Sie die Ausgabe des Befehls nie wiederherstellen können, würden Sie durch die Instanziierung eines solchen Objekts dennoch einen auszuführenden Befehl auswählen können, wodurch Sie eine generische Remote-Code-Ausführung erhalten und ein Risiko darstellen, das nur durch die Zugriffsrechte des Serverprozesses selbst begrenzt ist .

Natürlich ist der Angriff erst so einfach, wenn Sie die letzte Stufe erreicht haben, was Sie eigentlich nicht können sollten, da Exchange eine strenge Zulassungsliste hat, die Sie daran hindert, ein altes Objekt zum Instanziieren auszuwählen.

Theoretisch können nur sichere oder risikoarme Objekte über PowerShell aus der Ferne erstellt werden, so dass unsere imaginäre Instanziierung TextString oben oder a SimpleIntegerValue, könnte als akzeptabel angesehen werden, während a ConnectedTCPClient oder eine RunCmdAndReadOutput wäre es definitiv nicht.

Aber die ZDI-Forscher bemerken, dass sie dies tun könnten, bevor sie den letzten Schritt ausgelöst haben:

• SCHRITT 3. Exchange aus der Ferne dazu bringen, zu glauben, dass ein Objekt mit geringem Risiko, das den Sicherheitstest bestanden hat, tatsächlich ein anderes Objekt Ihrer Wahl ist.

Trotzdem können Sie davon ausgehen, dass Exchange die Remote-Erstellung sogar von Objekten mit geringem Risiko verhindert, um die Bedrohung noch weiter zu minimieren.

Aber die Forscher fanden heraus, dass sie:

• SCHRITT 2. Exchange aus der Ferne dazu bringen, es zu verwenden PowerShell Remoting Funktion zum Erstellen eines Objekts basierend auf extern gesteuerten Initialisierungsparametern.

Und das war möglich wegen der ProxyShell-ähnlichen Lücke, die nur halb gepatcht wurde:

• SCHRITT 1. Bringen Sie Exchange aus der Ferne dazu, eine Webanfrage mit Code zu akzeptieren und zu verarbeiten, indem Sie eine gültige username:password Feld auch in die Anfrage.

Selbst wenn der in der Anfrage genannte Benutzer nicht wirklich angemeldet war und eine Art 2FA-Prozess durchlaufen müsste, um auf sein eigenes Postfach zuzugreifen, ein Angreifer, der seine kannte username:password Kombination hätte genügend Authentifizierungsinformationen, um Exchange dazu zu bringen, eine Webverbindung zu akzeptieren, die zum Starten der in den Schritten 2 bis 4 oben beschriebenen Angriffskette verwendet werden könnte.

Grob gesagt, jeder gültig username:password Eine Kombination wäre ausreichend, da die „Authentifizierung“ lediglich erforderlich war, um zu verhindern, dass Exchange die HTTP-Anforderung im Voraus ablehnt.

Was ist zu tun?

Beachten Sie, dass dieser Angriff nur funktioniert:

• Wenn Sie lokale Exchange-Server haben. Microsoft behauptet, die eigenen Cloud-Dienste schnell gesperrt zu haben, sodass Exchange Online nicht betroffen ist. Stell sicher, dass du wissen, wo sich Ihre Exchange-Server befinden. Selbst wenn Sie jetzt Exchange Online verwenden, werden möglicherweise noch lokale Server ausgeführt, die möglicherweise versehentlich von Ihrem Migrationsprozess übrig geblieben sind.
• Wenn Ihre Server nicht gepatcht sind. Upewnij się, że das Exchange-Software-Update vom 2022 angewendet zu Schließen Sie die Schwachstellen die der Exploit erfordert.
• Wenn Ihre Server immer noch die Standardauthentifizierung akzeptieren, die auch als Legacy-Authentifizierung bezeichnet wird. Upewnij się, że alle Aspekte der Legacy-Authentifizierung blockiert Ihre Server werden die also nicht akzeptieren username:password die oben erwähnten Header und akzeptiert von vornherein keine riskanten AutoErmittlungsprotokollanforderungen. Dies stoppt Angreifer einen Server dazu zu bringen, ihre mit Sprengfallen versehenen Objekt-Instanziierungstricks zu akzeptieren, selbst wenn dieser Server nicht gepatcht ist.

Du kannst dich Bleib dran unserer offiziellen Präventions-, Behebungs- und Reaktionsempfehlungen, und Sophos-Kunden können die von unseren Produkten verwendeten Bedrohungserkennungsnamen über den Sophos X-Ops Twitter-Feed verfolgen (@SophosXOps).

Zu CVE-2022-41040 und CVE-2022-41082 wurden neue Informationen veröffentlicht: https://t.co/pHUVBjUeDI 1/3

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

---

ERFAHREN SIE MEHR ÜBER EXCHANGE-AUTHENTIFIZIERUNG UND OAUTH2

Mit Paul Ducklin und Chester Wisniewski
Intro- und Outro-Musik von Edith Mudge.

---