如何进行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复现与浅析就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：niceseo99@gmail.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
评论