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語言環境

Download

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