Exchange Sicherheitsvorfall HAFNIUM! Was tun?

11.11.2021 UPDATE NOVEMBER 2021 PATCH siehe Link

In den letzten Tagen dreht sich in vielen IT-Abteilungen und natürlich auch in vielen Systemhäusern einiges um das Thema Exchange Security speziell das kürzlich aufgetauchte „Exchange 0day exploit“. Diese Sicherheitslücke betrifft alle „onpremises“ Exchange Server Versionen von 2010 – 2019. Laut Microsoft sind Kunden mit Exchange Online nicht betroffen. Leider mussten wir bereits Ende letzter Woche feststellen, dass einige unserer Kunden (trotz Reverseproxy und anderen Schutzmechanismen) betroffen waren. Aber auch Kunden, welche den Exchange direkt veröffentlicht haben. Leider gibt es für solche Fälle keinen wirklichen Schutz außer reinem VPN Zugriff und Exchange gar nicht zu veröffentlichen.

Was also tun? Die Antwort ist ganz einfach, Exchange vom Internet nehmen, patchen und prüfen ob „eingebrochen“ wurde.

Zum Updateprozess hat das Microsoft Exchange Team seit gestern auch eine interessante Grafik veröffentlicht. Siehe Link.

Wer noch nicht gepatched hat findet die Links zum Security Update ( wird auch über Windows Update Dienst verteilt), seit gestern gibt es bereite neue Exchange SUs
https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2019-2016-and-2013-march-2-2021-kb5000871-9800a6bb-0a21-4ee7-b9da-fa85b3e1d23b

Zusätzlich gibt es noch ein PDF von Microsoft zum Thema Patching:
LINK.

Was ist mit Exchange 2010?

Ja es gibt sogar ein Update für Exchange 2010
https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2010-service-pack-3-march-2-2021-kb5000978-894f27bf-281e-44f8-b9ba-dad705534459

HINWEIS: das MSP in einer administrativen CMD starten, ansonsten kann die UAC (Benutzerkontensteuerung) zuschlagen und euch das Sicherheitsupdate verhageln.

Woher weiß ich ob „Eingebrochen“ wurde?

Ebenfalls einfache Antwort, im Zweifel wurde eingebrochen und es hat keiner bemerkt, es gibt aber ein paar Indizien, welche ich bei einigen Exchange Servern gesehen habe und welche sich wiederholt haben.

Zunächst also erst mal das obligatorische PowerShell Script auf den Exchange Server bringen ( Test-ProxyLogon.ps1)
https://github.com/microsoft/CSS-Exchange/tree/main/Security

Direkter Download von github

Sollte das Skript eine grüne Ausgabe erreichen, heißt das aber nicht man muss nichts tun!!! Security Patch und CUs einspielen ist auf jeden Fall Pflicht!! Ihr hattet dann vermutlich einfach nur Glück, dass es euch (noch) nicht erwischt hat.

Randinfo: bei vielen Exchange Servern gingen die Angriffe bereits am 03.03.2021 los. Achja, falls ihr folgendes Skript zur Bereinigung des Exchange Servers benutzt kann das das Ergebnis massiv verfälschen, da die eventuell vorhandenenen Einträge automatisch gelöscht worden sein könnten.
GitHub – SammyKrosoft/Clean-ExchangeLogs: Script from Edward van Bilkon, Microsoft Most Valuable Professional, to cleanup Exchange log files (Exchange 2013, 2016, 2019)

Sch*** die Ausgabe ist ROT!

Sofortmaßnahmen:

Exchange weg vom Internet, Virenscanner FullScan (Windows Defender) habe ich ganz gute Ergebnisse erzielt. Dieser hat bei mir die Exploits gefunden und auch unschädlich gemacht.
Zusätzlich auf jeden Fall noch den Microsoft Safety Scanner, für den Fall dass im Virenscanner Verzeichnisse ausgeschlossen wurden.

UPDATE 10.03.2021: Laut Microsoft findet der Defender die Exploits ab Version 1.331.2471.0

Um die aktuelle Version auszulesen, kann folgender PS Befehl verwendet werden:

Get-MpComputerStatus | ft AntivirusEnabled,AntivirusSignatureVersion,AntispywareEnabled,AntispywareSignatureVersion

Hier noch ein Screenshot aus dem Defender.

UPDATE 16.03.2021: NEUES EOMT.PS1 PowerShell Script verfügbar.
https://github.com/microsoft/CSS-Exchange/tree/main/Security#exchange-on-premises-mitigation-tool-eomt

Exchange On-premises Mitigation Tool (EOMT)

Dieses neue Skript soll vor allem die Exchange Server schützen (ab Exchange 2013-2019) die bisher noch keine CUs bzw. das Sicherheitspatches installiert haben. Mit diesem lässt sich also etwas mehr Zeit für den Patchvorgang verschaffen. (es ersetzt nicht das Updaten selbst).
Was benötige ich dazu:
– direkte Internetverbindung vom Exchange aus
– eine administrative PowerShell
Interessant ist, dass Microsoft dieses Skript eigentlich in fast jeder Situation empfiehlt.

Wer noch gar nichts unternommen hat
-> EOMT.PS1 (soll Exchangeverwundbarkeit reduzieren, auf Schaden prüfen)
Wer keine Updates installiert hat, aber die Tools zur Schadensbegrenzung ausgeführt hat
-> EOMT.PS1 ( Exchangeverwundbarkeit weiter reduzieren bzw. Exchange zu reparieren)
Wer bereits Updates installiert hat:
-> EOMT.PS1 ( als Vorsichtsmaßnahme)

HINWEIS: das Skript kann ohne Parameter ausgeführt werden, dieses führt nach der Prüfung einen MSERT Scan (QuickScan) durch um das System auf Backdoors und andere Schädlinge zu prüfen.

Was macht das Ding?

-Prüft die Verwundbarkeit des Exchange anhand von Sicherheitspatches bzw. Exchange Version
-Läd IIS URL Rewrite tool herunter (weitere Infos)
-Wendet IIS URL Rewrite am Exchange an
-Führt einen Microsoft Safety Scanner Prozess durch

Wichtige Frage, macht es was kaputt??
Ich konnte bisher keine Beeinträchtigung der Exchange Systeme durch EOMT feststellen.

Gibts ein LOG?

Ja direkt unter Laufwerk C:\EOMTSummary.txt

Die Entscheidung bei einem Befall den Exchange neu zu installieren, kann dieses Script natürlich nicht abnehmen, ebenfalls prüft es nur den Exchange und keine weiteren Systeme im Netzwerk.

Weitere Analyse

Nun ja, da man ja nicht genau weiß wer bzw. was getan wurde habe ich hier mal die häufigsten Änderungen am Exchange zusammengeschrieben. Ich würde die genannten Schritte trotz EOMT.PS1 kontrollieren.
HINWEIS: Ihr könnt betroffen sein und keine der genannten Infos treffen auf euch zu! Das hier sind nur die häufigsten Merkmale (zumindest bei mir).

• Eventlog prüfen und nachvollziehen was eventuell geändert wurde

• OAB (Offline Address Book) virtuelles Verzeichnis prüfen (Änderungsdatum) dieses wurde bei einigen Exchange Servern zurückgesetzt (könnte auch die Ursache für Zertifikatswarnungen sein)
  
• Dubiose Dateien in folgenden Pfaden (Datum der Änderung vergleichen):
  C:\inetpub\wwwroot\aspnet_client\supp0rt.aspx
  C:\inetpub\wwwroot\aspnet_client\discover.aspx
  C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\TimeoutLogout.aspx
  C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\OutlookEN.aspx
  C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\owa\39dba043\4e0b7b81\App_Web_1bsqa4yl.0.js
  Weitere Infos zu betroffenen Dateien siehe diesen Link
  

• NTFS Berechtigungen angepasst an folgendem Ordner
  C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth
  HINWEIS: sollte bei euch das CU abbrechen mit der Meldung „fehlende Berechtigung“, kann der genannte Ordner die Ursache sein. Hier sollte das „SYSTEM“/“Administratoren“/“Authentifizierte Benutzer (lesend)“ Zugriff haben. Am besten Vererbung von oben übernehmen.
  

• Geplante Aufgaben /Scheduled Tasks prüfen!
  An einem infizierten System sollten auf jeden Fall die Aufgaben prüft werden, hier zu habe ich ein kurzes PowerShell Skript geschrieben, welches alle Aufgaben auflistet, die die PowerShell.exe verwenden
  
  Englische Server:

$taskpowershell =  schtasks.exe /query /V /FO CSV | ConvertFrom-Csv | select TaskName,"Task to Run",Author,"Start Date","StartTime"|where{$_ -like "*powershell*"} 
$taskpowershell | fl

Deutsche Server

schtasks.exe /query /V /FO CSV | ConvertFrom-Csv | select Aufgabenname,"Auszufhrende Aufgabe",Startdatum,"Letzte Laufzeit",'N„chste Laufzeit' |where{$_ -like "*powershell*"}

• Prüfen der Anmeldefehler in AD

Get-ADUser -Filter * -Properties * | sort badpwdcount -Descending | Where-Object {$_.badPwdCount -gt 1} | ft Name,SamAccountName,badPwdCount  

Wenn keiner der genannten Infos zutreffen, das Skript aber trotzdem ROT meldet, ist es möglich, dass kein Exploit ausgeführt wurde, aber die Lücke geprüft wurde.

Wie schon mehrmals erwähnt gibt es keine Garantie, dass nicht doch noch eine Backdoor aktiv ist, aber mit diesem Restrisiko muss man nun leben oder den Exchange komplett neu aufsetzen.

Ach ja: Passwortänderung wäre ebenfalls nach „erfolgreicher“ Bereinigung zu erledigen.

Sollte ich weitere Regelmäßigkeiten erkennen teile ich diese auf meiner Plattform weiterhin.
To be continued….