CVE-2020-13935复现与浅析
NingKn
- 关注
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
收藏一下~
可以收录到专辑噢~
CVE-2020-13935复现与浅析
漏洞介绍:
Apache Tomcat中的WebSocket存在安全漏洞,该漏洞源于程序没有正确验证payload的长度。攻击者可利用该漏洞造成拒绝服务(无限循环)。
漏洞影响范围:
Apache Tomcat 10.0.0-M1-10.0.0-M6
Apache Tomcat 9.0.0.M1-9.0.36
Apache Tomcat 8.5.0-8.5.56
Apache Tomcat 7.0.27-7.0.104
漏洞修复方式:
Apache Tomcat更新版本
其他方式:禁用或限制对WebSockets的访问
漏洞复现环境:
CentOs7
tomcat9.30
jdk8
攻击方:
windows10
利用POC:
tcdoc.exe
漏洞复现步骤:
centos以及tomcat环境搭建教程可以看我之前的文章 点我查看
访问url地址发现tomcat默认存在的websocket地址:(tomcat部署完成后就存在)

下载测试poc:https://github.com/RedTeamPentesting/CVE-2020-13935
安装说明步骤进行编译会报错,这里需要修改proxy地址,命令:go env -w GOPROXY=https://goproxy.cn
编译成功:


攻击服务器:

服务器cpu利用率瞬间达到100%:

漏洞浅析:
根据redteam-pentesting分析的文章,这里说说我的理解。点我查看
我们看看WebSocket frame的结构:

图中说明,如果"负载长度"(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})
以上就是我的一写浅析,具体可查看redteam-pentesting分析 点我查看
本文为 NingKn 独立观点,未经允许不得转载,授权请联系FreeBuf客服小蜜蜂,微信:freebee2022
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏


相关推荐
入门级的log4j2漏洞RCE复现与环境搭建
2021-12-20
CVE-2017-10271漏洞复现与分析
2021-11-05
CVE-2020-9484 TomcatSession反序列化复现
2020-11-25
文章目录