Antivirensoftware Test 2022: Schutz vor den neuesten Bedrohungen

Die digitale Welt entwickelt sich rasant weiter, und mit ihr die ausgeklügelten Methoden von Cyberkriminellen. Insbesondere Microsoft Exchange-Systeme sind ins Visier geraten. Ende 2022 beobachteten Sicherheitsexperten von Bitdefender Labs einen Anstieg von Angriffen, die auf die Ausnutzung von ProxyNotShell/OWASSRF-Exploits abzielten, um Microsoft Exchange-Bereitstellungen zu kompromittieren. Server-Side Request Forgery (SSRF)-Angriffe auf Microsoft Exchange-Server gehören zu den beliebtesten und am häufigsten ausgenutzten Schwachstellen. Dieser Artikel beleuchtet die technischen Details dieser Angriffe und gibt Einblicke in die jüngsten Angriffsvektoren, die in freier Wildbahn entdeckt wurden.

Serviceorientierte Architektur als Grundlage

Die serviceorientierte Architektur (SOA) hat sich über lange Zeit bewährt. Sie ist ein Ansatz im Software-Design, bei dem ein System als Sammlung von Diensten organisiert wird, die über klar definierte Schnittstellen miteinander kommunizieren. Das Hauptziel von SOA ist es, die unabhängige Entwicklung und Wartung verschiedener Softwarekomponenten zu ermöglichen und deren Wiederverwendung in unterschiedlichen Kombinationen zur Erstellung neuer Systeme zu fördern. Einer der Hauptvorteile von SOA liegt in der erhöhten Flexibilität und Skalierbarkeit durch die Auflösung von Anwendungs grenzen. Dieses Konzept brachte jedoch neue Sicherheitsherausforderungen mit sich, da Sicherheitsmodelle nicht mehr fest in die Anwendungen integriert sind. Ein gängiger Ansatz ist die Bereitstellung einer begrenzten Anzahl gehärteter Service-Endpunkte, die als Proxy für andere Dienste fungieren. Ein “Endpunkt” bezieht sich hierbei nicht auf ein physisches Gerät, sondern auf eine netzwerkadressierbare Schnittstelle eines Dienstes, typischerweise eine URL, über die mit einer Dienstkomponente interagiert werden kann.

Diagramm zur Service-orientierten Architektur*Abb. 1 – Grundlegende Implementierung eines Proxy-Service-Endpunkts*

Microsoft Exchange – Eine scheinbar unüberwindbare Hürde?

Microsoft Exchange ist ein Beispiel für eine Anwendung, die Proxydienste nutzt, um das sensible Backend vor dem unvertrauenswürdigen öffentlichen Netzwerk zu schützen. Über die Jahre entwickelte sich die Philosophie von Microsoft Exchange hin zum Prinzip der Ko-Lokation – alle Exchange-Server (außer Edge Transport-Servern) sind Multi-Rollen-Server und setzen auf die Trennung der Rollen. Die Client Access Services (CAS) bilden die Schicht, die für die Annahme aller Arten von Client-Verbindungen (Front-End) und deren Weiterleitung an Back-End-Dienste zuständig ist.

Übersicht über die Microsoft Exchange-Architektur*Abb. 2 – Hochrangige Übersicht der Microsoft Exchange-Architektur*

Da CAS und die Backend-Dienste auf demselben Exchange Mailbox-Server gehostet werden, müssen Sicherheitskontrollen vorhanden sein. Backend-Dienste akzeptieren nur Anfragen mit einem gültigen Kerberos-Token von CAS. Selbst wenn man direkten Zugriff auf diese Dienste hätte, würden sie alle Verbindungen ablehnen, die nicht von einem der CAS-Dienste stammen.

Exchange-Backend-Validierung*Abb. 3 – Das Exchange-Backend validiert, dass Anfragen von vertrauenswürdigen Frontends stammen, mittels eines Autorisierungsheaders*

Server-Side Request Forgery (SSRF) – Die unterschätzte Schwachstelle

Wie bei vielen anderen “Secure-by-Design”-Architekturen wurden auch hier schnell neue Angriffstechniken entdeckt, um diese scheinbar sicheren Systeme ins Visier zu nehmen. Server-Side Request Forgery (SSRF) ist eine Angriffsart, die es einem Angreifer ermöglicht, eine manipulierte Anfrage von einem anfälligen Server an einen anderen Server zu senden, im Namen des anfälligen Servers. Dies kann dem Angreifer den Zugriff auf Ressourcen oder Informationen ermöglichen, die ihm sonst nicht direkt zugänglich wären, und ihm erlauben, Aktionen im Namen des anfälligen Servers durchzuführen.

Beispielsweise könnte ein Angreifer, wenn eine Webanwendung anfällig für SSRF ist, eine Anfrage vom anfälligen Server an eine lokale Netzwerkressource senden, die für den Angreifer normalerweise nicht zugänglich ist, wie etwa eine Datenbank. Alternativ könnte der Angreifer eine Anfrage an einen externen Server, wie z. B. einen Cloud-Dienst, senden, um Aktionen im Namen des anfälligen Servers durchzuführen. Um einen SSRF-Angriff erfolgreich durchzuführen, muss der Angreifer in der Lage sein, eine Anfrage vom anfälligen Server zu senden und den Inhalt der Anfrage so zu manipulieren, dass er die gewünschten Ressourcen abrufen oder die gewünschten Aktionen ausführen kann.

Beispiel eines SSRF-Angriffs*Abb. 4 – Beispiel eines SSRF-Angriffs auf einen Proxy-Service-Endpunkt*

Angriffe auf Microsoft Exchange – Der Beginn der Problematik

Die meisten von Sicherheitsexperten entdeckten Schwachstellen basieren auf fehlerhaften Implementierungen, wie z. B. Speicherfehlern oder Code-Injektionen. Es ist eher selten, Schwachstellen in der übergeordneten Architektur zu finden. Architektur-Schwachstellen sind in Produktionssystemen schwer zu beheben, insbesondere bei weit verbreiteter Software, bei der die Abwärtskompatibilität eine wichtige Funktion darstellt – wie bei Microsoft Exchange-Servern.

Anfang 2021 konzentrierten sich Sicherheitsexperten wie Orange Tsai und das DEVCORE Research Team genauer auf die CAS-Implementierung. Sie entdeckten nicht nur mehrere kritische Schwachstellen, sondern identifizierten CAS auch als neue Angriffsfläche, die seit Exchange 2013 auf allen Microsoft Exchange-Servern vorhanden ist. Die CAS-Implementierung auf lokalen Microsoft Exchange-Servern ist anfällig für SSRF-Angriffe. Diese anfängliche Entdeckung war jedoch nur die Spitze des Eisbergs.

Microsoft Exchange CAS anfällig für SSRF*Abb. 5 – Microsoft Exchange CAS ist anfällig für SSRF-Angriffe*

SSRF-Angriffe sind typischerweise auf die Kompromittierung der Verfügbarkeit oder Vertraulichkeit beschränkt, wie z. B. Denial of Service oder die Offenlegung sensibler Daten. In Kombination mit anderen Schwachstellen können sie jedoch Exploit-Ketten bilden, die zur Ausführung von Remote-Code (RCE) führen.

Betrachten wir eine dieser Exploit-Ketten genauer, um zu verstehen, wie Exploits zusammenwirken. Wir verwenden ProxyShell als Beispiel, eine Kombination aus drei verschiedenen Exploits. Der erste Exploit ist der bekannte SSRF-Angriff, der SYSTEM-Zugriff auf die Backend-Dienste gewährt. Da SYSTEM keine angebundenen Mailboxen hat, nutzt der Angreifer einen Exploit zur Privilegienerweiterung, um seinen Zugriff auf ein Domänenkonto “herabzustufen”. Als Nächstes speichert der Angreifer den Code der Web-Shell als E-Mail in der Mailbox-Datenbank. Mithilfe von PowerShell Remoting wird diese E-Mail dann mithilfe des Cmdlets New-MailBoxExportRequest als .pst-Datei exportiert, jedoch mit der Endung .aspx (die anfällige Version von Exchange validiert die Dateiendung nicht). Da die Permutationskodierung, die das PST-Dateiformat verwendet, gut dokumentiert ist, wird der verschlüsselte Web-Shell-Code in einem Format gespeichert, das während des Exportvorgangs automatisch entschlüsselt wird (clever!).

ProxyShell Exploit-Kette*Abb. 6 – ProxyShell Exploit-Kette*

Microsoft Exchange ist aus mehreren Gründen ein ideales Ziel für diese Exploit-Ketten:

• Es existiert ein komplexes Netzwerk von Frontend- und Backend-Diensten mit Legacy-Code zur Gewährleistung der Abwärtskompatibilität (viele-zu-viele-Beziehungen).
• Backend-Dienste vertrauen den Anfragen von der Frontend-CAS-Schicht – im Falle eines SSRF-Angriffs wird ein gültiges Kerberos-Token von CAS generiert.
• Mehrere Backend-Dienste laufen als Exchange Server selbst (SYSTEM-Konto).
• Remote PowerShell (RPS) umfasst Hunderte von PowerShell-Cmdlets.

Innerhalb relativ kurzer Zeit wurden mehrere Kombinationen von Schwachstellen entdeckt:

• ProxyLogon – Die ursprüngliche Exploit-Kette war eine Kombination aus CVE-2021-26855 und CVE-2021-27065. Das Ergebnis war eine RCE-Kette, die keine Authentifizierung erforderte.
• ProxyShell – Die zweite Exploit-Kette war eine Kombination aus CVE-2021-34473, CVE-2021-34523 und CVE-2021-31207. Das Ergebnis war eine RCE-Kette, die keine Authentifizierung erforderte.
• ProxyNotShell – Diese Exploit-Kette war eine Kombination aus CVE-2022-41080 und CVE-2022-41082. Obwohl diese RCE-Kette eine Authentifizierung erfordert, können beliebige gültige Anmeldeinformationen zur Eskalation des Zugriffs verwendet werden.
• OWASSRF – Zuerst von Crowdstrike gemeldet, nutzt diese Exploit-Kette die gleiche Kombination von Schwachstellen wie ProxyNotShell. Der Unterschied besteht darin, dass anstelle des Autodiscover-Dienstendpunkts der OWA-Dienstendpunkt des CAS-Frontends verwendet wird. Durch Änderung des vom SSRF-Angriff anvisierten Dienstendpunkts können Bedrohungsakteure die von Microsoft bereitgestellten Abhilfemaßnahmen umgehen.

Diese Liste von Exploit-Ketten ist keineswegs vollständig – es gibt weitere Ketten, die Autodiscover- und OWA-Dienste ausnutzen. Es ist nicht überraschend, dass diese Exchange-Schwachstellen sowohl in den Top 2021 routinemäßig ausgenutzten Schwachstellen als auch in den Top CVEs, die aktiv von staatlich gesponserten Cyberakteuren der Volksrepublik China ausgenutzt werden (Stand Oktober 2022) aufgeführt sind.

Aktuelle Entwicklungen und reale Angriffe

In diesem abschließenden Abschnitt werfen wir einen Blick auf einige reale Angriffe, die unsere Experten in den Bitdefender Labs entdeckt haben. Ende November 2022 registrierten wir eine erhöhte Nutzung von ProxyNotShell/OWASSRF zur Ausführung bösartiger Befehle.

Die Angriffsziele befanden sich überwiegend in den Vereinigten Staaten, aber auch Unternehmen aus Polen, Österreich, Kuwait und der Türkei waren betroffen. Die Branchen dieser Opfer umfassten Immobilien, Anwaltskanzleien, Fertigung, Beratung, Großhandel sowie Kunst und Unterhaltung. Wie erwartet, handelte es sich bei den meisten dieser Angriffe um opportunistische Attacken und nicht um gezielte Aktionen.

Fall 1 – Tools für Fernverwaltung

Im ersten Fall nutzten Angreifer die ProxyNotShell-Exploit-Kette und versuchten, zwei verschiedene Fernzugriffstools zu installieren. Das erste Tool war Meterpreter – eine Metasploit-Attack-Payload, die eine interaktive Shell bereitstellt und mittels In-Memory-DLL-Injection eingesetzt wird. Das zweite war ConnectWise Control (früher bekannt als ScreenConnect).

Beispiele für während dieses Angriffs erkannte (und blockierte) Befehlszeilen:

Die Angriffe wurden von den IP-Adressen 64.190.113[.]48 und 162.243.150[.]6 gestartet. Alle Stage-Server, von denen die Payload heruntergeladen wurde, sind bereits kompromittierte Microsoft Exchange-Server, höchstwahrscheinlich auf die gleiche Weise kompromittiert.

Alle URLs und Befehlszeilen wurden blockiert. Es ist anzunehmen, dass die Bereitstellung von Ransomware das wahrscheinlichste Ziel der Angreifer war.

Fall 2 – Initial Access Broker

Im zweiten Fall versuchten Angreifer, Persistenz auf dem kompromittierten System über Web-Shells zu etablieren. Eine Web-Shell ist ein bösartiges Programm (oder Skript), das auf einen Webserver hochgeladen wird, um unbefugten Zugriff auf den Server zu erlangen. Nach der Bereitstellung einer Web-Shell kann ein Angreifer beliebige Befehle oder Skripte ausführen und eine Vielzahl von Aktionen durchführen, wie z. B. das Hochladen zusätzlicher Malware, das Stehlen sensibler Daten oder das Starten von Angriffen auf andere Systeme.

Web-Shells werden häufig von Initial Access Brokern (IAB) verwendet. Ein Initial Access Broker ist eine Art Cyberkrimineller, der sich darauf spezialisiert, initialen Zugriff auf das Netzwerk einer Zielorganisation zu erlangen. Nach Erlangung des initialen Zugriffs kann der Access Broker den Zugriff auf das kompromittierte Netzwerk an andere kriminelle Gruppen verkaufen oder vermieten.

Schwachstellen wie Exchange-Proxy-Exploit-Ketten sind eine Goldgrube für Access Broker, da diese oft opportunistische Angriffe anstelle von gezielten bevorzugen. Mit dem Aufkommen von Ransomware-as-a-Service-Gruppen können Initial Access Broker eine stetige Versorgung potenzieller Ransomware-Ziele für Ransomware-Affiliates bereitstellen.

Bei diesem Angriff werden mehrere Echo-Befehle verkettet, um eine Base64-kodierte ausführbare Datei auf der Festplatte zu generieren.

Die Echo-Kette wird auch verwendet, um eine VBScript-Datei am Speicherort <span data-contrast="auto">%TEMP%qawWu.vbs</span> zu erstellen. Nach der Ausführung dieser VBscript-Datei liest sie den Inhalt der Base64-Datei <span data-contrast="auto">sMIod.b64</span>, dekodiert den Inhalt und speichert ihn an einem neuen Speicherort %TEMP%ujjQl.exe. Nach dieser Operation wird die ausführbare Datei gestartet und beide Dateien sMIod.b64 und <span data-contrast="auto">qawWu.vbs</span> werden gelöscht.

Diagramm eines Angriffs zur Erstellung von Web-Shells

Nach der Ausführung von ujjQl.exe lädt diese bösartige ausführbare Datei eine weitere ausführbare Datei von http://mail.p***a.com/owa/auth/data.zip (MD5 ad362104eea7afcd727b77e89a4a5e2e) herunter. Als Ergebnis dieser Operation werden zwei .aspx-Dateien (Web-Shells) an den folgenden Speicherorten erstellt:

• <span data-contrast="auto">%ExchangeInstallPath%FrontEndHttpProxyecpauthLogout.aspx</span> (MD5 ad086021b7ee50ff5b9acec4d79736be)
• %SystemDrive%inetpubwwwrootaspnet_clientsystem_web\iisstart.aspx (MD5 607a6987395f02086e0e355c9ba4d76e)

Fall 3 – Cuba Ransomware

In diesem Fall nutzten Angreifer die ProxyNotShell-Exploit-Kette, um PowerShell-Befehle auszuführen. Zunächst versuchten sie, die Datei <span data-contrast="auto">komar<xx>.dll</xx></span> herunterzuladen, die wir als Bughatch-Downloader identifiziert haben. Bughatch wird bekanntermaßen in Cuba-Ransomware-Operationen eingesetzt, unsere Zuordnung basiert jedoch hauptsächlich auf vielen bekannten IOCs und wiederverwendeter Infrastruktur. Nachdem die Download-Befehle blockiert wurden, fuhren sie mit der unbeaufsichtigten (stummgeschalteten) Installation des GoToAssist-Tools fort. GoToAssist ist eine legitime Fernsupport-Software von LogMeIn Inc.

Die nächste Aktion war die laterale Bewegung mittels GoToAssist:

Um den Zugriff aufrechtzuerhalten, erstellten die Angreifer auch Benutzerkonten mit lokalen Administratorrechten. Sie versuchten, verschiedene Tools herunterzuladen, wobei einige Dateien über PowerShell und andere über die bereitgestellten Tools heruntergeladen wurden. Die Analyse der heruntergeladenen Tools: