15
Aktuelle DNS Lücke in Windows Server
Mahlzeit,
hat jemand den "Workaround" von MS schon auf nem DC getestet?
Hintergrund: https://www.golem.de/news/windows-server-sigred-ist-eine-wurmartige-krit ...
Irgendwie trau ich mich nicht
Gruß,
Ex0r
hat jemand den "Workaround" von MS schon auf nem DC getestet?
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters DWORD = TcpReceivePacketSize Value = 0xFF00Hintergrund: https://www.golem.de/news/windows-server-sigred-ist-eine-wurmartige-krit ...
Irgendwie trau ich mich nicht
Gruß,
Ex0r
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Kommentar vom Moderator tomolpi am 15.07.2020 um 20:46:23 Uhr
Code-Tags hinzugefügt & Titel verfeinert
Content-ID: 587836
Url: https://administrator.de/forum/aktuelle-dns-luecke-in-windows-server-587836.html
Ausgedruckt am: 25.12.2024 um 13:12 Uhr
15 Kommentare
Neuester Kommentar
Hallo,
Irgendwie trau ich mich nicht
Hast Du keine Testumgebung zum Spielen (und Sachen testen, bevor es live geht)?
Ich habe es aber noch nicht getestet.
Irgendwie trau ich mich nicht
Ich habe es aber noch nicht getestet.
Gruß,
Ex0r
tomolpiEx0r
Zitat von @tomolpi:
Hallo,
Irgendwie trau ich mich nicht
Hast Du keine Testumgebung zum Spielen (und Sachen testen, bevor es live geht)?
Hallo,
Irgendwie trau ich mich nicht
negativ
Arbeite aber drann. Vielleicht ab nächstem Jahr 
Fleissig Snapshoten und Backup geht zwar auch irgendwie, nervt aber auf Dauer, jup.
hat jemand den "Workaround" von MS schon auf nem DC getestet?
Ja, hilft auf jeden Fall gegen den Exploit, mit ner Test-Payload gerade mal mit und ohne Setting getestet.Die Einstellung bewirkt ja nur das einzelne TCP DNS Anfragen auf max. 65kbytes begrenzt werden damit die malformed packets vom Dienst ja schon gar nicht mehr angenommen werden.
1
Ich habe eben auf dem Testsystem und nach kurzen tests auf allen Produktiven DCs den patch installiert. Bisher gibt's noch keinen Brand
Aber lieber irgendwelche obskuren DNS Probleme haben als viele Domänenadmins
Aber lieber irgendwelche obskuren DNS Probleme haben als viele Domänenadmins
Hallo Ex0r
Ich habe den Workaround heute früh auf meinen drei DCs (2012 R2) angewendet.
(HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters DWORD = TcpReceivePacketSize Value = 0xFF00)
Bislang keine Probleme. Das Tagesgeschäft läuft wie zuvor.
Grüsse
Marc
Ich habe den Workaround heute früh auf meinen drei DCs (2012 R2) angewendet.
(HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters DWORD = TcpReceivePacketSize Value = 0xFF00)
Bislang keine Probleme. Das Tagesgeschäft läuft wie zuvor.
Grüsse
Marc
1
Hallo, Patch heute früh in der Testumgebung eingespielt und getestet, keinerlei Probleme.
Danach auf 4 produktiven DCs in Betrieb genommen. Bisher läuft alles rund. 👍🏻
Grüße
maxblank
Danach auf 4 produktiven DCs in Betrieb genommen. Bisher läuft alles rund. 👍🏻
Grüße
maxblank
1Zitat von @maxblank:
Hallo, Patch heute früh in der Testumgebung eingespielt und getestet, keinerlei Probleme.
Danach auf 4 produktiven DCs in Betrieb genommen. Bisher läuft alles rund. 👍🏻
Ich habe eben im Lab und danach auch live nachgezogen, ich schließe mich meine Vorrednern an, keine Probleme.Hallo, Patch heute früh in der Testumgebung eingespielt und getestet, keinerlei Probleme.
Danach auf 4 produktiven DCs in Betrieb genommen. Bisher läuft alles rund. 👍🏻
Grüße
maxblank
tomolpimaxblank
1
Moin,
gestern nachmittags im Officebetrieb den Workaround gleich "live" am DC eingetragen und bislang keine Beschwerden von Kollegen, dass etwas nicht mehr funktioniert!
Der Patch ist inzwischen auch schon installiert und bislang ebenfalls keine Probleme festgestellt.
Gruß
gestern nachmittags im Officebetrieb den Workaround gleich "live" am DC eingetragen und bislang keine Beschwerden von Kollegen, dass etwas nicht mehr funktioniert!
Der Patch ist inzwischen auch schon installiert und bislang ebenfalls keine Probleme festgestellt.
Gruß
Wenn man sich die beschreibung des gesamten exploits anschaut:
https://research.checkpoint.com/2020/resolving-your-way-into-domain-admi ...
sind ja etliche sachen die zusammengechained werden müssen, spannende sache
https://research.checkpoint.com/2020/resolving-your-way-into-domain-admi ...
sind ja etliche sachen die zusammengechained werden müssen, spannende sache
1
Habe den Fix jetzt auch erst mal angewendet, da es nochwas dauert bis zum Patchday. Vergesst nich den DNS Dienst neuzustarten. Bisher jedenfalls ebenfalls keine Probleme.
Wow danke für den Link. Das ist mir aber echt ne Nummer zu hoch :D
Falls jemand gerade nicht die möglichkeit hat Zeitnah den REG anzupassen oder den Patch einzuspielen:
Eigentlich müsste es ausreichen die TCP Port 53 Kommunikation des DNS Servers ins Internet zu unterbinden, z.B. via Firewall.
Der Exploit funktioniert nur wenn der Windows DNS Server als Client fungiert und das Antwortpaket via TCP kommt.
Eigentlich wäre es mal spannend zu erfahren obs da draußen schon NS gibt die so eine Antwort ausliefern :D
Edit: Auch schön:
Aus https://research.checkpoint.com/2020/resolving-your-way-into-domain-admi ...
It appears that, unlike dns.exe!SigWireRead, dnsapi.dll!Sig_RecordRead does validate at Sig_RecordRead+D0 that the value that is passed to dnsapi.dll!Dns_AllocateRecordEx is less than 0xFFFF bytes, thus preventing the overflow.
The fact that this vulnerability does not exist in dnsapi.dll, as well as having different naming conventions between the two modules, leads us to believe that Microsoft manages two completely different code bases for the DNS server and the DNS client, and does not synchronize bug patches between them.
Verschwörungstheorien anyone? Eine Backdoor! :D
Eigentlich müsste es ausreichen die TCP Port 53 Kommunikation des DNS Servers ins Internet zu unterbinden, z.B. via Firewall.
Der Exploit funktioniert nur wenn der Windows DNS Server als Client fungiert und das Antwortpaket via TCP kommt.
Eigentlich wäre es mal spannend zu erfahren obs da draußen schon NS gibt die so eine Antwort ausliefern :D
Edit: Auch schön:
Aus https://research.checkpoint.com/2020/resolving-your-way-into-domain-admi ...
It appears that, unlike dns.exe!SigWireRead, dnsapi.dll!Sig_RecordRead does validate at Sig_RecordRead+D0 that the value that is passed to dnsapi.dll!Dns_AllocateRecordEx is less than 0xFFFF bytes, thus preventing the overflow.
The fact that this vulnerability does not exist in dnsapi.dll, as well as having different naming conventions between the two modules, leads us to believe that Microsoft manages two completely different code bases for the DNS server and the DNS client, and does not synchronize bug patches between them.
Verschwörungstheorien anyone? Eine Backdoor! :D
Ich bin jz kein Experte aber blockst du damit nicht auch die Verbindung zu den Root NS weg?
Naja, 99,9% der DNS Anfragen klappen über UDP, durch die sperre von TCP/53 sollte also alles i.O. sein.
Wie gesagt, ist nur ein alternativvorschlag wenn man grad Resssourcenknappheit hat und es nicht sofort "richtig" patchen kann
Wie gesagt, ist nur ein alternativvorschlag wenn man grad Resssourcenknappheit hat und es nicht sofort "richtig" patchen kann
Ich habe mal irgendwo gehört, dass man den eigenen DNS quasie eh komplett vom Internet abschotten kann. Also als DNS Hardening Maßnahme. Daher liegts du damit vermutlich wohl ganz gut.
