Skip to content
KitploitKITPLOIT
FerramentasBlog
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
CACredDecoder — C-Ark Credential Decoder para #CVE-2021-31796 | Kitploit
Ferramentas/GitHubGitHub/unmanarc/cacreddecoder
Quebra de SenhasFerramentas de Criptografia/DescriptografiaAnálise de VulnerabilidadesExploraçãoCriptografiaTestes de Penetração
GitHubunmanarc/cacreddecoder

CACredDecoder

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

Ver Repositório
11há 4 anosAinda não revisado

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

Decodificador de Credenciais C-Ark

Ferramenta de exploração para CVE-2021-31796
Uma ferramenta para decodificar arquivos de credenciais C-Ark

Por: Aaron Mizrachi        - https://twitter.com/unmanarc/
      Enrique Vaamonde - https://twitter.com/_ejvm
Primeiro lançamento: 2/Set/2019
Divulgação: 11/Out/2021

Referências

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

Divulgação Responsável:

Esta vulnerabilidade estava pendente de divulgação desde Set/2019.

E... aqui está a linha do tempo:

  • 2019-08-1x Durante um exercício, nossa equipe descobriu e relatou ao representante local do fornecedor uma potencial fraqueza criptográfica em alguns métodos de armazenamento de credenciais usados.
  • 2019-08-30 Até esta data, tínhamos apenas uma "prova de conceito em memória com ollydbg" usando suas próprias ferramentas. Tentávamos demonstrar como isso poderia se tornar um vetor de ataque para certas situações específicas, mas não conseguimos convencer. Então decidimos começar a codificar esta prova de conceito para ter um argumento mais óbvio.
  • 2019-09-02 Implementamos com sucesso o hashing e o algoritmo criptográfico em nossa própria prova de conceito (totalmente separada do produto).
  • 2019-09-03 Anunciamos nossas descobertas ao fornecedor e nosso interesse em torná-las publicamente disponíveis.
  • 2019-09-20 Recebemos um pedido do fornecedor para adiar a divulgação pública até que o problema fosse corrigido.
  • 2020-05 Entramos em contato novamente para obter autorização para lançar a ferramenta e trocamos alguns e-mails onde eles disseram que não estavam prontos.
  • 2021-09/2021-10 Descobrimos que outros pesquisadores não relacionados também encontraram e divulgaram publicamente a mesma vulnerabilidade recentemente, e diante disso... finalmente (após 2 anos!) fomos autorizados pelo fornecedor a compartilhar com vocês nossas descobertas e a ferramenta de prova de conceito para explorar a fraqueza criptográfica do CreateCredFile.

Uso potencial:

Durante um pentest, se alguém for esperto o suficiente para alcançar o PSM e acidentalmente obter acesso ao CredFile, essa pessoa pode potencialmente usar este arquivo para estabelecer uma conexão com o Vault e obter todo o domínio...

Como contramedida, a maioria dos arquivos de credenciais impõem algumas "restrições" para evitar que a senha seja usada em um ambiente/computador diferente (ex.: o próprio PSM do hacker).

No entanto, essas restrições podem ser modificadas se você reverter e obter a parte da chave bruta. Esta parte da chave decriptada pode ser usada para recriar outro arquivo com outros parâmetros de "segurança" (ex.: outro host, outro aplicativo, outro usuário do SO).

Modo de Operação

Para gerar a chave de decriptação bruta AES-256 (32 bytes), pegamos um par de SHA1SUM do campo de credencial "AdditionalInformation" acrescentando "0x00000000" e "0x00000001" para cada Hash; o primeiro Hash fornece os primeiros 20 bytes da chave, e o segundo apenas os últimos 12 bytes.

Se houver alguma restrição ambiental (como IP/Host/exepath/...), prefixamos cada valor de texto simples a AdditionalInformation antes de calcular ambos os SHA1SUMs.

É importante mencionar que o campo "ClientApp" é transformado com BASE64(SHA1SUM(strlower(ClientApp))) antes de ser prefixado a "AdditionalInformation" e gerar ambos os SHA1SUMs.

A decriptação é feita usando a função AES-256-CBC do OpenSSL utilizando o campo Password ou NewPassword. (https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption)

Estamos usando (verificationflags-16) para determinar qual validação/restrição está em vigor:

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

e no caso de algumas restrições não serem exibidas no arquivo de credencial de saída, você sempre pode introduzi-las manualmente. Acho que ambos podemos concordar que nem "caminho do aplicativo" nem "IP do cliente" são valores verdadeiramente aleatórios.

Mitigação:

Use o HSM \o/, não armazene a chave de decriptação no arquivo de credencial.

Como compilar:

root@kitploit:~
qmake . 
make -j8
Baixar ferramenta