CVE-2020-1472 | Netlogon Elevation of Privilege Vulnerability

[wznutzer 35]

Am 22.9.2020 um 12:49 schrieb zahni:

Was ich noch nicht ganz verstanden habe: Ist man nach dem Update nun geschützt oder erst nach dem "Enforcen"?

 

Am 22.9.2020 um 13:21 schrieb NorbertFe:

Aktuell musst du zwingend den Registry Wert setzen um damit das wirkt.

Das ist nach meinem Verständnis nicht so. Der Angriff läuft in fünf Schritten ab. Erstens werden die Anmeldeinformationen ermittelt. Wobei ermitteln hier nicht stimmt, weil diese nicht ermittelt werden. Man täuscht (spooft) vor die Anmeldeinformationen zu haben. So kann man sich dann wie ein Computer anmelden. Zweitens wird dann die Transportverschlüsselung der aufzubauenden Verbindung einfach abgeschaltet. Das ist kein Hack, weil Windows das schlicht erlaubt. Das ist notwendig, ohne den immer noch unbekannten Sessionkey könnte man keine verschlüsselte Verbindung aufbauen, deswegen abschalten. Die restlichen Schritte sparen wir uns hier, die sind für das Verstehen des Patch nicht relevant. Der Patch erzwingt nun Secure NRPC für alle Windows Server und Clients. Da der Sessionkey unbekannt ist, kann in Schritt zwei keine Verbindung aufgebaut werden. Außerdem wird auch Schritt eins des Hack unterbunden. Der Entdecker der Schwachstelle schreibt, dass Schritt eins mit Bruteforcing evtl. irgendwie noch funktionieren könnte, geschafft hat er es nicht. Daraus ergeben sich nun zwei Szenarien.

 

1)

Für Windows Systeme die einen Patch erhalten haben ist die Gefahr gebannt. Domäne übernehmen geht nicht mehr.

2)

Legacy Systeme und Drittanbieter-Geräte (NAS etc.) können noch immer unverschlüsselte Verbindungen aufbauen. Für diese Geräte wird Secure NRPC nicht durchgesetzt. Wenn es jetzt jemand schafft Schritt eins des Hacks wieder erfolgreich umzusetzen, können diese Geräte z. B. aus der Domäne ausgesperrt werden, weil das Computerkontopasswort im AD geändert werden könnte. Außerdem ist durch evtl. erfolgreiches Anwenden von CVE-2019-1424 per man-in-the-middle Zugriff auf das Legacy / Drittanbieter-Gerät möglich. Das ist noch immer uncool, aber lange nicht mehr so cool wie eine Domäne zu übernehmen und würde wohl auch keinen Score von 10 erhalten. Das in den KB-Artikeln beschriebene Enforcement, das ab Februar zwingend gilt, zielt auf diese Systeme. Um dieses Enforcement schon jetzt für diese Geräte zu aktivieren gibt es diesen Registrykey.

 

Grüße

[NorbertFe 2.089]

vor 11 Stunden schrieb wznutzer:

Das ist nach meinem Verständnis nicht so.

Ja war etwas zu flapsig formuliert. Solange der registry wert nicht gesetzt ist besteht auf jedem nicht gepatchtem System die Lücke und damit die Möglichkeit im ad schaden anzurichten. Siehe dein Punkt 2.

[Weingeist 159]

vor 2 Minuten schrieb NorbertFe:

Ja war etwas zu flapsig formuliert. Solange der registry wert nicht gesetzt ist besteht auf jedem nicht gepatchtem System die Lücke und damit die Möglichkeit im ad schaden anzurichten. Siehe dein Punkt 2.

So verstehe ich den Text auch. Und das finde ich bei so einem Bug eigentlich bedenklich. Hätte da eher die anderen ins Messer laufen lassen und diese dann die Flags setzen lassen das es Ausnahmen geben kann wenn schon Exploits im freien Markt existieren.

[NorbertFe 2.089]

Sehe ich ähnlich, aber für MS Verhältnisse ist das schon extrem kurz dieser Zeitraum. ;)

[Weingeist 159]

Vor allem wenn man bedenkt, dass viele Admins das gar nicht umsetzen dürften. Schlicht weil schon nicht bekannt. ;)

[NorbertFe 2.089]

vor 7 Minuten schrieb Weingeist:

Vor allem wenn man bedenkt, dass viele Admins das gar nicht umsetzen dürften. Schlicht weil schon nicht bekannt. ;)

Naja, das is aber generell so, wenn ich mir die Meldung bzw. Exchange ungepatcht in 250.000 Fällen so durchlese. ;) Ich gehe davon aus, dass das nicht MS spezifisch ist.

[mwiederkehr 384]

Es ist eine Gratwanderung: würden "Legacy-Systeme" automatisch ausgesperrt, gäbe das ein Drama ("Seit dem letzten Update funktioniert mein NAS nicht mehr!") und "Nebenbei-Admins" würden noch weniger Updates installieren als jetzt schon. Microsoft scheint dieses Risiko als grösser einzuschätzen als die Gefahr, die durch übernommene Computerkonten einhergeht. Zumal man damit ja nicht mehr die Domäne übernehmen kann (ausser vielleicht, man hat betreibt einen Samba als DC).

 

Was mich noch interessieren würde: es besteht die Möglichkeit, dass der Exploit schon lange bekannt war und im "Untergrund" gehandelt wurde. Haben Firmen mit kritischen Infrastrukturen Prozesse, um ihre Systeme bei Bekanntwerden solcher Lücken zu prüfen? Wird die AD-Datenbank offline auf merkwürdige Benutzer untersucht? Das Passwort vom KRBTGT-Account zurückgesetzt?

[testperson 1.728]

Hi,

 

gestern Abend hat Microsoft im MSRC Blog ein "To-Do" veröffentlicht: https://msrc-blog.microsoft.com/2020/10/29/attacks-exploiting-netlogon-vulnerability-cve-2020-1472/

Zitat

• UPDATE your Domain Controllers with an update released August 11, 2020 or later.
• FIND which devices are making vulnerable connections by monitoring event logs.
• ADDRESS non-compliant devices making vulnerable connections.
• ENABLE enforcement mode to address CVE-2020-1472 in your environment.

Der Im ersten Post verlinkte KB (https://support.microsoft.com/en-us/help/4557222/how-to-manage-the-changes-in-netlogon-secure-channel-connections-assoc) wurde ebenfalls mit dem "To-Do" geupdated.

 

Gruß

Jan

[testperson 1.728]

Hi,

 

ein kleiner Reminder damit der 09. Februar 2021 nicht "urplötzlich" und "unangekündigt" vor der Türe steht: Netlogon Domain Controller Enforcement Mode is enabled by default beginning with the February 9, 2021 Security Update, related to CVE-2020-1472 – Microsoft Security Response Center

Zitat

Netlogon Domain Controller Enforcement Mode is enabled by default beginning with the February 9, 2021 Security Update, related to CVE-2020-1472

 

Gruß

Jan

[Dukel 457]

Zum Glück habe ich in der Woche Urlaub :)

[testperson 1.728]

vor 39 Minuten schrieb Dukel:

Zum Glück habe ich in der Woche Urlaub :)

Dann solltest du die Updates in der Woche automatisch genehmigen. Dann erledigt sich das "von alleine". ;)

[zahni 558]

Hat ja nicht weh getan. Einfach vorher die Eventlogs nach den beschriebenen Events absuchen. Bei uns ist das schon aktiv,

[Kerberos_DLW 0]

gibt es eine Möglichkeit um zu prüfen ob ein Rechner Secure RPC kommunizieren kann ?

[NorbertFe 2.089]

vor 11 Minuten schrieb Kerberos_DLW:

gibt es eine Möglichkeit um zu prüfen ob ein Rechner Secure RPC kommunizieren kann ?

Wenn er es nicht kann, stehts im Logfile der Server. Siehe obige Links.

[Kerberos_DLW 0]

ja klar, aber kann man auch z.b. PowerShell Test-ComputerSecureChannel oder was auch immer eingeben ?