Microsoft hat neue Sicherheitsupdates für alle Exchange Server Versionen (2013 – 2019) veröffentlicht. Diesmal handelt es sich um die Schwachstellen, welche beim Pwn2Own 2021 erfolgreich benutzt wurden, um Exchange Server zu attackieren.
Die folgenden Schwachstellen werden behoben:
Hier mal eine Beschreibung von der Pwn2Own Webseite, vermutlich wird genau diese Schwachstelle nun behoben:
The DEVCORE team combined an authentication bypass and a local privilege escalation to complete take over the Exchange server.
Team Viettel successfully demonstrated their code execution on the Exchange server, but some of the bugs they used in their exploit chain had been previously reported in the contest. This counts as a partial win but does get them 7.5 Master of Pwn points.
Qeuelle: https://www.zerodayinitiative.com/blog/2021/4/2/pwn2own-2021-schedule-and-live-results
Die verfügbaren Updates sollten möglichst zeitnah eingespielt werden. Aktuell sind keine aktiven Exploits bekannt, dies kann sich aber bekanntlich schnell ändern, da mit der Verfügbarkeit der Updates auch oft die Schwachstellen an sich öffentlich gemacht werden.
Die Updates finden sich hier:
Hier wird einmal der Update Pfad für die Installation der Mai Updates deutlich:
Außerdem weißt Microsoft explizit darauf hin, dass die manuelle Installation des Updates eine Shell im „Elevated“-Modus („Als Administrator ausführen“) ausgeführt werden muss. Hier einmal ein Beispiel der „Elevated Shell“:
Alternativ kann das Update natürlich auch via WSUS, Windows Update oder anderen Tools installiert werden. Falls das Update der Exchange Server schief geht, finden sich hier übrigens einige mögliche Lösungen für die Probleme:
Auch enthalten die Sicherheitsupdates drei bekannte Probleme, welche in dem Artikel auf dem Exchange Team Blog beschrieben sind:
Das nächste CU, welches diese Updates enthalten wird, wird im Juni 2021 erwartet.
Hallo Zusammen!
Seit diesem Update (möglich auch durch das CU vorher) kommen unsere Clients bei dem externen Zugriff per Outlook ein Anmeldefenster angezeigt.
Die Mails werden auch bei Abbruch einwandfrei synchronisiert.
Es nervt alle extrem.
Ist da etwas bekannt, dass Änderungen mit diesem durchgeführt wurden?
VG
Den Mai Patch die letzten Tage, problemlos auf unseren beiden EX 2016 CU20 Servern installiert.
Auf einem der beiden Server, war ein Max Attachment Size Limit (für active Sync) interessant, nicht korrekt gesetzt.
Ob dieser Wert aber vom letzten CU20 schon „zurückgesetzt“ wurde oder von diesem Sec.Patch kann ich nicht sagen..
mit ner CMD als Admin, sind die ActiveSync WErte schnell gesetzt:
%windir%\system32\inetsrv\appcmd.exe set config „Default Web Site/Microsoft-Server-ActiveSync/“ -section:system.webServer/security/requestFiltering /requestLimits.maxAllowedContentLength:41838182
%windir%\system32\inetsrv\appcmd.exe set config „Default Web Site/Microsoft-Server-ActiveSync/“ -section:system.web/httpRuntime /maxRequestLength:40960
%windir%\system32\inetsrv\appcmd.exe set config „Exchange Back End/Microsoft-Server-ActiveSync/“ -section:system.webServer/security/requestFiltering /requestLimits.maxAllowedContentLength:41838182
%windir%\system32\inetsrv\appcmd.exe set config „Exchange Back End/Microsoft-Server-ActiveSync/“ -section:system.web/httpRuntime /maxRequestLength:40960
%windir%\system32\inetsrv\appcmd.exe set config „Exchange Back End/Microsoft-Server-ActiveSync/“ -section:appSettings /[key=’MaxDocumentDataSize‘].value:41838182
Hallo,
hatte jemand von euch Probleme mit pop3 nach dem Einspielen des Updates. Das Update ist auf einem Exchange 2013 fehlerfrei durchgelaufen . Jetzt kann sich aber ein Pop3 Client nicht mehr mit dem gepatchten Server verbinden. Die POP3 Dienste laufen bei mir. Compnentstate vom PopProxy ist „active“
Gruß
Anton
bei mir hat sich das Problem erledigt. Da war ein Konfigfehler in den POP-Settings. Das hatte mit dem Update nichts zu tun.
Exchange 2016 mit CU 19 bringt Fehler beim Einspielen von KB50003435. Berechtigungen sind da. Error writing to file D:\EX16HL\bin\Microsoft.Exchange.Search.OperatorSchema.dll. Verify that you have access to that directory.
Wie hast du die Installation versucht? Elevated Shell
Naja exchange 2003 war halt noch etwas anders. Seitdem waren rup oder cus oder Security Updates eigentlich immer kumulativ. Zumindest hab ich das so im Hinterkopf. Im Zweifel immer im entsprechenden kb Artikel nachschauen.
Hallo,
eine Frage in die Runde: Schließt das Mai-Update auch die Lücken aus dem April-Update, oder müssen zwingend beide Patches nacheinander eingespielt werden (für Server die noch kein April-Update bekommen haben)?
Viele Grüße
Welches Update genau meinst du? Wenn es um Sicherheitsupdates geht, dann musst du alle nach und nach installieren oder auf das nächste Exchange CU warten. Sicherheitsupdates sind nicht kumulativ.
Gruß
Nein muss er nicht. Steht auch im Kb Artikel, wenn man ihn liest:
Dieses Sicherheitsupdate ersetzt die folgenden zuvor veröffentlichten Updates:
Hinweise zum Sicherheitsupdate für Microsoft Exchange Server 2019, 2016 und 2013: 13. April 2021 (KB5001779)
Hallo Carsten,
es ging um KB5001779 (April) und KB5003435 (Mai). Ich hatte es schon so im Verdacht, dass Sicherheitsupdates nicht kumulativ sind. Vielen Dank für die schnelle Antwort!
Beachte dazu den Kommentar von NorbertFe. Anscheinend sind die nicht kumulativen Sicheitsupdates doch kumulativ. Früher war das nicht so. Irgendwie hängt das immer noch so fest im Hinterkopf fest :D
Exchange Update und Server CU lief problemlos durch. Server 2016, Exchange 2016.
Gruß
Update in/auf 2013 DAG installiert. Alles ok.
Grüße und danke für eure Infos!
Update auf EX2013 CU23 Problemlos installiert. OWA, Mailversand und Empfang funktionieren.
Patch mittels Windows Update eingespielt.
EXServer 2016 CU 19
Nach Serverneustart: OWA, EAC Problemlos.
Info am Rande:
Bekam, wie auch schon beim letzten Update ziemlich am Anfang und nochmal gegen Ende der Installation eine Visual Studio Just-In-Time debugger Meldung:
An unhandled Microsoft .net Framework Exception occured in w3wp.exe
Hab dann bei do you want to debug using the selected debuger auf no geklickt.
Version ist jetzt: 15.01.2176.014
schaut gut aus :)
ich mach jetzt Feierabend. Drücke jenen die Daumen, die da draußen noch werkeln bzw. überlegen ob sie einspielen sollen und andererseits zittern, dass sie nicht durch die Sicherheitslücke kompromittiert werden.
Schätze mal vorsichtig in einem Monat patchen wir wieder (restliche Pwn2Own 2021 CVE’s).
Fingers crossed.
Hang on…
Nächsten Monat gibts vermutlich neue cus. ;)
EX2016 mit CU20 Patch ca. 15 Minuten eingespielt. Keine Probleme bis jetzt.
Ist es normal, dass die AdminDisplayVersion nicht steigt?
Get-ExchangeServer | fl AdminDisplayVersion
AdminDisplayVersion : Version 15.1 (Build 2176.2)
Nach dem Update und nach einem Neustart bei beiden Servern. Alle Patches wurden jedoch immer eingespielt. Laut MS soll die Version ja steigen.
Ja ist normal,
Die AdminDisplayVersion wird nur bei einem CU erhöht.
get-command exsetup.exe | foreach {$_.fileversioninfo}
Noch als Hinweis…es wurden nicht alle Exchange Lücken vom Pwn2Own Event geschlossen. :-(
Hallo zusammen,
nach erfolgreicher Installation auf Exchange 2016 CU20 wurde wie gewünscht der Neustart des Servers eingeleitet.
Der Neustart hängt nun bereits 1 Stunden beim Herunterfahren „Windows wird vorbereitet / Schalten Sie den Computer nicht aus“. Jemand ein ähnliches Problem bzw. einen Tipp wie lange hier gewartet werden sollte oder was der nächste Schritt wäre.
Hallo Christian,
ich könnte mir gut vorstellen, dass du hier in ein anderes Messer gelaufen bist.
Les dir mal https://www.tech-faq.net/windows-wird-vorbereitet-schalten-sie-den-computer-nicht-aus/ durch.
Ciao Thomas
Moin Thomas und Christian,
den Fehler hatte ich in der letzten Zeit auch gleich 2 mal. Einfach nach dem Link vorgehen, den Thomas da schon gepostet hat. Funktioniert tadellos.
Gruß,
Edmund
Danke für den Tipp – soeben auch o.a. Anleitung benutzt, allerdings ist dort ein kleiner Fehler drin – das Kommando für die entfernte Shell muss nämlich
psexec64.exe \\Computername cmd
lauten (es fehlt ein \)
Hallo Christian,
hatte ich grade auch (manuell via elevated cmd von Exchenge 2016 CU20). Aber Geduld zahlt sich aus – nach ca. 90 Minuten konnte ich mich ohne weitere Aktion meinerseits wieder am System anmelden!
Außerdem liefen die Exchange Services im Hintergrund offensichtlich, ich konnte zumindest E-Mails versenden und empfangen…
Langsam wird es nervig, jeden Monat die Exchange updates, als würde Microsoft damit EXO schmackhaft machen…
Win2019,e2019cu9 keine Probleme mIt den updates.
Danke an Frank
Echt? Muss man was tun für sein Geld? ;)
Teile und Herrsche!
Ich glaube nicht, dass es darum geht etwas für sein Geld zu tun, sondern die Unsicherheit das mal wieder ein Scheunentor offen steht und das schnell geschlossen werden muss obwohl man dafür selber nichts kann.
Und wenn man Pech hat wie bei Hafnium, da sind die Angreifer schon drin bevor überhaupt der Patch da ist…
Und das geht dir mit anderen Produkten die ggf. exponiert zum I-net stehen anders? Router/Firewalls/Webserver usw. brauchen auch alle entsprechende Updates und bekommen die teilweise auch in kürzeren Abständen. Und der Zeitfaktor pro Update, den ignoriere ich jetzt einfach mal, denn ich denke das ist u.a. der Komplexität von Exchange geschuldet. ;)
@NorbertFE:
wenn ich ehrlich bin, dann geht es mir mit anderen Produkten die zum Internet exponiert sind in der Tat anders… lange ist es her, dass ich in einer Firewall oder einen Webserver „Authentification Bypass“ Schwachstellen hatte. Und wenn dann ist eben das System kontaminiert. aber ich muss nicht gleich um das ganze Windows Netzwerk zittern.
Was bei Exchange ein Graus ist, weil wenn du System Rechte auf den Server bekommst, dann kann der Angreifer sehr schnell Richtung Domain Controller gehen.
Die einzige Möglichkeit diese Schwachstellen bei Exchange zu vermeiden wäre ein reverse Proxy mit Authentifizierung davor. Aber das ist eher großen Firmen vorenthalten und selbst die öffnen dann andere Breitseiten (Siehe Citrix neulich).
In meinen Augen ist der Sicherheitsstandard bei Exchange nicht da wo er sein sollte, gemessen an dessen Einfluss in ein Windows Netzwerk.
Ich rede auch gar nicht erst davon den Exchange direkt ins Netz zu stellen, weil das ist dann Harakiri… aber selbst mit einer WAF davor bis du nicht vor „Authentification Bypass“ geschützt. Hafnium hat es eindrucksvoll bewiesen.
Der Zeitfaktor für die Updates ist übrigens auch ein Problem. Patchen eines unserer Exchange Server mit dem aktuellen Patch hat gut eine Stunde gedauert mit der ganzen Prozedur (Runterfahren, hochfahren, Installieren und so weiter). Wohlgemerkt es lief alles glatt, also Best Case Szenario.
Patchen eines Linux Mail Server bei uns dauert sonst meist 10 bis 15 Minuten.
Und ich glaube nicht, dass es an der Komplexität von Exchange liegt, dass es so lange dauert, sondern eher das die Software einfach schlecht programmiert ist wie das beispielsweise bei SAP Business One der Fall ist. Das merkt man auch daran, dass die Schwachstellen alle Exchange Versionen ab 2013 jedes mal betreffen… das zeigt doch, dass Microsoft keine Anstalten macht sein Produkt sicherheitstechnisch zu verbessern. Die Absicherungen in Exchange sind wohl auf Stand 2010 stecken geblieben… dummerweise aber die Welt nicht und besonders die IT Entwicklung nicht.
In meinen Augen hat sich seit einem Jahr gezeigt, dass Exchange für On Premise viel zu unsicher geworden ist. Der notwendige Aufwand um es abzusichern verteuert eine lokale Installation so sehr, dass es kaum noch Sinn macht wenn man nicht mehrere Hunderte oder Tausende Postfächer hat.
Ich lasse mich aber gerne eines besseren belehren :)
Liegt wohl eher daran, dass jetzt ein vermehrtes Augenmerk auf Exchange gelegt worden ist und nun nach und nach raus-kommt wie schlecht die Sicherheitsvorkehrungen von Microsoft in Exchange ab 2013 umgesetzt worden sind.
Man darf nicht vergessen, dass die Lücken immer für Exchange 2013, 2016 und 2019 gelten… das sind Lücken die Schlüsselkomponenten betreffen und da hat Microsoft ordentlich versäumt es abzusichern.
Microsoft legt aber auch keine Anstalten an den Tag die Probleme konsequent anzugehen. Die sind bei ihrem Cloud Modell und das was vorher war, davon wollen die nichts mehr wissen.
Ich warte jetzt geduldig bis der erste sichtbare Breach der Exchange Online Cloud kommt… dürfte nicht mehr allzu lange dauern… wenn man sieht das nach jedem Azure Update in der Cloud Exchange Online mal wieder down ist.
Vorteil bei der Cloud dürfte dann aber sein, das man selbst aus dem Schneider ist… wird der Firma selber nicht helfen die betroffen ist, aber zumindest der Itler muss nicht mehr für die Fehler von Microsoft geradestehen ;)
Naja, ist sicherlich vom Ziel her eben auch deutlich interessanter einen Exchange zu hacken (mit allem was dann intern mit umfällt und anfällt), als nen doofen Webserver. ;) Aber ich würde sagen man muss bei Cisco und Konsorten nicht lange suchen, um in der jüngeren Vergangenheit entsprechende Sicherheitslücken zu finden. Ich weiß, man muss ja kein Cisco verwenden, sondern Produkt XYZ hat nie und wenn dann nie so gravierende Lücken.
Ja Hafnium war übel, eben weil dagegen nichts geholfen hätte, außer „nicht im Internet“ stehen. Das Thema Reverse Proxy sehe ich nicht nur bei großen Firmen. Im Allgemeinen ist auch bei kleineren Firmen heutzutage eine halbwegs aktuelle Firewall dazu in der Lage (Hat Frank hier ja ausreichend gut mit der Sophos UTM beschrieben). Und wer heute noch ohne Firewall als FIrma im Netz hängt… sollte keinen Exchange haben. Ich sehe das auch so wie du, dass Exchange Security nicht da ist, wo sie sein sollte, aber damit wird man sich erstmal abfinden müssen, wenn man nicht in die Cloud will und aus welchen Gründen auch immer bei Exchange bleiben will oder muss.
Das Zeitthema sehe ich ehrlich gesagt nicht so wie du. Wenns zu lange dauert, dann ist es wohl nicht wichtig genug um entsprechende Redundanzen vorzuhalten. In meinen Augen ne ganz klare Ansage. :) Und ja, meine Linuxbasierten Systeme sind „im Allgemeinen“ schneller gepatcht, aber wem hilft das? ;)
Bye
Norbert
Moin,
also Cisco würde ich nie einsetzen wollen. Habe damals vor 15 Jahren schon schlechte Erfahrung gemacht und seitdem der Support in Indien ist kann man es komplett vergessen.
In meinen Augen liegt das aber auch daran, dass die Geräte immer mehr können sollen… und genau da ist das Problem. Siehe auch die vor kurzen passierten Angriffe auf Qnap Systeme mit Ransomware… nur weil der Hersteller seine Blotware automatisch drauf packt und diese dummerweise festen Administratorzugang hatten.
Hafnium war eine Schachpartie wo man mit 8 Zügen im Rückstand war… wie gesagt die einzige Möglichkeit es zu verhindern wäre gewesen Sicherheitssystem von mehreren 10.000 € vor Ort zu haben… welcher Mittelständler leistet sich Falcon Complete oder Reverse Proxy mit vor Auth? Keiner, weil das zuviel kostet laut denen… und dann müssen wir im Nachhinein die Scherben fegen…
Natürlich ist es interessant einen Exchange Server zu hacken… welcher Server macht das Tor in der Firma soweit auf wie ein Exchange Server? keiner. Und gerade deshalb sollte Microsoft in die Verantwortung genommen werden, weil deren Vorgehen ist ja schon als Grob fahrlässig anzusehen.
Das Problem ist ja, dass eine Firewall bei Exchange kaum was bringt… Die Sicherheitslücken sind im Exchange und die kann die Firewall nicht schützen außer wie von die erwähnt „nicht im Internet“ stehen. Wir haben die Sophos UTM und die finde ich ganz OK. Aber die konnte nichts gegen die Angriffe ausrichten. Wie den auch? Die Schwachstellen die Exchange hatte waren nicht mit einer üblichen Firewall zu schützen…
Wir haben mittlerweile alles bis auf Active Sync / Autodiscover / Mapi / Api von außen gesperrt. Weder RPC, noch OWA, noch ECP oder UM sind von außen erreichbar. UM haben wir mittlerweile ganz deaktiviert weil wir es nicht nutzen und es in den letzten Hacks eines der größten Einfallstore war.
Was die Zeit bei Updates angeht… da muss ich dir widersprechen… die Exchange Server hier haben die dicksten Ressourcen in der ganzen Firma… jeder Server hat 10 Xeon Kerne und 64 GB Ram sowie PCI Express SSD DC von Intel… bei wohlgemerkt um die 35 Postfächer… Im Betrieb liegt die Last bei so 8-9%… aber sobald Updates gemacht werden, dann kann die Last auf bis 100% steigen… und da sieht man ganz deutlich, dass da was an der Software nicht stimmt. Es dauert einfach lange eine Server zu patchen… ich habe etliche Windows Server hier… die sind in 20 Sekunden oben… nur die Exchange nicht, die brauchen so 5-10 Minuten bis die voll hochgefahren sind und alle Dienste stabil sind. Dabei liegt die Last dann nicht mal bei 20% während des Startvorgangs.
Redundanz ist ja vorhanden… warum haben wir wohl den DAG… gerade weil das Patchen so problematisch ist.
Unsere Linux Server begnügen sich mit weitaus weniger Ressourcen und nutzen diese auch wirklich aus.
vg
Alex
KB5003435 auf Exchange 2016 CU20 DAG manuell über CMD mit erhöhten Rechten eingespielt. Keine Probleme festgestellt bis jetzt.
VG
Alex
Moin moin,
auch hier das KB5003435 zusammen mit KB5003171 auf Exchange 2019 mit CU9 problemlos über Windows Update installiert. Nach Neustart und Tests schaut alles gut aus.
Viele Grüße
Daniel
Moin zusammen,
ich habe gerade das KB5003435 auf unseren Exchange-2016, CU19 ohne Probleme installiert.
Nach Serverneustart: Outlook-2016, OWA, EAC bisher keine Probleme.
Grüße
Roland
Bei mir auch so.
Das manuelle Update steht genau wie im Beispielbild für die elevated shell oben, nur der Button cancel ist aktiv?
Nach 10 Minuten ging es weiter…
Dauert gefühlt trotzdem ewig .
Ja, und? Das ist doch nun wirklich jedesmal so. ;) Bisschen Geduld und dann gehts weiter.
Ich hab probleme mit dem juni update bekomme die Meldung
Beim Installieren von Updates sind Probleme aufgetreten. Wir versuchen es allerdings später noch einmal. Falls dieser Fehler weiterhin auftritt und Sie Informationen im Web suchen oder sich an den Support wenden möchten, kann dieser Fehlercode hilfreich sein: (0x800f081f). Habs jetzt mehrfach versucht zu installieren aber immer wieder das gleiche.
Nervt einfach nur
Bisher bekomme ich noch kein einziges Update per WSUS. Bei anderen auch der Fall?