Nuevamente la buena gente de Horizon3.ai se hace eco de una vulnerabilidad que en principio estaba pasando desapercibida y en este caso de la mano de su investigador de seguridad Trampas Howe (quien al parecer se estrena en el blog con el post del que os vengo a comentar), nos aterriza y nos ofrece la indagación que se ha realizado sobre los detalles técnicos para explotar y aprovechar esta vulnerabilidad (CVE-2022-33679); Que inicialmente puede parecer muy teórica, pero que y como veremos, será un vector más para llegar a comprometer entornos de Active Directory.
Vayamos por lo inicial y es tratar de describir esta vulnerabilidad, que de ante mano os digo que haré una interpretación de lo que yo he entendido de donde puede estar el problema. Siempre puedes ir a los post originales (os lo dejo al final en las referencias), para una mayor comprensión.
Asumiendo que entendemos que es Kerberos y como funciona (en caso de que no, igualmente os dejo algunas referencias, esta vez un par de entradas de los especialistas de BlackArrow), podríamos asimilar que esta vulnerabilidad tiene semejanzas con la famosa técnica de ASREPRoast (también referenciada como AS-REP Roasting), en el sentido que funciona contra cuentas que no tienen habilitado la preautenticación Kerberos y que para poner el marcha el ataque no se necesita tener las credenciales del usuario en cuestión.
Otro aspecto relevante en este ataque es que se «juega» con la degradación del algoritmo de cifrado, llegando hasta «el débil» RC4-MD4, que se convierte en el escenario propicio para aplicar fuerza bruta a la clave de sesión del AS-REP. Acto seguido y ya con la clave de sesión junto a un TGT se generará un TGS-REQ al TGS para llegar a un ST (service ticket).
Todos los detalles técnicos y a bajo nivel de la degradación de Kerberos RC4-MD4, fueron publicados por el investigador de seguridad James Forshaw (@tiraniddo) de Google Project Zero en el siguiente tweet (el enlace en las referencias):
Aprovechamiento práctico
Listo, después de las presentaciones, vayamos a la acción. Para ello emplearemos el exploit liberado por el usuario Bdenneu en su GitHub:
La implementación sobre nuestro sistema es la mar de sencillo. El fichero requirements.txt solo tiene 2 elementos (impacket y arc4), ambas de versiones recientes.
Con esto implementado ya podríamos ver el mensaje de ayuda de la herramienta (que tira de Impacket por supuesto):
Partiremos localizando un usuario que tenga la preautenticación Kerberos deshabilitada (atributo DONT_REQ_PREAUTH), para ello emplearemos la herramienta kerbrute que ya hemos visto en este blog:
kerbrute userenum -d laboratory.local --dc 10.10.5.5 Users.txt
Si estuviéramos en una auditoría en cliente, llegados a este punto, ya estaríamos bastante ilusionados y tal vez exaltados. Lo siguiente que vendría es preformatear con la utilidad GetNPUsers de Impacket el resultado para Hashcat o John the Ripper, según nuestra conveniencia y finalmente proceder a crackear de forma offline el hash. ¿Verdad?
Sin embargo, ¿Qué pasa en aquellos casos que no es posible obtener en claro la password del hash, es decir, en caso de que el crackeo no sea fructífero? Recordemos que en principio es la única vía conocida de esta técnica denominada como ASREPRoast. ¿Desistimos y a otra cosa?
Pues no amiguitos, ahora gracias a esta vulnerabilidad CVE-2022-33679, estaremos solo en el punto de partida de una serie de posibilidades, vamos a revisar algunas de ellas.
Pondremos en marcha el exploit con los datos que disponemos hasta este momento:
python3 CVE-2022-33679.py laboratory.local/cshah SRV-DC -dc-ip 10.10.5.5
De ir todo correcto (que tendría que hacerlo), obtendremos la recuperación de la clave de sesión que propiciará que interactuemos nuevamente con el TGS para finalmente llegar al correspondiente ticket que se albergará en un fichero no legible inicialmente.
Emplearemos este fichero generado y lo exportaremos a nuestra variable de entorno KRB5CCNAME:
export KRB5CCNAME=pcosta_SRV-DC.ccache
De esta forma podremos contar con el mismo desde distintas herramientas, como por ejemplo CME:
crackmapexec smb SRV-DC -k
Las posibilidades serán las que nos permita los privilegios del usuario:
crackmapexec smb SRV-DC -k --shares
Ahora bien, una pregunta más: ¿Qué pasa si la cuenta de usuario implicada es una cuenta privilegiada? Veamos las posibilidades.
Aquí la configuración definidas para este nuevo usuario y sus asignaciones como miembro:
Pondremos una vez más en marcha el exploit y «setearemos» el resultado obtenido:
python3 CVE-2022-33679.py laboratory.local/pcosta SRV-DC -dc-ip 10.10.5.5 export KRB5CCNAME=pcosta_SRV-DC.ccache
Con esto llega el momento de validar las posibilidades con este usuario:
crackmapexec smb SRV-DC -k -x hostname crackmapexec smb SRV-DC -k -x systeminfo
Siendo que el usuario cuenta con privilegios de «Domain Admin» podremos dumpear los hashes del servidor:
crackmapexec smb SRV-DC -k --sam crackmapexec smb SRV-DC -k --ntds
Por último y como dicen por ahí que: «No solo de CrackMapExec vive el hombre (pentester)«, llega el momento de ver las posibilidades que obtendremos con Impacket, por ejemplo con la utilidad de psexec conseguiremos una sesión interactiva remota al host con máximos privilegios:
impacket-psexec pcosta@SRV-DC -k -no-pass
Todo esto ya lo ves, sin necesidad de obtener las credenciales en claro del usuario. Es todo por ahora, nos vemos en el siguiente post.
Referencias
- https://www.horizon3.ai/from-cve-2022-33679-to-unauthenticated-kerberoasting/
- https://googleprojectzero.blogspot.com/2022/10/rc4-is-still-considered-harmful.html
- https://github.com/Bdenneu/CVE-2022-33679
- https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2022-33679
- https://www.tarlogic.com/es/blog/como-funciona-kerberos/
- https://www.tarlogic.com/es/blog/como-atacar-kerberos/