CVE-2020-13935 漏洞复现
CVE-2020-13935 漏洞复现
漏洞简介
Apache Tomcat是美国阿帕奇(Apache)基金会的一款轻量级Web应用服务器。该程序实现了对Servlet和JavaServer Page(JSP)的支持。 Apache Tomcat中的WebSocket存在安全漏洞,该漏洞源于程序没有正确验证payload的长度。攻击者可利用该漏洞造成拒绝服务(无限循环)。以下产品及版本受到影响:Apache Tomcat 10.0.0-M1版本至10.0.0-M6版本,9.0.0.M1版本至9.0.36版本,8.5.0版本至8.5.56版本,7.0.27版本至7.0.104版本。
环境准备
靶机:Ubuntu20.04
Apache Tomcat 9.0.30
OpenJDK 1.8.0_292
攻击机:Microsoft Windows 10
Go语言环境
POC:tcdoc.exe
漏洞复现
在Ubuntu中安装完tomcat启动后,在Win10打开浏览器,地址栏输入http://IPaddress:8080/examples/websocket/echo.xhtml
查看是否可以访问,如果不可以访问,则说明该文件被删掉了,那就无法进行漏洞利用。
此时在Ubuntu上使用top -bn 1 -i -c
命令,可以看到CPU占有率为0.0
随后在win10上打开cmd,进入POC所在文件夹,输入如下命令
go env -w GOPROXY=https://goproxy.cn //修改proxy地址
go build //编译go程序,输出tcdos.exe
tcdos.exe ws://172.20.10.10:8080/examples/websocket/echoStreamAnnotation //攻击服务器
此时再次在Ubuntu上输入top -bn 1 -i -c
,可以看到CPU占有率为99.3
漏洞解析
WebSocket frame的结构:
参考RFC 6455 https://tools.ietf.org/html/rfc6455#section-5.2
图中说明,如果"负载长度"(payload length)设置为127,应该使用占64个bit的"扩展载荷长度"(extended payload length)作为载荷长度,即8个bytes。
WebSocket RFC要求:
如果[7bit的载荷长度(payload length)]为127(二进制11111111),则接下来的8个bytes被解释为64-bit长的"无符号整数",作为载荷长度。无符号整数最高有效位需写为0。
这里应该是为了提高容错性,兼容错误的编程实现。因为无符号整数必然大于0,而有符号整数最高位才用1表示负数,0表示正数。
那么在构造"扩展载荷长度"(extended payload length)时,将最高有效位设置为1,故意违反RFC规范,成为无效的载荷(payload)
以下是redteam-pentesting分析文章中关于无符号整数最高位的poc构造:
In order to construct a frame with an invalid payload length, triggering the misbehavior in the Apache Tomcat implementation, we set the following eight bytes to
0xFF
:// set msb to 1, violating the spec and triggering the bug buf.Write([]byte{0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF})
参考资料
https://www.freebuf.com/vuls/256004.html
https://github.com/RedTeamPentesting/CVE-2020-13935
https://blog.csdn.net/qq_43427482/article/details/109668114