natali_mis - stock.adobe.com

Unsicherer Austausch: Exchange-Server bergen eigene Risiken

Microsoft Exchange ist ein beliebtes Angriffsziel für Kriminelle. Bei On-Premises-Installationen nutzen die Angreifer häufig ungepatchte Schwachstellen der Exchange-Server aus.

Die für viele Unternehmen zentralen und daher weit verbreiteten Microsoft-Exchange-Server sind ein lohnendes Ziel für Hacker. Viele Legacy-Versionen sind dabei noch in Betrieb, obwohl sie Microsoft gar nicht mehr unterstützt, und deren Schwachstellen bleiben damit bestehen.

Auch aktuelle Versionen bilden dank Zero-Day-Schwachstellen ein lohnendes und weites Feld für zunächst opportunistisch vorgehende Angreifer. Professionelle Hacker nutzen neu bekanntgewordene Schwachstellen und führen automatische Scans nach davon betroffenen Systemen durch, um für sich einen Fernzugang einzurichten. In der Folge starten sie über eine identifizierte Schwachstelle manuell weitergeführte, komplexe und folgenreiche Attacken, um einen größtmöglichen Schaden zu verursachen oder auch ein Bedrohungsszenario für eine Lösegeldforderungen aufzubauen.

Diese Lücken in der Sicherheit von Exchange-Servern haben zudem einen weiteren Nachteil: Sie werden schneller und regelmäßiger publik als andere und das oft, bevor es einen Patch oder auch nur einen Workaround gibt. Der an sich vorbildliche Patchday ist für viele Hacker ein Startschuss, um zu sehen, welcher IT-Administrator das notwendige Update verpasst. Das ist häufig der Fall, denn viele Updates sind komplex, so dass die IT-Zuständigen sie nicht installieren. In einem Fall aus dem Jahr 2021 waren etwa von 120.000 betroffenen Exchange-Servern in den USA auch nach drei Wochen 10.000 Server ohne die bereitgestellten Updates und blieben damit gefährdet.

Abbildung 1: Ein weites Feld für Hacker: Die Computer-Suchmaschine Shodan zeigt, wie viele Server weltweit verwundbar sind, um mit der älteren Version des ProxyShell-Angriffs attackiert zu werden.
Abbildung 1: Ein weites Feld für Hacker: Die Computer-Suchmaschine Shodan zeigt, wie viele Server weltweit verwundbar sind, um mit der älteren Version des ProxyShell-Angriffs attackiert zu werden.

Doch auch die Softwarearchitektur des Microsoft-Exchange-Servers birgt Risiken in sich. Ein Exchange-Server ist aufgrund seiner Funktion kontinuierlich mit dem Internet verbunden und schreibt zahlreiche offene Ports zwingend vor. Zudem bedarf er hoher Privilegien, um seine Funktionalitäten abbilden zu können. Viele Schwachstellen beruhen auf fehlerhaften Implementierungen – zum Beispiel Speicherfehler oder Code Injection.

Microsoft Exchange ist zudem ein ideales Ziel für bestimmte Angriffe, weil es auf einem komplexen Netzwerk von Frontend- und Backend-Diensten beruht. Dies zu ändern ist durch den Legacy-Code für die geschuldete Rückwärtskompatibilität in Many-to-Many-Beziehungen schwer möglich. Backend-Dienste vertrauen zudem den Anfragen aus dem Frontend-CAS-Layer, die er durchlässt. Außerdem laufen sie häufig direkt auf dem Exchange Server mit einem SYSTEM-Account. Diesen können Hacker gut für ihre Aktivitäten nutzen, ebenso wie die Remote PowerShell (RPS) mit ihren Hunderten Cmdlet-Befehlen.

Proxies und SOA-Architektur als Angriffsfläche eines Exchange-Servers

Ein weiteres Problem ist die Service-Oriented-Architektur (SOA) der Exchange Server. SOA ist ein Ansatz des Software-Designs, der ein System als ein Bündel von Diensten organisiert. Diese Dienste kommunizieren miteinander über exakt definierte Schnittstellen. Die Hauptidee hinter SOA ist es, verschiedene Software-Komponenten unabhängig voneinander zu entwickeln und zu warten. Außerdem ermöglicht dieses Design, die einzelnen Elemente in verschiedenen Kombinationen zusammenzusetzen, wiederzuverwenden und so neue Systeme zu entwickeln.

Der Vorteil größerer Flexibilität und Skalierbarkeit durch das Beseitigen der Applikationsgrenzen bedingt aber auch Sicherheitsprobleme. Denn Sicherheitsmodelle sind nun nicht mehr länger ein hart kodierter Teil der Anwendung. Um dieses Problem zu lösen, verfolgen viele Entwickler den Ansatz, nur einige wenige gehärtete Dienstendpunkte als Proxy für andere Dienste zu exponieren. Unter Endpunkt wird in diesem Fall nicht ein physisches Gerät, sondern der adressierbare Endpunkt eines Dienstes verstanden – zum Beispiel eine URL für die Interaktion mit einer Servicekomponente.

Abbildung 2: Die Basis-Implementierung eines Proxy-Server-Endpunktes.
Abbildung 2: Die Basis-Implementierung eines Proxy-Server-Endpunktes.

Proxies in Microsoft Exchange als Instrument einer SOA-Sicherheitsarchitektur sollen sensible Backends von nicht vertrauenswürdigen öffentlichen Netzwerken abschirmen. Mit Ausnahme des Edge-Transport-Servers nehmen dabei alle Exchange-Server mehrere Rollen ein und vertrauen darauf, diese Rollen zu trennen. Der Client Access Service (CAS) übernimmt in dieser verteilten Architektur die Aufgabe einer zusätzlichen Sicherheitsebene, die für alle möglichen Formen einer Client-Verbindung am Frontend eingreift und ein Proxy für die Backend-Dienste ist.

Abbildung 3: Die Grundlagen der Microsoft-Exchange-Architektur.
Abbildung 3: Die Grundlagen der Microsoft-Exchange-Architektur.

Das Hosting des CAS und der Backend-Dienste auf demselben Exchange Mailbox Server verlangt nach Sicherheitskontrollen. Backend-Dienste akzeptieren daher nur Anfragen mit einem validen Kerberos-Token des CAS. Selbst wenn ein Angreifer einen direkten Zugang hätte, würden die Dienste alle Anfragen, die nicht von einem der CAS-Dienste überprüft ankommen, ablehnen.

Abbildung 4: Das Exchange-Backend überprüft die Anfragen eines vertrauten Frontends anhand des Autorisationsheaders
Abbildung 4: Das Exchange-Backend überprüft die Anfragen eines vertrauten Frontends anhand des Autorisationsheaders

SSRF-Angriffe hebeln die Exchange-Proxy-Sicherheit auf

Hacker haben aber schon früh einen Weg gefunden, den Schutz durch einen Proxy Layer zu umgehen. Eine Server Side Request Forgery (SSRF) erlaubt es ihnen, eine eigens angefertigte Anfrage von einem verwundbaren Server an einen anderen Server zu senden. So erhalten sie Zugang zu Ressourcen oder Informationen, die ihnen anders nicht direkt zugänglich sind. Angreifer können zudem im Namen des verwundbaren Servers Aktionen durchführen.

Im Fall einer Webapplikation mit SSRF-Sicherheitslücke könnte ein Angreifer eine Anfrage vom verwundbaren Server an eine lokale Netzwerkressource, wie etwa eine Datenbank, senden. Alternativ sendet er eine Anfrage an einen externen Server, wie einen Cloud-Dienst, um im Namen des gekaperten Servers Aktionen durchzuführen. Sobald ein Hacker eine Anfrage senden und deren Inhalt manipulieren kann, um Zugang zu erhalten, kann er frei schalten und walten.

Abbildung 5: Beispiel einer SSRF-Attacke auf einen Endpunkt von Proxy-Diensten.
Abbildung 5: Beispiel einer SSRF-Attacke auf einen Endpunkt von Proxy-Diensten.

Die SSRF-Attacken dienen typischerweise einem Denial of Service oder der Datenexfiltration. In Kombination mit anderen Sicherheitslücken können sie jedoch eine Exploit-Kette in Gang setzen, um weiteren Schadcode per Fernzugriff auszuführen (Remote Code Execution – RCE).

Abbildung 6: Detaillierte Übersicht über einen SSRF-Angriff auf Microsoft Exchange CAS.
Abbildung 6: Detaillierte Übersicht über einen SSRF-Angriff auf Microsoft Exchange CAS.

Das folgende Beispiel der ProxyShell-Attacke zeigt dabei die Komplexität eines Angriffs, der drei Exploits verkettet: Zunächst starten die Hacker mit einem bekannten SSRF-Angriff und erhalten so einen SYSTEM-Zugang auf die Backend-Dienste eines Microsoft-Exchange-2019-Mailbox-Servers. SYSTEM hat keine angehängten Mailboxen. Um SYSTEM-Restriktionen zu umgehen, deeskaliert der Angreifer die erworbenen Privilegien auf einen Domänen-Account.

Im nächsten Schritt speichert er den ausführbaren schädlichen Web-Shell-Code als eine E-Mail innerhalb der Mailbox-Datenbank. Mit PowerShell Remoting exportiert er diese Mail als eine .pst-Datei. Hierzu nutzt er das New-MailBoxExportRequest Cmdlet, aber diesmal mit einer .aspx-Erweiterung. Eine verwundbare Exchange-Version validiert keine Datenerweiterungen. Der verschlüsselte Web-Shell-Code einer Malware ist in einem Dateiformat gespeichert, welches während des Exports automatisch entschlüsselt wird.

Abbildung 7: Die ProxyShell-Exploit-Kette im Überblick.
Abbildung 7: Die ProxyShell-Exploit-Kette im Überblick.

Weitreichende Möglichkeiten für die Angreifer

Der als Mail-Inhalt importierte Schadcode erschließt den Hackern unterschiedliche Möglichkeiten. Dank des Zugriffes auf den Server durch Web Shell können Angreifer die Kommandos ihrer Wahl durchführen und verschiedene Aktionen starten: den Upload zusätzlicher Malware, das Entwenden sensitiver Inhalte oder Anschlussattacken auf weitere Systeme. In einem beobachteten Fall nutzten die Akteure die ProxyNotShell-Exploit-Kette und versuchten, zwei verschiedene Remote Acccess Tools (RAT) zu installieren.

Martin Zugec, Bitdefender

„Um Angriffe auf Microsoft Exchange-Server abzuwehren, bedarf es einer gestaffelten Cyberabwehr mit Fähigkeiten zu Prävention, Erkennung und Abwehr.“

Martin Zugec, Bitdefender

In einem anderen Fall versuchten Initial Access Broker einen persistenten Zugang an das kompromittierte System über Web-Shells zu erlangen und diesen zu verkaufen oder zu vermieten. Ebenso lässt sich Ransomware einschleusen: Hier installierten Cyberkriminelle den Bughatch-Downloader, der von den Betreibern der Cuba-Ransomware bekannt ist.

Nach Blocken des Downloads versuchten die Angreifer den Umweg über eine stille unbegleitete Installation des GoToAsist-Tools – eine legitime Remote Support Software von LogMeIn. Eine weitere belegte Möglichkeit ist der Diebstahl von Zugangsdaten aus einer SAM-Datenbank und einem LSASS-Speicher: Die Urheber der Attacke versuchten ein einkodiertes PowerShell-Kommando für einen Cobalt-Strike-Stager mit einem C&C-Server auszuführen, vermutlich auch mit der Absicht, eine erpresserische Attacke zu starten.

Microsoft-Exchange-Sicherheit in die IT-Abwehr integrieren

Um Angriffe auf Microsoft Exchange-Server abzuwehren, bedarf es einer gestaffelten Cyberabwehr mit Fähigkeiten zu Prävention, Erkennung und Abwehr. Zentraler Bestandteil der Prävention vor Angriffen für Microsoft Exchange Server mit einem meist langen Lebenszyklus ist eine strikte Patch-Disziplin und ein Patch Management, um nach nicht gepatchten Sicherheitslücken zu suchen. Ein solches Patch Management sollte sich dabei nicht nur auf Windows beschränken, sondern auf alle Applikationen und Dienste mit Internetzugang.

Für die effiziente Abwehr ist es wichtig, die Reputation von IP-Adressen und URLs zu überprüfen. Denn so erkennt die Cyberdefensive viele externe unerwünschten Akteure allein schon an ihrer Herkunft. Hacker, die Schwachstellen für  komplexe weitergehende Angriffe ausnutzen wollen, erfordern fortschrittliche Fähigkeiten, um Angriffe zu erkennen und abzuwehren: Entweder durch eine XDR-Plattform (Extended Detection and Response) oder mit der Hilfe externer Sicherheitsexperten als MDR-Dienst (Managed Detection and Response).

Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.

Erfahren Sie mehr über Anwendungs- und Plattformsicherheit