这篇文章给大家介绍怎么浅析反序列化POC,内容非常详细,感兴趣的小伙伴们可以参考借鉴,希望对大家能有所帮助。CommonsCollections的利用就是一部反序列化漏洞腥风血雨的历史。CommonsCollections类型的POC编写:CC反射链的编写离不开四个Transformer类:ConstantTransformer,invokerTransformer,ChainedTransformer,TransfoeredMap第一个ConstantTransformer负责输入一个xxx.class,返回java.lang.Class的类对象,这个是为了后续调用获得getMethod的对象。第一个invokerTransformer相当于执行Method getRun = Runtime.class.getMethod(“getRuntime”,参数类型说明)通过反射传入getRuntime参数的getMethod方法,当然传入这个方法反射得到的结果是,getRuntime的Method对象。第二个invokerTransformer相当于执行Runtime getRun = getRun.invoke();第三个invokerTransformer相当于执行Method getexec = Runtime.class.getMethod(“exec”,参数类型说明)getexec.invoke(getRun,需要执行的命令)最后通过给ChainedTransformer传入Transform数组,再将ChainedTransformer传入TranformedMap,进行decorate,EntrySet转化,最后触发TranformedMap类的setValue方法,通过setValue方法逐个触发Transformer类的transform方法。参见:https://mp.weixin.qq.com/s/OMXrFc7uUN8wGv6yHno3Lghttps://www.freebuf.com/articles/web/246081.htmlLazyMap类型POC的构造LazyMap的调用还是与TransformedMap的调用有些不同,因为LazyMap没有setValue方法,那么就要想办法去调用LazyMap的get方法。通过get方法去触发ChainedTransformer的transfrom方法,这个时候就不能使用编写TransformedMap那样的套路去玩了。需要使用动态代理机制去触发AnnotationInvocationHandler类的invoke方法那就需要构造两次InvocationHandler代理,第一次构造是为了LazyMap的代理对象再进行任何方法调用的时候进行invoke方法中default选项的触发,第二次为了让InvocationHandler代理对象进行readObject方法调用。参见:https://www.freebuf.com/articles/web/247672.htmlBadAttributeValueExpException类型POC编写BadAttributeValueExpException类的readObject方法调用了传入数据流的val域的toString方法。那么就找一个val域有toString方法的类,而且这个类toString方法可以触发LazyMap对象的get操作,这个类可以传入LazyMap对象。TiedMapEntry正好满足:toString方法调用getValue方法getValue方法,调用map类型对象的get方法,而LazyMap又是map接口的实现类,完美。实现过程:CC链传入ChainedTransformer,ChainedTransformer传入LazyMap,LazyMap传入TiedMapEntry,TiedMapEntry作为BadAttributeValueExpException的val域的引用,经过序列化的BadAttributeValueExpException进行readObject,readObject调用val域的toSting,toString调用getValue,getValue调用get,get触发ChainedTransformer的transform方法,ChainedTransformer的transform方法触发Transformer数组的transform方法。weblogic XMLDecoder是基于SOAP去解析的,具体的分析文章网上都有,后面会附加参考链接。简单来说XMLDecoder的修补史就是SOAP标签的绕过史首先看CVE-2017-3506,因为XMLDecoder对SOAP形式的XML文件进行解析,对WorkContext标签内的所有标签进行解析,将java标签下的第一个职位class的object标签解析为需要加载的类,将最后一个class值为method的void标签解析为加载的类所要使用的方法,将array标签内class的值解析为方法的参数类型,length为参数的个数,中间的void+string类型的标签为方法执行的各个参数值。接着看CVE-2017-10271对CVE-2017-3506的补丁内容:只是过滤了object标签,那又找了新的类去绕过,voidElementHandler继承自ObjectElementHandler所以,void标签,自然也就可以按照Object标签进行解析处理了。只是过滤了object标签,那又找了新的类去绕过,voidElementHandler继承自ObjectElementHandler所以,void标签,自然也就可以按照Object标签进行解析处理了。接下来贴出一个CVE-2017-10271&CVE-2017-3506的通用POC再看CVE-2019-2725对之前的补丁:平安团队对此进行了分析,最后的结论:1、 禁用 object、new、method 标签2、 如果使用 void 标签,只能有 index 属性3、 如果使用 array 标签,且标签使用的是 class 属性,则它的值只能是 byte但是class标签还在,这个标签可以声明需要免费云主机域名调用的类,还有惊喜,就是array标签可以使用,只要是byte类型就行。那么现在需要找到这次出问题的地方,看之前的补丁。那就找一个既可以解析byte类型的构造方法的类,UnitOfWorkChangeSet(盗个图)那就让它调用这个类,给这个类传递byte数组这里在weblogic 10.3.6(JDK 1.6)的环境下复现:首先这个类的构造方法可以readObject,那就先构造这样一个类。先用ysoserial生成commons-collection生成一个反序列化文件。然后将这个反序列化转化为16进制,一个字节是8个二进制位,一个字节相当于2个16进制位,16进制转化为byte型,并进行POC的拼接。每一段反序列化数据必定以ac ed开头,那么第一个字节的值就应该是:ac=10101100=172,但是byte的存储范围是-128~+127,这个明显是溢出了,然而计算机的存储是按照补码进行存储的,补码到原码的计算应该是符号位为1,其余各位取反,然后再整个数加1。11010011+00000001=11010100=-84,这就是为什么POC中第一个开头的字节值为-84。那么接下来编写生成POC的py脚本。反序列化文件转化思路:先将文件中中的数据转化为16进制,然后两个16进制数为一组,并在其之前拼接’0x’然后将其归为一个列表的元素。进制转换思路:如果两个16进制的10进制值小于127,那么不对它进行操作,保留原值,如果不是则对其进行原码运算,最后转为10进制值。原码运算思路:补码-1,得到反码,反码除符号位外按位取反。将这些10进制的值挨个拼接到XML的标签中。代码如下:然后发送到/wls-wsat/的接口中,成功弹出计算器。(这里有一个疑问,为什么别人编写的POC要去掉
这里注意,POC都顶格写啊,为什么,参见廖师傅的文章:http://xxlegend.com/参考链接:https://www.freebuf.com/vuls/206374.htmlT3这个东西吧,存在即合理,所以每次都被安全研究的大佬们找到内部类,然后通过序列化数据加载内部类。T3协议的作用说白了,T3就是另类的远程方法调用T3反序列化数据的构成T3的数据流程是这样接收的,客户端发送固定的握手信息:t3 12.2.1nAS:255nHL:19nMS:10000000nPU:t3://us-l-breens:7001nn服务端返回:客户端再发送经过特殊构造CC链的新建文件的反序列化数据T3数据构造过程:在一台开启weblogic服务的靶机上将/Oracle/Middleware/user_projects/domains/base_domain/bin/stopWebLogic.sh,进行修改,在这个脚本对另一个weblogic主机发送stop的请求的时候,会会发送T3的序列化数据,之后使用wireshark抓取该数据。修改过程:https://d1iv3.me/2018/06/05/CVE-2015-4852-Weblogic-%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96RCE%E5%88%86%E6%9E%90/如何利用T3协议进行远程类加载利用T3协议的反序列化机制,反序列化可以远程加载方法的类,然后去加载远程方法,即二次序列化。这里使用低版本weblogic的尝试一下CC链+JRMP远程方法调用,还是CVE-2019-2628,再次回顾一下weblogic stop脚本的流量。第一次握手:第二次发送序列化请求:第三次发送序列化对象:虽然看着是一滩还算清楚的洋码子,但是大佬们POC的编写已经开始细节了(和我之前学大佬的大有差别,https://blog.csdn.net/he_and/article/details/97924679)。在这里先用上一次的文章的POC试一下能不能二次序列化:先用yso生成一个JRMP请求的序列化脚本启动服务器监听和HTTP服务结果报错正常反序列化成功之后服务端报错为:那么看下别人的是怎么成功的,先贴出GitHub上的示例:https://github.com/0xn0ne/weblogicScanner/blob/master/stars/cve_2018_2628.py首先看注释:说是第一次是发送t3的请求对象第二次才是序列化的对象,对比一下GitHub脚本与weblogic stop脚本,握手的就不看了,直接看t3请求的数据:将data1,2,3,4直接拼接好,hex转码,拼接data2的时候注意,data2变量的尾部有这么一个小细节在data2中间还有一个细节意思就是说,尾部的dport(一般为7001)转化为4位16进制之后,填充到{0}的位置。7001转化为16进制为1b59,我直接把后面的format去掉,将{0}替换为1b 59。hex解码与weblogic的stop脚本流量对比不同之处。除了IP地址的不同好像没有什么不同,再看反序列化数据的第二段将反序列化的数据拼接到序列化的数据流中。那为什么要分成data1,2,3,4这样发送呢,再返回看数据包的过程。那么截取掉1b59等待端口的16进制来替换在长度为1514的序列化请求数据包后面还有一个长度为88的数据包,也截取出来OK,那么在序列化数据的时候发送了两次TCP的数据返回结果与数据包中的一致,所以感觉没必要分四次发送开始第二步,发送恶意序列化对象,这里还是看一下原POC可以看到fe010000为一段反序列化数据的结束,aced0005为一段反序列化数据的开头,还是先看数据包进入该数据包,只截取00000372之后的Hex,前面的都是TCP数据包的字符,只有后面才是真正的T3数据然后求下这段Hex的长度/2,Hex转化后长度的值为:372,那么大致判断为这段数据的组合方式为“固定的T3数据头”+“反序列化数据段”,而这种分段方式每段反序列化数据段都是以aced0005开头,以fe010000结尾,我这里先尝试直接截取第一个aced0005之前的数据,后面直接从yso生成的序列化文件中拼接到截取的数据后,再在这段数据后’fe010000’,然后求出这段Hex字符串的长度,填充到开头,以左补0的方式。那么POC就可以编写如下了:利用yso输出JRMPClient的序列化文件启动yso的监听执行脚本,弹出计算器在看下数据包的后续流程:参考文档:https://l3yx.github.io/2020/04/22/Weblogic-IIOP-%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96%E6%BC%8F%E6%B4%9E/贴一下原因吧:Weblogic IIOP协议默认开启,跟T3协议一起监听在7001端口,这次漏洞主要原因是错误的过滤JtaTransactionManager类,JtaTransactionManager父类AbstractPlatformTransactionManager在之前的补丁里面就加入到黑名单列表了,T3协议使用的是resolveClass方法去过滤,resolveClass方法是会读取父类的,所以T3协议这样过滤没问题。但是IIOP协议这块虽然也是使用的这个黑名单列表,但不是使用resolveClass方法去判断,默认只会判断本类的类名,而JtaTransactionManager类不在黑名单列表里面并且存在jndi注入。这里对Y4er师傅的poc进行一下分析(注要是底层实在跟不动,顶不住啊,能改改POC就行了),https://github.com/Y4er/CVE-2020-2551其中createMemoitizedProxy创建了一个AnnotationInvocationHandler的动态代理,然后将这个动态代理的对象发送到服务端,进行反序列化。具体的参见Y4er师傅的源码。直接尝试一下补充一个关于cve-2020-2551的GitHub检测脚本的说明:https://github.com/0xn0ne/weblogicScanner/blob/master/stars/cve_2020_2551.py首先运行如下程序在此处,给IIOP的服务器指定一个错误的端口,这个程序会报错:说是连接不到这个服务器,且没有通讯流量,那把它换成正常的7001端口抓取数据包:程序正常运行,使用wireshark抓取数据包:将其Hex一下看:发现红色部分由客户端发送的数据与检测脚本的一致。返回包中如果存在GIOP字段说明存在漏洞。LDAP可以除了可以描述Java的对象信息,还可以返回序列化数据,由JNDI的类进行反序列化。这个比较简单,直接将生成的序列化文件BASE64编码,然后客户端LDAP请求返回序列化数据就行了。关于怎么浅析反序列化POC就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。
故障现象:客户反应在内部新增加一个网段后,该网段上网速度很慢,打开网页需要很长时间!客户网络环境:排查过程:经了解客户在D-SW-A上增加一个新网段后,下面的PC上网速度很慢,在客户现场进行测试,更换成原有网段之后,上网速度马上恢复正常。这不科学啊!登录到D-…
免责声明:本站发布的图片视频文字,以转载和分享为主,文章观点不代表本站立场,本站不承担相关法律责任;如果涉及侵权请联系邮箱:360163164@qq.com举报,并提供相关证据,经查实将立刻删除涉嫌侵权内容。