Użyj Trickest, aby łatwo budować i automatyzować przepływy pracy zasilane przez najbardziej zaawansowane narzędzia społecznościowe na świecie.
Uzyskaj dostęp już dziś:
Podstawowe informacje
Java Remote Method Invocation, czyli Java RMI, to obiektowy mechanizm RPC, który pozwala obiektowi znajdującemu się w jednej maszynie wirtualnej Java na wywoływanie metod obiektu znajdującego się w innej maszynie wirtualnej Java. Umożliwia to programistom pisanie rozproszonych aplikacji przy użyciu paradygmatu obiektowego. Krótkie wprowadzenie do Java RMI z ofensywnej perspektywy można znaleźć w tej prezentacji blackhat.
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
Zazwyczaj tylko domyślne komponenty Java RMI ( RMI Registry i Activation System ) są powiązane z powszechnymi portami. Obiekty zdalne implementujące rzeczywistą aplikację RMI są zazwyczaj powiązane z losowymi portami, jak pokazano w powyższym wyniku.
nmap czasami ma problemy z identyfikacją chronionych SSL usług RMI. Jeśli napotkasz nieznaną usługę ssl na powszechnym porcie RMI, powinieneś przeprowadzić dalsze dochodzenie.
Komponenty RMI
Mówiąc prosto, Java RMI pozwala deweloperowi udostępnić obiekt Java w sieci. Otwiera to port TCP, na którym klienci mogą się łączyć i wywoływać metody na odpowiednim obiekcie. Mimo że brzmi to prosto, istnieje kilka wyzwań, które Java RMI musi rozwiązać:
Aby przekazać wywołanie metody za pomocą Java RMI, klienci muszą znać adres IP, port nasłuchujący, zaimplementowaną klasę lub interfejs oraz ObjID docelowego obiektu ( ObjID to unikalny i losowy identyfikator, który jest tworzony, gdy obiekt jest udostępniany w sieci. Jest wymagany, ponieważ Java RMI pozwala wielu obiektom nasłuchiwać na tym samym porcie TCP ).
Zdalni klienci mogą alokować zasoby na serwerze, wywołując metody na udostępnionym obiekcie. Wirtualna maszyna Java musi śledzić, które z tych zasobów są nadal używane, a które mogą być zbierane przez garbage collector.
Pierwsze wyzwanie jest rozwiązywane przez RMI registry, które jest zasadniczo usługą nazewniczą dla Java RMI. RMI registry sam w sobie jest również usługą RMI, ale zaimplementowany interfejs i ObjID są stałe i znane wszystkim klientom RMI. Umożliwia to klientom RMI korzystanie z RMI registry tylko poprzez znajomość odpowiedniego portu TCP.
Gdy deweloperzy chcą udostępnić swoje obiekty Java w sieci, zazwyczaj wiążą je z RMI registry. Registry przechowuje wszystkie informacje potrzebne do połączenia z obiektem (adres IP, port nasłuchujący, zaimplementowana klasa lub interfejs oraz wartość ObjID) i udostępnia je pod nazwą czytelną dla ludzi ( bound name ). Klienci, którzy chcą korzystać z usługi RMI, pytają RMI registry o odpowiednią bound name, a rejestr zwraca wszystkie wymagane informacje do połączenia. Tak więc sytuacja jest zasadniczo taka sama jak w przypadku zwykłej usługi DNS. Poniższy listing pokazuje mały przykład:
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();}}}
Drugi z wymienionych powyżej problemów jest rozwiązywany przez Distributed Garbage Collector (DGC). Jest to kolejna usługa RMI z dobrze znaną wartością ObjID i jest dostępna praktycznie na każdym punkcie końcowym RMI. Kiedy klient RMI zaczyna korzystać z usługi RMI, wysyła informację do DGC, że odpowiadający obiekt zdalny jest w użyciu. DGC może wtedy śledzić liczbę referencji i jest w stanie oczyścić nieużywane obiekty.
Razem z przestarzałym Activation System, są to trzy domyślne komponenty Java RMI:
RMI Registry (ObjID = 0)
Activation System (ObjID = 1)
Distributed Garbage Collector (ObjID = 2)
Domyślne komponenty Java RMI są znanymi wektorami ataku od dłuższego czasu i istnieje wiele luk w przestarzałych wersjach Java. Z perspektywy atakującego, te domyślne komponenty są interesujące, ponieważ implementują znane klasy / interfejsy i łatwo można z nimi interagować. Sytuacja jest inna w przypadku niestandardowych usług RMI. Aby wywołać metodę na obiekcie zdalnym, musisz znać odpowiadający podpis metody z wyprzedzeniem. Bez znajomości istniejącego podpisu metody, nie ma możliwości komunikacji z usługą RMI.
RMI Enumeration
remote-method-guesser to skaner luk Java RMI, który jest w stanie automatycznie identyfikować powszechne luki RMI. Kiedy zidentyfikujesz punkt końcowy RMI, powinieneś spróbować:
$ 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
Wynik akcji enumeracji jest opisany bardziej szczegółowo na stronach dokumentacji projektu. W zależności od wyniku, powinieneś spróbować zweryfikować zidentyfikowane luki.
Wartości ObjID wyświetlane przez remote-method-guesser mogą być używane do określenia czasu działania usługi. Może to pozwolić na zidentyfikowanie innych luk:
Nawet gdy podczas enumeracji nie zidentyfikowano żadnych luk, dostępne RMI usługi mogą nadal ujawniać niebezpieczne funkcje. Ponadto, mimo że komunikacja RMI z domyślnymi komponentami RMI jest chroniona przez filtry deserializacji, w przypadku rozmowy z niestandardowymi usługami RMI takie filtry zazwyczaj nie są stosowane. Znajomość ważnych sygnatur metod w usługach RMI jest zatem cenna.
Niestety, Java RMI nie obsługuje enumeracji metod na obiektach zdalnych. Mimo to, możliwe jest bruteforcing sygnatur metod za pomocą narzędzi takich jak remote-method-guesser lub rmiscout:
Oprócz zgadywania, powinieneś również poszukać w wyszukiwarkach lub GitHub interfejsu lub nawet implementacji napotkanego RMI serwisu. Bound name oraz nazwa zaimplementowanej klasy lub interfejsu mogą być tutaj pomocne.
Znane interfejsy
remote-method-guesser oznacza klasy lub interfejsy jako known, jeśli są wymienione w wewnętrznej bazie danych narzędzia znanych RMI services. W tych przypadkach możesz użyć akcji known, aby uzyskać więcej informacji na temat odpowiadającego RMI service:
$ 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}
Użyj Trickest, aby łatwo budować i automatyzować przepływy pracy zasilane przez najbardziej zaawansowane narzędzia społecznościowe na świecie.
Uzyskaj dostęp już dziś: