STRUTS2的getClassLoader漏洞利用资源-CSDN文库

67 浏览量 2021-01-30 16:19:55 上传评论收藏 624KB PDF 举报

资源推荐

资源详情

资源评论

STRUTS2的的getClassLoader漏洞利用漏洞利用

0x00 摘要

我在《攻击JAVA WEB》，文中提多关于“classLoader导致特定环境下的DOS漏洞”，当时并没有更加深入的说明，这几天

struts官方修补了这个漏洞，本文是对这个漏洞的深入研究。

0x01 正文

这一切，得从我们控制了classLoader说起，曾经写过一篇文章，提到了一个小小的技术细节，非常不起眼的一个鸡肋。引用

《Spring framework（cve-2010-1622）漏洞利用指南》：

Struts2其实也本该是个导致远程代码执行漏洞才对，只是因为它的字段映射问题，只映射基础类型，默认不负责映射其他类

型，所以当攻击者直接提交URLs[0]=xxx时，直接爆字段类型转换错误，结果才侥幸逃过一劫罢了。

tomcat8.0出来后，这个问题爆发了，这是一个鸡肋漏洞的逆袭。

在struts2任何一个action运行之前，一旦接受到用户提交参数xx=zzzzz时，就由Ognl负责调用对应的当前action的setXxx方

法，至于set方法到底是干什么的，其实不重要，里面的逻辑也不重要，我们只关注这个方法调用了，参数传递了。这种对属

性的改变，有时候是可以很大程度的影响后续复杂逻辑。

普及一点基础

Object是java的基础类，所有的class生成的对象，都会继承Object的所有属性和方法，因此当前action无论是什么代码，必须

有Object自带的getClass方法，这个方法会返回一个Class对象，Class对象又一定会有getClassLoader方法，最终在每个

action都可以

getClass().getClassLoader()

我研究这个问题，在几年前了，这个东西理解起来不容易，尤其是各个web容器不一致，刚巧当时有个阿里巴巴内部《tomcat

等容器的classLoader加载原理》培训，收获匪浅。本文篇幅有限，简单的讲一下。

在JRE启动中，每个Class都会有自己的ClassLoader。web容器，为了方便的管理启动过程，通常都有实现自定义的

ClassLoader。《Spring framework》的漏洞的利用场景真的非常幸运，利用了web容器的特性getURLs方法，所有容器的

servlet的ClassLoader都会通过继承父类UrlClassLoader得到getURLs这个方法，所以这个漏洞可以不受容器影响。事实上，

每个容器的ClassLoader都是自己实现的，环境必然会有所不同，那次struts2侥幸逃过一劫，所以我的一个关注点，一都放在

几大web容器的ClassLoader代码变化上，哪天看到tomcat8居然把resources放进ClassLoader上，而ServletContext刚巧挂在

resources上，顿时知道肉戏来了。

上传webshell的可能性研究

多次的远程代码执行漏洞洗礼，我一直在脑海里模拟“ServletContext被控制了，这次能干什么”，究竟有哪些路线，可以通往

代码执行的领域。

比如：Struts2会去servletContext里取到一个值，然后把它作为Ognl执行掉。这个太简单了，我自己都不信。

Ognl的Context树形结构：

servletContext被转换成Map，变成了图中的application子项，这个位址很尴尬，如果是上一层Node，从上到下找到value

Stack，确实有实现这个思路的可能，但现在看来，这条路断了，它不支持找到父节点。经过多次找寻后，确认Ognl出局，只

能从web容器本身入手。

运行在Tomcat8下的struts，在随便哪个action代码中，插入这段，下断点，

this.getClass().getClassLoader();

任何一个Action的classLoader都是org.apache.catalina.loader.WebappClassLoader，这是漏洞的源头。

我的思路，是给context赋予初始化参数readOnly=false。因为在tomcat上，所有的请求，都会默认由defaultServlet上处理，

或者由jspServet处理。只要在context初始化时，readOnly=false，接下来defaultServlet就会真的处理PUT请求DELETE请求

等等大威力请求，于是我们可以直接PUT文件上来。

这个思路的前提，是defaultservlet再被初始化一次。现实很残酷，这个思路最终没有得到执行，原因是servlet只会初始化一

次，而readOnly属性只有在servlet初始化时，才会真的给servet的readOnly属性赋值。这次突破，宣告失败。

几个这个漏洞的调试小技巧：

1. 仅仅从debug上查看ognl的赋值情况，是不准确的，debug只能看到这个类定义好的变量。

如果有一个代码是这样的：

public void setName(String name){…}

但是并没有定义过这个属性，这时debug无法看到这个东西，但是其实ognl可以直接通过name=zzzzz调用，并且能把zzzz传

递过去。

2. 或者只有一个私有属性，但是没有set方法，其实也是ognl不能赋值的。

这个debug，观察这个漏洞时，仅仅是个参考，要真正深入进去看代码才能和ognl的视线保持一致。

3. 一个final的对象，或者只是get方法返回一个对象，看起来像是只读的，其实对象的属性还是可以改的，这个只是对象的引

用。

你可以理解为指针指向的地址不能变，但是指向的那个对象的属性，是可以修改的。

举例：

public User getUser()

{

return this.user;

}

public final User user;

这两处代码，其实真正返回给OGNL的都是user对象，对象的属性只要还有set方法，也都是可以被修改的。依然可以通过

url?user.name=xxx

对user的name赋值。

struts2运行在tomcat8.0.1rc5(2013,11月前)的任意文件读取漏洞

在tomcat的环境下，classLoader会挂载一个resources，类名叫做“StandardRoot”，这个恐怖的东西，和tomcat的资源文件管

理有关，debug看到的第一个属性就是非常危险的属性“allowLinking”。

剩余6页未读，继续阅读

内容反馈

weixin_38732842

粉丝: 4
资源: 951

最新资源

资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！点击此处反馈

feedback-tip