Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
CACredDecoder — C-Ark Credential Decoder für #CVE-2021-31796 | Kitploit
Tools/GitHubGitHub/unmanarc/cacreddecoder
Passwort-CrackingVerschlüsselungs-/EntschlüsselungstoolsSchwachstellenanalyseExploitationKryptographiePenetrationstests
GitHubunmanarc/cacreddecoder

CACredDecoder

C-Ark Credential Decoder für #CVE-2021-31796

Repository anzeigen
11vor 4 JahrenNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

C-Ark Credential Decoder

Exploit-Tool für CVE-2021-31796
Ein Tool zum Dekodieren von C-Ark-Credential-Dateien

Von: Aaron Mizrachi        - https://twitter.com/unmanarc/
      Enrique Vaamonde - https://twitter.com/_ejvm
Erste Veröffentlichung: 2/Sep/2019
Offenlegung: 11/Oct/2021

Referenzen

  • https://packetstormsecurity.com/files/164023/CyberArk-Credential-File-Insufficient-Effective-Key-Space.html
  • https://vuldb.com/?id.181904

Verantwortungsvolle Offenlegung:

Diese Schwachstelle lag seit September 2019 zur Veröffentlichung bereit.

Und hier ist der Zeitplan:

  • 2019-08-1x Während einer Übung entdeckte und meldete unser Team dem lokalen Vertreter des Anbieters eine potenzielle Krypto-Schwäche in einigen verwendeten Methoden zur Speicherung von Anmeldeinformationen.
  • 2019-08-30 Bis zu diesem Datum hatten wir nur einen „ollydbg“-In-Memory-Proof-of-Concept mit ihren eigenen Tools. Wir versuchten zu verdeutlichen, wie dies in bestimmten Situationen zu einem Angriffsvektor werden kann, aber wir konnten den Punkt nicht klar machen. Also beschlossen wir, diesen Proof-of-Concept zu programmieren, um ein offensichtlicheres Argument zu haben.
  • 2019-09-02 Wir implementierten erfolgreich den Hashing- und den Krypto-Algorithmus in unserem eigenen Proof-of-Concept (völlig losgelöst vom Produkt).
  • 2019-09-03 Wir kündigten dem Anbieter unsere Ergebnisse und unser Interesse an einer öffentlichen Verfügbarkeit an.
  • 2019-09-20 Wir erhielten eine Anfrage des Anbieters, die öffentliche Veröffentlichung zu verschieben, bis das Problem behoben sei.
  • 2020-05 Wir kontaktierten sie erneut, um die Freigabe zur Veröffentlichung des Tools zu erhalten, und tauschten einige E-Mails aus, in denen sie sagten, sie seien nicht bereit.
  • 2021-09/2021-10 Wir haben festgestellt, dass andere nicht verwandte Forscher kürzlich ebenfalls dieselbe Schwachstelle gefunden und öffentlich gemacht haben. Aus diesem Grund... haben wir endlich (nach 2 Jahren!) die Freigabe vom Anbieter erhalten, unsere Ergebnisse und das Proof-of-Concept-Tool zur Ausnutzung der Krypto-Schwäche von CreateCredFile mit Ihnen zu teilen.

Potenzielle Verwendung:

Während eines Pentests kann jemand, der klug genug ist, das PSM zu erreichen und versehentlich Zugriff auf die CredFile zu erlangen, potenziell diese Datei verwenden, um eine Verbindung zum Vault herzustellen und die gesamte Kontrolle zu erlangen...

Als Gegenmaßnahme legen die meisten Credential-Dateien einige „Einschränkungen“ fest, um zu verhindern, dass das Passwort in einer anderen Umgebung/einem anderen Computer verwendet wird (z. B. dem eigenen PSM des Hackers).

Diese Einschränkungen können jedoch geändert werden, wenn Sie den Rohschlüsselteil umkehren und erhalten. Dieser entschlüsselte Schlüsselteil kann verwendet werden, um eine weitere Datei mit anderen „Sicherheits“-Parametern zu erstellen (z. B. einem anderen Host, einer anderen Anwendung, einem anderen OS-Benutzer).

Funktionsweise

Um den rohen AES-256-Entschlüsselungsschlüssel (32 Byte) zu generieren, nehmen wir ein Paar SHA1SUM aus dem Credential-Feld „AdditionalInformation“, wobei wir für jeden Hash „0x00000000“ und „0x00000001“ anhängen; der erste Hash liefert die ersten 20 Bytes des Schlüssels, der zweite nur die letzten 12 Bytes.

Falls es Umgebungseinschränkungen gibt (wie IP/Host/exepath/...), stellen wir jeden Klartextwert der AdditionalInformation voran, bevor wir beide SHA1SUMs berechnen.

Es ist wichtig zu erwähnen, dass das Feld „ClientApp“ mit BASE64(SHA1SUM(strlower(ClientApp))) transformiert wird, bevor es der „AdditionalInformation“ vorangestellt und beide SHA1SUMs generiert werden.

Die Entschlüsselung erfolgt mit der AES-256-CBC-OpenSSL-Funktion unter Verwendung des Feldes Password oder NewPassword. (https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption)

Wir verwenden (verificationflags-16), um zu ermitteln, welche Validierung/Einschränkung aktiv ist:

root@kitploit:~
usingClientApp      = ((uVerificationsFlag&0x1) != 0);
usingAppPath        = ((uVerificationsFlag&0x2) != 0);
usingClientIP       = ((uVerificationsFlag&0x4) != 0);
usingOSUser         = ((uVerificationsFlag&0x8) != 0);
usingClientHostname = ((uVerificationsFlag&0x20) != 0);

und falls einige Einschränkungen nicht in der ausgegebenen Credential-Datei angezeigt werden, können Sie sie jederzeit von Hand einfügen. Ich denke, wir sind uns beide einig, dass weder „App-Pfad“ noch „Client-IP“ wirklich zufällige Werte sind.

Gegenmaßnahme:

Verwenden Sie das HSM \o/, speichern Sie den Entschlüsselungsschlüssel nicht in der Cred-Datei.

Build-Anleitung:

root@kitploit:~
qmake . 
make -j8
Tool herunterladen