Kritisches Update für SigRed Bug im Windows DNS Server

[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)

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


Anzeige

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)


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit, Update, Windows Server abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

15 Antworten zu Kritisches Update für SigRed Bug im Windows DNS Server

  1. Juergen S. sagt:

    Patches installiert, bin mal gespannt, welche Auswirkungen dies haben wird :-D

    1.6gb (WinServer2016)…

  2. Guido sagt:

    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?

    • Robert Richter sagt:

      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!

  3. U. Strübing sagt:

    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!!!

    • Günter Born sagt:

      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.

  4. JC sagt:

    Muss im DWORD-Wert 0xFF00 oder FF00 eingetragen werden?

    Dank für Eure Angaben

    • Günter Born sagt:

      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.

    • Robert Richter sagt:

      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

  5. RA sagt:

    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

Schreibe einen Kommentar zu Günter Born Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.