Exchange Security Fixes - 03/2021

[mwiederkehr 373]

Ach, jetzt, wo ich auch die harte "der Server läuft stabil, der braucht kein CU"-Fraktion überzeugt und die CUs installiert habe, kommt Microsoft mit Patches für alte Versionen. Erzähle ich denen aber nicht. 

 

Der Trick mit dem "Dienste stoppen, .Net 4.8 installieren, CU installieren", den ich vor einiger Zeit hier erhalten habe, hat übrigens überall funktioniert. Krassester Fall war ein Exchange 2013 SP1, der jetzt tadellos mit CU23 läuft.

 

Ich habe übrigens auf keinem Server eine "Infektion" festgestellt. Vielleicht nicht gefunden, vielleicht Glück gehabt oder evtl. waren KMU nicht die Zielgruppe, wenn es von den Chinesen kam. Man will sich gar nicht vorstellen, was passiert wäre, wenn der Exploit in den Händen einer Malware-Gang gelandet wäre...

[NorbertFe 2.034]

vor einer Stunde schrieb mwiederkehr:

Ich habe übrigens auf keinem Server eine "Infektion" festgestellt. Vielleicht nicht gefunden, vielleicht Glück gehabt oder evtl. waren KMU nicht die Zielgruppe, wenn es von den Chinesen kam. Man will sich gar nicht vorstellen, was passiert wäre, wenn der Exploit in den Händen einer Malware-Gang gelandet wäre...

Du hast dann vermutlich "nur" Glück gehabt. Ich sehe hier grad andere Bilder.

[Ebenezer 13]

Hi, wir haben 7 Firmen mit Exchange 2016 in der Betreuung und bei 6 Firmen haben wir zum Glück schon vor Monaten dafür gesorgt, dass das ECP Verzeichnis nur aus dem LAN erreichbar ist (entweder via NGINX oder mittels der IIS Rolle  IP- und Domäneneinschränkungen) ... das hat uns diesesmal offensichtlich vor Infektionen gerettet... bei der 7. Firma wurde scheinbar nur "angeklopft":

 

/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@vmexch16.domain.local:444/autodiscover/autodiscover.xml?#","200"

 

Wir haben alle Server mittels der PS Skripte Test-ProxyLogon und detect_webshells geprüft. Hilfreich war es auch folgenden Blog im Auge zu behalten (z.B: via RSS Feed in Outlook):

 

https://msrc-blog.microsoft.com/

 

Da die 4 Lücken bereits vor der Veröffentlichung ausgenutzt wurden stellt sich mir die Frage was da demnächst noch kommt und ob das tatsächlich im Zusammenhang mit dem SolarWinds Hack steht und ob es inm anbetracht dessen eine kluge Idee ist den Exchange via 443 überhaupt noch zu verföffentlichen ... Active Sync und OWA und OAW nur noch via VPN?

 

Nico

 

 

 

[jimmyone 15]

Wir überlegen derzeit, was wir mit unserem Exchange 2016 machen.

Das System war auf CU18, wurde am Samstag auf CU19 gehoben und das KB installiert.

Glaubt man diesem Kommentar: https://techcommunity.microsoft.com/t5/exchange-team-blog/released-march-2021-exchange-server-security-updates/bc-p/2188076/highlight/true#M29753

sind das nur Indikatoren. Diese treffen scheinbar auch auf uns zu. Wir sehen aber auch Zugriffe / Requests auf das OAB allerdings mit http Fehler 500.

Hier hat allerdings unser Gateway, was quasi auf dem Leitungsweg nach Signaturen scannt einen Block durchgeführt.

 

Im Weiteren Check der Logs wird das ganze mit einem AppError für OAB und ECP zurück gemeldet, der als Hinweistext beinhaltet, dass mittels des DOMÄNE\Administrator keine Verbindung hergestellt werden konnte. Der o.g. Benutzer ist bei uns auch kein Exchange Benutzer.

 

Schaut man dann auf diesen Link: https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/#scan-log zur Prüfung auf Webshells etc. finden wir in keinem der angegeben Pfade etwas. Auch der MSERT findet nichts.

 

Firewall seitig wurden die IPs, welche die Requests gesendet haben blockiert und mit Bekanntwerden, entsprechend erweitert. Diese waren aber nicht auf China zurückzuführen sondern u.a. aus Bonn (NRW) und den Niederlanden stammend. Wir sehen auch keine ZIPs, RARs, 7z die seltsam wären. Der hauseigene Virenscanner liefert keine Resultate.

 

Alle Microsoft Hinweise haben wir damit abgefrühstückt und nichts gefunden, außer den Einträgen, die im Kommentar als Probing bezeichnet wurden.

 

Wir sind allerdings etwas weiter auf die Suche gegangen und haben in diesem Blog: https://www.crowdstrike.com/blog/falcon-complete-stops-microsoft-exchange-server-zero-day-exploits/ noch ein paar Hinweise für uns mitgenommen.

Ich weiß zwar nicht ob der Link erlaubt ist, aufgrund der Tragweite, sorry falls verboten.

 

Jedenfalls wird hier ebenfalls von Indikatoren für folgende Files gesprochen: C:\Windows\Microsoft.NET\Framework64\*\Temporary ASP.NET Files\root\*\*\App_Web_[0-9a-z]{8}.dll

Entsprechende Files finden wir, die sowohl vor, in der fraglichen Zeit, als auch nach Einspielen der Patches erstellt werden.

Die Frage die sich stellt ist, in wie weit dieser Indikator nun zählt.

 

Intern herrscht gemischte Stimmung. Es gibt die Fraktion vom Netz nehmen und die Fraktion, keine bis sehr wenige Indikatoren aber keine feststellbaren Exploits.

Ich finde das ein Dilemma. Beide Seiten haben Stichhaltige Argumente.

 

Weitere Checks waren bei uns z.B. auch auf Änderungen von Benutzern im AD (Erstellt, geändert etc.) auch das war unauffällig.

Lokale Admins wurden nicht erstellt, die Gruppe der lokalen Admins nicht angepasst, die Virtual Directories weisen keine Änderung auf.

Der Healthchecker ist unauffällig, ein PROCDUMP des LSASS ebenfalls.

 

Sich jetzt noch weitere Meinungen zu holen macht es wahrscheinlich nicht besser: Aber wie würdet ihr das jetzt bewerten?

Offensichtlich hätte man in das System eingebrochen, wenn man nicht schon auf dem Leitungsweg am Gateway gestoppt worden wäre und der Admin Benutzer tatsächlich Admin gewesen wäre.

Ein bisschen unruhig machen mich die App_Web DLLs.

 

Das Firewall / Monitoring Team hat zusätzlich keine Auffälligkeiten entdeckt, was den Datenstrom ein- und ausgehend angeht.

Laut diesem Team bewegt sich das innerhalb der sonst üblichen Bewegungen.

 

Irgendwie glaube ich, dass wir nur Spitze des Eisberges sehen...

 

Grüße

Jimmyone

 

 

bearbeitet 9. März 2021 von jimmyone
Exchange Release ergänzt

[gallahead 1]

Heey, 

 

bei uns sieht es exakt identisch aus. Macht es Sinn das Betriebssystem auf einen Stand vor den Attacken zurückzusetzen? Dürfte das mögliche Malware entfernen ohne Mailbox Datenverlust?

[jimmyone 15]

Wir haben heute erzählt bekommen, dass ein System eines befreundeten Unternehmens, also im Dialog erfahren, nach einer internen Untersuchung bereits Mitte Januar ohne aufzufallen kompromittiert wurde.

 

Für unsere Umgebung scheint zum Tagesschluss immer klarer zu werden, dass wir nur aus wenigen Gründen wahrscheinlich der Kompromittierung entgangen sind.

 

1.) Der Benutzer Administrator der Domäne war nicht verfügbar.

Das Log gibt Aufschluss, dass über den Autodiscover Versuche mit verschiedenen TLDs und Domainnames unternommen wurden.

In einem weiteren Schritt wurde versucht per MAPI dennoch zugreifen zu können, auch das war aufgrund des fehlenden Benutzers nicht erfolgreich. Die Meldungen lauten entsprechend.

Z.b. S-ID-2-5456- can't act as mailbox owner. User not available.

 

2. Das Gateway Log gibt Aufschluss, das die dahinterliegende Scan Engine Javascript Files (y.js, x.js und CNAuth.js) heraus gefiltert hat.

 

3. Die DLLs App_Web im .Net Verzeichnis sind wohl kein Kriterium wie oben angenommen und werden wohl auch durch Exchange selbst erzeugt.

 

4. Wir haben sämtliche Dienste, die sonst ohne VPN erreichbar wären zunächst abgeschaltet und triggern nun einige Tage ob es versteckte Webshells gibt, die entweder selbst eine Kommunikation aufnehmen oder von außen angesprochen werden. Stellt sich auch das als negativ heraus wird das System wieder bereitgestellt, bleibt aber zunächst weiter unter Beobachtung.

 

@gallahead: Ich vertrau der Engine der Systemwiderherstellung nicht wirklich. Wenn das System wieder aufgebaut werden soll, würde ich es from scratch hochziehen, Backups der DB einspielen und dann eine Bereitstellung wieder vornehmen. 

 

LG

[Alith Anar 40]

vor 10 Stunden schrieb mwiederkehr:

Der Trick mit dem "Dienste stoppen, .Net 4.8 installieren, CU installieren", den ich vor einiger Zeit hier erhalten habe, hat übrigens überall funktioniert. Krassester Fall war ein Exchange 2013 SP1, der jetzt tadellos mit CU23 läuft.

Ist der Weg auch supportet?

Oder kann ich die ganzen CU irgendwo herunterladen?

 

Wir haben heute einen Anruf erhalten mit genau dem selben Fall ... EX2013 SP1
Hab dem Kunden gesagt, wird Ihn mindestens einen Tag kosten, denn (wenn man Sie überhaupt noch findet) sind es bis zum letzten Update 6 CU + 5 .Net die eingespielt werden müssen.

[Nobbyaushb 1.471]

CU sind kumulativ, du brauchst eigentlich nur das letzte CU, wenn der SP1 hat, ist das CU4 drauf

 

Wenn du andere brauchst musst du jemanden fragen, der sowas ggf. noch rumliegen hat...

[Alith Anar 40]

Ich weiss das die Kumulativ sind :)
Aber es ist entsprechend auch nur .Net 4.5.1 drauf.
Und früher hies es mal das das MS jeden Support einstellt, wenn man einen unsupporteten Stand hat und auch wenn der der Stand jetzt zwar korrekt ist, aber zwischendrin mal ein CU zu einer nicht passenden .Net installiert wurde.

Daher direkt von 4.5.1 bei deaktivierten Exchange diensten auf 4.8 und dann das CU 19 drauf. ... Supported oder nicht ...

[NorbertFe 2.034]

vor 31 Minuten schrieb Alith Anar:

Ist der Weg auch supportet?

Oder kann ich die ganzen CU irgendwo herunterladen?

 

Wir haben heute einen Anruf erhalten mit genau dem selben Fall ... EX2013 SP1
Hab dem Kunden gesagt, wird Ihn mindestens einen Tag kosten, denn (wenn man Sie überhaupt noch findet) sind es bis zum letzten Update 6 CU + 5 .Net die eingespielt werden müssen.

Es ist bei MS inzwischen dokumentiert, dass man das machen "kann". Wahrscheinlich hatten sie keinen Bock ständig die Frage zu bekommen, wo man denn CU6, CU 8, CUxx runterladen kann.

[Alith Anar 40]

Ok,
Dann mache ich es mal so ...
Thx

[MrCocktail 192]

vor 11 Minuten schrieb Alith Anar:

Daher direkt von 4.5.1 bei deaktivierten Exchange diensten auf 4.8 und dann das CU 19 drauf. ... Supported oder nicht ...

Wenn du Microsoft fragst, nein.

Die Aussage ist seit Exchange 2013, es ist das überspringen eines Updates erlaubt.

Technisch gehen tut es.

[Alith Anar 40]

Ok, also immer noch der offizielle Stand, wie ich ihn kenne ;)

[siberia21 13]

 

vor 13 Stunden schrieb testperson:

Microsoft stellt jetzt für ältere / unsupportete CUs auch einen entsprechenden Fix bereit: March 2021 Exchange Server Security Updates for older Cumulative Updates of Exchange Server - Microsoft Tech Community

 

Description of the security update for Microsoft Exchange Server 2019, 2016, and 2013: March 2, 2021 (KB5000871):

 

Auf GitHub (CSS-Exchange/Security at main · microsoft/CSS-Exchange · GitHub) gibt es noch ein weiteres Script (CompareExchangeHashes.ps1), um die Installation auf infizierte Dateien zu durchsuchen.

 

 

Ich grüße euch, aber das ergibt keinen Sinn oder verstehe ich was nicht?

 

Der hier verlinkte und vorhin von Heise noch mal hochgebrachte Artikel spricht davon siehe heise:

 

"All das ist nicht trivial. Selbst das Einspielen der Patches erfordert oft noch vorbereitende Updates, da Microsoft die Patches normalerweise nur für die jeweils noch unterstützten Update-Stände (kumulative Updates, CUs) bereitstellt. Das sind aktuell CU 7/8 für Exchange 2019, CU 18/19 für Exchange 2016 und CU 23 bei Exchange 2013. Dem eigentlich bereits abgekündigten Exchange 2010 spendiert Microsoft ausnahmsweise auch noch Patches, sofern es sich auf 2010 SP 3 befindet."

 

"Angesichts der Dringlichkeit der Situation hat Microsoft jedoch jetzt auch Security-Patches erstellt, die sich installieren lassen, wenn die aktuellen kumulativen Updates aus irgendwelchen Gründen nicht eingespielt werden können. Details dazu finden sich hier: March 2021 Exchange Server Security Updates for older Cumulative Updates of Exchange Server"

 

aus Artiekl: 

 

https://www.heise.de/news/Exchange-Luecken-BSI-ruft-IT-Bedrohungslage-rot-aus-5075457.html

 

Nun, findet man dazu aber nichts. Der Update Katalog ist auf Stand: 02.03.2021.

 

Siehe hier:

 

http://www.catalog.update.microsoft.com/Search.aspx?q=KB5000871

 

Bringt mir also gar nichts, da dies ja die CU sind. 

 

Wo sind also für den Exchange 2010,13,16 und 19 die passenden  .msp Dateien?

 

 

bearbeitet 9. März 2021 von siberia21
ich ergänze das in einem andren Beitrag.

[NorbertFe 2.034]

vor 45 Minuten schrieb Alith Anar:

Ok, also immer noch der offizielle Stand, wie ich ihn kenne ;)

Dann hier der neue offizielle Stand ;)

https://docs.microsoft.com/en-us/Exchange/plan-and-deploy/supportability-matrix?view=exchserver-2019#microsoft-net-framework

Zitat

If you are upgrading Exchange Server from an unsupported CU to the current CU and no intermediate CUs are available, you should first upgrade to the latest version of .NET that's supported by your version of Exchange Server and then immediately upgrade to the current CU. This method doesn't replace the need to keep your Exchange servers up to date and on the latest supported CU. Microsoft makes no claim that an upgrade failure will not occur using this method, which may result in the need to contact Microsoft Support Services.

 

vor 43 Minuten schrieb siberia21:

Wo sind also für den Exchange 2010,13,16 und 19 die passenden  .msp Dateien?

Liest du die von dir geposteten Links auch? :)

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

 

Runterscrollen bis:

How to get and install the update