
Top News Exchange Hack: Zwei neue Zero-Days im Microsoft Exchange Server werden aktiv für Angriffe ausgenutzt
von Tina Siering

Allgeier secion Webinar am 04.10.2022 - Microsoft Exchange Zero Day
Warnung vor zwei neuen kritischen IT-Sicherheitslücken
Achtung: Am 29. September 2022 veröffentlichte das GTSC einen Blogartikel zu Sicherheitslücken mit einem hohen Risiko! Es wird über eine neue Angriffsmöglichkeit berichtet, bei der zwei noch nicht veröffentlichte Sicherheitslücken (0-Day) ausgenutzt werden. Angreifer können dabei Remote Code Execution (RCE) auf betroffene Microsoft On-Premise Exchange-Server durchführen.
Auch unsere Security Analysten haben bei der aktiven Analyse im Rahmen unserer Managed Security Services Auffälligkeiten in Zusammenhang mit den neuen Zero-Day-Schwachstellen verifiziert. Die Schwachstelle tritt dabei u.a. im Outlook Web Access (OWA) bzw. in einer dazugehörigen Komponente auf und ist von Microsoft bisher nicht behoben worden.
Besonders kritisch:
Nach aktuellem Kenntnisstand unserer Security-Analysten stellen sich die Schwachstellen als so kritisch heraus, dass sie es dem Angreifer ermöglichen Remote Code Execution (RCE) auf dem kompromittierten System durchzuführen. Es gibt derzeit noch keine CVE-Nummern für diese Schwachstellen. Bei der Zero Day Initiative sind aber Advisories mit einem CVSS von 8.8 und 6.3 eingereicht worden.
Anfragen, die in dieser Exploit-Kette verwendet werden, ähneln aber jenen, die bei Angriffen verwendet werden, die auf die ProxyShell-Schwachstellen abzielen.
Microsoft hat bisher keine Informationen zu den beiden Sicherheitslücken veröffentlicht!
Der Exploit funktioniert in zwei Phasen:
- Anfragen mit einem ähnlichen Format wie die ProxyShell-Schwachstelle: autodiscover/autodiscover.json?@evil.com/<Exchange-backend-endpoint>&Email=autodiscover/autodiscover.json%3f@evil.com .
- Die Verwendung des obigen Links, um auf eine Komponente im Backend zuzugreifen, in der das RCE implementiert werden könnte.
Bis Microsoft entsprechende Sicherheitsupdates veröffentlicht, um die beiden Zero-Days zu beheben, teilte GTSC einen temporären Workaround mit:
Wählen Sie in Autodiscover at FrontEnd die Registerkarte URL Rewrite und dann Request Blocking.
- Fügen Sie dem URL-Pfad die Zeichenfolge „ .*autodiscover\.json.*\@.*Powershell.* “ hinzu.
- Bedingungseingabe: Wählen Sie {REQUEST_URI}
Unsere Security Analysten haben die Empfehlung des Workarounds geprüft und kommen zur Erkenntnis den Zugriff von extern besser komplett zu unterbinden, um potenzielle ernsthafte Schäden in der aktuellen zu vermeiden. Läuft Ihr Exchange Server nicht On-Premise oder ist OWA nicht von extern erreichbar, so sind Sie von dieser Lücke zwar betroffen, jedoch besteht keine Gefahr einer Kompromittierung.
Unsere Allgeier secion-Kunden mit einem aktiven Managed Service-Vertrag für ACD werden selbstverständlich über maliziöse Kommunikation auf ihren Systemen informiert, aktuell prüfen wir aktiv auf IoCs.
Handlungsempfehlung
1. Betroffene Systeme vom Internet trennen
a) Firewall-Regelwerk deaktivieren
2. Bei virtuellen Maschinen sollte zusätzlich – am besten vor dem Trennen der Netzwerkverbindung – ein Snapshot mit Arbeitsspeicher erstellt werden. Dies könnte bei einer späteren forensischen Untersuchung hilfreich sein.
3. Betroffenes System temporär vom Netzwerk trennen
a)Virtuelle Netzwerkkarte oder physisches Netzwerkkabel trennen
4. Betroffene Systeme offline auf bekannte Indicator of Compromise (IoC) überprüfen
Am sichersten ist die vollständige Trennung des Systems vom Internetzugang (ein- und ausgehend) sowie eine temporäre Trennung des Systems vom Netzwerk allgemein. Während das System nicht mehr mit dem Netzwerk verbunden ist, sollten die Logs des zum Exchange gehörigen IIS auf malizöse Verbindungen überprüft werden. Zusätzlich sollten die in den bekannten IoCs aufgelisteten Dateien überprüft werden.
Um Organisationen und Unternehmen bei der Überprüfung zu helfen, ob Exchange-Server bereits von ausgenutzt wurden, hat GTSC eine Richtlinie und ein Tool zum Scannen von IIS-Protokolldateien (standardmäßig gespeichert im Ordner %SystemDrive%\inetpub\logs\LogFiles) veröffentlicht.
Method 1: Use powershell command:
Get-ChildItem -Recurse -Path <Path_IIS_Logs> -Filter “*.log” | Select-String -Pattern ’powershell.*autodiscover\.json.*\@.*200
Weiterführende Informationen: https://gteltsc.vn/blog/warning-new-attack-campaign-utilized-a-new-0day-rce-vulnerability-on-microsoft-exchange-server-12715.html
Melden Sie sich zu diesem wichtigen Thema bereits heute zum Webinar "Microsoft Exchange 0-Day" an, welches wir am 04.10.2022 von 14 Uhr bis 15 Uhr durchführen werden.
Anmeldelink: https://register.gotowebinar.com/register/7786495483422818576
Wir veröffentlichen an dieser Stelle im Laufe des Tages weitere Updates und Informationen!
Update 30.09.2022 11:51 MESC
Microsoft hat die beiden Sicherheitslücken (CVE-2022-41040, CVE-2022-41082) bestätigt.
Microsoft Customer Guidance-Link:
https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/
Die erste Schwachstelle (CVE-2022-41040) ist eine Server-Side Request Forgery (SSRF)-Schwachstelle, während die zweite (identifiziert als CVE-2022-41082) Remote Code Execution (RCE) ermöglicht, wenn PowerShell für den Angreifer zugänglich ist.
Update 01.10.2022 12:30 MESC
Microsoft hat das Mitigation Tool "EOMTv2" bereitgestellt, um die aktuelle Sicherheitslücke CVE-2022-41040 zu beheben.
Nähere Informationen finden Sie auf folgender Seite des Herstellers:
Update 04.10.2022 15:00 MESC
Die von Microsoft herausgegebene Empfehlung, den PowerShell-Remotezugriff für Benutzer ohne Administratorrechte zu deaktivieren, via
Method 1:
Use powershell command:
Get ChildItem Recurse Path < Path_IIS_Logs > Filter “*.log” | Select String Pattern
powershell autodiscover json .*.*\\@.*200
hat sich als nicht effizient herausgestellt und kann mit geringem Aufwand umgangen werden. Im Speziellen erscheint das „@“-Zeichen im URL-Block von Microsoft als unnötig präzise und daher unzureichend.
Sicherheitsforscher des GTSC bestätigen, dass (anstelle des von Microsoft vorgeschlagenen URL-Blocks) eine weniger spezifische Alternative zur Verfügung steht, die eine breitere Palette von Angriffen abdecken sollte: .*autodiscover\.json.*Powershell.*
Wie empfehlen Ihnen, Ihre Einstellungen dahingehend zu prüfen und ggf. anzupassen.
Quelle: https://www.bleepingcomputer.com/news/security/microsoft-exchange-server-zero-day-mitigation-can-be-bypassed/
Update 05.10.2022 09:17 MESC
Microsoft hat zwischenzeitlich die Handlungsempfehlungen angepasst und die Regel in die vorgeschlagenen Fassung korrigiert:.*autodiscover\.json.*Powershell.*
.
Zudem haben die Entwickler von Microsoft das angebotene EOMTv2-Skript zum automatisierten Ausrollen der Rewrite-Regel mit der verbesserten Regel ausgestattet.
---------------------------------------------------------------------------------------------------------
Der von Allgeier secion eingesetzte MVSP Schwachstellenscanner erkennt und meldet seit dem 04.10.2022 die Exchange Exploits!
Update 06.10.2022 10:04 MESC
Microsoft hat erneut eine aktualisierte Regel vorgelegt. Es wird den Administratoren geraten, die bisher angelegte Regel zu entfernen und eine neue einzusetzen:
=> Zeichenkette .*autodiscover\.json.*Powershell.* muss für Request-Block-Regel für Autodiscover neu angelegt werden.
Aktualisierte Anleitung von Microsoft zu empfohlenen Gegenmaßnahmen: Auswahl der Option "Regular Expression" unter "Using" auswählen sowie für "How to block" auf "Abort Request". Neu angelegte Regel auswählen und auf "Edit" unter "Conditions" klicken. Im Feld "Condition Input" die Zeichenkette {URL} in {UrlDecode:{REQUEST_URI}} ändern.
Administratoren, die den Exchange Emergency Mitigation Service (EEMS) aktiviert haben, haben von Microsoft bereits die erneut aktualisierte Regel erhalten und es musst nichts getan werden. Ohne EEMS: Admins können das angepasste EOMTv2-Skript Vs. 22.10.05.2304 zum automatisierten Eintrag nutzen oder die Regel manuell anlegen.
Ergänzend sollte der Remote-PowerShell-Zugriff für nicht-Administratoren deaktiviert werden.
Update 07.10.2022 09:16 MESC
Empfehlung zur Prüfung auf Proxynotshell
Proxynotshell-Check via nmap: https://github.com/CronUp/Vulnerabilidades/blob/main/proxynotshell_checker.nse
Update 10.10.2022 09:00 MESC
Es gibt weitere Anpassungen von Microsoft, um die Schwachstelle zu mitigieren, Details im folgenden Artikel:
Update 09.11.2022 10:21 MESC
Im Rahmen des November 2022 Patch Tuesday hat Microsoft die ProxyNotShell-Schwachstellen im Sicherheitsupdate KB5019758 für Microsoft Exchange Server 2019, 2016 und 2013 behoben:
https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2019-2016-and-2013-november-8-2022-kb5019758-2b3b039b-68b9-4f35-9064-6b286f495b1d
Update 21.12.2022 15:45 MESC
Achtung: Seit 20. Dezember 2022 existieren neue Erkenntnisse darüber, dass es den Angreifenden möglich ist, die von Microsoft veröffentlichten Mitigationsmaßnahmen zu umgehen und Schadsoftware auf den Zielsystemen zu installieren.
Ransomware-fähige Angreifer verwenden eine neue Exploit-Kette, die eine der ProxyNotShell-Schwachstellen (CVE-2022-41082) enthält, um eine Remotecodeausführung auf Microsoft Exchange-Servern zu erreichen. Anstelle der Schwachstelle CVE-2022-41040, einer SSRF-Schwachstelle im Autodiscover-Endpunkt von Microsoft Exchange, wird eine neue Schwachstelle CVE-2022-41080 verwendet, um eine Rechteausweitung über Outlook Web Access (OWA) zu erreichen.
Auf Basis der neuen Berichte muss davon ausgegangen werden, dass die von Microsoft vorgeschlagenen Mitigationsmaßnahmen keine hinreichende Schutzwirkung entfalten. IT-Sicherheitsverantwortliche sollten daher schnellstmöglich die Installation der am 8. November 2022 veröffentlichten Patches (KB5019758) prüfen. Wenn Sie den Patch KB5019758 nicht sofort anwenden können, sollten Sie OWA deaktivieren, bis der Patch angewendet werden kann.
Anhang
Festgestellte Indicators of Compromise (IOCs)
Indicator of Compromise (IoC) sind Merkmale und Daten, die auf die Kompromittierung eines Computersystems oder Netzwerks hinweisen. Dabei handelt es sich beispielsweise um außergewöhnliche Netzaktivitäten, besondere Dateien, Einträge in Logfiles oder gestartete Prozesse.
Folgende Kompromittierungsindikatoren sind derzeit bekannt, bzw. hat unser SOC Team im Rahmen seiner Analyse aufgedeckt:
IoC Liste Exchange 0day:
Files:
pxh4HG1v.ashx:
- SHA-256 c838e77afe750d713e67ffeb4ec1b82ee9066cbe21f11181fd34429f70831ec1
RedirSuiteServiceProxy.aspx:
- SHA-256 65a002fe655dc1751add167cf00adf284c080ab2e97cd386881518d3a31d27f5
- SHA-256 b5038f1912e7253c7747d2f0fa5310ee8319288f818392298fd92009926268ca
Xml.ashx:
- SHA-256 c838e77afe750d713e67ffeb4ec1b82ee9066cbe21f11181fd34429f70831ec1
errorEE.aspx:
- SHA-256 be07bd9310d7a487ca2f49bcdaafb9513c0c8f99921fdf79a05eaba25b52d257
Dll.dll:
- SHA-256 074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82
- SHA-256 45c8233236a69a081ee390d4faa253177180b2bd45d8ed08369e07429ffbe0a9
- SHA-256 9ceca98c2b24ee30d64184d9d2470f6f2509ed914dafb87604123057a14c57c0
- SHA-256 29b75f0db3006440651c6342dc3c0672210cfb339141c75e12f6c84d990931c3
- SHA-256 c8c907a67955bcdf07dd11d35f2a23498fb5ffe5c6b5d7f36870cf07da47bff2
180000000.dll:
- SHA-256 76a2f2644cb372f540e179ca2baa110b71de3370bb560aca65dcddbd7da3701e
IPs:
- 137[.]184[.]67[.]33
- 125[.]212[.]220[.]48
- 5[.]180[.]61[.]17
- 47[.]242[.]39[.]92
- 61[.]244[.]94[.]85
- 86[.]48[.]6[.]69
- 86[.]48[.]12[.]64
- 94[.]140[.]8[.]48
- 94[.]140[.]8[.]113
- 103[.]9[.]76[.]208
- 103[.]9[.]76[.]211
- 104[.]244[.]79[.]6
- 112[.]118[.]48[.]186
- 122[.]155[.]174[.]188
- 125[.]212[.]241[.]134
- 185[.]220[.]101[.]182
- 194[.]150[.]167[.]88
- 212[.]119[.]34[.]11
- 13[.]77[.]160[.]181
- 109[.]167[.]197[.]53
- 3[.]238[.]137[.]11
- 3[.]238[.]137[.]12
- 37[.]120[.]153[.]229
- 185[.]65[.]134[.]252
- 49[.]34[.]171[.]65
- 143[.]110[.]251[.]168
- 172[.]104[.]218[.]130
- 213[.]226[.]123[.]154
- 146[.]0[.]75[.]2
- 206[.]188[.]196[.]77