Mirrors/hacktricks

Fork 0

mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 13:13:41 +00:00

carlospolop 63bd9641c0 f

2023-06-05 20:33:24 +02:00

16 KiB

Raw Blame History

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

¿Trabajas en una empresa de ciberseguridad? ¿Quieres ver tu empresa anunciada en HackTricks? ¿O quieres tener acceso a la última versión de PEASS o descargar HackTricks en PDF? ¡Consulta los PLANES DE SUSCRIPCIÓN!
Descubre The PEASS Family, nuestra colección exclusiva de NFTs
Obtén la oficial PEASS & HackTricks swag
Únete al 💬 grupo de Discord o al grupo de telegram o sígueme en Twitter 🐦@carlospolopm.
Comparte tus trucos de hacking enviando PRs al repositorio hacktricks y al repositorio hacktricks-cloud.

Este contenido fue tomado de https://www.errno.fr/artifactory/Attacking_Artifactory

Conceptos básicos de Artifactory

Usuarios y contraseñas predeterminados

Las cuentas predeterminadas de Artifactory son:

Cuenta	Contraseña predeterminada	Notas
admin	password	cuenta de administración común
access-admin	password (<6.8.0) o un valor aleatorio (>= 6.8.0)	utilizado solo para operaciones de administración local
anonymous	''	usuario anónimo para recuperar paquetes de forma remota, no habilitado por defecto

Por defecto, no se aplica ninguna política de bloqueo de contraseñas, lo que convierte a Artifactory en un objetivo principal para ataques de relleno de credenciales y de rociado de contraseñas.

Autorizaciones

Idealmente, esto es lo que debería ver al conectarse a Artifactory:

Por otro lado, si se le presenta algo más parecido a esto:

Significa que se ha habilitado el "Acceso anónimo" en el panel de administración, que es una configuración común utilizada para permitir que las aplicaciones recuperen artefactos sin problemas, pero que le permite a usted, el atacante, ver más de lo que es preferible.

Comprobación de los derechos de la cuenta

¡A veces, debido a una mala configuración, se permite que el usuario anónimo implemente archivos en algunos repositorios!

Para comprobar en qué repositorios puede implementar el usuario anónimo, utilice la siguiente solicitud:

curl http://localhost:8081/artifactory/ui/repodata?deploy=true
{"repoList":["artifactory-build-info","example-repo-local"]}

Si hay entradas repoKey en la solicitud, cualquier persona anónima puede desplegar en ellas, lo cual es realmente malo. Definitivamente, se debe estar autenticado para desplegar cualquier archivo.

Esto se puede generalizar a otras cuentas una vez que se obtiene una contraseña o token para ellas.

Listado de usuarios

Por alguna razón, la lista de usuarios es un derecho reservado solo para los administradores. Encontré una forma alternativa de listar usuarios (aquellos que están desplegando activamente al menos) que se basa en el valor "Desplegado por" de los artefactos:

Este script simplemente intenta encontrar recursivamente todos los usuarios que han desplegado artefactos. Tenga en cuenta que podría tardar un tiempo en completarse si hay muchos repositorios (>1000).

./artifactory_list_users.py http://127.0.0.1:8081/artifactory
There are 23 repositories to process
Found user admin
Found user test
Found user user
Found user test_deploy

Permisos

Aquí están los permisos básicos y su utilidad:

Manage: ?
Delete/Overwrite: interesante para pentest
Deploy/Cache: interesante para pentest
Annotate: necesario para CVE-2020-7931
Read: generalmente un permiso predeterminado

Vulnerabilidades conocidas

Aquí hay una lista seleccionada de vulnerabilidades públicas de alto impacto:

CVE-2016-10036: Carga de archivo arbitraria y RCE (<4.8.6)

Detalles aquí.

Este es un poco antiguo y es poco probable que te encuentres con una versión tan desactualizada de Artifactory. Sin embargo, es bastante efectivo, ya que es una simple travesía de directorios que permite la ejecución de código arbitrario en el nivel de Tomcat.

CVE-2019-9733: Bypass de autenticación (<6.8.6)

Advertencia original aquí.

En versiones anteriores de Artifactory (hasta 6.7.3), la cuenta access-admin usaba una contraseña predeterminada password.

Normalmente, esta cuenta local está prohibida para acceder a la interfaz de usuario o la API, pero hasta la versión 6.8.6, Artifactory podía ser engañado para creer que la solicitud emanaba localmente si se establecía el encabezado HTTP X-Forwarded-For en 127.0.0.1.

CVE-2020-7931: Inyección de plantillas en el lado del servidor (Artifactory Pro)

Advertencia original aquí.

Aquí hay una herramienta que escribí para automatizar la explotación de esta vulnerabilidad.

Estos son necesarios para la explotación:

un usuario con derechos de implementación (crear archivos) y anotación (establecer filtrados)
Artifactory Pro

La vulnerabilidad es bastante simple: si un recurso implementado se establece en filtrado, se interpreta como una plantilla de Freemarker, lo que le da al atacante una ventana de ataque SSTI.

Aquí están los primitivos implementados:

lecturas básicas del sistema de archivos
escrituras limitadas del sistema de archivos

Estos deberían ser suficientes para darle ejecución de código remoto de varias maneras, desde la más fácil/silenciosa hasta la más difícil/ruidosa:

leyendo un secreto en el sistema de archivos que le permite pivotar (/home/user/.bash_history, /home/user/password.txt, /home/user/.ssh/id_rsa …)
agregando una clave SSH al usuario
implementando un archivo .war para ejecutar un servlet
implementando un script de usuario Groovy de Artifactory

Historias .war: travesuras de Java renameTo()

Esta es una pequeña historia de cómo me golpeé la cabeza contra la pared durante horas, si no días, durante una prueba de penetración. Me encontré con una versión desactualizada de Artifactory que sabía que era vulnerable a CVE-2020-7931. Implementé la plantilla SSTI original de la advertencia y comencé a buscar en el sistema de archivos. Parecía que Artifactory se había instalado en una ubicación no estándar, lo que no es demasiado inusual ya que a los administradores les gusta mantener particiones separadas entre binarios de aplicaciones, datos, registros y configuración (¡esto es algo bueno!). No había claves SSH o contraseñas en el directorio principal del usuario que me hubieran proporcionado un pivote fácil, así que llegó el momento de ser menos discreto y escribir en el sistema de archivos. La carga útil inicial (una clave pública) en el directorio de carga de Artifactory fue bien, pero simplemente no pude moverla al directorio de claves SSH. Así que volví a mi sandbox de explotación, lo probé de nuevo y, ¡oh sorpresa!, funcionó bien. Así que tenía que haber una configuración diferente que me impidiera completar el método renameTo(). En este punto, siempre es una buena idea consultar la documentación ... que claramente establece que no se pueden renombrar archivos en diferentes sistemas de archivos, lo que supongo que tiene sentido dependiendo de la implementación del método, es decir, si funciona a nivel de inodo. Arg.

¿Recuerdas lo que dije sobre los administradores que les gustan las particiones? Bueno, ¡este es un caso de un administrador que sin saberlo endureció su configuración contra mi explotación! Así que tuve que profundizar en lo que es esencialmente una cárcel de Java para encontrar otro método que me permitiera escribir un archivo en disco. Y eso no fue divertido en absoluto, ya que no estoy familiarizado con ninguna de las cosas involucradas: plantillas FTL, Java, Tomcat/Catalina. Rápidamente descubrí que las fugas de la cárcel de Java regulares simplemente no funcionarían, ya que instanciar nuevas clases estaba prohibido. Después de horas de leer la documentación de las clases de Java y Catalina, finalmente encontré un método write() en un objeto al que podía acceder. Pero estaba limitado a la ruta base de la aplicación web... Así que luego pensé en combinar la escritura en otro sistema de archivos y el renameTo() a través de este sistema de archivos recién alcanzable para, con suerte, poder escribir en cualquier lugar. Y funcionó un poco. Logré escribir fuera del directorio de carga temporal ... pero no tan lejos de él, ya que ahora estaba atrapado en otro sistema de archivos que era el punto de montaje de todas las cosas de Artifactory: configuración, aplicación y cosas. Así que todavía no hay clave SSH para mí.

De acuerdo, podría escribir en la carpeta raíz de Artifactory, ¿seguramente podría hacer algo aquí? Oye, ¿no hace Tomcat por defecto implementar archivos WAR escritos en su ruta de aplicación? Así que usé msfvenom para generar una shell web JSP empaquetada en un archivo WAR y lo probé en mi sandbox... bueno, se implementó correctamente, pero no me dio ejecución de comandos. Parece que el Tomcat predeterminado no maneja los JSP. Ugh. Cada vez más frustrado, busqué otra forma de ejecutar código en Tomcat y encontré otro método de ejecución usando servlets. No pude encontrar una carga útil adecuada, así que jódete, estoy todo adentro en este punto y desarrollé mi propio método que puedes encontrar aquí. Lo probé en el sandbox, funciona, bien. Lo puse en el objetivo, se implementa y... nada. Resulta que había un proxy delante de Artifactory que reescribía todas las URL a /artifactory. Así que aunque mi puerta trasera estaba implementada y funcionando, no había forma de acceder a ella... Si hubiera algún tipo de ejecución de código remoto para lograr en este punto, tendría que estar en el contexto de Artifactory, no de Tomcat.

Al día siguiente, estoy sollozando en mi escritorio mirando por última vez la documentación de Artifactory con la esperanza vana de una epifanía. Y luego aparecieron las palabras mágicas "scripts Groovy". Resulta que hay una forma complicada de ejecutar scripts Groovy, escribiéndolos en disco y luego recarg

cat artifactory.hashes
user:1f70548d73baca61aab8660733c7de81${CAFEBABEEBABEFAC}
john artifactory.hashes --format=dynamic_1
Loaded 1 password hash (dynamic_1 [md5($p.$s) (joomla) 256/256 AVX2 8x3])
password         (user)

El otro tipo de contraseña bcrypt no requiere nada especial, es simplemente un hash bcrypt estándar:

cat artifactory_bcrypt.hashes
admin:$2a$08$EbfHSAjPLoJnG/yHS/zmi.VizaWSipUuKAo7laKt6b8LePPTfDVeW
john artifactory_bcrypt.hashes
Loaded 1 password hash (bcrypt [Blowfish 32/64 X2])
password          (admin)

Secretos remotos

Artifactory puede necesitar almacenar secretos para identificarse en servicios remotos. Estos secretos no están hashados, por supuesto, se almacenan cifrados en el disco, con la clave junto a ellos. Hay dos tipos de secretos mencionados en la documentación oficial.

Formato antiguo (<5.9): DES-EDE

TODO. Abra un problema si tiene datos cifrados de muestra.

Nuevo formato (>=5.9): cifrado AES128-CBC, almacenado como base58

Los secretos externos (como las contraseñas de los servidores remotos) se encuentran en los descriptores de configuración, por ejemplo, /var/opt/jfrog/artifactory/etc/artifactory.config.latest.xml y se ven así:

<keyStorePassword>AM.25rLQ.AES128.vJMeKkaK6RBRQCUKJWvYEHUw6zs394X1CrRugvJsQGPanhMgQ5be8yjWDhJYC4BEz2KRE</keyStorePassword>

Donde:

AM siempre denota un secreto cifrado de Artifactory
25rLQ es el identificador del secreto que debe coincidir con el identificador de la clave
AES128 obviamente es el algoritmo utilizado
vJMeK...KRE es la codificación base58 de IV_SIZE|IV|secret|CRC

Se pueden encontrar más secretos (tokens, copias de seguridad de configuración...) utilizando la siguiente expresión regular:

grep -r 'AM\..*\.AES128\.' /var/opt/jfrog/artifactory/

La clave se almacena en /var/opt/jfrog/artifactory/etc/security/artifactory.key y tiene este aspecto:

JS.25rLQ.AES128.7fcJFd3Y2ib3wi4EHnhbvZuxu