[English]Im Code des Windows DNS Server existiert seit 17 Jahren ein Bug, der zu einer kritischen Schwachstelle führt. Die per Wurm ausnutzbare Schwachstelle könnte ausgenutzt werden, um Domain-Administrator-Privilegien zu erlangen und die gesamte dahinter liegende Unternehmensinfrastruktur zu gefährden.
Anzeige
Ich habe die Information bereits gestern Abend von Check Point, aber unter Embargo, erhalten, komme daher erst jetzt dazu, die Details zu publizieren. Sicherheitsforscher von Check Point Software Technologies sind auf eine Schwachstelle gestoßen, die seit 17 Jahre unentdeckt geblieben war. Die SIGRed genannte Schwachstelle ist so gefährlich, dass Microsoft der Behebung die höchstmögliche Priorität einräumte. Alle Windows-Server-Betriebssysteme seit 2003 sind betroffen. Ein Patch steht bereit. Außerdem existiert ein temporärer Workaround.
Kritische Schwachstelle SIGRed (CVE-2020-1350)
In ihrem Blog-Beitrag beschreiben die Sicherheitsforscher von Check Point Software Technologies die Schwachstelle SIGRed (CVE-2020-1350) bei der Remotecodeausführung in Windows-Domänennamenssystem-Servern. Die Schwachstelle basiert auf dem Bug, dass Anfragen nicht ordnungsgemäß verarbeitet werden. Das Ganze ist auch als "Windows DNS Server Remote Code Execution Vulnerability" bekannt.
SIGRed (CVE-2020-1350) ist eine wurmfähige, kritische Schwachstelle, der ein CVSS-Basiswert von 10,0 zugewiesen wurde. Die Schwachstelle befindet sich im Windows DNS-Server, und betrifft die Windows Server-Versionen 2003 bis 2019. Durch die Schwachstelle kann eine böswillige DNS-Antwort ausgelöst werden. Da der betreffende Dienst mit erhöhten Privilegien (SYSTEM) ausgeführt wird, erhält ein Angreifer bei erfolgreicher Ausnutzung die Rechte eines Domänenadministrators. Dadurch wird die gesamte Unternehmensinfrastruktur effektiv gefährdet.
(Quelle: YouTube)
Anzeige
Durch das Senden einer DNS-Antwort, die einen großen (mehr als 64 KB) SIG-Eintrag enthält, können Angreifer einen kontrollierten Heap-basierten Pufferüberlauf von etwa 64 KB verursachen und so Schadcode zur Ausführung bringen. Check Point Software Technologies demonstriert das Ganze in obigem YouTube-Video, und legt in ihrem Blog-Beitrag die Details offen.
Das Domain Name System (DNS) ist quasi das 'Telefonbuch des Internet' und ermöglicht Clients sich mit Servern zu verbinden, um auf Ressourcen zuzugreifen. Es ist ein Modell, das Domänennamen auf IP-Adressen abbildet, um eine Verbindung zum richtigen Server zu ermöglichen. Wird diese Zuordnung manipuliert, gerät das ganze Konzept in eine sicherheitstechnische Schieflage.
Microsoft stellt Patch und Workaround bereit
Microsoft hat diese Kurzmitteilung zur Schwachstelle veröffentlicht und führt Details im Beitrag zu CVE-2020-1350 aus. Dort werden die kritischen Updates für Windows Server 2008 SP2 bis hin zu Windows Server Version 2004 (Server Core-Installation) aufgelistet. Der Bug wird mit den regulären Updates für Windows zum Patchday 14. Juli 2020 beseitigt.
Falls ein Patch nicht sofort installiert werden kann, gibt Microsoft im Supportbeitrag KB4569509 noch weitere Hinweise, wie die Schwachstelle durch einen Workaround zumindest abgemildert werden kann. Dazu ist in der Registry der Schlüssel:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters
mit dem 32-Bit-DWORD Wert TcpReceivePacketSize = 0xFF00 einzutragen. Hier noch einige Werte:
- Der Standardwert (auch max.) = 0xFFFF
- Der empfohlene Wert = 0xFF00 (255 Bytes weniger als das Maximum)
Sie müssen den DNS-Dienst neu starten, damit die Registrierungsänderung wirksam wird. Da es hier im Blog bereits nachgefragt wurde: TCP-basierte DNS-Antwortpakete, die den empfohlenen Wert überschreiten, werden ohne Fehler verworfen. Das könnte dazu führen, dass einige Anfragen nicht beantwortet werden, und es zu einem unvorhergesehenen Ausfall kommt. Ein DNS-Server wird von diesem Workaround aber nur dann negativ beeinflusst, wenn er gültige TCP-Antworten erhält, die größer sind als im Workaround definiert (über 65.280 Byte). Details sind dem Artikel hier samt FAQ zu entnehmen.
Ähnliche Artikel:
Microsoft Office Patchday (7. Juli 2020)
Microsoft Security Update Summary (14. Juli 2020)
Patchday: Windows 10-Updates (14. Juli 2020)
Anzeige
Patches installiert, bin mal gespannt, welche Auswirkungen dies haben wird :-D
1.6gb (WinServer2016)…
Würde den Patch gern auf einem Win 2008 R2 (ja leider) installieren aber er meckert dass der Windows Module Installer aktualisiert werden muss…allerdings ist der Patch (KB2533552) widerum schon installiert…und da stehste nun….
Hat jemand zufällig das gleiche Problem?
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters
DWORD = TcpReceivePacketSize
Value = 0xFF00
Registry-Eintrag beim 2008 R2 setzen, wie oben auch beschrieben, DNS-Server Dienst neu starten oder reboot machen -> FERTIG!
Das ist ja nur der Workaround, der es letztendlich nicht komplett behebt (nach meinem Verständnis)
Habe nun gefunden dass man KB4565354 benutzen soll, damit hat es dann auch geklappt.
Danke trotzdem :-)
Bist Du mit Deinem Server im ESU-Programm, oder geht der Patch ohne ESU?
Ohne ESU wird nichts laufen.
Moin zusammen!
Mal prinzipiell gefragt: Wie warscheinlich ist eine Beeinträchtigung durch Anwenden des Work-Around-Reg.Patches? Welche realen Szenarien einer Beeinträchtigung sind denkbar?
Bei der Gelegenheit: Ein allervorzüglichstes Dankeschön lieber Günter, für Deine allzeit interessanten und wertvollen Informationen!!!
Nicht wissen, sondern aus dem Bauch heraus: Wenn irgendwo eine Stelle Datenpakete größerer Länge senden würde, schneidet man mit dem Registry-Wert deren Kommunikation ab. Ob das zutrifft, kann ich nicht beurteilen. Beim Patch hat man dagegen die Bufferlängenüberprüfung auf einen Überlauf implementiert. Dann wird das gehandhabt, was bis dahin an Paketlängen verarbeitet werden konnte.
Muss im DWORD-Wert 0xFF00 oder FF00 eingetragen werden?
Dank für Eure Angaben
0xFF00 ist das, was der Registrierungseditor will.
Korrektur: Du gibst FF00 im Dialogfeld 'Binärwert ..' ein (Option 'Hexadezimal' angewählt) – angezeigt wird 0x0000ff00. Ein 0x lässt sich im Dialogfeld nicht eintippen.
hatte auch erst 0xFF00 drinen, da kam bei mir ein anderer Wert.
In eine Text-Datei kopieren, .reg Endung vergeben, Doppelclick, DNS-Dienst neu starten oder reboot, fertig! :)
ach ja, die Anführungszeichen, wenn man von der WebSite kopiert, vorher checken, dass sie den normalen (Shift+2) entsprechen.
————————
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\DNS\Parameters]
"TcpReceivePacketSize"=dword:0000ff00
Moin,
nachdem ich den DWord Eintrag TcpReceivePacketSize erstellt habe und den Wert 0xFF00 eingegeben und mit OK bestätigt habe, wird der Wert aber anders angezeigt.
Value data:
41ff00
und bei Data
0x0041ff00 (4325120)
Ist das Korrekt?
Danke für Antworten.
Grüße
Roland
Gebe im Regedit.exe FF00 ein – siehe meinen Nachtrag oben (getestet unter Win 7).
Danke.