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

Download

OpenJDK 1.8.0_292

攻擊機：Microsoft Windows 10

Go語言環境

Configuration

POC：tcdoc.exe

POC

漏洞複現

在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

https://www.cnblogs.com/gongchixin/articles/7998054.html

DIVING INTO A WEBSOCKET VULNERABILITY IN APACHE TOMCAT