Reaktion auf Microsoft Exchange 0-Day-Angriff

Am 6. März hat Microsoft öf­fent­lich auf Schwach­stel­len in der Microsoft-Exchange-Software hin­ge­wie­sen. IONOS wusste bereits am 3. März um den möglichen An­griffs­punkt und hat sofort damit begonnen, die von Microsoft be­reit­ge­stell­ten Updates auf alle selbst be­trie­be­nen Exchange-Systeme auf­zu­spie­len, um so die Feh­ler­quel­le aus­zu­schal­ten. Die Systeme von IONOS waren deshalb nicht von der An­griffs­wel­le betroffen.

In diesem Interview mit dem Lead Exchange Engineer John Barnes klären wir die wich­tigs­ten Fragen zu dem Thema.

Wir haben bereits am 3. März früh­mor­gens von der Schwach­stel­le erfahren und sofort mit einer Aus­wer­tung begonnen: Welche Server müssen gepatcht werden? Dann haben wir die Arbeit auf das Team auf­ge­teilt, um den Patch-Prozess zu be­schleu­ni­gen.

Wir wussten direkt, dass dieses Update sehr wichtig ist, weil es untypisch von Microsoft ist, Patches abseits vom Mo­nats­rhyth­mus zu ver­öf­fent­li­chen. Sobald wir uns mit den Details der Schwach­stel­len be­schäf­tig­ten und die tech­ni­schen Aus­wir­kun­gen ver­stan­den, wurde klar, dass dieser Patch so schnell wie möglich durch­ge­führt werden musste.

Unsere Platt­for­men sind mit hoher Redundanz aus­ge­stat­tet. In Si­tua­tio­nen wie dieser können wir deshalb die Platt­for­men während der Ge­schäfts­zei­ten patchen, ohne dass Kunden Einbußen im Service fest­stel­len. Wo es möglich ist, ist der Patch-Prozess zudem au­to­ma­ti­siert. Ein großer Teil unserer Server hatte den Patch daher schon vor dem Beginn des Tages in­stal­liert.

Um die anderen Teile der Plattform haben wir uns schritt­wei­se gekümmert und dabei die Ar­beits­last zwischen den Servern hin und her bewegt, um Ser­vice­un­ter­bre­chun­gen zu vermeiden. Das hat am Mittwoch den größten Teil des Tages in Anspruch genommen. Die Teile, die wir als am ge­fähr­dets­ten ansehen, haben wir prio­ri­siert. Wir haben auch mit be­son­de­rer Auf­merk­sam­keit nach ver­däch­ti­gen Ak­ti­vi­tä­ten auf der Plattform Ausschau gehalten.

Während die Patching-Arbeit lief, nahmen wir außerdem an einer Kon­fe­renz­schal­tung mit Microsoft bezüglich des Updates teil. Und wir haben uns mit dem IONOS-Si­cher­heits­team ab­ge­spro­chen, um si­cher­zu­stel­len, dass die In­for­ma­tio­nen im gesamten Un­ter­neh­men verteilt wurden. Beim Telefonat mit Microsoft war besonders hilfreich zu erfahren, dass der Schwer­punkt im Moment auf dem Patchen lag und nicht auf dem Versuch, den Exploit auf andere Weise zu ent­schär­fen.

Sobald der Patching-Prozess ab­ge­schlos­sen war, kon­zen­trier­ten wir uns auf die Suche nach An­halts­punk­ten für eine Kom­pro­mit­tie­rung (In­di­ca­tors of Com­pro­mi­se). Dies ist ein lang­wie­ri­ger Prozess, da unsere Platt­for­men sehr um­fang­reich sind und wir mit größter Sorgfalt vorgehen. Deshalb hat das Scannen mehrere Tage gedauert.

Nummer eins sollte auf jeden Fall sein, die Schwach­stel­len so schnell wie möglich zu patchen. Bei ge­schäfts­kri­ti­schen Systemen wie etwa E-Mail kann dies manchmal schwierig sein. Wenn die Schwach­stel­len sehr großen Schaden ver­ur­sa­chen können, muss man auch darüber nach­den­ken, das System kurz­zei­tig ab­zu­schal­ten, um den Patch schneller in­stal­lie­ren zu können.

Als Hosting-Anbieter sind wir darauf vor­be­rei­tet, bei solchen Vorfällen schnell und ent­schie­den zu reagieren. Da wir uns tag­täg­lich damit befassen, haben wir Kontakte und In­for­ma­ti­ons­quel­len, durch die wir sehr schnell Bescheid wissen – meist schon bevor die Öf­fent­lich­keit in­for­miert wird.

Unsere Prozesse sind in hohem Maße au­to­ma­ti­siert und verwaltet, weshalb wir in kürzester Zeit reagieren können. Wir un­ter­hal­ten weltweit Platt­for­men mit Geo-Redundanz. Das bedeutet, dass wir Updates auf­spie­len können, ohne dass Leis­tungs­ein­schrän­kun­gen wahr­nehm­bar wären. Als Hoster bieten wir bereits seit 2010 Hosted-Exchange-Platt­for­men an und haben deshalb, abgesehen von Microsoft selbst, kon­kur­renz­lo­se Erfahrung auf dem Gebiet. Uns ist klar, dass solche Si­tua­tio­nen eintreten können – wichtig ist, wie man darauf reagiert.

Ich glaube, besonders kleinere Un­ter­neh­men, die eigene Exchange Server „On Premises“, also vor Ort, betreiben, sind einem hohen Risiko aus­ge­setzt. Diese Nutzer haben oft nicht die nötigen Res­sour­cen, bei den vier­tel­jähr­li­chen Cu­mu­la­ti­ve Updates von Microsoft up to date zu bleiben.

Als Microsoft das neue Update ver­öf­fent­licht hat, war dieses zunächst nur für die beiden letzten Cu­mu­la­ti­ve Updates für jede Version von Exchange verfügbar. Un­ter­neh­men, die hier nicht auf dem neuesten Stand waren, mussten also erst das neueste Cu­mu­la­ti­ve Update in­stal­lie­ren, bevor sie die Schwach­stel­le beheben konnten. Dies kann ein we­sent­lich auf­wen­di­ge­rer Prozess sein, als nur ein Si­cher­heits­up­date für Exchange zu in­stal­lie­ren, und dauert deutlich länger, was wiederum die An­fäl­lig­keit des Un­ter­neh­mens für diese Si­cher­heits­lü­cke erhöht.

Für diese spe­zi­fi­sche Si­cher­heits­lü­cke: Microsoft selbst empfiehlt den He­alth­Che­cker, um den Patch-Level des eigenen Servers her­aus­zu­fin­den und bestimmen zu können, ob der Server ein Update braucht. Es kann es sein, dass über Microsoft Update nicht er­sicht­lich ist, dass Sie ein aus­ste­hen­des Update haben, wenn Ihre Exchange Server nicht auf das neueste Cu­mu­la­ti­ve Update gepatcht sind. Test-Pro­xy­Lo­gon ist ein Script von Microsoft, dass dabei hilft, Anzeichen einer Ge­fähr­dung zu iden­ti­fi­zie­ren.

Ansonsten finde ich den Nessus Vul­nerabi­li­ty Scanner besonders effektiv, wenn es darum geht, Schwach­stel­len und un­ge­patch­te Server zu iden­ti­fi­zie­ren.

Dieser Exploit war besonders fies, ein „Un­au­then­ti­ca­ted Remote Code Execution as System“-Exploit. Diese Si­cher­heits­lü­cke ist besonders ge­fähr­lich, weil Microsoft Exchange Server ty­pi­scher­wei­se hohe Pri­vi­le­gi­en im Active Directory genießen, dem Haupt­me­cha­nis­mus innerhalb von Un­ter­neh­men für Au­then­ti­fi­zie­rung und Au­to­ri­sie­rung in Windows.

Das bedeutet, dass das Risiko für Un­ter­neh­men sehr hoch ist. Es besteht eine große Wahr­schein­lich­keit, dass Un­ter­neh­mens­da­ten gestohlen oder zerstört werden, dass die Funk­ti­ons­fä­hig­keit verloren geht und so weiter. Die möglichen Aus­wir­kun­gen auf das Un­ter­neh­men, wenn ein Angreifer diese Schwach­stel­le er­folg­reich ausnutzen kann, sind kaum zu un­ter­schät­zen.

Ich finde es immer schwierig, bei solchen Si­cher­heits­lü­cken eine de­fi­ni­ti­ve Ent­war­nung zu geben. Wir haben auf Basis der der­zei­ti­gen In­for­ma­tio­nen von Microsoft alles un­ter­sucht und konnten dabei nichts fest­stel­len. Aber ein wirklich ver­sier­ter bös­wil­li­ger Angriff kann es sehr schwierig machen, eine Kom­pro­mit­tie­rung zu erkennen.

Tat­säch­lich ist in­zwi­schen durch ver­schie­de­ne News-Quellen ans Licht gekommen, dass diese Schwach­stel­le bereits Anfang Januar gefunden und an Microsoft gemeldet wurde. Ende Februar, kurz bevor Microsoft den Patch ver­öf­fent­licht hat, wurden weit­läu­fi­ge Angriffe bekannt. Das bedeutet, dass es einen be­trächt­li­chen Zeit­rah­men gibt, in dem die Schwach­stel­le aus­ge­nutzt werden konnte.

Ich gehe davon aus, dass Un­ter­neh­men nun über­den­ken werden, ob sie weiterhin ihr E-Mail-System auf On-Premises-Servern laufen lassen möchten – und die War­tungs­kos­ten gegenüber dem Hosting der ge­schäfts­kri­ti­schen Systeme bei einem ver­trau­ens­wür­di­gen Cloud-Anbieter abwägen.

Weitere In­for­ma­tio­nen:

https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/

https://msrc-blog.microsoft.com/2021/03/02/multiple-security-updates-released-for-exchange-server/

https://msrc-blog.microsoft.com/2021/03/05/microsoft-exchange-server-vul­nerabi­li­ties-mi­ti­ga­ti­ons-march-2021/