Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
CACredDecoder — C-Ark Credential Decoder per #CVE-2021-31796 | Kitploit
Strumenti/GitHubGitHub/unmanarc/cacreddecoder
Password CrackingStrumenti di Crittografia/DecrittografiaAnalisi delle VulnerabilitàExploitCrittografiaPenetration Testing
GitHubunmanarc/cacreddecoder

CACredDecoder

C-Ark Credential Decoder per #CVE-2021-31796

Vedi Repository
114 anni faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

C-Ark Credential Decoder

Strumento di exploit per CVE-2021-31796
Uno strumento per decodificare i file di credenziali C-Ark

Di: Aaron Mizrachi        - https://twitter.com/unmanarc/
      Enrique Vaamonde - https://twitter.com/_ejvm
Prima release: 2/Sep/2019
Divulgazione: 11/Oct/2021

Riferimenti

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

Divulgazione responsabile:

Questa vulnerabilità era in attesa di pubblicazione da settembre 2019.

E... ecco la cronologia:

  • 2019-08-1x Durante un esercizio, il nostro team ha scoperto e segnalato al rappresentante locale del fornitore una potenziale debolezza crittografica in alcuni metodi di archiviazione delle credenziali utilizzati.
  • 2019-08-30 Fino a questa data, avevamo solo un "ollydbg" proof of concept in memoria utilizzando i loro strumenti. Stavamo cercando di dimostrare come questo potesse diventare un vettore di attacco per alcune situazioni specifiche, ma non siamo riusciti a convincere. Quindi abbiamo deciso di iniziare a scrivere questo proof of concept per avere un argomento più evidente.
  • 2019-09-02 Abbiamo implementato con successo l'hashing e l'algoritmo crittografico nel nostro proof of concept (completamente indipendente dal prodotto).
  • 2019-09-03 Abbiamo comunicato le nostre scoperte al fornitore e il nostro interesse a renderle pubbliche.
  • 2019-09-20 Abbiamo ricevuto una richiesta dal fornitore di posticipare la pubblicazione fino a quando il problema non fosse stato risolto.
  • 2020-05 Li abbiamo ricontattati per ottenere il via libera alla pubblicazione dello strumento e ci siamo scambiati un paio di email in cui dicevano di non essere pronti.
  • 2021-09/2021-10 Abbiamo scoperto che anche altri ricercatori non collegati a noi hanno recentemente trovato e divulgato pubblicamente la stessa identica vulnerabilità, e visto ciò... alla fine (dopo 2 anni!) abbiamo ricevuto il via libera dal fornitore per condividere con voi le nostre scoperte e lo strumento proof-of-concept per sfruttare la debolezza crittografica di CreateCredFile.

Utilizzo potenziale:

Durante un pentest, se qualcuno è abbastanza furbo da raggiungere il PSM e ottenere accidentalmente l'accesso al CredFile, potrebbe potenzialmente usare questo file per stabilire una connessione al Vault e ottenere l'intero regno...

Come contromisura, la maggior parte dei file di credenziali impone alcune "restrizioni" per evitare che la password venga utilizzata in un ambiente/computer diverso (ad es. il PSM personale dell'hacker).

Tuttavia, tali restrizioni possono essere modificate se si inverte il processo e si ottiene la porzione grezza della chiave. Questa porzione di chiave decrittata può essere utilizzata per ricreare un altro file con altri parametri di "sicurezza" (ad es. un altro host, un'altra applicazione, un altro utente del sistema operativo).

Modalità di funzionamento

Per generare la chiave grezza di decrittazione AES-256 (32 byte), prendiamo una coppia di SHA1SUM dal campo credenziale "AdditionalInformation" aggiungendo "0x00000000" e "0x00000001" per ogni hash; il primo hash fornisce i primi 20 byte della chiave, il secondo solo gli ultimi 12 byte.

Se sono presenti restrizioni ambientali (come IP/Host/exepath/...), anteponiamo ogni valore in chiaro a AdditionalInformation prima di calcolare entrambi gli SHA1SUM.

È importante menzionare che il campo "ClientApp" viene trasformato con BASE64(SHA1SUM(strlower(ClientApp))) prima di essere anteposto a "AdditionalInformation" e di generare entrambi gli SHA1SUM.

La decrittazione viene eseguita utilizzando la funzione AES-256-CBC di OpenSSL con il campo Password o NewPassword. (https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption)

Stiamo usando (verificationflags-16) per capire quale validazione/restrizione è attiva:

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

e nel caso in cui alcune restrizioni non siano visualizzate nel file di credenziali di output, puoi sempre inserirle a mano. Penso che possiamo entrambi concordare sul fatto che né "percorso dell'app" né "IP del client” siano valori davvero casuali.

Mitigazione:

Usa l'HSM \o/, non memorizzare la chiave di decrittazione nel file cred.

Istruzioni di compilazione:

root@kitploit:~
qmake . 
make -j8
Scarica lo strumento