Use Trickest para construir e automatizar fluxos de trabalho facilmente, impulsionados pelas ferramentas comunitárias mais avançadas do mundo.
Acesse hoje:
A Invocação de Métodos Remotos Java, ou Java RMI, é um mecanismo RPC orientado a objetos que permite que um objeto localizado em uma máquina virtual Java chame métodos em um objeto localizado em outra máquina virtual Java. Isso permite que os desenvolvedores escrevam aplicações distribuídas usando um paradigma orientado a objetos. Uma breve introdução ao Java RMI de uma perspectiva ofensiva pode ser encontrada nesta palestra do blackhat.
Porta padrão: 1090,1098,1099,1199,4443-4446,8999-9010,9999
PORT STATE SERVICE VERSION
1090/tcp open ssl/java-rmi Java RMI
9010/tcp open java-rmi Java RMI
37471/tcp open java-rmi Java RMI
40259/tcp open ssl/java-rmi Java RMI
Geralmente, apenas os componentes padrão Java RMI (o RMI Registry e o Activation System) estão vinculados a portas comuns. Os objetos remotos que implementam a aplicação RMI real geralmente estão vinculados a portas aleatórias, como mostrado na saída acima.
o nmap às vezes tem problemas para identificar serviços RMI protegidos por SSL. Se você encontrar um serviço ssl desconhecido em uma porta RMI comum, deve investigar mais a fundo.
Componentes RMI
Para simplificar, Java RMI permite que um desenvolvedor torne um objeto Java disponível na rede. Isso abre uma porta TCP onde os clientes podem se conectar e chamar métodos no objeto correspondente. Apesar de parecer simples, existem vários desafios que o Java RMI precisa resolver:
Para despachar uma chamada de método via Java RMI, os clientes precisam conhecer o endereço IP, a porta de escuta, a classe ou interface implementada e o ObjID do objeto alvo (o ObjID é um identificador único e aleatório que é criado quando o objeto é disponibilizado na rede. É necessário porque o Java RMI permite que múltiplos objetos escutem na mesma porta TCP).
Clientes remotos podem alocar recursos no servidor invocando métodos no objeto exposto. A máquina virtual Java precisa rastrear quais desses recursos ainda estão em uso e quais podem ser coletados como lixo.
O primeiro desafio é resolvido pelo RMI registry, que é basicamente um serviço de nomeação para Java RMI. O RMI registry em si também é um serviço RMI, mas a interface implementada e o ObjID são fixos e conhecidos por todos os clientes RMI. Isso permite que os clientes RMI consumam o RMI registry apenas conhecendo a porta TCP correspondente.
Quando os desenvolvedores querem tornar seus objetos Java disponíveis na rede, geralmente os vinculam a um RMI registry. O registry armazena todas as informações necessárias para se conectar ao objeto (endereço IP, porta de escuta, classe ou interface implementada e o valor ObjID) e as torna disponíveis sob um nome legível por humanos (o nome vinculado). Clientes que desejam consumir o serviço RMI perguntam ao RMI registry pelo nome vinculado correspondente e o registry retorna todas as informações necessárias para a conexão. Assim, a situação é basicamente a mesma que com um serviço DNS comum. A listagem a seguir mostra um pequeno exemplo:
importjava.rmi.registry.Registry;importjava.rmi.registry.LocateRegistry;importlab.example.rmi.interfaces.RemoteService;publicclassExampleClient {privatestaticfinalString remoteHost ="172.17.0.2";privatestaticfinalString boundName ="remote-service";publicstaticvoidmain(String[] args){try {Registry registry =LocateRegistry.getRegistry(remoteHost); // Connect to the RMI registryRemoteService ref = (RemoteService)registry.lookup(boundName); // Lookup the desired bound nameString response =ref.remoteMethod(); // Call a remote method} catch( Exception e) {e.printStackTrace();}}}
O segundo dos desafios mencionados acima é resolvido pelo Distributed Garbage Collector (DGC). Este é outro RMI service com um valor ObjID bem conhecido e está disponível em basicamente cada RMI endpoint. Quando um RMI client começa a usar um RMI service, ele envia uma informação para o DGC de que o correspondente remote object está em uso. O DGC pode então rastrear a contagem de referências e é capaz de limpar objetos não utilizados.
Juntamente com o Activation System obsoleto, estes são os três componentes padrão do Java RMI:
O RMI Registry (ObjID = 0)
O Activation System (ObjID = 1)
O Distributed Garbage Collector (ObjID = 2)
Os componentes padrão do Java RMI têm sido vetores de ataque conhecidos há bastante tempo e múltiplas vulnerabilidades existem em versões desatualizadas do Java. Do ponto de vista de um atacante, esses componentes padrão são interessantes, porque implementam classes / interfaces conhecidas e é facilmente possível interagir com eles. Esta situação é diferente para RMI services personalizados. Para chamar um método em um remote object, você precisa conhecer a assinatura do método correspondente com antecedência. Sem conhecer uma assinatura de método existente, não há como se comunicar com um RMI service.
RMI Enumeration
remote-method-guesser é um scanner de vulnerabilidades Java RMI que é capaz de identificar automaticamente vulnerabilidades comuns de RMI. Sempre que você identificar um RMI endpoint, deve tentar:
$ rmg enum 172.17.0.2 9010
[+] RMI registry bound names:
[+]
[+] - plain-server2
[+] --> de.qtc.rmg.server.interfaces.IPlainServer (unknown class)
[+] Endpoint: iinsecure.dev:37471 TLS: no ObjID: [55ff5a5d:17e0501b054:-7ff7, 3638117546492248534]
[+] - legacy-service
[+] --> de.qtc.rmg.server.legacy.LegacyServiceImpl_Stub (unknown class)
[+] Endpoint: iinsecure.dev:37471 TLS: no ObjID: [55ff5a5d:17e0501b054:-7ffc, 708796783031663206]
[+] - plain-server
[+] --> de.qtc.rmg.server.interfaces.IPlainServer (unknown class)
[+] Endpoint: iinsecure.dev:37471 TLS: no ObjID: [55ff5a5d:17e0501b054:-7ff8, -4004948013687638236]
[+]
[+] RMI server codebase enumeration:
[+]
[+] - http://iinsecure.dev/well-hidden-development-folder/
[+] --> de.qtc.rmg.server.legacy.LegacyServiceImpl_Stub
[+] --> de.qtc.rmg.server.interfaces.IPlainServer
[+]
[+] RMI server String unmarshalling enumeration:
[+]
[+] - Caught ClassNotFoundException during lookup call.
[+] --> The type java.lang.String is unmarshalled via readObject().
[+] Configuration Status: Outdated
[+]
[+] RMI server useCodebaseOnly enumeration:
[+]
[+] - Caught MalformedURLException during lookup call.
[+] --> The server attempted to parse the provided codebase (useCodebaseOnly=false).
[+] Configuration Status: Non Default
[+]
[+] RMI registry localhost bypass enumeration (CVE-2019-2684):
[+]
[+] - Caught NotBoundException during unbind call (unbind was accepeted).
[+] Vulnerability Status: Vulnerable
[+]
[+] RMI Security Manager enumeration:
[+]
[+] - Security Manager rejected access to the class loader.
[+] --> The server does use a Security Manager.
[+] Configuration Status: Current Default
[+]
[+] RMI server JEP290 enumeration:
[+]
[+] - DGC rejected deserialization of java.util.HashMap (JEP290 is installed).
[+] Vulnerability Status: Non Vulnerable
[+]
[+] RMI registry JEP290 bypass enmeration:
[+]
[+] - Caught IllegalArgumentException after sending An Trinh gadget.
[+] Vulnerability Status: Vulnerable
[+]
[+] RMI ActivationSystem enumeration:
[+]
[+] - Caught IllegalArgumentException during activate call (activator is present).
[+] --> Deserialization allowed - Vulnerability Status: Vulnerable
[+] --> Client codebase enabled - Configuration Status: Non Default
A saída da ação de enumeração é explicada em mais detalhes nas páginas de documentação do projeto. Dependendo do resultado, você deve tentar verificar as vulnerabilidades identificadas.
Os valores ObjID exibidos pelo remote-method-guesser podem ser usados para determinar o tempo de atividade do serviço. Isso pode permitir identificar outras vulnerabilidades:
Mesmo quando nenhuma vulnerabilidade foi identificada durante a enumeração, os serviços RMI disponíveis ainda podem expor funções perigosas. Além disso, apesar da comunicação RMI com componentes padrão RMI ser protegida por filtros de desserialização, ao se comunicar com serviços RMI personalizados, esses filtros geralmente não estão em vigor. Conhecer assinaturas de métodos válidas em serviços RMI é, portanto, valioso.
Infelizmente, Java RMI não suporta a enumeração de métodos em objetos remotos. Dito isso, é possível bruteforçar assinaturas de métodos com ferramentas como remote-method-guesser ou rmiscout:
Além de adivinhar, você também deve procurar em motores de busca ou GitHub pela interface ou até mesmo pela implementação de um serviço RMI encontrado. O bound name e o nome da classe ou interface implementada podem ser úteis aqui.
Known Interfaces
remote-method-guesser marca classes ou interfaces como known se elas estiverem listadas no banco de dados interno da ferramenta de serviços RMI conhecidos. Nesses casos, você pode usar a ação known para obter mais informações sobre o serviço RMI correspondente:
$ rmg enum 172.17.0.2 1090 | head -n 5
[+] RMI registry bound names:
[+]
[+] - jmxrmi
[+] --> javax.management.remote.rmi.RMIServerImpl_Stub (known class: JMX Server)
[+] Endpoint: localhost:41695 TLS: no ObjID: [7e384a4f:17e0546f16f:-7ffe, -553451807350957585]
$ rmg known javax.management.remote.rmi.RMIServerImpl_Stub
[+] Name:
[+] JMX Server
[+]
[+] Class Name:
[+] - javax.management.remote.rmi.RMIServerImpl_Stub
[+] - javax.management.remote.rmi.RMIServer
[+]
[+] Description:
[+] Java Management Extensions (JMX) can be used to monitor and manage a running Java virtual machine.
[+] This remote object is the entrypoint for initiating a JMX connection. Clients call the newClient
[+] method usually passing a HashMap that contains connection options (e.g. credentials). The return
[+] value (RMIConnection object) is another remote object that is when used to perform JMX related
[+] actions. JMX uses the randomly assigned ObjID of the RMIConnection object as a session id.
[+]
[+] Remote Methods:
[+] - String getVersion()
[+] - javax.management.remote.rmi.RMIConnection newClient(Object params)
[+]
[+] References:
[+] - https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html
[+] - https://github.com/openjdk/jdk/tree/master/src/java.management.rmi/share/classes/javax/management/remote/rmi
[+]
[+] Vulnerabilities:
[+]
[+] -----------------------------------
[+] Name:
[+] MLet
[+]
[+] Description:
[+] MLet is the name of an MBean that is usually available on JMX servers. It can be used to load
[+] other MBeans dynamically from user specified codebase locations (URLs). Access to the MLet MBean
[+] is therefore most of the time equivalent to remote code execution.
[+]
[+] References:
[+] - https://github.com/qtc-de/beanshooter
[+]
[+] -----------------------------------
[+] Name:
[+] Deserialization
[+]
[+] Description:
[+] Before CVE-2016-3427 got resolved, JMX accepted arbitrary objects during a call to the newClient
[+] method, resulting in insecure deserialization of untrusted objects. Despite being fixed, the
[+] actual JMX communication using the RMIConnection object is not filtered. Therefore, if you can
[+] establish a working JMX connection, you can also perform deserialization attacks.
[+]
[+] References:
[+] - https://github.com/qtc-de/beanshooter
Protocol_Name: Java RMI #Protocol Abbreviation if there is one.
Port_Number: 1090,1098,1099,1199,4443-4446,8999-9010,9999 #Comma separated if there is more than one.
Protocol_Description: Java Remote Method Invocation #Protocol Abbreviation Spelled out
Entry_1:
Name: Enumeration
Description: Perform basic enumeration of an RMI service
Command: rmg enum {IP} {PORT}
Use Trickest para construir e automatizar fluxos de trabalho facilmente, impulsionados pelas ferramentas comunitárias mais avançadas do mundo.
Obtenha Acesso Hoje:
