Exchange-0-day-Exploit 2022

Ende Sept 2022 gab es erste Berichte über einen Exchange 0-Day Exploit, der im asiatischen Raum auch für Angriffe verwendet werden soll.

Diese Lücke ist die erste, die Microsoft über den EEMS - Ex Emergency Mitigation Service korrigiert.

BSI Warnung: Neuer 0-Day Exploit in Microsoft Exchange Server
https://bsi.bund.de/dok/1074144  -> https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2022/2022-258168-1032.html
https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2022/2022-258168-1032.pdf?__blob=publicationFile&v=2
US CISA: Microsoft Releases Guidance on Zero-Day Vulnerabilities in Microsoft Exchange Server
https://www.cisa.gov/uscert/ncas/current-activity/2022/09/30/microsoft-releases-guidance-zero-day-vulnerabilities-microsoft

Hinweis:
Der erste RegEx von Microsoft nicht in allen Fällen ausreichend.
Update: Microsoft hat am 5. Okt 2022 seine Anleitung entsprechend aktualisiert.

Verlauf

Achtung: Die Lücken werden nicht durch das Security Update vom 11. Okt 2022 abgesichert.

Datum Aktion

28. Sep 2022

Erste Informationen und Gerüchte zu einer neuen Lücke, über die Exchange Server per HTTPS fremdem Code ausführen.

29. Sep 2022

Microsoft bestätigt die Lücke und entsprechende CVE-Einträge wurde zugewiesen

30. Sep 2022

Erste Hinweise die Lücke "CVE-2022-41040" per URLRewrite zu entschärfen.

Condition: {REQUEST_URI}}
Pattern .*autodiscover\.json.*\@.*Powershell.*
Match: Wildcard

 Microsoft veröffentlicht ein Skript und ein Update über den EEMS - Exchange Emergency Mitigation Service

02. Okt 2022

Die URLRewrite-Regel wird korrigiert (RegEx statt Wildcard)

Alt: Match: Wildcard
Neu: Match: RegEx

04. Okt 2022

Die URLRewrite-Regel wird erweitert RegEx.

Alt: .*autodiscover\.json.*\@.*Powershell.*
Neu: .*autodiscover\.json.*Powershell.*

05. Okt 2022

Die URLRewrite-Condition wird erweitert, nachdem gezeigt wurde, dass es noch Lücken gibt.

VN Microsoft Exchange mitigations bypass CVE-2022-41040, CVE-2022-41082
https://www.youtube.com/watch?v=JQtW9xd5-Hw&ab_channel=Whitehat%F0%9F%87%BB%F0%9F%87%B3

Alt: {REQUEST_URI}}
Neu: Condition: {UrlDecode:{REQUEST_URI}}

06. Okt 2022

Eine Korrektur am Skript EOMTv2 erfolgt.

07. Okt 2022

Updates für EEMS und EOMTv2 um die neuen Konfigurationen anzuwenden.

08. Okt 2022

Erneute Überarbeitung des RegEx.

Alt: .*autodiscover\.json.*Powershell.*
Neu: (?=.*autodiscover)(?=.*powershell)

Wer die Konfiguration über den EEMS - Exchange Emergency Mitigation Service machen lässt, sollte mit maximal einer Stunde Verzögerung die Korrekturen erhalten haben. Alle anderen Administratoren müssen jedes mal nacharbeiten.

Angriffsvektor

Betroffen sind aber wohl alle noch unterstützten Exchange 2013 bis 2019-Server. Vielleicht ist auch Exchange 2010 und früher betroffen aber dafür wird es wohl keine Updates geben.

Microsoft is investigating two reported zero-day vulnerabilities affecting Microsoft Exchange Server 2013, 2016, and 2019. The first vulnerability, identified as CVE-2022-41040, is a Server-Side Request Forgery (SSRF) vulnerability, while the second, identified as CVE-2022-41082, allows remote code execution (RCE) when PowerShell is accessible to the attacker.
Quelle: https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/

Die beiden Bugs haben aber schon einen CVE:

  • CVE-2022-41040 Microsoft Exchange Server Elevation of Privilege Vulnerability
  • CVE-2022-41082 Microsoft Exchange Server Remote Code Execution Vulnerability

Ein Angreifer kann über die Lücke in Autodiscover "CVE-2022-41040" dann die Lücke in der Remote PowerShell "CVE-2022-41082" ausnutzen. Allerdings ist das Risiko etwas niedriger als bei Hafnium Exploit, denn der erste Exploit erfordert einen "authenticated user", um dann den zweiten Exploit auszunutzen.

In these attacks, CVE-2022-41040 can enable an authenticated attacker to remotely trigger CVE-2022-41082. It should be noted that authenticated access to the vulnerable Exchange Server is necessary to successfully exploit either of the two vulnerabilities.
Quelle: https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/

Das ist aber dennoch kein Freibrief, denn "Authenticated User" ist keine große Hürde. Der Angreifer kann ja schon gültige Credentials "auf Vorrat" gesammelt haben oder von intern den Angriff starten.

Risiko ist Real!

Im Internet gibt es viele Diskussionen darüber, wie kritisch die Lücke denn nun tatsächlich ist. Verschiedene Administratoren fühlen sich sicher, wenn ihr Exchange Server nicht aus dem Internet und nur per VPN o.ä. erreichbar ist. Zudem ist die Lücke ja nur mit einer gültigen Authentifizierung ausnutzbar und sei damit deutlich weniger Kritisch als der Hafnium Exploit, bei dem ein anonymer Zugriff reicht.

Ich widerspreche diesen Einschätzungen sehr deutlich und beschreibe, warum jeder die Schutzmaßnamen schnellstens umsetzen sollte.

Diesmal muss der Angreifer sich authentifizieren. Aber dies ist keine reale Hürde. Die Angreifer können damit zwar nicht alle Exchange Server der Welt angreifen aber sie können sicher sein, dass durch Credential Stuffing, Phishing und andere Wege die Angreifer zumindest für einige Firmen schon gültige Zugangsdaten haben und nur auf so eine Schwachstelle gewartet haben. Sie starten nun ihre Motoren und nutzen die Zugangsdaten, um von extern erreichbare Exchange Server zu kapern.

Aber auch Server, die nicht direkt erreichbar sind, können von intern angesprochen werden. Die Angreifer können diese "Kunden" erreichen, indem Sie per VPN oder RDP-Verbindungen mithilfe der bekannten Zugangsdaten letztlich einen Innenangriff starten.

Aber selbst wenn das alles nicht möglich ist, dann kann ich als Angreifer eine bösartige Webseite aufsetzen und ihre arglosen Mitarbeiter auf diese Seite lenken. Das heruntergeladene JavaScript kann natürlich auch HTTP-Zugriffe auf andere Webseiten und damit von intern auch ihren Exchange Server erreichen. Da das Skript sogar vom Anwender unter seinem Zugang ausgeführt wird, ist er auch gegenüber dem Exchange Server "authentifiziert".

Ich habe all diese Wege nicht geprüft aber sie erscheinen mit mehr als möglich und daher sollen alle Exchange Server möglichst schnell geschützt werden.

Schutz aktivieren

Mittlerweile haben sie drei Optionen sich gegen die Lücke zu schützen, die alle auf URLSCAN aufsetzen. Über eine entsprechende Regel werden die gefährlichen Zugriffe abgeblockt.

  1. EEMS
    Wenn Sie seit dem Sep 2021 mit Exchange 2016/2019 auch die Funktion EEMS - Exchange Emergency Mitigation Service installiert und aktiviert haben, dann sollte der Patch seit 1. Okt 2022 schon aktiv sein
  2. Exchange On-Premises Mitigation Tool v2 (EOMTv2)
    Microsoft stellt ein PowerShell-Script bereit, welches ihren Exchange Server ebenfalls passend konfiguriert. Bei Bedarf installiert es sogar URLRewrite
  3. Manuell
    Microsoft (und die MSXFAQ u.a.) beschreiben auf Blogs die manuellen Schritte zur Konfiguration von URLRewrite, damit die bösartigen URLs geblockt werden.

Alle drei Wege bewirken letztlich das gleiche Ergebnis:

Über URLRewrite wird die schädliche REQUEST-URI abgeblockt.

Wenn Sie einen Reverse Proxy oder eine Web Application Firewall einsetzen, dann können Sie auch dort die URLs filtern. Das schützt aber meist nicht gegen Angriffe von Intern. Gehen Sie immer davon aus, dass ein Angreifer vielleicht einen Zugang per VPN oder RDP in ihre Netzwerk hat und dann nicht von extern kommt.

EEMS in Aktion

Nach dem am 29. Sep. 2022 die ersten Meldungen und ein Microsoft Blogartikel erschienen ist, hat Microsoft am 1. Oktober erstmals die Möglichkeit des EEMS - Exchange Emergency Mitigation Service genutzt, um alle Exchange Server automatisch mit einer Konfigurationsänderung zu versehen. Das funktioniert natürlich nur ,wenn:

  • Sie nutzen Exchange 2016CU22 oder Exchange 2019 CU11 und höher
    Erst ab dieser Version  vom Sep 2021 oder später ist der EEMS Service voranden
  • Der Exchange Server die URL https://officeclient.microsoft.com/getexchangemitigations erreichen kann
    Der EEMS pollt regelmäßig diese URL auf Updates
  • EEMS muss aktiviert ist
    Sie können dies auf Organisationslevel und pro Server deaktivieren.

Ob EEMS bei ihnen die Korrektur schon ausgeführt hat, können Sie zum einen per PowerShell prüfen. In meinen Lab mit zwei Servern hat nur ein Server die Konfiguration schon übernommen.

Der EX02 ist aber "Down" und hat daher noch kein Update umgesetzt. Die Änderungen können Sie auch im IIS Manager sehen

Das ist genau das Ergebnis, welche Sie aus der JSON-Datei auch erwarten durften:


Quelle: https://officeclient.microsoft.com/getexchangemitigations

Etwas lesbarer formatiert:

<RewriteConfiguration> 
   <type>Web</type> 
   <path>IIS:/sites/Default Web Site</path> 
   <section>system.webServer/rewrite/rules</section> 
   <rules> 
      <rule name="EEMS M1.1 PowerShell - inbound" stopProcessing="true"> 
         <match url=".*" /> 
         <conditions> 
            <add input="{UrlDecode:{REQUEST_URI}}" pattern="(?=.*autodiscover)(?=.*powershell)" /> 
         </conditions> 
         <action type="AbortRequest" /> 
      </rule> 
   </rules>
</RewriteConfiguration>

Abweichend von der Beschreibung auf dem Microsoft Blog wurden die Änderungen auf der Root-Seite und nicht nur im virtuellen "Autodiscover"-Verzeichnis angelegt. Die von mir vorab von Hand angelegten Einträge wurden nicht entfernt sondern sind ebenfalls noch vorhanden.

Wer Exchange 2016/2019 mit einem aktuell unterstützten Patchstand hat und EEMS funktioniert, ist nicht mehr über HTTPS angreifbar, weil über eine URLRewrite-Regel der IIS die bösen URLs wegblockt.

Achtung
Wenn Sie ein neues Exchange CU installieren, dann wird auch die IIS-Konfiguration neu gemacht und EEMS muss die Änderungen wieder addieren. Sie sind dann also bis zu einer Stunde "ungeschützt"

Exchange On-Premises Mitigation Tool v2 (EOMTv2)

Wer auf seinem Server die Funktion EEMS - Exchange Emergency Mitigation Service nicht nutzen kann oder möchte aber die später beschriebene manuelle Konfiguration zu umständlich findet, kann von Microsoft ein fertiges PowerShell-Script einsetzen.

Download
https://github.com/microsoft/CSS-Exchange/releases/latest/download/EOMTv2.ps1

Das Skript ist mit ca. 600 Lines of Code deutlich umfangreicher als meine Kurzfassung am Ende. Es prüft aber die eigene Version, lädt bei Bedarf ein Update herunter, installiert das eventuell fehlende URLRewrite und kann damit auch Server absichern, bei denen damals bei der Installation URLRewrite oder EEMS nicht installiert wurde. Eine ausführliche Beschreibung finden Sie bei MIcrosoft

Manuelle Gegenmaßnahme IIS (Teil1)

Microsoft hat aber erste Gegenmaßnahmen veröffentlicht.

Exchange Online Kunden müssen nicht aktiv werden, da Microsoft hier in der Verantwortung steht und angeblich entsprechende Vorkehrungen bereits getroffen wurden.

Seit EEMS funktioniert, sollten Sie keine manuellen Änderungen machen und ggfls. vorherige manuelle Änderungen entfernen.

Achtung:
In der ersten Veröffentlichung hat Microsoft eine Regel "RequestBlockingRule1" auf das "Autodiscover"-Verzeichnis angelegt und später auf die Wurzel geändert. Auch EEMS setzt den Eintrag in der Wurzel im Default Web aber entfernt nicht einen manuellen Eintrag darunter. Wenn dann der Name "RequestBlockingRule1" identisch ist, dann kommt der IISManager durcheinander, da eine vererbte und manuelle Rewrite-Rule nicht den gleichen Namen haben dürfen:

Gehen Sie dann in die "web.config und entfernen Sie manuell " den Eintrag. Übrigens: Die "Vererbung" von URLScan scheint IISAdmin zu machen.
Das Problem dabei ist, dass der IIS dann einen "500 URL_Rewrite"-Fehler generiert und Autodiscover nicht mehr funktioniert.
Siehe dazu auch URL_Rewrite.

Der temporäre Fix besteht primäre darin, die URLRewrite-Regeln des "Autodiscover"-Verzeichnisses anzupassen.

  1. IISAdmin starten
  2. Default Webseite auswählen
  3. "Default Web Site" auswählen
    In ersten Versionen hat Microsoft die Regel auf das Autodiscover-Verzeichnis anwenden lassen
  4. Feature URL_Rewrite auswählen
  5. Action: Regel addieren
  6. Request Blocking auswählen
  7. Pattern ".*autodiscover\.json.*Powershell.*" eingeben
    Früher war es noch der alte Wert. ".*autodiscover\.json.*\@.*Powershell.*"
  8. Bedingung von "{URL}" auf "{UrlDecode:{REQUEST_URI}} " umstellen

Das Bild ist nicht aktuell Die RegEx-Einstellung ist zu ändern

Microsoft beschreibt nicht, ob Sie "RegEx" oder "Wildcards" nutzen müssen. Wenn ich mit das Pattern anschaue, dann würde ich das auf "REGEX" umstellen.

Wer sehr viele Server hat, wird sich überlegen, wie er die Einstellungen per Skript oder Powershell durchführen kann.

$site = "iis:\sites\Default Web Site\Autodiscover"
$filterRoot = "system.webServer/rewrite/rules/rule[@name='CVE-2022-41040,CVE-2022-41082$_']"
Clear-WebConfiguration `
   -pspath $site `
   -filter $filterRoot
Add-WebConfigurationProperty `
   -pspath $site `
   -filter "system.webServer/rewrite/rules" `
   -name "." -value @{name='CVE-2022-41040,CVE-2022-41082' + $_ ;patternSyntax='Regular Expressions';stopProcessing='False'}

Set-WebConfigurationProperty `
   -pspath $site `
   -filter "$filterRoot/match" `
   -name "url" -value ".*"

$list = @{
    pspath = $site
    filter = "$filterRoot/conditions"
    Value = @{
       input = '{UrlDecode:{REQUEST_URI}} '
       matchType ='0'
       pattern ='.*autodiscover\.json.*Powershell.*'
       ignoreCase ='True'
       negate ='False'
    }
}

Add-WebConfiguration @list
Set-WebConfigurationProperty `
   -PSPath $site `
   -filter "$filterRoot/action" `
   -name '.' `
   -value @{type='CustomResponse'; statusCode=404; statusReason='Not found'}

Danke in dem Zuge an meinem Kollegen bei Marc Bogadi von Net at Work für die Bereitstellung des Code.

Manuelle Gegenmaßnahme PowerShell (Teil2)

Es gibt aber noch einen zweiten Angriffsvektor, der aber wohl nur von intern erreicht werden kann. Dazu müssen Sie den Zugriff auf die beiden folgenden Port blockieren:

  • HTTP: 5985
  • HTTPS: 5986

Wie werden von der "Remote PowerShell" genutzt und müssen von internen Client schon mal gar nicht erreichbar sein. Das ist wieder eine Steilvorlage zur Einrichtung von Firewalls zwischen den Clients und den Exchange Servern, so dass die Exchange Server nicht mehr ungefiltert erreichbar sind.

Schutz über Reverse Proxy/HLB

Wenn sie mehrere Exchange Server betreiben, dann nutzen Sie vermutlich einen Loadbalancer davor. Für die Veröffentlichung in das Internet betreiben viele Firmen auch einen Reverse Proxy in der DMZ, durch den alle HTTP-Requests laufen. Wenn diese Systeme nicht nur auf Layer4 umsetzen, sondern selbst die HTTPS-Verbindung aufbrechen (Layer7), dann können sie auch dort URLs filtern. Entsprechende Hinweise haben die Hersteller ebenfalls veröffentlicht.

Achten sie aber auch hier darauf, dass die Updates am Regex-Ausdruck von Microsoft ggfls. nicht aktualisiert wurden. Zudem darf es speziell von intern natürlich keinen "Bypass" für Angreifer geben, die direkt den Exchange Server ansprechen. Denken Sie hier auch z.B. an die EWS-Erreichbarkeit für Exchange Hybrid-Bereitstellungen oder interne Angreifer über gekaperte Mitarbeiter-Konten

Erkennen und Beseitigen

Angeblich hat dieser Fix keine Auswirkungen auf die Funktion von Exchange. Aber er verrät auch viel über den Angriffsvektor:

  • Der externe Angriff erfolgt über "Autodiscover V2"
  • Anscheinend akzeptiert Autodiscover hinter dem Dateinamen noch weitere Befehle
  • Im IIS-Log sollte man solche Angriffe mit einer Suche nach dem gleichen RegEx schnell "finden"
    Zumindest wenn der Angreifer nicht die Zeilen in den Logs löscht.

Wenn Sie tatsächlich schon "Opfer" sind, weil Sie entweder sehr früh angegriffen wurden oder einfach lange nicht gepatched haben, dann sollten Sie ihren Server und vielleicht sogar ihr gesamtes Netzwerk als kompromittiert betrachten. Ansonsten erst einmal die Gegenmaßnahmen einleiten und Logs sichern.

Was der Angreifer mit den erlangten Berechtigungen angestellt hat, werden die meisten Opfer schon aufgrund fehlender Erfahrung und Logdateien nicht ermitteln können. Mit etwas Glück wurden sie von genau den gleichen Angreifern kompromittiert, bei deren Angriffen die Lücke erkannt wurde.

Dann können Sie auf ihrem Server prüfen, ob es eine dll.dll-Datei gibt die im IIS als Handler für von extern anonym erreichbar Unterverzeichnisse eingetragen wurden. Laut dem GTSC waren die bei befallenen Kunden die folgenden URLs

Opfer1:
  https://*:443/ews/web/webconfig/
  https://*:443/owa/auth/webcccsd/
  https://*:444/ews/auto/
  https://*:444/ews/web/api/
Opfer2:
  http://*:80/owa/auth/Current/script/
  https://*:443/owa/auth/Current/script/

Sie sehen aber schon, dass zwischen zwei Angriffen sich schon der Pfad geändert hat und das wird nicht die einzige Änderung bleiben. Die von diesen Angreifern genutzte Malware sollten Virenscanner erkennen und daher den Server schützen. Das funktioniert natürlich nur, wenn:

  • Sie einen Virenscanner auf dem Exchange Server haben
  • Der Virenscanner auch aktuelle Patternfiles nutzt
  • Die Angreifer den Schadcode nicht verändert haben

Für die ersten Stunden nach Veröffentlichung der Lücke können Sie davon ausgehen, dass die Angreifer noch ihre funktionierenden Codes verwenden aber es ist nur eine Frage der Zeit, bis andere Angreifer mit dem Wissen um den Fix auch die Lücke finden und mit anderer Malware unterwegs sind. Insofern ist das Erkennen wichtig aber das Beseitigen ein individueller Prozess.

Weitere Links