자바 원격 메서드 호출 또는 _Java RMI_는 한 _자바 가상 머신_에 위치한 객체가 다른 _자바 가상 머신_에 위치한 객체의 메서드를 호출할 수 있도록 하는 객체 지향 RPC 메커니즘입니다. 이를 통해 개발자는 객체 지향 패러다임을 사용하여 분산 애플리케이션을 작성할 수 있습니다. 공격적인 관점에서 _Java RMI_에 대한 간단한 소개는 이 블랙햇 강연에서 확인할 수 있습니다.
기본 포트: 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
보통 기본 Java RMI 구성 요소(RMI Registry 및 Activation System)만 일반 포트에 바인딩됩니다. 실제 RMI 애플리케이션을 구현하는 _remote objects_는 위의 출력에서 보여준 것처럼 일반적으로 임의의 포트에 바인딩됩니다.
_nmap_은 때때로 _SSL_로 보호된 RMI 서비스를 식별하는 데 어려움을 겪습니다. 일반 RMI 포트에서 알 수 없는 ssl 서비스를 발견하면 추가 조사를 해야 합니다.
RMI 구성 요소
간단히 말해, _Java RMI_는 개발자가 _Java object_를 네트워크에서 사용할 수 있도록 합니다. 이는 클라이언트가 연결하고 해당 객체의 메서드를 호출할 수 있는 TCP 포트를 엽니다. 이게 간단하게 들리지만, _Java RMI_가 해결해야 할 여러 가지 도전 과제가 있습니다:
_Java RMI_를 통해 메서드 호출을 전송하려면 클라이언트는 IP 주소, 수신 포트, 구현된 클래스 또는 인터페이스 및 대상 객체의 ObjID를 알아야 합니다( ObjID는 객체가 네트워크에서 사용 가능해질 때 생성되는 고유하고 임의의 식별자입니다. _Java RMI_는 여러 객체가 동일한 TCP 포트에서 수신할 수 있도록 허용하기 때문에 필요합니다).
원격 클라이언트는 노출된 객체의 메서드를 호출하여 서버에서 리소스를 할당할 수 있습니다. _Java virtual machine_은 이러한 리소스 중 어떤 것이 여전히 사용 중인지, 어떤 것이 가비지 수집될 수 있는지를 추적해야 합니다.
첫 번째 도전 과제는 기본적으로 _Java RMI_의 이름 서비스인 _RMI registry_에 의해 해결됩니다. RMI registry 자체도 _RMI service_이지만, 구현된 인터페이스와 ObjID는 고정되어 있으며 모든 RMI 클라이언트가 알고 있습니다. 이를 통해 RMI 클라이언트는 해당 TCP 포트만 알면 RMI 레지스트리를 사용할 수 있습니다.
개발자가 자신의 _Java objects_를 네트워크 내에서 사용 가능하게 만들고자 할 때, 일반적으로 이를 _RMI registry_에 바인딩합니다. _registry_는 객체에 연결하는 데 필요한 모든 정보(IP 주소, 수신 포트, 구현된 클래스 또는 인터페이스 및 ObjID 값)를 저장하고 이를 사람이 읽을 수 있는 이름( bound name )으로 제공합니다. _RMI service_를 사용하려는 클라이언트는 해당 _bound name_에 대해 _RMI registry_에 요청하고, 레지스트리는 연결하는 데 필요한 모든 정보를 반환합니다. 따라서 상황은 기본적으로 일반 DNS 서비스와 동일합니다. 다음 목록은 작은 예제를 보여줍니다:
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();}}}
위에서 언급한 두 번째 도전 과제는 Distributed Garbage Collector (DGC)에 의해 해결됩니다. 이것은 잘 알려진 ObjID 값을 가진 또 다른 _RMI service_이며 기본적으로 모든 _RMI endpoint_에서 사용할 수 있습니다. _RMI client_가 _RMI service_를 사용하기 시작하면, 해당 _remote object_가 사용 중임을 _DGC_에 알리는 정보를 전송합니다. 그 후 _DGC_는 참조 수를 추적하고 사용되지 않는 객체를 정리할 수 있습니다.
더 이상 지원되지 않는 _Activation System_과 함께, 이들은 _Java RMI_의 세 가지 기본 구성 요소입니다:
RMI Registry (ObjID = 0)
Activation System (ObjID = 1)
Distributed Garbage Collector (ObjID = 2)
_Java RMI_의 기본 구성 요소는 꽤 오랫동안 알려진 공격 벡터였으며, 구식 Java 버전에는 여러 취약점이 존재합니다. 공격자의 관점에서 볼 때, 이러한 기본 구성 요소는 알려진 클래스/인터페이스를 구현했기 때문에 흥미롭고, 이들과 상호작용하는 것이 쉽습니다. 그러나 사용자 정의 _RMI services_의 경우 상황이 다릅니다. _remote object_에서 메서드를 호출하려면 해당 메서드 시그니처를 미리 알아야 합니다. 기존 메서드 시그니처를 모르면 _RMI service_와 통신할 방법이 없습니다.
RMI Enumeration
remote-method-guesser는 일반적인 _RMI vulnerabilities_를 자동으로 식별할 수 있는 Java RMI 취약점 스캐너입니다. RMI endpoint를 식별할 때마다 시도해 보아야 합니다:
$ 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
열거 작업의 출력은 프로젝트의 문서 페이지에서 더 자세히 설명되어 있습니다. 결과에 따라 식별된 취약점을 확인해 보아야 합니다.
_remote-method-guesser_에 의해 표시된 ObjID 값은 서비스의 가동 시간을 결정하는 데 사용될 수 있습니다. 이는 다른 취약점을 식별하는 데 도움이 될 수 있습니다:
열거 중에 취약점이 식별되지 않았더라도, 사용 가능한 RMI 서비스는 여전히 위험한 기능을 노출할 수 있습니다. 또한, RMI 기본 구성 요소에 대한 RMI 통신은 역직렬화 필터로 보호되지만, 사용자 정의 RMI 서비스와 대화할 때 이러한 필터는 일반적으로 적용되지 않습니다. 따라서 RMI 서비스에서 유효한 메서드 시그니처를 아는 것은 가치가 있습니다.
불행히도, _Java RMI_는 _원격 객체_에서 메서드를 열거하는 것을 지원하지 않습니다. 그렇다고 하더라도, remote-method-guesser 또는 rmiscout와 같은 도구를 사용하여 메서드 시그니처를 브루트포스하는 것은 가능합니다:
추측 외에도, 검색 엔진이나 _GitHub_에서 만난 RMI 서비스의 인터페이스나 구현을 찾아보는 것이 좋습니다. 여기서 _bound name_과 구현된 클래스 또는 인터페이스의 이름이 도움이 될 수 있습니다.
알려진 인터페이스
remote-method-guesser는 도구의 내부 데이터베이스에 나열된 _RMI 서비스_인 경우 클래스를 또는 인터페이스를 known으로 표시합니다. 이러한 경우 known 작업을 사용하여 해당 _RMI 서비스_에 대한 추가 정보를 얻을 수 있습니다:
$ 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}
Trickest를 사용하여 세계에서 가장 진보된 커뮤니티 도구로 구동되는 워크플로우를 쉽게 구축하고 자동화하세요.
오늘 바로 접근하세요:
