Shulou(Shulou.com)05/31 Report--

This article will explain in detail how to reproduce and analyze CVE-2020-13935. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Vulnerability introduction:

There is a security vulnerability in WebSocket in Apache Tomcat because the program does not properly validate the length of the payload. An attacker can exploit this vulnerability to cause a denial of service (infinite loop).

Scope of vulnerability impact:

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

Vulnerability repair method:

Updated version of Apache Tomcat

Other ways: disable or restrict access to WebSockets

Vulnerability recurrence environment:

CentOs7

Tomcat9.30

Jdk8

Attackers:

Windows10

Take advantage of POC:

Tcdoc.exe

Vulnerability recurrence steps:

For centos and tomcat environment building tutorials, please see my previous article.

Access the url address to discover the default websocket address of tomcat: (it exists after tomcat deployment is completed)

Download and test poc: https://github.com/RedTeamPentesting/CVE-2020-13935

Installation instructions: error will be reported when compiling the steps. You need to modify the proxy address here. Command: go env-w GOPROXY= https://goproxy.cn

Compiled successfully:

Attack the server:

Server cpu utilization reaches 100% in an instant:

Analysis of loopholes:

According to the article analyzed by redteam-pentesting, here is my understanding.

Let's look at the structure of WebSocket frame:

The figure shows that if the load length (payload length) is set to 127. the extended load length (extended payload length), which accounts for 64 bit, should be used as the load length, that is, 8 bytes.

Look at the WebSocket RFC requirements:

If [load length (payload length) of 7bit] is 127 (binary 11111111), the next 8 bytes are interpreted as "unsigned integers" of 64-bit length as load length. The most significant bit of an unsigned integer should be written as 0.

This should be to improve fault tolerance and be compatible with error programming. Because unsigned integers must be greater than 0, and the highest bit of signed integers uses 1 for negative numbers and 0 for positive numbers.

Then when we construct the "extended load length" (extended payload length), we set the most significant bit to 1, which deliberately violates the RFC specification and becomes an invalid load (payload).

The following is the poc construct for the highest bit of unsigned integers in the redteam-pentesting analysis article:

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}) about how to reproduce and analyze CVE-2020-13935, so much for sharing here. I hope the above content can be helpful to everyone and learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.