Microsoft postet momentan Sicherheitspatches wie Sand am Meer. Vor ein paar Tagen haben wir bereits über einen Zero-Day-Exploit berichtet, dessen Beitrag wir regelmässig an immer wieder neue Updates dazu seitens Microsofts angepasst haben.
Am 11. Oktober veröffentlichte Microsoft nun auch noch zusätzlich ein weiteres Sicherheitsupdate (KB5018410) für Windows 10 als auch ein weiteres für den Exchange Server 2013 / 2016 sowie 2019 (KB5019077).
Bei dem Exchange Oktober 2022 Sicherheitsupdate handelt es sich nicht um einen Fix der Zero-Day Sicherheitslücke, über die wir bereits berichtet haben, sondern es handelt sich vielmehr um ein reguläres Sicherheitsupdate. Auf die Behebung der Zero-Day-Lücke müssen wir noch warten. So lange gilt es den empfohlenen Workaround anzuwenden.
Das Sicherheitsupdate KB5018410 für Windows 10 Clients beinhaltet vorrangig eine Veränderung hinsichtlich TLS. Das seit Jahren als potenziell unsichere TLS 1.0 wird durch das KB5018410 erzwungenermaßen auf Windows 10 Clients deaktiviert. Hierzu haben wir folgende Fragen beantwortet:
Bei welchen Serverversionen ist TLS 1.2 standardmäßig nicht aktiv?
Windows 8.1, Windows Server 2012 R2, Windows 10, Windows Server 2016 und neuere Versionen von Windows unterstützen TLS 1.2 für die Client-Server-Kommunikation über WinHTTP von Haus aus, da es per se bereits als Default aktiviert ist.
Wurde das auf den Serverversionen ggf. durch Updates nachgezogen?
Systemadministratoren, die sich regelmäßig um Updates bemühen, sollten am 14.06.2016 bereits durch das Update KB3140245 für Windows 8 Embedded, Windows Server 2008 R2, Windows Server 2012 sowie Windows 7 ebenfalls als Default TLS 1.1 sowie TLS 1.2 aktiviert haben.
Deswegen kann in den meisten Fällen aufgeatmet werden, da zumindest der Exchange Server bereits TLS 1.2 unterstützt. Wichtig: Kunden, bei denen explizit das Update angehalten wurde oder anderweitig dieses erzwungene Default-Verhalten beeinflussen, müssen ggf. handeln.
Gibt es Handlungsbedarf? Müssen Sie aktiv werden?
Microsoft kommentiert insbesondere für die Best-Practices einer sicheren Serverumgebung seit längerer Zeit, dass TLS 1.0 eine unzureichende Sicherheit darstellt. So ergibt beispielsweise ein «Health-Check» der Exchange Server Organisation häufig die Aussprache einer Empfehlung zur Deaktivierung von TLS 1.1 und TLS 1.0. Dementsprechend ratsam ist es, innerhalb der eigenen zu verantwortenden (Exchange)-Serverlandschaft die Unterstützung von TLS 1.0 und TLS 1.1 zu unterbinden. Für eine Windows-Client-Landschaft darf davon ausgegangen werden, dass dort wo Updates regelmässig bereitgestellt und installiert werden die Unterstützung von TLS 1.2 gegeben ist, sofern hier nichts gegenteilhaftes bspw. durch GPOs konfiguriert wurde, was diese Default-Settings wiederum überschreibt.
Wichtig ist darüber hinaus sicherzustellen, dass im Unternehmen nicht 3rd-Party Anwendungen oder Anwendungsszenarien stattfinden, die weiterhin TLS 1.0 und TLS 1.1 voraussetzen. Etwaige SSL-VPN Konfigurationen sollten hinsichtlich Ihrer TLS-Konfiguration geprüft werden, sofern hierbei nach der Installation des Updates KB5018410 aus dem Oktober Probleme aufgetreten sind. Über entsprechende Probleme bei SSL-VPNs wurde im Blog von Microsoft dazu diskutiert: KB5018410 Breaks SSL VPN – Microsoft Q&A.
Auch die Client-Kommunikation zu Drittanbieter-Mailservern kann beeinflusst sein.
Aktuell vermehren sich in einschlägigen Blogs rund um Microsoft Beiträge zu Problemen bei nicht gegebener Unterstützung von TLS 1.3 durch das Update. Das führt zu Fehlern wie “The connection to the server was interrupted. (0x800CCC0F)”. Zur Problemlösung werden das Pausieren bzw. das De-Installieren des Updates empfohlen, sofern der Server weder TLS 1.2 noch TLS 1.3 supportet. Weiterhin empfehlt Microsoft manuell TLS 1.3 zu deaktivieren oder das Ganze global über Richtlinien für die Clients zu steuern.
Generell empfiehlt es sich sämtliche Konfigurationen zu prüfen, um sicherzustellen, ob der Support durch TLS 1.2 gegeben ist. In dem gleichen Atemzug können Sie auch überprüfen und sicherstellen, dass Sie global überall in Ihrer Servicelandschaft TLS 1.1 sowie TLS 1.0 deaktiviert haben.
Berücksichtigen Sie dabei neben Ihren Exchange-Servern, Windows Servern (Files Servers, DCs etc.) auch Komponenten wie VPNs oder wie im folgenden Beispiel die Konfiguration Ihres Load-Balancers:
In dem hiergezeigten Beispiel handelt es sich um die Default-Werte, die zumindest in der Kemp Version 7.2.57.0.21570 bereits den Best-Practices entsprechen sollten.
Microsoft verweist auf zwei Beiträge:
