Exchange Server Hafnium Exploit

Unternehmen stellen häufig Exchange Dienste wie ActiveSync (Abruf der Mails per Mail-App auf dem Handy), OWA (Outlook Web Access – Zugriff auf Outlook über eine Webschnittstelle) und damit meist auch unwissentlich ECP (Exchange Admin-Konsole) für den Zugriff aus dem Internet für Ihre Mitarbeiter zur Verfügung. Diese Dienste werden aktuell missbraucht. Der Zugriff geschieht dabei von extern über das Internet-Protokoll https auf Port 443.
Dieser Artikel bietet einen Einstieg in die Thematik, listet weitere Quellen und zeigt die Möglichkeiten, die Sie zum Schutz Ihrer Systeme mithilfe der Security Services einer WatchGuard Firewall zur Verfügung haben.

Wie heise berichtet:

Die aktuelle Lücke in Exchange Servern ermöglicht Angreifern, die reguläre Authentifizierung zu umgehen und sich als Administrator eines Exchange-Servers anzumelden. Im Rahmen der Untersuchungen fanden Sicherheitsforscher eine weitere Schwachstelle, über die sie Dateien für eine Remote Code-Ausführung (RCE) in Exchange platzieren konnten. Daraus bauten sie einen funktionsfähigen Proof of Concept Exploit. Mit dem ließ sich die Exchange-Authentifizierung umgehen und der Server kompromittieren.
Da ein Exchange Server im Active Directory hohe Rechte besitzt, gibt ein erfolgreicher Angriff auf das E-Mail System dem Angreifer auch die Möglichkeit das Active Directory anzugreifen und hier Daten abzugreifen, zu verändern und weitere interne System anzugreifen.
Exploits für die ProxyLogon-genannte Lücke in Exchange Server kursieren bereits, nun kommt auch noch Ransomware dazu. Erste Nutzer berichten von verschlüsselten Dateien.

Weiterführende Infos finden Sie unter:

WatchGuard:
>> Exchange Server Vulnerabilities Actively Exploited in the Wild
>> HAFNIUM Exchange Server Exploit Protection Measures

Microsoft:
>> Hafnium: Microsoft Exchange-Sicherheitsupdate zum Schutz vor neuen nationalstaatlichen Attacken verfügbar

Kundeninformation von Microsoft (=> zum Aufblättern klicken!)

Microsoft hat mehrere Sicherheitsupdates für Microsoft Exchange Server veröffentlicht. Die Updates schließen Sicherheitslücken, die in einigen Fällen für gezielte Attacken genutzt wurden.

Aktuell betroffen von der Schwachstelle sind die lokalen Exchange Server 2010, 2013, 2016 und 2019. Exchange Online ist nicht beeinträchtigt. Um das Sicherheitsrisiko zu minimieren, empfehlen wir, unverzüglich die folgenden drei Schritte durchzuführen:

Patches für Exchange-Umgebungen installieren:
Um die Schwachstellen zu beheben, sollten Sie auf die neuesten Exchange Cumulative Updates wechseln und dann die entsprechenden Sicherheitsupdates auf jedem Exchange Server installieren. Sie können das Skript „Exchange Server Health Checker“ nutzen, das Sie von GitHub herunterladen können (verwenden Sie bitte die neueste Version). Sobald Sie dieses Skript ausführen, können Sie feststellen, ob Sie mit den Updates für Ihren lokalen Exchange Server im Verzug sind (beachten Sie, dass das Skript Exchange Server 2010 nicht unterstützt).

Suche nach den Indicators of Compromise
In diesem Artikel hat Microsoft Informationen zusammengefasst, die SOCs und Security Verantwortlichen dabei helfen sollen, proaktiv nach verdächtigen Aktivitäten in ihrer Umgebung zu suchen. Dort finden Sie auch die Indicators of Compromise (IOCs), Erkennungsrichtlinien und erweiterte Suchanfragen, mit denen Sie diese Aktivität mithilfe von Exchange-Serverprotokollen, Azure Sentinel, Microsoft Defender für Endpoint und Microsoft 365 Defender untersuchen können. Bitte führen Sie alle dort genannten Schritte aus. Weitere Informationen und Handlungsempfehlungen sind im Artikel verlinkt.

Indicators of Compromise zeigen positive Ergebnisse?
Wenn der Scan der Exchange-Protokolldateien für Kompromissindikatoren (Indicators of Compromise) positive Ergebnisse zeigt, können Sie sich gerne an uns wenden.

Weitere Ressourcen zu den Microsoft Exchange Sicherheitsupdates finden Sie hier:

Bitte besuchen Sie regelmäßig die hier geteilten Links und Quellen, da diese fortlaufend aktualisiert werden.

Heise:
>> Exchange Server: Angreifer nutzen Schwachstellen für Ransomware “DearCry”
>> Neues Tool von Microsoft: Exchange-Server mit wenigen Klicks absichern

 

BSI:
Das BSI empfiehlt, die Analyse- und Reparaturprogramme und Sicherheitsupdates, die auch von Microsoft inzwischen angeboten werden, sofort zu installieren
>> Detektion und Reaktion

Wie kann ich mich Schützen?

Intrusion Prevention Service

Watchguard hat zum Schutz die Signaturen seines Intrusion Prevention Service (IPS) ergänzt und veröffentlicht. Diese finden sie auch im Watchguard Security Portal: hier nach „CVE-2021-26“ suchen.
Die Signaturen Ihrer WG Firewall sollten mindestens die unten dargestellten Versionenstände aufweisen. Diese Finden Sie im Firebox System Manager unter Subscription Services:

Bei größeren Modellen: min. Version 18.137

Bei kleineren Modellen wie bspw. der T-15: min. Version 4.1132

Ergänzung 2021-03-16:

Die entsprechenden Signaturen finden Sie im WatchGuard-Security-Portal:

 

1. Folgende Watchguard Sicherheits-Dienste für eingehende Exchange Policies aktivieren

Intrusion Prevention Service

  • IPS erkennt und blockiert die erste Stufe des Angriffs der Exploit-Kette
    Voraussetzung ist eine aktivierte HTTPS-Deep-Inspection auf einer HTTPS-Proxy-Action, da das Angriffspattern natürlich nur dann erkannt wird, wenn die Firewall den verschlüsselten HTTPS-Stream aufbrechen kann.

Gateway AntiVirus

  • Beinhaltet mehrere Signaturen zur Erkennung und Blockierung der bei dem Angriff verwendeten WebShells
    Voraussetzung ist ein HTTP-Proxy mit aktiviertem Gateway-Antivirus und für HTTPS ebenfalls eine aktivierte HTTPS-Deep-Inspection auf der ausgehenden HTTPS-Proxy-Action, mit der der Zugriff vom Exchange-Server ins Internet geregelt ist.
    In diesem Fall würde der Download der WebShells von HTTPS-Servern geprüft, erkannt und unterbunden werden.

APT Blocker

  • APT Blocker erkennt erfolgreich die bösartigen PowerShell-Backdoors, die bei diesem Angriff verwendet werden.
    Auch hier wird ausgehend eine entsprechende Proxy-Action für HTTP und HTTPS mit Deep Inspection benötigt.
    Der APT-Blocker im TDR-Host-Sensor kann hier ebenfalls hilfreich sein.

Geolocation

  • Auch die Verwendung der Geolocation kann eine sinnvolle Hürde darstellen. Aktivieren Sie in den Exchange Policies die Geolocation mit Einschränkung nur der für Sie relevanten Länder. Bspw. nur Europa erlauben (beachten Sie die IP-Locationen der E-Mail Server Ihrer Kunden). Die Verwendung der Geolocation haben wir bereits in einem früheren >> Blog-Artikel von 2017 behandelt.
    Dies ist natürlich kein 100%iger Schutz, aber wenn der Großteil aller IPs im Internet bereits beim Zugriff auf den OWA/Exchange geblockt werden, können diese auch keinen Angriff ausführen. Natürlich wären die Server weiterhin von System in den erlaubten Ländern/Regionen aus angreifbar.
2. Access Portal in Verbindung mit Microsoft Exchange (Pre-Authentication):

Die erste Angriffsstufe für diese Bedrohung erfordert einen Exchange-Server, der dem Internet ausgesetzt ist (wie z.B: ein einfaches Port-Forwarding mit SNAT). Sie können diese Stufe des Angriffs entschärfen, indem Sie den Exchange-Server hinter dem Access Portal der Firebox schützen. In diesem Falle läuft über das Access Portal eine sog. Pre-Authentication, so dass nur Requests mit validen Credentials überhaupt bis auf den Exchange durchgereicht werden. Wie das funktioniert erklären wir in diesem >> HOW-TO-Blogartikel.

Zusätzlich hat dies den Vorteil, dass die Authentifizierung gegen die E-Mail-Domain durchgeführt wird und der Exchange nur noch über https://<domain-name>/ erreichbar ist, aber nicht mehr unter https://<ip>; d.h. ein reiner Scan auf einen IP-Range und dort auf der IP zufällig laufender OWA-Instanzen greift von vornherein ins Leere.

Mit Hilfe von Reverse-Proxy-Aktionen in der Access Portal Konfiguration können Remote-Benutzer ohne VPN-Client eine sichere Verbindung zu internen Webanwendungen und Microsoft Exchange Diensten herstellen.

  • Mobile Geräte mit Microsoft Mail-Clients (über ActiveSync)
  • Microsoft Outlook
  • Microsoft Outlook-Webzugriff
  • Microsoft Outlook Web Access über das Access Portal (mit automatischer Anmeldung)
3. AuthPoint

Durch die Anmeldung mit einem zusätzlichen Authentifikations-Faktor können Sie Web-Anmeldungen zusätzlich absichern.

Wenn der Benutzer versucht, sich bei einer Anwendung anzumelden, die eine Authentifizierung erfordert, erscheint die AuthPoint-Authentifizierungsseite. Um sich anzumelden, gibt der Benutzer sein AuthPoint-Passwort ein (falls erforderlich) und wählt eine Authentifizierungsmethode. Bespw. ein OneTime-Password oder eine Push-Benachrichtigung auf das mobile Gerät des Benutzers.
In unserem Infoportal finden Sie weitere Informationen zum Thema >> AuthPoint.

4. Panda Adaptive Defense 360

Falls die bisher genannten Maßnahmen (mangels Konfiguration, Zeitversatz,…) den Zugriff auf den Exchange nicht verhindern konnten, greift Adaptive Defense 360 (auf dem Exchange-Server) als “Last Line Of Defense”.
Konnte der Zugriff auf den Mailserver nicht unterbunden werden, wird dennoch die Ausführung weiterer schadhafter Aktionen auf dem Server verhindert. Voraussetzung ist hier der Lock Modus.
Jegliche Post-Exploit-Aktionen werden im Lock-Modus durch das Zero-Trust verfahren präventiv unterbunden. Der Schadcode wurde damit auf dem Exchange-Server nicht ausgeführt!
Ebenso bietet Panda AD360 Erkennung für die PowerShell-Payloads und viele der an diesem Angriff beteiligten Webshells.
In unserem Infoportal finden Sie weitere Informationen zum Thema >> Panda Endpoint Security.

 

Stand des Artikels:

  • 2021-03-15: Artikel veröffentlicht (if/jw/wm/ms)
  • 2021-03-16: CVE-Nummern und Security-Portal Link ergänzt (wm)
  • 2021-03-16: Link von heise auf neues Tool von Microsoft ergänzt (wm)

5 Kommentare zu “Exchange Server Hafnium Exploit”

  1. Jürgen Strobel

    Hallo, dankeschön für den Artikel, hilft schon weiter zu wissen, das WG das nun in Ihren Diensten erkennen kann. 🙂
    Habt Ihr evtl. einen Hinweis oder Beispiele, welche IPS Signatur hier trifft. Oder wie evtl. die Meldung im Log aus sieht, evtl. mit Beispielen aus dem Log.

    1. Werner Maier

      Vielen Dank für den Hinweis!
      Die entsprechenden Infos sind ergänzt. Es wäre dann im Zweifelsfall ein Log-Eintrag eines IPS-Treffers. (suchen nach “IPS” im Log).

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:


<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>