Zero-day Vulnerabilities in Microsoft Exchange Server

[Ebenezer 13]

Hallo,

 

über heise sind wir auf folgende Quelle gestoßen:

https://gteltsc.vn/blog/warning-new-attack-campaign-utilized-a-new-0day-rce-vulnerability-on-microsoft-exchange-server-12715.html#:~:text=Temporary containment measures

 

Dann haben wir die von Microsoft gefunden:

https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/ 

 

Es gibt nur eine kleinere Abweichung in der Konfiguration:

 

Bei Microsoft steht in der URL Rewrite Regel Using: Wildcards

Und bei GTSC (auf die heise heute morgen verwiesen hat) steht Using: Regular Expressions

 

Kann Jemand beurteilen in wieweit diese Einstellung für eine erfolgreiche Blockierung relevant ist?

 

Danke!

 

 

Ergänzung: insofern die Ports 5985 und 5986 (remote PowerShell) nicht nach außen offen sind, kann das wohl wenn überhaupt nur von intern ausgenutzt werden ... somit ist der Angriffsvektor deutlich eingeschränkt

bearbeitet 30. September 2022 von Ebenezer

[CoolAce 17]

Hallo,

im Zweifel die vom Hersteller ist die richtige, Microsoft selbst weiss es am besten

Gruß

Coolace 

 

und du solltest mit dem Powershell Befehl prüfen ob du schon betroffen bist

[cj_berlin 1.315]

vor einer Stunde schrieb Ebenezer:

 

Ergänzung: insofern die Ports 5985 und 5986 (remote PowerShell) nicht nach außen offen sind, kann das wohl wenn überhaupt nur von intern ausgenutzt werden ... somit ist der Angriffsvektor deutlich eingeschränkt

Das ist ein Trugschluss. Remote PowerShell zu *Exchange* geht über einen Web-Endpoint, somit 443 oder sogar 80.

[Garant 3]

vor 1 Stunde schrieb Ebenezer:

 

Bei Microsoft steht in der URL Rewrite Regel Using: Wildcards

Und bei GTSC (auf die heise heute morgen verwiesen hat) steht Using: Regular Expressions

 

Kann Jemand beurteilen in wieweit diese Einstellung für eine erfolgreiche Blockierung relevant ist?

 

Moin,

 

das würde mich allerdings auch interessieren - für welche Konfiguration habt Ihr euch entschieden bzw. welche ist die gültige?

[Ebenezer 13]

Wie ist dann das hier zu verstehen:

 

Authenticated attackers who can access PowerShell Remoting on vulnerable Exchange systems will be able to trigger RCE using CVE-2022-41082. Blocking the ports used for Remote PowerShell can limit these attacks. 

• HTTP: 5985 
• HTTPS: 5986

Quelle: https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/ 

[cj_berlin 1.315]

OK, es sind ZWEI Vulnerabilities in einem Blog-Beitrag  Die zweite könnte tatsächlich den normalen PowerShell-Endpoint nutzen - hier liegen im Moment noch keine Details vor. Andererseits sollte das WinRM-basierte Remoting ja erst recht nur für andere Exchange-Server oder Management-Workstations erreichbar sein, hier ist der Angriffsvektor in wohlgemanagten Systemen tatsächlich eher beschränkt. 

[Ebenezer 13]

vor 50 Minuten schrieb Garant:

 

Moin,

 

das würde mich allerdings auch interessieren - für welche Konfiguration habt Ihr euch entschieden bzw. welche ist die gültige?

Es funktioniert nur mit Regular Expressions! Dann ist die MS Anleitung stand jetzt also falsch!

[NorbertFe 2.034]

Korrekt es müssen regular Expressions sein. Und besonders fies, wenn man die Regel vorher falsch angelegt hat, muss das "Muster" auch auf .* geändert werden. Nur * verursacht Fehler. 

[mwiederkehr 373]

Wäre das jetzt nicht ein klassischer Fall für eine "Emergency Mitigation" (https://learn.microsoft.com/en-us/exchange/exchange-emergency-mitigation-service?view=exchserver-2019)? Aktuell wurde dort noch keine entsprechende Regel veröffentlicht.

[NorbertFe 2.034]

Wäre es. Aber bei MS schlafen sie, oder sie trauen ihrem eigenen Prozess nicht. ;)

 

Kemp hat inzwischen auch was dazu veröffentlicht: https://support.kemptechnologies.com/hc/en-us/articles/9548819650701

bearbeitet 30. September 2022 von NorbertFe

[MurdocX 951]

vor 15 Stunden schrieb mwiederkehr:

Wäre das jetzt nicht ein klassischer Fall für eine "Emergency Mitigation"

Wurde jetzt veröffentlicht und der Bericht aktualisiert. 

 

vor 14 Stunden schrieb NorbertFe:

Aber bei MS schlafen sie

Sind wohl gerade aufgewacht  
 

[NorbertFe 2.034]

Kommunikation ist definitiv nicht deren Stärke. :/

[NorbertFe 2.034]

Hallo,

 

die derzeit bei ms angegebene mitigation kann wohl umgangen werden.

hier gibts die aktuell wirksamere:

https://gteltsc.vn/blog/warning-new-attack-campaign-utilized-a-new-0day-rce-vulnerability-on-microsoft-exchange-server-12715.html

[LK28 11]

Hallo,

 

ich habe die Exchange Regel auch manuell hinzugefügt, und habe mir dann noch was zu dem EEMS durchgelesen.

Nun habe ich entdeckt, dass es im IIS auf der Default Web Site diese EEMS Regel anscheinend gibt. Diese wurde nicht manuell hinzugefügt.

 

Microsoft schreibt, dass es einen Windows Dienst geben soll, den ich aber nicht finde. Jedenfalls finde ich nichts zu "EEMS".

 

Würde gerne wissen, ob EEMS damit enabled ist oder ich hier daneben liege. So wie ich das jetzt sehe, ist EEMS laut dem Bild enabled und ich kann meine manuell hinzugefügte Regel wieder entfernen?

 

Danke

 

Edit:

Ich hab jetzt doch dank Powershell Abfrage durch die englische Bezeichnung entdeckt, dass der EEMS Dienst (auf deutsch MS Exchange Notfallschutzdienst) ausgeführt wird.

 

Daher gehe ich davon aus, dass die Sicherheitslücke durch die automatisch erstellte Regel damit von alleine erledigt wurde.

bearbeitet 5. Oktober 2022 von LK28

[NorbertFe 2.034]

vor 11 Stunden schrieb LK28:

Microsoft schreibt, dass es einen Windows Dienst geben soll, den ich aber nicht finde. Jedenfalls finde ich nichts zu "EEMS".

 

im deutschsprachigen System "Microsoft Exchange Notfallminderungsdienst". Englisch Microsoft Exchange Mitigation Service. ;)

vor 11 Stunden schrieb LK28:

Daher gehe ich davon aus, dass die Sicherheitslücke durch die automatisch erstellte Regel damit von alleine erledigt wurde.

Ja, aber da wurde schon wieder was geändert. Also lieber nochmal prüfen. die manuell erzeugten Regeln kannst du dann ggf. löschen.