Skip to content
KitploitKITPLOIT
HerramientasBlog
Enviar
HerramientasBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
CACredDecoder — Decodificador de credenciales C-Ark para #CVE-2021-31796 | Kitploit
Herramientas/GitHubGitHub/unmanarc/cacreddecoder
Descifrado de ContraseñasHerramientas de Cifrado/DescifradoAnálisis de VulnerabilidadesExplotaciónCriptografíaPruebas de Penetración
GitHubunmanarc/cacreddecoder

CACredDecoder

Decodificador de credenciales C-Ark para #CVE-2021-31796

Ver Repositorio
11hace 4 añosAún no revisado

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

Decodificador de Credenciales C-Ark

Herramienta de explotación para CVE-2021-31796
Una herramienta para decodificar archivos de credenciales C-Ark

Por: Aaron Mizrachi        - https://twitter.com/unmanarc/
      Enrique Vaamonde - https://twitter.com/_ejvm
Primera versión: 2/Sep/2019
Divulgación: 11/Oct/2021

Referencias

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

Divulgación responsable:

Esta vulnerabilidad estaba pendiente de publicación desde Sep/2019.

Y... aquí está la línea de tiempo:

  • 2019-08-1x Durante algún ejercicio, nuestro equipo descubrió y reportó al representante local del proveedor una posible debilidad criptográfica en algunos métodos de almacenamiento de credenciales utilizados.
  • 2019-08-30 Hasta esta fecha, solo teníamos una prueba de concepto en memoria con "ollydbg" usando sus propias herramientas. Intentábamos demostrar cómo esto podía convertirse en un vector de ataque para ciertas situaciones específicas, pero no logramos hacerlo. Así que decidimos comenzar a programar esta prueba de concepto para tener un argumento más evidente.
  • 2019-09-02 Implementamos con éxito el hash y el algoritmo criptográfico en nuestra propia prueba de concepto (totalmente desvinculada del producto).
  • 2019-09-03 Anunciamos nuestros hallazgos al proveedor y nuestro interés en hacerlos públicos.
  • 2019-09-20 Recibimos una solicitud del proveedor para retrasar la publicación pública hasta que el problema estuviera solucionado.
  • 2020-05 Nos pusimos en contacto de nuevo para obtener autorización para liberar la herramienta e intercambiamos un par de correos diciendo que aún no estaban listos.
  • 2021-09/2021-10 Hemos descubierto que otros investigadores no relacionados también han encontrado y divulgado recientemente la misma vulnerabilidad públicamente, y dado esto... finalmente (¡después de 2 años!) el proveedor nos ha autorizado a compartir con ustedes nuestros hallazgos y la herramienta de prueba de concepto para explotar la debilidad criptográfica de CreateCredFile.

Uso potencial:

Durante un pentest, si alguien es lo suficientemente hábil como para llegar al PSM y accidentalmente obtener acceso al CredFile, esa persona podría potencialmente usar este archivo para establecer una conexión con el Vault y obtener todo el reino...

Como contramedida, la mayoría de los archivos de credenciales colocan algunas "restricciones" para evitar que la contraseña se use en un entorno/equipo diferente (p. ej., el propio PSM del hacker).

Sin embargo, esas restricciones pueden modificarse si se hace ingeniería inversa y se obtiene la porción de clave sin procesar. Esta porción de clave descifrada puede usarse para volver a crear otro archivo con otros parámetros de "seguridad" (p. ej., otro host, otra aplicación, otro usuario del SO).

Modo de operación

Para generar la clave de descifrado sin procesar AES-256 (32 bytes), tomamos un par de SHA1SUM del campo de credencial "AdditionalInformation" añadiendo "0x00000000" y "0x00000001" para cada hash; el primer hash proporciona los primeros 20 bytes de la clave, y el segundo solo los últimos 12 bytes.

Si hay restricciones ambientales (como IP/Host/exepath/...), anteponemos cada valor de texto plano a AdditionalInformation antes de calcular ambos SHA1SUM.

Es importante mencionar que el campo "ClientApp" se transforma con BASE64(SHA1SUM(strlower(ClientApp))) antes de anteponerse a "AdditionalInformation" y generar ambos SHA1SUM.

El descifrado se realiza mediante la función AES-256-CBC de OpenSSL utilizando el campo Password o NewPassword. (https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption)

Estamos usando (verificationflags-16) para determinar qué validación/restricción está en vigor:

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

y en el caso de que algunas restricciones no se muestren en el archivo de credenciales de salida, siempre puedes introducirlas manualmente. Creo que ambos podemos estar de acuerdo en que ni la "ruta de la aplicación" ni la "IP del cliente" son valores realmente aleatorios.

Mitigación:

Usa el HSM \o/, no almacenes la clave de descifrado en el archivo de credenciales.

Cómo compilar:

root@kitploit:~
qmake . 
make -j8
Descargar herramienta