Frage zum KB5008383 (CVE-2021-42291) securityDescriptor

[phatair 39]

Hallo zusammen,

 

ich weiß das dieser KB schon älter ist, aber aktuell prüfen wir die Logs um zu prüfen ob wir hier Probleme haben/bekommen. 

Das erzwingen des Enforcement modes wurde auf Januar 2024 verschoben.

 

Im KB Beitrag sind die EventIDs aufgeführt, die man prüfen soll. Nun ist es so, dass bei uns auf jedem der DCs beim Neustart folgende EventIDs geschrieben werden. Diese sind auch in den aufgelisteten EventIDs vorhanden

Quelle: ActiveDirectory_DomainService Event-ID 3054

Die Info von MS dazu lautet

"Mode Change Events – temporary removal of Implicit Owner rights"

"Events that occur when bit 29 of the dSHeuristics attribute is changed, which changes the mode of the temporary removal of Implicit Owner rights portion of the update."

Zitat

Das Verzeichnis wurde so konfiguriert, dass implizite Besitzerberechtigungen beim anfänglichen Festlegen oder Ändern des nTSecurityDescriptor zugelassen werden. attribut während LDAP-Hinzufüge- und -Änderungsvorgängen. Warnungsereignisse werden protokolliert, aber es werden keine Anforderungen blockiert.  
 
Diese Einstellung ist nicht sicher und sollte nur als temporärer Problembehandlungsschritt verwendet werden. Überprüfen Sie die vorgeschlagenen Schutzmaßnahmen über den link unten. 

 

Quelle: ActiveDirectory_DomainService Event-ID 3051

Die Info von MS dazu lautet

"Mode Change Events – Additional AuthZ verification for LDAP Add operations"

"Events that occur when bit 28 of the dSHeuristics attribute is changed, which changes the mode of the Additional AuthZ verifications for the LDAP Add operations portion of the update."

Zitat

Das Verzeichnis wurde so konfiguriert, dass bei LDAP-Add-Vorgängen keine Autorisierung pro Attribut erzwungen wird. Warnungsereignisse werden protokolliert werden, es werden jedoch keine Anforderungen blockiert.  
 
Diese Einstellung ist nicht sicher und sollte nur als temporärer Problembehandlungsschritt verwendet werden. Überprüfen Sie die vorgeschlagenen Schutzmaßnahmen über den link unten. 

 

Ich würde das jetzt aber so verstehen, dass dies nur Info sind zum einen über die neuen Berechtigungen informieren und dass man den enforcement mode aktivieren sollte um die bestmögliche Sicherheit zu erhalten. 

 

Die wirklich kritischen EventIDs wären die, die unter 

"Audit mode events" -> "Events that occur in Audit mode to log potential security concerns with an LDAP Add or Modify operation." gelistet werden (also 3047 - 3049 + 3056 und 3044 - 3046).

 

Wie handhabt ihr das? Habt ihr den enforcement mode manuell aktiviert oder wartet ihr bis MS das aktiviert?

Das manuelle aktivieren scheint ja nicht so einfach zu sein wie z.b. bei KB5020805, wo man einfach nur ein RegKey setzen muss. Hier muss ich ja wohl Attribute im AD anpassen.

 

Oder verstehe ich das komplett falsch?

 

Vielen Dank.

Gruß,

Steffen

[Weingeist 159]

*Hmpf* auch ein Artikel den ich übersehen habe. Irgendwie bin ich zu doof immer alles auf dem Radar zu haben. Gibts eigentlich irgendwo eine Auflistung über alle Massnahmen die von MS gepflegt wird inkl. aktuellem Status sowie die Umsetzungsphasen etc? Würde manches vereinfachen :-/

 

Generell kann man sagen: Je früher man aktiviert desto besser. Ich aktiviere meist nach dem TryAndError Prinzip. Schauen was allenfalls nicht mehr geht und darauf reagieren. Oder erst Audit, beheben und dann aktivieren.

Grund: Wenn MS das ganze propagiert, mit Timelines versieht etc. ist der Exploit entweder gut bekannt und wird bereits ausgenutzt oder er ist es spätestens wenn MS so granulare Infos bereitstellt. Da wird dann das Verhalten von Windows entsprechend analysiert und darauf reagiert.

 

 

Bezüglich diesem spezifisch dSHeuristics: Gibt es einen empfohlenen, möglichst "sicher" Wert den man eintragen sollte? Sobald ja der Wert vorhanden ist, müssen alle Flags gesetzt werden, zumindest bis zu dem Flag, den man braucht. Ist irgendwie nicht alles so trivial beschrieben bei MS was nun genau empfohlen wird. =)

[MurdocX 953]

Am 28.4.2023 um 09:31 schrieb phatair:

Wie handhabt ihr das?

Einlesen, aktiviert und fertig. Auswirkungen, die es zu spüren gab im Cluster-Bereich, wurden schon gepatcht.

[phatair 39]

Am 29.4.2023 um 17:51 schrieb Weingeist:

*Hmpf* auch ein Artikel den ich übersehen habe. Irgendwie bin ich zu doof immer alles auf dem Radar zu haben. Gibts eigentlich irgendwo eine Auflistung über alle Massnahmen die von MS gepflegt wird inkl. aktuellem Status sowie die Umsetzungsphasen etc? Würde manches vereinfachen :-/

Das habe ich mich auch schon gefragt, aber noch nichts passendes gefunden.

Ich schaue meistens bei Heise, Born und bei MS im Message Center

Am 30.4.2023 um 10:42 schrieb MurdocX:

Einlesen, aktiviert und fertig. Auswirkungen, die es zu spüren gab im Cluster-Bereich, wurden schon gepatcht.

Danke - dann werde ich mal schauen ob ich es komplett verstehe und dann aktivieren :) 

[Weingeist 159]

Am 2.5.2023 um 07:38 schrieb phatair:

Das habe ich mich auch schon gefragt, aber noch nichts passendes gefunden.

Born hat jetzt was seit ein paar Tagen für den aktuellen Kram. Vielleicht pflegt er es ja auch. Habe ich aber auch erst später gesehen mit ältere Beiträge. =)

--> https://www.borncity.com/blog/2023/05/02/windows-hrtung-termine-2023/

 

Und MS hat jetzt auch einen Dienst für Admins wenn man sich online anmeldet. Da bekommt man dann die Bug und wohl auch Sicherheits-Bulletins zugemailt. Vor kurzem gelesen.

[phatair 39]

Am 10.5.2023 um 12:20 schrieb Weingeist:

Born hat jetzt was seit ein paar Tagen für den aktuellen Kram. Vielleicht pflegt er es ja auch. Habe ich aber auch erst später gesehen mit ältere Beiträge. =)

--> https://www.borncity.com/blog/2023/05/02/windows-hrtung-termine-2023/

 

Und MS hat jetzt auch einen Dienst für Admins wenn man sich online anmeldet. Da bekommt man dann die Bug und wohl auch Sicherheits-Bulletins zugemailt. Vor kurzem gelesen.

Den Beitrag hatte ich doch glatt übersehen. Danke!

 

Bezüglich der MS Sicherheits-Bulletins - das habe ich auch gelesen. Aber das scheint nur für Enterprise Kunden zu sein, da nur M365 E Lizenzen davon profitieren.

Wir haben aber M365 Business Lizenzen und sind somit raus. Finde ich eine Frechheit, aber was soll man machen. Wir schauen uns halt immer verstärkt nach MS Alternativen um. 

[testperson 1.707]

Hi,

 

wenn ich das jetzt bereits erzwingen möchte, muss ich das dSHeuristics Attribut auf 28 Stellen erweitern. Dabei ist zu beachten, dass die 10te Stelle eine 1 sein muss, um dem Active Directory mitzuteilen, dass das Attribut jetzt mehr als 10 Stellen hat. Die 20igste Stelle muss eine 2 sein, damit das AD informiert ist, dass das Attribut jetzt 20 Stellen hat. Jetzt setze ich die 28igste Stelle auf 1 für Enforcement "Additional AuthZ verifications for LDAP Add operations" sowie die 29igste Stelle auf 1 für Temporary removal of Implicit Owner Enforcement?

 

Zitat

10 -> tenthChar -> When setting dSHeuristics to a value that is 10 or more Unicode characters long, if the value of tenthChar is not character "1", the server rejects the update. See section 3.1.1.5.3.2.

20 -> twentiethChar -> When setting dSHeuristics to a value that is 20 or more Unicode characters long, if the value of twentiethChar is not character "2", the server rejects the update. See section 3.1.1.5.3.2.

• Ist das Attribut leer oder 0 (also Default): 00000000010000000002000000011
• Gibt es bereits Werte, werden diese einfach übernommen und mit 0 aufgefüllt, außer Stelle 10 (-> 1), 20 (-> 2), 28 (-> 1) und 29 (-> 1): 0010000001000000000200000001 
  • Hier wäre dSHeuristics 001 gewesen
    • 3 auf 1 -> "List Object Mode"
• Hat das Attribut bereits mehr als 10 oder 20 Stellen, muss(?) Stelle 10 bereits 1 und Stelle 20 2 sein und es wird einfach am Ende bis zur 28igsten erweitert, welche dann 1 wird und die 29igste Stelle wird ebenfalls 1: 00000000010000001002000001011
  • Hier wäre dSHeuristics 00000000010000001002000001 gewesen
    • 17 auf 1 -> fKVNOEmuW2K (Was auch immer es tut)
    • 26 auf 1 -> fLoadV1AddressBooksOnlySetting (Wo auch immer man v1 Adressbücher findet/nutzt)
• Hat das Attribut bereits mehr als 10 oder 20 Stellen und 10 ist keine 1 und/oder 20 keine 2, dann ist schonmal generell etwas falsch?
  • Die heilige Handgranate von Antiochia - YouTube

 

• KB5008383—Active Directory permissions updates (CVE-2021-42291) - Microsoft Support
• [MS-ADTS]: dSHeuristics | Microsoft Learn

Passen meine "Annahmen" so?

 

(Das sollte sich doch in ein PowerShell Script bringen lassen.)

 

Danke und Gruß

Jan

 

Edit: Habe vor lauter 0, 1 und 2 vollkommen die 29igste Stelle für das Enforcement "Temporary removal of Implicit Owner for LDAP Modify operations" überlesen. :)

bearbeitet 12. Mai 2023 von testperson

[NilsK 2.957]

Moin,

 

wer auch immer sich diesen Schw*chsinn mit dem dSHeuristics ausgedacht hat ... ein Quell steter Freude seit 25 Jahren.

 

Gruß, Nils

 

[Weingeist 159]

@testperson: So verstehe ich das auch. Ich scheitere etwas damit was tatsächlich eingestellt werden soll bei den anderen Bits/Zeichen. 28/29 ist ja dann für das enforcement des aktuellen Zeugs. Beide auf 1 und es ist aktiviert. Soweit so gut.

Immerhin scheint man - weil eben Standardmässig alle Werte 0 sind - am Standardverhalten nichts zu ändern wenn man einfach die letzten Zeichen für die aktuellen Enforcements auf 1 setzt und ansonsten nur die Erweiterungsbits auf 1 (10) bzw. 2 (20).

 

Betreffend Powershell: Hier sind die verschiedenen Variante gut beschrieben, inkl. Powershell. Einfahc für ältere Werte, aber kann man ja adaptieren: https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/duplicate-spn-errors-active-directory-migration-tools-and-kb/ba-p/258102

 

 

Bei manchen habe ich aber das Gefühl, man sollte aus Sicherheitsgründen vom Standard abweichen. Manche sind selbsterklären durch die Beschreibung, andere eher nicht. Aber beurteilen welche Variante nun sicherer ist, fällt mir nur aufgrund der Beschreibung bei manchen einigermassen schwer. Gibt es da Empfehlungen?

 

Als Beispiel Bit bzw. Zeichen 9, das scheint mir z.B. relevant zu sein, da es um Passwörter geht: Was ist den da nun tatsächlich erwünscht? Will man diese Heuristic aufs fUserPwdSupport haben oder nicht? Falls man sie haben will, will man das nur bei AD LDS  (0) oder auch bei AD DS (1) haben oder eben nirgends? Wenn ich es richtig interpretiere ist es besser mit.

ABER: Warum ist es dann standardmässig bei AD DS nicht aktiviert obwohl es die einstellung schon mindestens 15 Jahre gibt? Aus irgend einem Grund wurde die ja geschaffen und standardmässig für eine der beiden Varianten aktivert und für die andere deaktiviert.

[testperson 1.707]

In meiner Testumgebung mit leerem dSHeuristics und in der mit aktiviertem LOM hat es jedenfalls funktioniert:

 

# https://support.microsoft.com/en-au/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1
# https://learn.microsoft.com/de-de/openspecs/windows_protocols/ms-adts/e5899be4-862e-496f-9a38-33950617d2c5

$ADDomain = Get-ADDomain -Current LocalComputer
$DN = -join(
    "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,",
    $ADDomain.DistinguishedName
)
$ADObject = Get-ADObject -Identity $DN `
    -Properties dsHeuristics
    
[string]$dSHeuristics = $ADObject.dsHeuristics

while($dSHeuristics.Length -lt 29){
    $dSHeuristics = -join(
        $dSHeuristics,
        "0"
    )
}

# fLDAPBlockAnonOps
<#
    https://learn.microsoft.com/de-de/openspecs/windows_protocols/ms-adts/e5899be4-862e-496f-9a38-33950617d2c5
    If this character is "2", then the fLDAPBlockAnonOps heuristic is false;
    otherwise, the fLDAPBlockAnonOps heuristic is true. If this character is
    not present in the string, it defaults to "2" when the DC functional
    level is less than DS_BEHAVIOR_WIN2003, and to "0" otherwise.

    https://learn.microsoft.com/de-de/openspecs/windows_protocols/ms-adts/4e11a7e6-e18c-46e4-a781-3ca2b4de6f30
    If the fLDAPBlockAnonOps heuristic of the dSHeuristics attribute (see
    section 6.1.1.2.4.1.2) is true, anonymous (unauthenticated) users are
    limited to performing rootDSE searches and binds. If fLDAPBlockAnonOps is
    false, anonymous users can perform any LDAP operation, subject to access
    checks that use the ACL mechanisms described in this section.
#>
# $dSHeuristics = $dSHeuristics -replace "(?<=^.{6}).","0"
$dSHeuristics = $dSHeuristics -replace "(?<=^.{9}).","1"
$dSHeuristics = $dSHeuristics -replace "(?<=^.{19}).","2"
$dSHeuristics = $dSHeuristics -replace "(?<=^.{27}).","1"
$dSHeuristics = $dSHeuristics -replace "(?<=^.{28}).","1"

<#
Set-ADObject -Identity $DN `
    -Replace @{dsHeuristics=$dSHeuristics}
#>

 

Wer" scharf schalten" möchte, muss halt den letzten Kommentarblock entfernen. :)