{"id":25178,"date":"2020-09-17T13:37:28","date_gmt":"2020-09-17T11:37:28","guid":{"rendered":"https:\/\/www.kaspersky.de\/blog\/?p=25178"},"modified":"2020-09-17T13:37:28","modified_gmt":"2020-09-17T11:37:28","slug":"cve-2020-1472-domain-controller-vulnerability","status":"publish","type":"post","link":"https:\/\/www.kaspersky.de\/blog\/cve-2020-1472-domain-controller-vulnerability\/25178\/","title":{"rendered":"Zerologon-Sicherheitsl\u00fccke bedroht Dom\u00e4nencontroller"},"content":{"rendered":"

Zum Patch-Tuesday des diesj\u00e4hrigen Augusts schloss Microsoft mehrere Sicherheitsl\u00fccken, darunter auch CVE-2020-1472<\/a>. Die Netlogon-Protokoll-Sicherheitsl\u00fccke erhielt eine CVSS-Bewertung von 10 und wurde somit als \u201ekritisch\u201c eingestuft. Dass sie eine Bedrohung darstellen k\u00f6nnte, wurde nie bezweifelt, aber neulich ver\u00f6ffentlichte der Secura-Forscher, der die Schwachstelle entdeckte, Tom Tervoort einen detaillierten Bericht<\/a>, in dem er erkl\u00e4rte, warum die als Zerologon bekannte Sicherheitsl\u00fccke so gef\u00e4hrlich ist und wie sie zur \u00dcbernahme eines Dom\u00e4nencontrollers genutzt werden kann.<\/p>\n

Um was handelt es sich bei Zerologon?<\/h2>\n

Im Wesentlichen ist CVE-2020-1472 das Ergebnis eines Fehlers im kryptographischen Authentifizierungsverfahren des Netlogon Remote Protocol. Das Protokoll authentifiziert Benutzer und Rechner in dom\u00e4nenbasierten Netzwerken und wird auch zur Fern-Aktualisierung von Computer-Passw\u00f6rtern verwendet. Durch die Schwachstelle kann sich ein Angreifer als Client-Computer ausgeben und das Kennwort eines Dom\u00e4nencontrollers (ein Server, der ein ganzes Netzwerk steuert und Active Directory-Dienste ausf\u00fchrt) ersetzen, wodurch der Angreifer Dom\u00e4nenverwaltungsrechte erlangen kann.<\/p>\n

Wer ist angreifbar?<\/h2>\n

CVE-2020-1472 stellt ein Risiko f\u00fcr Unternehmen dar, deren Netzwerke auf Windows Server-Dom\u00e4nencontrollern basieren. So k\u00f6nnen Cyberkriminelle einen Dom\u00e4nencontroller \u00fcbernehmen, der auf einer beliebigen Version von Windows Server 2019 oder Windows Server 2016 sowie einer beliebigen Edition von Windows Server Version 1909, Windows Server Version 1903, Windows Server Version 1809 (Datacenter- und Standard-Editionen), Windows Server 2012 R2, Windows Server 2012 oder Windows Server 2008 R2 Service Pack 1 basiert. Um angreifen zu k\u00f6nnen, m\u00fcssten Cyberkriminelle zun\u00e4chst in das Unternehmensnetzwerk eindringen, aber das ist keine gro\u00dfe H\u00fcrde. Insbesondere Insider-Angriffe<\/a> und Infiltrierungen \u00fcber Ethernet-Anschl\u00fcsse<\/a> in \u00f6ffentlich zug\u00e4nglichen R\u00e4umlichkeiten sind keine Pr\u00e4zedenzf\u00e4lle mehr.<\/p>\n

Gl\u00fccklicherweise wurde Zerologon bisher noch nicht bei einem realen Angriff eingesetzt (oder zumindest wurde noch nichts dar\u00fcber berichtet). Der Bericht von Tervoort hat jedoch f\u00fcr Aufsehen gesorgt und h\u00f6chstwahrscheinlich die Aufmerksamkeit von Cyberkriminellen erregt. Obwohl die Forscher keinen funktionierenden Proof-of-Concept ver\u00f6ffentlicht haben, haben sie keinen Zweifel daran, dass Angreifer auf der Grundlage der Patches einen solchen erstellen k\u00f6nnen.<\/p>\n

Wie man sich gegen Zerologon-basierte Angriffe sch\u00fctzt<\/h2>\n

Microsoft hat Anfang August Patches ver\u00f6ffentlicht<\/a>, um die Schwachstelle f\u00fcr alle betroffenen Systeme zu schlie\u00dfen. Wenn Sie also Ihre Systeme noch nicht aktualisiert haben, ist es h\u00f6chste Zeit, dies zu tun. Dar\u00fcber hinaus empfiehlt Microsoft, alle Anmeldeversuche \u00fcber die anf\u00e4llige Version des Protokolls zu \u00fcberwachen und Ger\u00e4te zu identifizieren, welche die neue Version nicht unterst\u00fctzen. Idealerweise, so Microsoft, sollte der Dom\u00e4nencontroller auf einen Modus gesetzt werden, in dem alle Ger\u00e4te die sichere Version von Netlogon verwenden m\u00fcssen.<\/p>\n

Die Updates erzwingen diese Einschr\u00e4nkung nicht, da das Netlogon Remote-Protocol nicht nur in Windows verwendet wird. Viele Ger\u00e4te, die auf anderen Betriebssystemen basieren, sind ebenfalls auf das Protokoll angewiesen. Wenn Sie die Verwendung des sicheren Netlogons zwingend vorschreiben, werden Ger\u00e4te, die die sichere Version nicht unterst\u00fctzen, nicht richtig funktionieren.<\/p>\n

Nichtsdestotrotz m\u00fcssen alle Dom\u00e4nencontroller ab dem 9. Februar 2021 den Erzwingungsmodus verwenden (d. h. alle Ger\u00e4te werden dazu gezwungen, das aktualisierte, sichere Netlogon zu verwenden), so dass Administratoren das Problem der Drittanbieter-Ger\u00e4tekonformit\u00e4t im Voraus l\u00f6sen m\u00fcssen (durch Updates oder manuelles Hinzuf\u00fcgen von Ausnahmen). Weitere Informationen \u00fcber den August-Patch, die kommenden \u00c4nderungen im Februar sowie detaillierte Richtlinien finden Sie in diesem Microsoft Beitrag.<\/a><\/p>\n\n","protected":false},"excerpt":{"rendered":"

Die Sicherheitsl\u00fccke CVE-2020-1472 \u201eZerologon\u201c im Netlogon-Protokoll erm\u00f6glicht Angreifern die \u00dcbernahme von Dom\u00e4nencontrollern.<\/p>\n","protected":false},"author":2581,"featured_media":25179,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1848,3107,3108],"tags":[3119,25,2903,1498],"class_list":{"0":"post-25178","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-cve","11":"tag-microsoft","12":"tag-schwachstelle","13":"tag-schwachstellen"},"hreflang":[{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/cve-2020-1472-domain-controller-vulnerability\/25178\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/cve-2020-1472-domain-controller-vulnerability\/21903\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/cve-2020-1472-domain-controller-vulnerability\/17377\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/cve-2020-1472-domain-controller-vulnerability\/23294\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/cve-2020-1472-domain-controller-vulnerability\/21486\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/cve-2020-1472-domain-controller-vulnerability\/20106\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/cve-2020-1472-domain-controller-vulnerability\/23898\/"},{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/cve-2020-1472-domain-controller-vulnerability\/22837\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/cve-2020-1472-domain-controller-vulnerability\/29085\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/cve-2020-1472-domain-controller-vulnerability\/8828\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/cve-2020-1472-domain-controller-vulnerability\/37048\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/cve-2020-1472-domain-controller-vulnerability\/15680\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/cve-2020-1472-domain-controller-vulnerability\/16049\/"},{"hreflang":"pl","url":"https:\/\/plblog.kaspersky.com\/cve-2020-1472-domain-controller-vulnerability\/13982\/"},{"hreflang":"zh","url":"https:\/\/www.kaspersky.com.cn\/blog\/cve-2020-1472-domain-controller-vulnerability\/11985\/"},{"hreflang":"ja","url":"https:\/\/blog.kaspersky.co.jp\/cve-2020-1472-domain-controller-vulnerability\/29235\/"},{"hreflang":"nl","url":"https:\/\/www.kaspersky.nl\/blog\/cve-2020-1472-domain-controller-vulnerability\/26096\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/cve-2020-1472-domain-controller-vulnerability\/22875\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/cve-2020-1472-domain-controller-vulnerability\/28197\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/cve-2020-1472-domain-controller-vulnerability\/28029\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.de\/blog\/tag\/schwachstelle\/","name":"Schwachstelle"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/25178","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/users\/2581"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/comments?post=25178"}],"version-history":[{"count":5,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/25178\/revisions"}],"predecessor-version":[{"id":25189,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/25178\/revisions\/25189"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media\/25179"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media?parent=25178"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/categories?post=25178"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/tags?post=25178"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}