漏洞简介
CVE编号:CVE-2020-9484,危险级别:高危
Apache Tomcat是美国阿帕奇(Apache)软件基金会的一款轻量级Web应用服务器,在中小型系统和并发访问用户不是很多的场合下被普遍使用,是开发和调试JSP 程序的首选。该程序实现了对Servlet和JavaServer Page(JSP)的支持。目前Tomcat最新版本为10.0.0-M4。
近日,Apache Tomcat发布通告称修复了一个源于持久化Session的远程代码执行漏洞(CVE-2020-9484)。当Tomcat使用了自带session同步功能时,使用不安全的配置(没有使用EncryptInterceptor)会存在反序列化漏洞,攻击者通过精心构造的数据包,可以对使用了自带session同步功能的Tomcat服务器进行攻击。要利用该漏洞,攻击者需要同时满足以下4个条件:
1、攻击者可以控制服务器上的文件名/文件内容;
2、服务器上配置使用了PersistenceManager的FileStore;
3、PersistenceManager配置了sessionAttributeValueClassNameFilter值为“NULL”或者其他宽松的过滤器,使得攻击者可以提供反序列化对象;
4、攻击者知道FileStore使用的存储位置到可控文件的相对路径。
攻击者在同时满足以上4个条件时,可以发送一个恶意构造的请求,来造成反序列化代码执行漏洞。
漏洞检测
第一步:从Apache Tomcat官网下载的安装包名称中会包含Tomcat的版本号,如果用户解压后没有更改Tomcat的目录名称,可以通过查看文件夹名称来确定当前使用的版本。
如果解压后的Tomcat目录名称被修改过,或者通过Windows Service Installer方式安装,可使用软件自带的version模块来获取当前的版本。也可以进入Tomcat安装目录的bin目录,运行version.bat(Linux运行version.sh)后,可查看当前的软件版本号。
第二步:查看conf/context.xml文件或具体项目的server.xml文件中,是否存在以下<Manager>节点
若当前版本在受影响范围内且在PersistenceManager配置中使用了FileStore,则可能存在安全风险。
漏洞防护
目前官方已在最新版本中修复了该漏洞,请受影响的用户尽快升级版本进行防护,官方下载链接:
版本号
|
下载地址
|
Apache Tomcat 10.0.0-M5
|
https://tomcat.apache.org/download-10.cgi
|
Apache Tomcat 9.0.35
|
https://tomcat.apache.org/download-90.cgi
|
Apache Tomcat 8.5.55
|
https://tomcat.apache.org/download-80.cgi
|
Apache Tomcat 7.0.104
|
https://tomcat.apache.org/download-70.cgi
|
其他防护措施
Apache Tomcat官方已经发布新版本修复上述漏洞,建议受影响用户尽快升级进行防护。不方便升级的用户,还可以暂时禁用FileStore功能,或者单独配置sessionAttributeValueClassNameFilte的值来确保只有特定属性的对象可以被序列化/反序列化。
什么是序列化和反序列化?
Java描述的是一个‘世界’,程序运行开始时,这个‘世界’也开始运作,但‘世界’中的对象不是一成不变的,它的属性会随着程序的运行而改变。
但很多情况下,我们需要保存某一刻某个对象的信息,来进行一些操作。比如利用序列化将程序运行的对象状态以二进制形式储存在文件系统中。然后可以在另一个程序中对序列化后的对象状态数据进行反序列化恢复对象。可以有效地实现多平台之间的通信、对象持久化存储。
一个类的对象要想序列化成功,必须满足两个条件:
1、该类必须实现 java.io.Serializable 接口。
2、该类的所有属性必须是可序列化的。如果有一个属性不是可序列化的,则该属性必须注明是短暂的。
如果你想知道一个 Java 标准类是否是可序列化的,可以通过查看该类的文档,查看该类有没有实现 java.io.Serializable接口。
Java反序列化漏洞简介
因此要利用Java反序列化漏洞,需要在进行反序列化的地方传入攻击者的序列化代码。能符合以上条件的地方即存在漏洞。
反序列化漏洞起源开发失误开发时产生的反序列化漏洞常见的有以下几种情况:1重写ObjectInputStream对象的resolveClass方法中的检测可被绕过。2使用第三方的类进行黑名单控制。虽然Java的语言严谨性要比PHP强的多,但在大型应用中想要采用黑名单机制禁用掉所有危险的对象几乎是不可能的。因此,如果在审计过程中发现了采用黑名单进行过滤的代码,多半存在一两个‘漏网之鱼’可以利用。并且采取黑名单方式仅仅可能保证此刻的安全,若在后期添加了新的功能,就可能引入了新的漏洞利用方式。所以仅靠黑名单是无法保证序列化过程的安全的。
基础库基础库中隐藏的反序列化漏洞
优秀的Java开发人员一般会按照安全编程规范进行编程,很大程度上减少了反序列化漏洞的产生。并且一些成熟的Java框架比如Spring
MVC、Struts2等,都有相应的防范反序列化的机制。如果仅仅是开发失误,可能很少会产生反序列化漏洞,即使产生,其绕过方法、利用方式也较为复杂。但其实,有很大比例的反序列化漏洞是因使用了不安全的基础库而产生的。
2015年由黑客Gabriel
Lawrence和Chris Frohoff发现的‘Apache Commons
Collections’类库直接影响了WebLogic、WebSphere、JBoss、Jenkins、OpenNMS等大型框架。直到今天该漏洞的影响仍未消散。
存在危险的基础库:
commons-fileupload 1.3.1
commons-io 2.4
commons-collections 3.1
commons-logging 1.2
commons-beanutils 1.9.2
org.slf4j:slf4j-api 1.7.21
com.mchange:mchange-commons-java 0.2.11
org.apache.commons:commons-collections 4.0
com.mchange:c3p0 0.9.5.2
org.beanshell:bsh 2.0
b5org.codehaus.groovy:groovy 2.3.9
org.springframework:spring-aop 4.1.4.RELEASE