[English]Wir werden in wenigen Stunden wohl Sicherheitsupdates für On-Premises Exchange Server (2016-2019) bekommen, die hoffentlich die seit Ende September 2022 bekannten zwei 0-Day-Schwachstellen (CVE-2022-41040, CVE-2022-41082) schließen. Aber es ist vermutlich noch eine weiterer 0-day Schwachstelle in Exchange Server enthalten, die aktiv in freier Wildbahn ausgenutzt wird, um die Installationen mit der LockBit 3.0-Ransomware zu infizieren. Hier einige Informationen, was mir bekannt ist.
Anzeige
Die letzte Woche hat die NotProxyShell genannte Schwachstelle – durch die bisher ungepatchten Schwachstellen (CVE-2022-41040, CVE-2022-41082) – ja Administratoren arg beschäftigt. Ich hatte hier im Blog ausgiebig über diesen Sachverhalt berichtet (siehe Links am Artikelende). Aber da schlummert noch mehr im Microsofts Exchange Server-Software.
Neue 0-day-Schwachstelle entdeckt
Ich bin gerade auf Twitter über nachfolgenden Tweet darauf gestoßen, dass es eine weitere, neue 0-day-Schwachstelle in Exchange Server gibt. Entdeckt wurde diese im Juni 2022 von AhnLab, einem südkoreanischen Softwareunternehmen und Marktführer bei Antivirenprogrammen in Südkorea.
Deren Sicherheitsforscher beschreiben die Fund im Blog-Beitrag Von der Exchange Server-Schwachstelle bis zur Ransomware-Infektion in nur 7 Tagen (auf koreanisch verfasst). Im Juli 2022 wurde ein Kunde des Anbieters durch Ransomware infiziert. AhnLab hat dann zwei der betroffenen Server, die mit Windows Server 2016 Standard liefen, inspiziert und fand dort die Ransomware LockBit 3.0 vor. Hier ein grober Überblick des Schadensverlaufs:
Anzeige
- Auf den infizierten Systemen mit Windows Server 2016 wurde eine WebShell unter Verwendung einer Exchange Server-Schwachstelle installiert
- Diese ermöglichte eine RDP-Verbindung über SSH-Tunneling
- Dann wurden per BloodHound Informationen über das AD abgerufen
- Im Anschluss wurden mit Mimikatz Informationen über AD-Administratorkonten extrahiert
Die LockBit 3.0 Ransomware konnte ca. 1,3 TB an Daten von den Servern abrufen und verschlüsselte dann die Dateien dieser Systeme. AhnLabs schreibt, dass der WebShell-Upload vermutlich durch eine 0-Day-Schwachstelle erfolgen konnte. Für die WebShell-Aufrufe wurden mehrere VPN-IPs verwendet. Alle Remote-Befehle zur Kontrolle der LockBit3.0 Ransomware-Infektion wurden mittels Wmic ausgeführt.
Laut AhnLabs dauerte es lediglich sieben (7) Tage vom Hochladen der WebShell bis zur Übernahme des AD-Administratorkontos und der Infektion mit Ransomware. Laut den Sicherheitsforschern soll der Angreifer soll russischer Abstammung sein.
Noch einige Einzelheiten
Der betroffene Kunde betreibt zwei Mailserver für den E-Mail-Dienst und sorgt für einen Lastenausgleich der Mailserververbindungen zu Mail01 und Mail02, indem er den L4-Switch in der Frontstage verwendet. Mail01 und Mail02 sind Microsoft Exchange Server, und der IIS-Server wird ebenfalls genutzt, um den Mail-Webdienst und einen mobilen Zugriff bereitzustellen.
Am 21. Juli 2022 wurden (vermutlich) WebShell-Dateien in den OWA-Ordner auf Mail02 hochgeladen. Die WebShell-Dateien wurden später verschlüsselt, so dass deren Inhalt nicht mehr analysiert werden konnte. Im IIS-Protokoll wurde eine der beiden WebShell-Dateien als HttpRedirService.aspx identifiziert (weshalb die Sicherheitsforscher von WebShells ausgehen).
Der Kunde war bereits im Dezember 2021 durch Microsoft Exchange Server-Schwachstellen kompromittiert worden. Seitdem erhielt dieser Kunde technischen Support von Microsoft und führte vierteljährlich (Januar, April, Juli) Sicherheitspatches durch. Der neueste Patch war seinerzeit Update KB5014261, welches am 10. Mai 2022 veröffentlicht und vom Kunden am 9. Juli installiert wurde. AhnLabs schreibt dazu:
Betrachtet man den Schwachstellenverlauf von Microsoft Exchange Server, so wurde die Schwachstelle bezüglich Remotecodeausführung am 16. Dezember 2021 (CVE-2022-21969), die Schwachstelle bezüglich der Rechteausweitung im Februar 2022 und die jüngste Schwachstelle am 27. Juni bekannt gegeben.
Das heißt, unter den nach Mai offengelegten Schwachstellen gab es keine Berichte über Schwachstellen im Zusammenhang mit Remote-Befehlen oder der Dateierstellung.
Da die Exchange-Server am 9. Juli 2022 vollständig gepatcht waren, die WebShell aber erst am 21. Juli 2022 installiert wurde, ist davon auszugehen, dass der Angreifer eine nicht offengelegte Zero-Day-Schwachstelle ausgenutzt hat. AhnLabs schreibt, dass theoretisch die Möglichkeit besteht, dass die von dem vietnamesischen Sicherheitsunternehmen GTSC am 28. September offengelegten Schwachstellen von Microsoft Exchange Server (CVE-2022-41040, CVE-2022-41082) für die Infektion ausgenutzt wurden. Aber die Angriffsmethode, der generierte WebShell-Dateiname, und nachfolgende Angriffe nach der Installation der WebShell lassen vermuten, dass ein anderer Angreifer eine andere Zero-Day-Schwachstelle ausgenutzt hat.
PS: Hat mit dem aktuellen Fall nichts zu tun – aber ich verweise mal auf diese Kommentare zu meinem Blog-Beitrag Ragnar Locker Ransomware-Infektion bei Campari-Gruppe. Ein betroffener Administrator beschreibt seine Erfahrungen mit der Ragnar Locker-Ransomware-Infektion in seinem Unternehmen. Interessant ist sein Hinweis, warum die angelegten AD-Benutzer (printer) nicht gefunden wurden.
Artikelreihe:
Exchange Server werden über 0-day Exploit angegriffen (29. Sept. 2022)
Microsofts Empfehlungen für die Exchange Server 0-day-Schwachstelle ZDI-CAN-18333
Neues zur Exchange Server 0-day-Schwachstelle ZDI-CAN-18333: Korrekturen, Scripte und EMS-Lösung
Exchange Server: Microsofts 0-day-Schutz aushebelbar, neue Einschätzungen (3. Oktober 2022)
Exchange Server: Microsofts bessert Lösungen für 0-day-Schutz nach (5. Oktober 2022)
Ähnliche Artikel:
Exchange 2016/2019: Outlook-Probleme durch AMSI-Integration
Exchange Server September 2021 CU kommt zum 28.9.2021 mit Microsoft Exchange Emergency Mitigation Service
Exchange: Extended Protection, Checkliste und Probleme
Update für Exchange Extended Protection-Script, aber weiterhin Fehler
Exchange Health Checker – Script-Erweiterungen von Frank Zöchling
Anzeige
Hab Gerade gesehen M$ hat beim Oktober SU die beiden CVEs noch nicht gefixt
„NOTE The October 2022 SUs do not contain fixes for the zero-day vulnerabilities reported publicly on September 29, 2022 (CVE-2022-41040 and CVE-2022-41082). Please see this blog post to apply mitigations for those vulnerabilities. We will release updates for CVE-2022-41040 and CVE-2022-41082 when they are ready."
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-october-2022-exchange-server-security-updates/ba-p/3646263
Reicht es wenn ich das aktuelle SU installiere ohne vorher extra Mai und August SU's zu installieren? Habe CU23 installiert und wollte nun direkt die SU für Oktober installieren ? Hieß ja immer, dass die SU kumulativ wären. Aber diesmal steht nicht, „ersetzt August Update" ?!
Ja, die SUs sind kumulativ. Das letzte/ neuste reicht.
Gruß
Okay also Oktober SU von heute reicht :-)
Na, dann hoffen wir mal, dass MS dies zeitnah endlich lösen wird.
Nimmt das mit diesen Exchanges und diesen Remoteshells denn kein Ende? Als Betriebsverantwortliche für Exchangeservers kann man ja echt nicht mehr beruhigt schlafen…
Beruhigt schlafen konnte man noch nie und wird man auch nie können. Wer das nicht sehen kann, ist zu naiv für Betriebsverantwortung.
Naja, wer immer noch meint dass eine Härtung seiner Umgebung (Anpassung von TLS/Cipher Suites, Outbound Firewalling, Segmentierung DMZ und LAN, Anpassung Active Directory (Service Accounts, Umsetzung von RBAC, etc.). Logging, etc.) nicht erforderlich ist, hab ich kein Mitleid.
Wer meint eine Exchange Plattform On-Premise betreiben zu können, ohne vorgelagerte Systeme wie AD FS + WAP sowie Firewall + WAF zu nutzen und zu pflegen, habe ich ebenfalls kein Mitleid.
Ja, es kostet Zeit und Geld, aber es ist inzwischen unabdingbar, wenn man Wert auf Sicherheit legt.
Leider wird nicht dargestellt, wie die betroffene Umgebung aussieht und welche Rahmenbedingungen (Einsatz der obengenannen Techniken) es gegeben hat. Somit könnte man für sich selbst eine grobe Risiko Abschätzung vornehmen.
Das Problem ist, dass Microsoft diese konkreten und leider elementar erforderlichen Sicherheitserfordernisse nicht eindeutig und für "Durchschnittsadmins" verständlich empfiehlt.
Issues that are fixed in this update
Can't finish the E-discovery process for an on-premises mailbox (KB5019807)
E-Discovery search fails in Exchange Online (KB5019808)
https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2019-and-2016-october-11-2022-kb5019077-b5ae8793-5e5c-4faa-972d-9228945973e5
https://support.microsoft.com/en-gb/topic/description-of-the-security-update-for-microsoft-exchange-server-2013-october-11-2022-kb5019076-6e3ff0b8-4bc7-4f21-883c-9df3e27ed5dd
So isses wohl wirklich – dieses SU ist einzig ein Re-Release des August SU indem die Probleme mit der Archiving-Funktion gefixt wurden:
>>> 2.0 11. Okt. 2022
To address known issue of Outlook Probes not functioning properly with extended protection turned on, Microsoft has updated the Microsoft Exchange security updates. Please see the Exchange Team Blog for more information.
Steht überall in den adressierten CVEs dieses "Oktober" SUs:
CVE-2022-21979
CVE-2022-21980
CVE-2022-24477
CVE-2022-24516
CVE-2022-30134
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-21979
…"einfach" vom Internet trennen.
OWA ist ausschließlich per VPN erreichbar und die Mobile Devices werden mit einer vernünftigen MDM Software ausgerollt.
Leider befindet sich hinter dem AhnLab-Link auf Twitter nur noch ein 404 Error. Gründe für das Entfernen oder den Move der Seite werden von dem Unternehmen nicht angegeben.
*ttps://asec.ahnlab.com/ko/39682/
———————–
GB: Im Wayback-Cache ist der Artikel noch drin
Danke für die Ergänzung
hat denn noch niemand installiert?
Hallo,
es scheint zu der obigen Meldung irgendwie keine weiteren Infos zu geben – weder offiziell noch in dem Blog oben.
War das jetzt eine falsche Einschätzung des Blogs oder ist das offline, um keine weitere Aufmerksamkeit auf eine mögliche Verwundbarkeit zu lenken?
Hat jemand ne Idee?