如何进行CVE-2020-13935复现与浅析

这篇文章将为大家详细讲解有关如何进行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 bugbuf.Write([]byte{0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF})

关于如何进行CVE-2020-13935复现与浅析就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。