Exchange Server: Microsofts 0-day-Schutz aushebelbar, neue Einschätzungen (3. Oktober 2022)

Exchange Logo[English]Seit Ende September 2022 ist eine 0-Day-Schwachstelle (ZDI-CAN-18333) in Microsofts On-Premises Exchange Servern (2013, 2016 und 2019) bekannt. Die Schwachstellen (CVE-2022-41040, CVE-2022-41082) werden bereits in freier Wildbahn ausgenutzt. Microsoft hat zwar reagiert und einen Workaround zum Schutz veröffentlicht sowie per EMS URI Rewrite-Regeln zum Schutz ausgerollt. Aber die URI Rewrite-Ausdrücke lassen sich umgehen. Zudem werden die ersten (bisher Fake) Exploits im Internet angeboten. Hier ein Überblick über die neuesten Entwicklungen.


Anzeige

Die 0-day-Schwachstelle ZDI-CAN-18333

Zum 29. September 2022 hatte ich im Blog-Beitrag Exchange Server werden über 0-day Exploit angegriffen (29. Sept. 2022) über die 0-day-Schwachstelle ZDI-CAN-18333 berichtet. Microsoft Exchange Server 2013, 2016 und 2019 werden durch zwei ungepatchte Zero-Day-Schwachstellen CVE-2022-41040 (Server-Side Request Forgery) und CVE-2022-41082 (Remote Code Execution per PowerShell) gefährdet.

Für die Schwachstelle wird inzwischen der Begriff ProxyNotShell benutzt, weil die Sicherheitslücken ein ähnliches Angriffsszenario wie bei ProxyShell erfordern, es sich aber nicht um die ProxyShell-Schwachstelle handelt.

Glücklicherweise benötigt ein Angreifer einen authentifizierten Zugriff auf den anfälligen Exchange Server, um eine der beiden Sicherheitslücken erfolgreich auszunutzen. Zudem muss er PowerShell-Scripte (remote) ausführen können, hat dann aber die Möglichkeit einer Privilegienerhöhung. On-Premises-Installationen, die nicht per Internet erreichbar sind, sollten gegenüber Remote-Angriffen geschützt sein. Allerdings sind zahlreiche Exchange-Installationen direkt per Internet erreichbar (siehe Microsofts Empfehlungen für die Exchange Server 0-day-Schwachstelle ZDI-CAN-18333).

Sophos on Exchange 0-day

Vom Bauchgefühl überwiegt bei mir aber die Einstufung, dass die (mutmaßlich in China sitzenden) Hintermänner, die den Exploit in freier Wildbahn ausnutzen, genügend Anmeldeinformationen aus Phishing-Angriffen haben, um zahlreiche Exchange-Server anzugreifen. Die Nacht bin auf obigen Tweet von Sophos gestoßen, die diese Einschätzung stützen. Sophos hat das Ganze hier aufgegriffen (siehe auch obige Tweets)und schreibt, dass Kunden mit den Sophos-Sicherheitslösungen geschützt seien.

Inzwischen werden von Betrügern wohl erste (bisher aber wohl Fake) Exploits für die obigen Schwachstellen per Internet zum Kauf angeboten. Die Kollegen von Bleeping Computer haben die Nacht in diesem Artikel auf den Sachverhalt hingewiesen.

Microsofts Workaround kann umgangen werden

Die Nacht bin ich auf Twitter auf nachfolgenden Tweet von Sicherheitsforscher Kevin Beaumont gestoßen. Ein Sicherheitsforscher mit dem Alias Jangggg hat sich das URL-Pattern, welches von Microsoft im Blog-Beitrag Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server beschrieben wurde, angesehen. Sein Fazit: Die URI-Blockierungsregel ist nicht ausreichend, und kann leicht umgangen werden. Beaumont hat es verifiziert und bestätigt dies.

Exchange 0-day: MS mitigation doesn't work

Microsoft hat den Beitrag Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server zum 2. Oktober 2022 um folgende Hinweise ergänzt:

Administratoren sollten die Ausführung von Remote PowerShell-Zugriffen in ihrer Exchange-Umgebung unterbinden. Dann lässt sich eine Schwachstelle nicht mehr ausnutzen und der Angriffsvektor funktioniert in der bisher bekannten Weise nicht mehr. Problem: Damit könnten sich Administratoren aber selbst in bestimmten Szenarien ungewollt aussperren (siehe diese Warnung von Beaumont). In  folgendem YouTube-Video demonstriert der Sicherheitsforscher Jang seine Erkenntnisse (einfach das Bild anklicken und auf YouTube das Video ansehen).

Microsoft Exchange mitigations bypass CVE-2022-41040, CVE-2022-41082(Quelle: YouTube)


Anzeige

Die Kollegen von Bleeping Computer haben in diesem Beitrag noch einige Details veröffentlicht. Zusammengefasst: Sicherheitsforscher wie Will Dormann sowie die vietnamesischen Entdecker haben den Ansatz von Jang getestet und herausgefunden, dass das Pattern ".autodiscover.json.*@.*Powershell." nicht ausreichend sei, um Angriffe zu verhindern. Das Zeichen @ sei eine zu große Einschränkung, heißt es. Der Sicherheitsforscher hat das URI-Muster ".*autodiscover\.json.*Powershell.*" vorgeschlagen. Sieht so aus, als ob des Thema Exchange Administratoren auch weiterhin beschäftigen wird. Vor allem sollten Kunden mit hybriden Exchange-Lösungen sich im Klaren sein, dass sie auch gefährdet sein können. Die Kollegen von Bleeping Computer geben an, dass laut Beaumont hybride Exchange-Installationen von mehr als 1.200 Unternehmen per Internet erreichbar seien.

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)
Exchange Server: Microsofts bessert Lösungen für 0-day-Schutz nach (8. 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


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

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

43 Antworten zu Exchange Server: Microsofts 0-day-Schutz aushebelbar, neue Einschätzungen (3. Oktober 2022)

  1. Susanne sagt:

    Kevin schreibt auf Twitter aber, dass er von der remote powershell Abschaltung abrät, oder?

    • Robert sagt:

      Nicht ganz – er schreibt, dass er damit vorsichtig wäre, da man schnell mal 'aus Versehen' einen Admin- oder Service-Account damit lahmlegen kann, was sich dann auf die Funktionalität des Exchange-Servers auswirkt, bzw. ihn ausser Gefecht setzt.

    • Günter Born sagt:

      Ist im Text berücksichtigt, danke für den Hinweis – könnte bei VMs ein Problem werden. Wie Robert anmerkt: Ein Admin muss wissen, was er tut, wenn er die Remote PowerShell ausknipst.

      • M.D. sagt:

        Darauf ein ganz klares "Jain", jedenfalls in Verbindung mit Exchange. Es sieht doch zurzeit so aus, dass nicht einmal mehr das Microsoft Exchange Team weiß, was es da tut. Jetzt von den Admins zu verlangen, dass sie es besser wissen (müssen), ist schon ziemlich gewagt. Allerdings scheint es des Öfteren dann doch so zu sein, traurig aber wahr.

      • R.S. sagt:

        Stimmt.
        Habe ich schon erlebt.
        Bei allen Accounts wurde vom Kollegen Remote PowerShell ausgeschaltet, auch Admin und Serviceaccounts.
        Resultat: Die EX-PowerShell funktionierte nicht mehr.
        Per EX-PowerShell wieder anmachen ging also auch nicht.

        Also musste ich ins AD und darüber die Remote PowerShell wieder für den Admin anmachen und der konnte dann über EX PowerShell die Remote PowerShell für die Serviceaccounts wieder anschalten.

        Remote PowerShell für alle Accounts abschalten ist also eine sehr schlechte Idee!

  2. Anonymous sagt:

    Ein schnell gebastelter Zaun vor einer Backdoor schliesst die Backdoor nicht, sowas überraschendes.

  3. bytemaster sagt:

    Frickeldreck aus Redmond, man kennt es nicht anders. Aber es ist ja der Marktführer, dem man blind hörig ist.

  4. nk sagt:

    Wir haben die beiden Remote Powershell Ports 5985, 5986 in der Firewall (Exchange Server) gesperrt. Ob das genügt?

    Wenn ich den Remote-Powershell-Blog von MS korrekt verstehe, können im Grunde genommen alle Benutzer Remote Powershell benutzen, müssen aber auch in einer entsprechenden Exchange Management Gruppe sein um es zu dürfen. Das wäre bei uns nicht der Fall. Aber es ist halt alles bissl schwammig..

    • Anonymous sagt:

      Remote PowerShell wird über das HTTP Protokoll bereitgestellt. Die Blockierung eingehender Verbindungen über Port 5985,5986 dürfte daher keinen ausreichenden Schutz darstellen.

  5. Boris sagt:

    hmm, jetzt heißt es leider wieder warten, bis ausreichend mutige Admins den neuen URl-Filter eingespielt und die Remote PowerShell deaktiviert haben. Gerade bei 3rd Party Tools bin ich unsicher, ob danach noch alles funktioniert.

    Leider misbraucht MS ja inzwischen die Kunden als Beta-Tester :-|

  6. AGR sagt:

    Wenn man ungewollt alle User inklusive Admins von der RemotePowerShell ausschließt, so kann man über einen kleinen Umweg doch noch die PowerShell für einen Admin wieder aktivieren. Einfach mal einen neuen User erstellen. Dieser bekommt nämlich automatisch das Recht dazu, kurz in die Admingruppe hinzufügen, RemotePowerShell für den ursprünglichen Admin aktivieren und den neuen User wieder entfernen.

    • Anonymous sagt:

      Die Berechtigung für RemotePowerShell wird im Multi-Value-Attribut "protocolSettings" eines Benutzerobjekts gespeichert. Der Eintrag "RemotePowerShell§0" bedeutet, dass der Zugriff auf RemotePowerShell verboten ist. "RemotePowerShell§1", oder jegliches Fehlen dieses Eintrags, bedeutet der Zugriff ist gestattet.

  7. Michael sagt:

    Hallo,
    ich hab mal eine Frage.
    Ich habe seit heute das Problem mit weitergeleiteten Meetingsnotifications.
    Ich habe einige Benutzern das Remotepowershell Recht entzogen.
    Und auch hat Microsoft das URL Rewrite auf die Default Site gelegt.
    Jetzt bekomme ich bei weitergeleiteten Meetings Benachrichtigungen:

    EventID 2009 MSexchange Mid-Tier Storage
    [Process:w3wp PID:3540 Thread:50] Error occurred while resolving the Active Directory object for from email address field: 'extern@domain.com'. Audit log will not be generated for this case. Exception details:
    Microsoft.Exchange.Data.Storage.ObjectNotFoundException: Der Active Directory-Benutzer wurde nicht gefunden.
    bei Microsoft.Exchange.Data.Storage.ExchangePrincipalFactory.c__DisplayClass25_0.b__0()
    bei Microsoft.Exchange.Data.Storage.ExchangePrincipalFactory.FromProxyAddress(IRecipientSession session, String proxyAddress, RemotingOptions remotingOptions)
    bei Microsoft.Exchange.Data.Storage.COWAudit.GetSubmitEffectiveMailboxOwner(MailboxSession session, CallbackContext callbackContext, Boolean& auditModernGroupsBasedOnDelegateLogonUser)

    Der externe bekommt von der weitergeleiteten Nachricht nichts mit.
    Das war vorher anders.
    Könnte ihr mal euren Exchange auf EventID 2009 durchsuchen?
    Danke
    Michael

    • Michael sagt:

      Bei mir ist alles sauber, bei meinen Kunden laufen beide Mitigation rules parallel und PS Remoting ports sind nur für die Admins freigegeben und für die Exchange Server.

  8. Stefan A. sagt:

    Microsoft empfiehlt ja: "we strongly recommend Exchange Server customers to disable remote PowerShell access for non-admin users in your organization".

    https://learn.microsoft.com/en-us/powershell/exchange/control-remote-powershell-access-to-exchange-servers?view=exchange-ps%22%20\l%20%22use-the-exchange-management-shell-to-enable-or-disable-remote-powershell-access-for-a-user

    Wenn man sich den Artikel durchliest heißt es ja:
    "By default, all user accounts have access to remote PowerShell. However, to actually use remote PowerShell to connect to an Exchange server, the user needs to be a member of a management role group, or be directly assigned a management role that enables the user to run Exchange cmdlets"

    Mir stellt sich nun die Frage, wie man das nun am sinnvollstem umsetzt?!
    Man müsste ja zum Beispiel erst einmal ALLE User in eine CSV exportieren und anschließend diese dann kontrollieren / bearbeiten, wer weiterhin Zugriff benötigt und das Ganze dann zurück importieren.

    Und aufgrund des Hinweise von Kevin Beaumont kann das auch Probleme nach sich ziehen:
    https://twitter.com/GossiTheDog/status/1577197806720208896?t=iFQMeB3J5tk7U2bMFhjymQ&s=19

    Wie habt ihr das bei euch umgesetzt?

    • Michael sagt:

      sperre einfach alle IP Adressen (sowohl extern/"Internet" als auch intern) außer die Admin Workstations/Admin Jump hosts/Exchange Server etc. Das Ganze richtest als lokale Firewall Rule ein am Exchange server, idealerweise auch auf der Segmentation firewall falls vorhanden.

      • 1ST1 sagt:

        Genau das frage ich mich auch… Wer macht für einen EX schon Remote PowerShell fürs Internet auf, oder für normale Outlook-User? Das begrenzt man idealerweise auf den/die Admin-Terminalserver.

        • Anonymous sagt:

          Exchange Remote PowerShell wird mittels IIS bereitgestellt und ist nicht zu verwechseln mit PowerShell Remoting (Port 5985/5986).

          • Bent sagt:

            Bedeutet also, dass ich theoretisch beides unterbinden muss?
            Es wird ja auf unterschiedlichen Seiten zu dem Thema mal geraten die PS-Remoting Ports zu sperren und auf anderen (u.a. MS selbst) wird geraten Remote PowerShell für nicht-administrative User zu deaktivieren.

            Was ist jetzt der richtige Weg?

        • Olli sagt:

          Jetzt aber mal die dumme Frage:

          Beim Ausnutzen dieser Lücke wird das über den IIS terminiert – was sieht also die "Remote PowerShell" für eine anfragendes System – doch nicht etwa den IIS auf localhost? Dann wäre das Blockieren über die lokale Windows Firewall für diesen Fall nutzlos (Für andere Fälle natürlich nicht).

  9. Gabriel sagt:

    Das gute ist, dass ich diese Lücke nehmen konnte und mal den Zugriff auf den Exchange von aussen auf die, für die Hybridkonfiguration erfolderlichen, IPs zu begrenzen.
    EXO Migration ist so gut wie abgeschlossen. Alles was jetzt nicht mehr funktioniert gilt ab jetzt als notwendiger Kollateralschaden.

  10. Noah N. sagt:

    Microsoft hat die Mitigation in ihrer Customer Guidance über das Wochenende ohne Kommentar angepasst.

    In der Version von Freitagvormittag (https://web.archive.org/web/20220930095424/https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/) war noch die Rede davon, den Change unter der IIS Application "autodiscover" durchzuführen:
    The current mitigation is to add a blocking rule in "IIS Manager -> Default Web Site -> Autodiscover -> URL Rewrite -> Actions" to block the known attack patterns.

    Nun hat sich der Scope anscheinend mit der aktuellen Version der Customer Guidance (https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/) verändert:
    The current Exchange Server mitigation is to add a blocking rule in "IIS Manager -> Default Web Site -> URL Rewrite -> Actions" to block the known attack patterns.

    Im schlimmsten Fall stehen Kunden, die den Change bereits am Freitag umgesetzt haben, nun ganz ohne Schutz dar.

    • Dominik sagt:

      Hallo, ich muss jetzt mal dumm fragen. Im Blogabschnitt wird berichtet, dass dieses Umschreiben des URL-Writers nicht wirklich etwas bringt und umgehen werden kann. Bezieht sich das auf die "alte" Lösung vom 30.09. bis 02.10. oder auch auf die gestern veröffentliche neue Lösung vom 04.10. ?

      • Dave sagt:

        Es bezog sich vorerst auf die "alte" Lösung, da anscheinend das @ ein zu großer Faktor war.

        Bei uns ist es jetzt jedoch so, dass wir beide Regeln aktiv haben mit dem gleichen Pattern und wieder ein 403 erhalten.
        Jemand zufällig eine Idee? Server wurden bereits neugestartet.

  11. Ben sagt:

    Wenn man seine Admin- und Service-Accounts per OUs im AD von den normalen Endusern getrennt hat, könnte man entsprechend auch (nach Überprüfung der erstmal nur rausgelassenen Userliste) mit nem Einzeiler für die User in der OU "Benutzer" (und untergeordneten OUs) abschalten:

    Get-User -OrganizationalUnit "OU=Benutzer,OU=X,DC=firma,DC=xyz,DC=de" -ResultSize Unlimited -Filter 'RemotePowerShellEnabled -eq $true' | Set-User -RemotePowerShellEnabled $false

    (Darf man dann für die danach angelegten Benutzer halt nicht vergessen…)

  12. Thilo sagt:

    …was ist eigentlich mit den "Usern" Gast, DefaultAccount, krbtgt, Exchange Online-ApplicationAccount, DiscoverySearchMailbox die sind per Standard ja auch enabled…

  13. Dominik sagt:

    am kommenden Dienstag ist Patch-Day. Bis dahin könnte man auch den Exchange-Server nach außen zumachen, sodass OWA nicht vom Internet aus erreichbar ist.

    oder noch besser Owa nur intern nutzen und sich per VPN einwählen und dann Owa nutzen, falls nötig. Man sieht wieder wie riskant es ist, den Exchange direkt ins Internet zu stellen.

  14. Archetim sagt:

    Bei mir hat die Rewrite-Rule ActiveSync gestört, hat das noch jemand beobachtet? Die Logs waren unauffällig, allerdings konnten die Smartphones weder senden noch empfangen. Nach Deaktivierung der Rule und IISRESET hat wieder alles funktioniert.

    Ich hatte allerdings nach dem ersten Eintragen der Rule keinen IISRESET gemacht, da das ja nicht nötig sein sollte. Ich werde das jetzt nochmal testen mit IISRESET nach dem Aktivieren der Rule.

    Das macht alles keinen Spass mehr… Zum Glück steht unser Exchange nicht im Netz :-(

    • Archetim sagt:

      Okay, ich kann wohl Entwarnung geben. Ich hatte die Rule erstmals mit dem EOMTv2-Script von MS eintragen lassen, dabei wurde die URL-Rewrite-Komponente zunächst installiert, da die bei mir noch fehlte. Diese Installation erfordert allerdings einen IISRESET, den das Script aber nicht mit macht.

      Also lieber mal einen IISRESET mehr als zu wenig machen…

    • Anonymous sagt:

      Hast du evtl. noch die ursprüngliche Regel unter "Autodiscover" drin? Falls ja, diese erst löschen und dann unter "Default Web Site" die neue Regel setzen.

      Ich hatte auch beide Regeln noch drin und konnte keine neuen Outlook-Profile einbinden. Es wurde permanent nach User/Passwort gefragt. Nachdem ich die alte Regel unter "Autodiscover" gelöscht hatte, ging es dann wieder.

    • Dominik sagt:

      Ich antworte nur auf den letzten Satz. Dann sei doch froh, dass dein Owa nicht direkt im Internet erreichbar ist.

  15. R.S. sagt:

    Microsoft hat die Exchange Mitigation EM1 übrigens heute Nacht angepasst, jetzt steht da das Pattern .*autodiscover\.json.*Powershell.* drin.
    Damit ist die Lücke im ursprünglichen Pattern geschlossen.

  16. FrankvanLight sagt:

    Hallo zusammen,
    weiß jemand ob auch Exchange 2010 davon betroffen ist, ich weiß das hier der Support schon fast 2 Jahre rum ist haben aber noch einen Kunden der schon seit 1,5 Jahre am Migrieren ist und wegen größere Probleme hier aktuell nicht weiter macht.

    Die kommen jetzt natürlich mit was machen wir damit :) zu uns …..

  17. Stefan A. sagt:

    Hier gibt es noch neue Erkenntnisse zu dem Thema:

    1. „Remote PowerShell is published via port 443 so blocking ports is not an effective mitigation (because blocking that would be… well…)"

    https://techcommunity.microsoft.com/t5/exchange-team-blog/customer-guidance-for-reported-zero-day-vulnerabilities-in/bc-p/3645120/highlight/true#M34413

    Interpretiere ich so, blockieren der Ports 5985/5986 hilft nicht.

    -> Also notwendig die Mitigation „We strongly recommend Exchange Server customers disable remote PowerShell access for non-admin users in your organization" umzusetzen.

    2. Hier ein neues Statement von Will Dormann:

    „There's a bypass to the fix to the bypass to the mitigation for ProxyNotShell / CVE-2022-41040.
    Because characters can be encoded, looking for ".*autodiscover.json.*Powershell.*" in {REQUEST_URI} isn't sufficient.
    Use {UrlDecode:{REQUEST_URI}} instead!"

    https://twitter.com/wdormann/status/1576922677675102208

    Das Thema kommt nicht zur Ruhe :/

  18. Gero sagt:

    oar….

    Wenn man die per EEMS erstellte Regel ändert bleibt das dann?
    Oder besser eine zweite erstellen?
    Oder beißt sich das?

Schreibe einen Kommentar

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.