Outlook-Schwachstelle CVE-2023-23397 nicht vollständig gepatcht – Absicherung erforderlich

[English]Noch ein kurzer Nachtrag zum März 2023-Patchday. Microsoft hat zum 14. März 2023 die kritische RCE-Schwachstelle CVE-2023-23397 in Outlook zwar mit einem Sicherheitsupdate versehen. Aber der Patch ist unvollständig, der Angriff kann weiterhin mit etwas modifizierten E-Mails immer noch ausgelöst werden. Und inzwischen ist ein Proof of Concept öffentlich, was demonstriert, wie die Schwachstelle ausgenutzt wird.


Anzeige

Kritische RCE-Schwachstelle CVE-2023-23397

In Microsoft Outlook gibt es eine kritische Schwachstelle CVE-2023-23397, die eine Rechteauswertung durch Dritte ermöglicht. Diese Elevation of Privilege-Schwachstelle (EvP) wird als extrem kritisch eingestuft, und hat den CVEv3-Score von 9.8 erhalten. Das Problem: Angreifer können eine bösartige E-Mail an eine anfällige Version von Outlook senden. Sobald Outlook diese Mail empfängt, kann (ohne Zutun des Nutzers) eine Verbindung zu einem vom Angreifer kontrollierten Gerät hergestellt werden.

Der Angreifer kann so den Net-NTLMv2-Hash des E-Mail-Empfängers abgreifen (siehe auch diesen Artikel aus 2019 mit Erklärungen). Dieser Hash ermöglicht einem Angreifer sich in einem NTLM-Relay-Angriff als Empfänger des Opfers zu authentifizieren. Diese Schwachstelle wird seit Mitte April 2022 durch russische Angreifer aktiv ausgenutzt (siehe auch diesen Beitrag von deep instinct, der Fälle aufzeigt). Es sieht so aus, als ob auch andere Angreifer diese Schwachstelle ausnutzen (siehe diesen Palo Alto Networks-Artikel).

PoC verfügbar, patchen angesagt

Am 22. März 2023 hat ein Sicherheitsforscher ein Proof of Concept (PoC) zur Ausnutzung der Schwachstelle in einem Video auf Twitter demonstriert (einfach nachfolgendes Bild anklicken, um das Video auf Twitter abzuspielen – oder auf der GitHub-Seite abrufen) und den Code dafür auf Github veröffentlicht.

PoC für Outlook RCE-Schwachstelle CVE-2023-23397

Aktuell liest man nur, dass Administratoren und Nutzer die unterstützten Outlook-Versionen (z.B. Outlook 2013 und 2016) patchen sollen. Ich hatte sowohl im Blog-Beitrag Outlook wegen kritischer Schwachstelle CVE-2023-23397 patchen als auch in weiteren Beiträgen (siehe Linkliste am Artikelende) auf diese Schwachstelle hingewiesen.

Wenn ich es richtig einsortiere, ist das vor allem ein Problem in Unternehmensumgebungen, wo der erbeutete Net-NTLMv2-Hash des E-Mail-Empfängers für eine laterale Bewegung in den IT-Netzwerken mit Microsoft Servern missbraucht werden könnte.

Schwachstelle unvollständig gepatcht

Problem bei den ganzen Patch-Aufforderungen ist, dass Microsoft den Angriffsvektor für die RCE-Schwachstelle CVE-2023-23397 nicht vollständig geschlossen hat. Blog-Leser 1ST1 weist in diesem Kommentar darauf hin (danke dafür). Dominic Chell demonstriert in nachfolgendem Tweet im eingebetteten Video (Bild anklicken und das Video auf Twitter abrufen) die weiterhin bestehende Möglichkeit, das Ganze weiterhin auszunutzen.

Outlook RCE-Schwachstelle CVE-2023-23397 ausnutzen


Anzeige

An dieser Stelle bleibt für Administratoren die Frage, was man nun noch tun kann. Ich verweise auf den Microsoft-Beitrag zu CVE-2023-23397, wo es am Abschnitt "Mitigations" heißt:

  • Add users to the Protected Users Security Group, which prevents the use of NTLM as an authentication mechanism. Performing this mitigation makes troubleshooting easier than other methods of disabling NTLM. Consider using it for high value accounts such as Domain Admins when possible. Please note: This may cause impact to applications that require NTLM, however the settings will revert once the user is removed from the Protected Users Group. Please see Protected Users Security Group for more information.
  • Block TCP 445/SMB outbound from your network by using a perimeter firewall, a local firewall, and via your VPN settings. This will prevent the sending of NTLM authentication messages to remote file shares.

So ad-hoc würde ich sagen, dass das Blockieren von ausgehendem TCP 445/SMB-Traffic in einer Firewall oder anderen Lösungen das Problem entschärft. Denn dadurch wird das Senden von NTLM-Authentifizierungsmeldungen an Remote-Dateifreigaben verhindert. Die Schwachstelle ist dann auf diesem Weg nicht mehr ausnutzbar. Der Microsoft Blog-Beitrag Microsoft Mitigates Outlook Elevation of Privilege Vulnerability gibt noch einige Hinweise zu betroffenen Produkten (Outlook für Windows in allen Versionen) und zu den Auswirkungen für Unternehmensumgebungen.

Ähnliche Artikel:
Outlook wegen kritischer Schwachstelle CVE-2023-23397 patchen
Patchday: Microsoft Office Updates (14. März 2023)
Exchange Server Sicherheitsupdates (14. März 2023)


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Office, Sicherheit abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

21 Antworten zu Outlook-Schwachstelle CVE-2023-23397 nicht vollständig gepatcht – Absicherung erforderlich

  1. MOM20xx sagt:

    warum wundert mich das nur. vermutlich deswegen das script um exchange mailboxen von schädlichen mails zu säubern. microsoft patcht mal wieder unvollständig.

  2. 1ST1 sagt:

    Das mit SMB auf Firewall/Proxy blocken ist das einfachste und sinnvollste, sollte schon ewig sowieso schon Standard sein. Schonmal mit einem "Protected User" gearbeitet? Nee, das will man nicht!!!

    • Anonymous sagt:

      Ja, haben wir mal versucht und nach etwa 3 Minuten rückgängig gemacht.

    • Tom801 sagt:

      Innerhalb eines Unternehmens sollte es so sein. Aber wenn der Benutzer unterwegs ist per Mobile Hotspot oder nur schon im Homeoffice, da wird gegen aussen 445 selten geblockt. Da müsste die Windows Firewall o.ä. blocken, bis die VPN offen ist. Und dort wo es keine VPN gibt, könnte es tricky werden.
      Und wer erzwingt schon die Outlook Mail Vorschau auf text only Corp weit.

      • 1ST1 sagt:

        Warum sollte denn ein Firmengerät im Homeoffice am VPN vorbei ins Internet funken dürfen? Außer ggf. zu bestimmten vordefinierten Diensten…?

  3. Paul sagt:

    Warum sollte jemand der auch nur leidlich sein Handwerk versteht den Port für das *lokale* Netzwerk Protokoll 445 ins Internet forwardem?
    Das gibt es doch gar nicht.

    Andererseits, wie soll ein Homeofficer an die Daten kommen die auf Servern liegen, wenn Port 445 auf VPN gesperrt wird?

    Außerdem laufen solche Angriffe nie direkt
    Sondern es wird ein PC im LAN oder at Home übernommen und
    der Angriff von diesem PC gefahren.

    Sollte das nicht vielmehr heißen:
    Lagern Sie ihren Daten lieber nicht auf Microsoft Servern?

  4. Stefan A. sagt:

    Ich bin eher schockiert, dass Microsoft das erst seit heute Nacht ergänzt hat und nicht von Anfang an offen kommunizierte:

    „3/23/2023: Added a note mentioning the CVE-2023-23397 defense in depth fix included in Exchange Server March 2023 SUs (or later)"

    „Exchange Server (with March 2023 SU) and Exchange Online drop the PidLidReminderFileParameter message property at TNEF conversion when new message is received from outside of the organization"

    https://techcommunity.microsoft.com/t5/exchange-team-blog/released-march-2023-exchange-server-security-updates/ba-p/3764224

    https://msrc.microsoft.com/blog/2023/03/microsoft-mitigates-outlook-elevation-of-privilege-vulnerability/

    • R.S. sagt:

      Und das hier:
      Please note that Exchange Server March 2023 SUs contain a "defense in depth" change that removes the value of the property that can be exploited on unpatched Outlook for Windows clients for messages that are newly delivered to user mailboxes from outside of the organization. No admin action is necessary other than installing March 2023 (or later) SU.

      Heißt:
      Auch ungepatchte Outlookversionen sind sicher, wenn neue schädlichen Mails von außerhalb der Organisation kommen UND bei Exchange das März 2023-SU installiert ist, da der Exchange das filtert.

    • Bent sagt:

      Heißt das ich bin mit der Installation vom März SU safe?

  5. Andy sagt:

    Zitat:
    So ad-hoc würde ich sagen, dass das Blockieren von ausgehendem TCP 445/SMB-Traffic in einer Firewall oder anderen Lösungen das Problem entschärft. Denn dadurch wird das Senden von NTLM-Authentifizierungsmeldungen an Remote-Dateifreigaben verhindert. Die Schwachstelle ist dann auf diesem Weg nicht mehr ausnutzbar.

    Aus dem Unternehmen heraus mag das wirken. Die Frage ist, wie sich das ganze außerhalb dieser "geschützten Umgebung" auswirkt. Im Homeoffice zum Beispiel. Oder in einem öffentlichen Hotspot. Dort sind die Anmeldedaten der User ja auch verfügbar, weil in der Regel zwischengespeichert. Ich meine eine Fritzbox sollte NTLM per Default nicht ins Internet routen. Aber getreu dem Motto "alle User sind Terroristen" weiß man halt nicht, was die mit ihrer Fritzbox daheim so alles an- und einstellen. Alles in allem ein heikles Thema …

  6. Robert sagt:

    Wenn alle Server und Workstations im Netz SMB Signing als SMB Client UND SMB Server (jede Workstation ist ja auch als SMB Server anzusehen) verwenden, sollte doch so ein abgegriffener Hash gar nicht funktionieren – oder?

  7. Christoph von Wittich sagt:

    Blocken von SMB ist unzureichend. Das ganze lässt sich auch mit WebDAV ausnutzen.
    Man sollte auf allen Geräten LLMNR und MDNS deaktivieren, denn damit lassen sich Anfragen für Angreifer bequem umleiten.

    Bzgl. "Protected Users" – ja damit läuft erstmal vieles nicht. Aber wenn sich niemand bei den Herstellern beschwert und Kerberos fordert, wird das auch leider weiterhin so bleiben.

  8. Andy sagt:

    Die "Protected Users Security Group" sperrt übrigens alle User außerhalb der Erreichbarkeit der oder des Domänencontrollers aus. Keine zwischengespeicherten Anmeldedaten mehr, was im Fall eines nicht erreichbaren Domänencontrollers (z.B. weil VPN erst nach der Anmeldung aktiviert wird) bedeutet: keine Anmeldung am Rechner möglich! Blöd, wenn der User im 500km entfernten Homeoffice sitzt oder beim Kunden im Einsatz ist. Hat man kein LAPS im Einsatz, müssen in solchen Fällen die statischen Kennwörter des lokalen Administrators rausgegeben werden. Sehr ungünstig!

    • Chris sagt:

      Homeoffice Laptops bzw. Laptops die das eigene Netzwerk verlassen sollte man grundsätzlich mit einer installierten Fernwartungssoftware versehen.

      Dann kann man, solange das Gerät einen Zugang zum Internet hat, Support leisten. W-Lan kann man auch ohne Anmeldung im Startbildschirm einrichten.

      Der Admin meldet sich auf dem PC an, baut den VPN Tunnel auf und dann wechselt man den Benutzer (Wechseln, nicht den Admin abmelden! Weil man dann den VPN Tunnel wieder kappen würde). Dadurch das der VPN dann im Hintergrund noch läuft klappt auch der Domainlogin des normalen Benutzers.

      Voila, der Laptop kennt wieder den Domainbenutzer und der Admin kann seine Session wieder abmelden.

      • Andy sagt:

        Das mag in einer Bude mit 20 Leuten (und 5 davon im Homeoffice) vielleicht funktionieren. Wir haben 1500 User weltweit verstreut. In Spitzenzeiten arbeitet davon ein Viertel mobil. Neben der Menge der User haben wir das Problem der Zeitverschiebung. Wie gesagt, für ne kleine Bude durchaus machbar und tatsächlich ein Workaround. In großen Umgebungen in der Form allerdings nicht darstellbar.

  9. Philipp sagt:

    … wir betreuen ein Stadtteilkulturzentrum, was vor einem Jahr in die Cloud zu Microsoft gegangen ist eher mit knirschenden Zähnen, weil wir, wären wir zuvor gefragt worden auf keinen Fall diesen Schritt empfohlen hätten. Nach Veröffentlichung der Informationen zur Lücke habe ich eine zwei-stündige Recherche, unter Einbeziehung zwei großer Integratoren / Reseller und des Microsoft Supports hinter mich gebracht wo es dann die Aussage gab: "Wer in der Cloud ist, braucht sich keine Sorgen machen". Die Outlook Updates haben wir vergangene Woche dennoch sicherheitshalber vorgenommen, da es ja eigentlich ein Outlook Schwachstelle ist.

    Nachdem ich diesen Beitrag nun gelesen habe, möchte ich mal in die Runde fragen ob da jemand was zu weiß. "Betrifft das Problem Microsoft Kunden, die in der MS365 Cloud arbeiten ebenfalls, oder nur on-premise Installationen?"
    Muss ich nun erneut aktiv werden?

    Viele Grüße

    Was ich nach wie vor nicht gefunden habe ist:

  10. Tom sagt:

    Kurze Anfänger-Frage wegen "Outlook CVE-2023-23397 und 10:04 16.04.2023""Port 445 (SMB) an der Perimeter Firewall blocken":
    Ich habe einen Draytek Router, dort habe ich in der Firewall folgendes gesetzt:
    "TCP/UDP, Port: from 445 to any"
    Ist das so richtig? Oder muss der Zielport statt "Any" auch "445" sein?
    Gibt es eine Möglichkeit zu testen ob der ausgehende Port wirklich gesperrt ist?
    Habe es mit "\\live.sysinternals.com\tools" probiert, aber das ist erreichbar …
    Danke!
    Tom

  11. Patrick sagt:

    Weiß jemand, ob die Lücke durch MS mittlerweile vollständig gestopft wurde? Finde leider dazu nichts im Web…

Schreibe einen Kommentar zu Singlethreaded Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.