Shulou(Shulou.com)06/01 Report--

Java how to call RMI remotely, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

JNDI

JNDI (Java Naming and Directory Interface,Java naming and Directory Interface) is a standard Java naming system interface provided by SUN. JNDI provides a unified client API. Through the implementation of different access provider interfaces JNDI service provider interfaces (SPI), managers map JNDI API to specific naming services and directory systems, so that Java applications can interact with these naming services and directory services.

JRMP

Java remote method Protocol (English: Java Remote Method Protocol,JRMP) is a protocol specific to Java technology that is used to find and reference remote objects. This is the line layer protocol that runs under Java remote method invocation (RMI) and above TCP/IP.

RMI

Java remote method call, namely Java RMI (Java Remote Method Invocation), is an application programming interface used to implement remote procedure calls in the Java programming language. It enables programs running on the client to call objects on the remote server. The remote method invocation feature enables Java programmers to distribute operations in a network environment. The whole purpose of RMI is to simplify the use of remote interface objects as much as possible.

Critical version of JDK

RMI attack vector

RMI Serialization Attack

Note: there are no version restrictions on this Demo, but some of the logic may differ due to version reasons.

Demo

With JDK 1.8.0_151

With java-rmi-server/ rmi.RMIServer 、 Services 、 PublicKnown

With java-rmi-client/ rmi.RMIClient 、 Services 、 ServicesImpl 、 PublicKnown

PS: the lower version cannot have a valid breakpoint under RegistryImpl_Skel.

Analysis.

The difference between two kinds of bind

Server RMI Registry Client

When server registers the service through bind, it serializes the transport service name & Ref, so it goes into RegistryImpl_Skel.dispatch and gets it first by deserialization.

Server (RMI Registry) Client

In this mode, because server and Registry are on the same machine, there is no need for serialization transmission because there is already its Ref on the server when the bind is registered, just add the corresponding key value to the bindings list.

Registration, request process

The core of RMI Registry is RegistryImpl_Skel. When Server executes bind and Client executes lookup, it will be processed through sun.rmi.registry.RegistryImpl_Skel#dispatch.

Bind

First notice that ServiceImpl inherits UnicastRemoteObject and creates a stub that returns this service through exportObject when instantiated.

Public class ServiceImpl extends UnicastRemoteObject implements Service {.} / * * Exports the specified object using the specified server ref.*/private static Remote exportObject (Remote obj, UnicastServerRef sref) throws RemoteException {/ / if obj extends UnicastRemoteObject, set its ref.if (obj instanceof UnicastRemoteObject) {((UnicastRemoteObject) obj). Ref = sref;} return sref.exportObject (obj, null, false);}

Then apply to the RMI Registry server to register and bind the service name through bind & stub follows into sun.rmi.registry.RegistryImpl_Stub#bind, and notice that when applying to RMI Registry, the third parameter corresponds to the operation in operations.

In particular, the two writeObject write the serialized service name, stub, to the output stream of var3.

When RMI Registry receives the application, it will enter the relevant process through the passed operation value, enter bind at 0: 00, and note that readObject deserializes twice to obtain the service name & stub, and then writes the key value to bindings List.

This leads to a point: Server performs a serialization attack by requesting a bind operation from RMI Registry.

Lookup

Again, when Client applies to RMI Registry for a lookup lookup (sun.rmi.registry.RegistryImpl_Stub#lookup), the Operand passed is 2, and the target service name is deserialized.

RMI

Registry (sun.rmi.registry.RegistryImpl_Skel#dispatch) will also deserialize the query service name first, and then query it from bindings list.

This leads to another point: Client performs a serialization attack by requesting a lookup operation from RMI Registry.

But is it over?

We look down and notice that the writeObject appears on line 86, where the stub serialization from the query is transferred to Client.

Going back to the code in Client, you can see the readObject of 104 lines.

This leads to a third point: RMI Registry passively attacks Client through lookup operations.

Serialize on call

Now that we've sorted out some of the contents of bind and lookup, how does client implement remote calls?

Through the follow-up, we can see that the

The dynamic proxy implemented by java.rmi.server.RemoteObjectInvocationHandler and finally called by the sun.rmi.server.UnicastRef#invoke implementation.

In the call, we notice that the parameters are packaged by marshalValue, and the content returned is deserialized by unmarshalValue.

Limit

Demo here is very difficult to encounter in practice, because evil is generated based on known Services and PublicKnown (including known vulnerabilities), and local gadget is more often used in attacks.

Attack direction

Notice that we have put forward three attack directions.

1.Server performs a serialization attack by requesting a bind operation from RMI Registry

2.Client performs a serialization attack by requesting a lookup operation from RMI Registry

3.RMI Registry passively attacks Client through lookup operations.

In fact, note that the Server mentioned in the first point does not have to be initiated by the target server. For example, any server (including the attacker) can initiate a registration request to the registry and attack the RMI Registry through bind, for example:

Client-- bind-- > RMI Registry (Server)

The same is true in the second and third points, so let's update it:

1. Request a bind operation from RMI Registry for serialization attack

two。 Request a lookup operation from RMI Registry for serialization attack

3.RMI Registry passively serializes the attack requestor through lookup operations.

Bind-RMIRegistryExploit

With JDK 1.7.0_17

With java-rmi-server/ rmi.RMIServer2

With ysoserial.exploit.RMIRegistryExploit

Ysoserial.exploit.RMIRegistryExploit actually corresponds to the direction of bind attack, so let's take a brief look at its code.

The core lies in two points. For the first point, you can take a look at cc1 Analysis and the Java dynamic Agent-practice article.

Sun.reflect.annotation.AnnotationInvocationHandler dynamic proxy Remote.class

Bind operation

It is mentioned here why dynamic proxies are needed because in sun.rmi.registry.RegistryImpl_Skel#dispatch, when bind is executed, it is deserialized by Remote.readObject, resulting in a call to the

AnnotationInvocationHandler.invoke .

RMI Remote Object

Codebase delivery and useCodebaseOnly

An important feature of RMI is the dynamic class loading mechanism. When the corresponding class cannot be found in the local CLASSPATH, the class will be loaded in the specified codebase.

Java.rmi.server.useCodebaseOnly=false is required, but this feature is enabled until 6u45 and 7u21 change the default to true to defend against attacks.

Here is a quote from the official document Enhancements in JDK 7:

If the JVM on one side of the RMI connection specifies one or more URL in its java.rmi.server.codebase system properties, the information is passed to the other side through the RMI connection. If the receiver JVM's java.rmi.server.useCodebaseOnly system property is set to false, it will attempt to use these URL to load the Java class referenced in the RMI request flow.

The behavior of loading a class from a location specified by the remote side connected by RMI, when disabled

Java.rmi.server.useCodebaseOnly is set to true. In this case, only from a preconfigured location such as the locally specified

The java.rmi.server.codebase property or local CLASSPATH) loads the class instead of from the information passed by codebase through the RMI request stream.

Demo

Client attacks Server

With JDK 1.7.0_17

With java-rmi-server/rmi.RMIServer2

With java-rmi-client/rmi.RMIClient2 、 remote.RemoteObject

If Client specifies the codebase address, when Server loads the target class, it will now look for it in the local classpath, and if it cannot find it, it will look for the specified address again through codebase.

In order to be able to load the target class remotely, you need Server to load and configure RMISecurityManager, and also set:

Java.rmi.server.useCodebaseOnly=false

How is it called after the codebase is transferred?

Is also created by dynamic proxy classes

Java.rmi.server.RemoteObjectInvocationHandler#invokeRemoteMethod implements remote calls.

After receiving the call instruction, Server enters the

Sun.rmi.server.MarshalInputStream#resolveClass

Because useCodebaseOnly is false, the target class is read remotely from the address specified by the client.

After reading all of them, go back to

Java.io.ObjectInputStream#readOrdinaryObject

Call

Java.io.ObjectStreamClass#initNonProxy is instantiated.

Server attacks Client

With JDK 1.7.0_17

With java-rmi-server/rmi.RMIServer3 、 remote.RemoteObject2

With java-rmi-client/rmi.RMIClient3

By comparison, we can see that the logic is consistent from sun.rmi.server.UnicastRef#invoke, but the upper layer calls come from different sources, so I won't repeat it any more.

Distinguish the direction of attack

Method invocation requests are all from Client.

But the difference is that

The logic code at sun.rmi.server.UnicastRef#invoke (java.rmi.Remote,java.lang.reflect.Method,java.lang.Object [], long).

Line 79: Client attacks Server by letting Server request remote Class to produce results. Because of the security of the local malicious class of the same name, it will not cause an attack on the local.

Line 89: Server attacks Clinet because Client needs to obtain remote Class for local deserialization after obtaining the security result.

JRMP

With JDK 1.7.0_80

With java-rmi-server/rmi.RMIServer2

It depends on the situation:

In the RMI communication process mentioned above, it is assumed that when the client communicates with the RMI server, although it also communicates on the JRMP protocol and attempts to transmit a serialized malicious object to the server, if the server also returns a malicious serialized object from the client, then the client may also be attacked. The client can communicate with socket using JRMP, and the client directly uses the JRMP protocol to send data without receiving the return from the server. Therefore, this kind of attack is also more secure.

Here we analyze several related Class of ysoserial, first enumerate the related functions.

Payloads.JRMPListener enables JRMP snooping service on the target server's target port-independent utilization

Payloads.JRMPClient sends registration Ref, destination exploit.JRMPListener address to the target server

Exploit.JMRPListener passive requestor transmits serialized payload

Exploit.JRMPClient actively transmits serialized payload to the target server

In addition, we need to know something about DGC in order to understand the following.

RMI.DGC provides classes and interfaces for RMI distributed garbage collection. When the RMI server returns an object to its client (the caller of the remote method), it tracks the use of the remote object in the client. When there are no more references to the remote object on the client, or if the referenced "lease" expires and is not updated, the server will garbage collect the remote object.

Payloads.JRMPListener

Before we learn, let's take a look at the two interface implementations of JAVA native serialization.

1.Serializable API: writeObject, readObject, writeReplace, readResolve are required

2.Externalizable API: writeExternal and readExternal are required.

Analysis.

Back in JRMPListener, the code is simple, and the main function is to generate a payload that opens the target port to listen to the RMI service.

We first follow in

Ysoserial.payloads.util.Reflections#createWithConstructor, understand the function logic.

1. First look for the constructor under RemoteObject whose parameter type is RemoteRef.

two。 Dynamically generate a new constructor and generate an instance for ActivationGroupImpl based on the found constructor.

Why do you need this? In fact, it is to avoid calling the constructor of ActivationGroupImpl itself, to avoid complex or other uncontrollable problems.

Let's take a look at what UnicastRemoteObject does during the serialization phase, follow from reexport to exportObject, create a listener and return this stub.

In addition, through the above analysis, in fact, we only need UnicastRemoteObject to enable monitoring utilization, the following two can also be used, but wonder why the author uses subclass conversion?

ActivationGroupImpl uro = Reflections.createWithConstructor (ActivationGroupImpl.class, RemoteObject.class, new Class [] {RemoteRef.class}, new Object [] {new UnicastServerRef (jrmpPort)}); UnicastRemoteObject uro = Reflections.createWithConstructor (UnicastRemoteObject.class, RemoteObject.class, new Class [] {RemoteRef.class}, new Object [] {new UnicastServerRef (jrmpPort)})

Utilization

Java-cp ysoserial-master.jar ysoserial.exploit.XXXXX JRMPListener java-cp ysoserial-master.jar ysoserial.exploit.JRMPClient

Payloads.JRMPClient

Analysis.

As the core code of payloads is still not much, generate ref and encapsulate it into handler, dynamically proxy Registry class.

In fact, we can set it to Null for ClassLoader, and this question can be answered through the resource link above.

As for why Qiang changed to Registry? Just because we dynamically proxy this class, we integrate various methods that require proxy classes, and we can replace them with any Object subclass when these methods are not called.

Now let's look at the code logic:

When we pass an proxy ready for serialization, we also serialize its members to the effect that we don't expand here, we need to see the serialization for ourselves, so we call its parent class RemoteObject.readObject ()

Notice that the readExternal method is finally called for the reasons mentioned above.

Here will be called

Sun.rmi.server.UnicastRef#readExternal

And then enter

Sun.rmi.transport.LiveRef#read

However, it is not possible to enter the DGCClient registration here, but the ref information is stored in the

In ConnectionInputStream.incomingRefTable.

When the input connection is finally released, the ref in incomingRefTable is registered.

Why would you do that? The java notes are written, but the details are not found.

/ * Save reference in order to send "dirty" call after all args/returns* have been unmarshaled. Save in hashtable incomingRefTable. This* table is keyed on endpoints, and holds objects of type* IncomingRefTableEntry.*/

The process in sun.rmi.transport.DGCImpl_Skel#dispatch is similar to that in annotations.

When you go back to ref registration, you will actually register refs in DGCClient.

Then the transmitted data is directly deserialized and parsed, and the content here is placed in

Explained in exploit.JRMPListener.

Therefore, after analyzing the whole process, we do not see the need to use dynamic proxies, so it is sufficient to serialize and transfer RemoteObject subclasses directly when generating payload, while the native easy-to-control subclass is RemoteObjectInvocationHandler, that is:

Utilization

Payloads.JRMPClient is used in conjunction with exploit.JRMPListener.

Java-cp ysoserial-master.jar ysoserial.exploit.JRMPListener java-cp ysoserial-master.jar ysoserial.exploit.XXXXX JRMPClient:

Exploit.JRMPListener

Distinguish the difference between the two JRMPListener

Payloads.JRMPListener turns on JMRP snooping on the target machine

Exploit.JRMPListener implements responses to JRMP Client requests

Analysis.

You can see from Main that the basic logic is to open the listening JRMP port and wait for the connection to transmit malicious payload.

The protocol is parsed during monitoring, and connections that are StreamProtocol or SingleOpProtocol are answered through doMessage.

In doMessage, payload packets are sent to remote RMI calls.

So where is payload populated?

Notice that this code in the doCall function is the same as the entry point for cc5.

It is important to note, however, that the trigger point of BadAttributeValueExpException.readObject is not necessarily valObj.toSting (), and there are a lot of inexplicable phenomena during debugging.

Leaving aside the subsequent utilization, let's look at how the target requests JRMPListener from the beginning.

The Ref will be registered with the DGCClient and transmitted through 80 requests and 81 responses. Here, you can focus on the call stack and learn about the above DGC content.

So how did 80 come into being?

80 is written directly to the first byte when you see StreamRemoteCall initialization.

The target then reads the value pair passed by Listener and then chooses whether or not to deserialize the content, and the deserialized content is connected to it.

In addition, the meaning of var1 here is to determine whether the Listener is returned normally. If an exception error occurs on the Listener side for some reason, the error message needs to be passed back to the request side, and the message is serialized, so deserialization will be triggered on the request side.

Utilization

If you can't make use of it directly, you need to send payloads.JRMPClient to the target machine for passive attack.

Java-cp ysoserial-master.jar ysoserial.exploit.JRMPListener

Exploit.JRMPClient

Distinguish the difference between the two JRMPClient, and RMIRegistry

Exploit

Payloads.JRMPClient registers Ref with the target DGC

Exploit.JRMPClient transmits serialized payload to destination DGC

Exploit.RMIRegistryExploit transmits serialized payload to destination RMI.Registry, targeting RMI.Registry listening port

The following is the different information of listening ports opened by payloads.JRMPListener and RMI.Registry under nmap scanning:

Exploit.JRMPClient can attack both.

Exploit.RMIRegistryExploit can only attack the latter.

Analysis.

Read the Int data in sun.rmi.server.UnicastServerRef#dispatch first.

And then in

Read Long data in sun.rmi.server.UnicastServerRef#oldDispatch.

After entering the sun.rmi.transport.DGCImpl_Skel#dispatch, first determine whether the read Long data, that is, the interface hash value, is the same.

Then the corresponding processing is carried out according to the Int data read before.

Utilization

Java-cp ysoserial-master.jar ysoserial.exploit.JRMPClient JNDI Reference

The content about JNDI has been covered at the beginning of the article, and there is no additional need here for the time being.

Demo

With JDK 1.7.0_17

With jndi\ rmi.RMIClient, rmi.RMIServer

Analysis.

Let's follow up on Client and execute lookup to see what happens.

Similarly, Client requests Server to query the stub corresponding to test_service, and then executes to com.sun.jndi.rmi.registry.RegistryContext#decodeObject to get the ref of the target class.

And then bring the ref to

The remote factory class is loaded in javax.naming.spi.NamingManager#getObjectInstance (so writing the first class parameter on the Server side of the new Reference does not affect it).

This means that when the Client performs the lookup operation, it loads the remote malicious class directly to RCE without any other gadget.

Defense

Due to the default configuration of com.sun.jndi.rmi.object.trustURLCodebase=false from 6u141, 7u131 and 8u121, direct remote loading is restricted. The error message is as follows:

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.