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