如何進(jìn)行CVE-2020-13935復(fù)現(xiàn)與淺析

這篇文章將為大家詳細(xì)講解有關(guān)如何進(jìn)行CVE-2020-13935復(fù)現(xiàn)與淺析，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

漏洞介紹：

Apache Tomcat中的WebSocket存在安全漏洞，該漏洞源于程序沒有正確驗(yàn)證payload的長(zhǎng)度。攻擊者可利用該漏洞造成拒絕服務(wù)（無限循環(huán)）。

漏洞影響范圍：

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

漏洞修復(fù)方式：

Apache Tomcat更新版本

其他方式：禁用或限制對(duì)WebSockets的訪問

漏洞復(fù)現(xiàn)環(huán)境：

CentOs7

tomcat9.30

jdk8

攻擊方：

windows10

利用POC：

tcdoc.exe

漏洞復(fù)現(xiàn)步驟：

centos以及tomcat環(huán)境搭建教程可以看我之前的文章 點(diǎn)我查看

訪問url地址發(fā)現(xiàn)tomcat默認(rèn)存在的websocket地址：（tomcat部署完成后就存在）

下載測(cè)試poc：https://github.com/RedTeamPentesting/CVE-2020-13935

安裝說明步驟進(jìn)行編譯會(huì)報(bào)錯(cuò)，這里需要修改proxy地址，命令：go env -w GOPROXY=https://goproxy.cn

編譯成功：

攻擊服務(wù)器：

服務(wù)器cpu利用率瞬間達(dá)到100%：

漏洞淺析：

根據(jù)redteam-pentesting分析的文章，這里說說我的理解。

我們看看WebSocket frame的結(jié)構(gòu):

圖中說明，如果"負(fù)載長(zhǎng)度"(payload length)設(shè)置為127，應(yīng)該使用占64個(gè)bit的"擴(kuò)展載荷長(zhǎng)度"(extended payload length)作為載荷長(zhǎng)度，即8個(gè)bytes。

看看WebSocket RFC要求：

如果[7bit的載荷長(zhǎng)度(payload length)]為127(二進(jìn)制11111111), 則接下來的8個(gè)bytes被解釋為64-bit長(zhǎng)的"無符號(hào)整數(shù)",作為載荷長(zhǎng)度。無符號(hào)整數(shù)最高有效位需寫為0。

這里應(yīng)該是為了提高容錯(cuò)性，兼容錯(cuò)誤的編程實(shí)現(xiàn)。因?yàn)闊o符號(hào)整數(shù)必然大于0，而有符號(hào)整數(shù)最高位才用1表示負(fù)數(shù)，0表示正數(shù)。

那么我們?cè)跇?gòu)造"擴(kuò)展載荷長(zhǎng)度"(extended payload length)時(shí)，將最高有效位設(shè)置為1，故意違反RFC規(guī)范，成為無效的載荷(payload)

以下是redteam-pentesting分析文章中關(guān)于無符號(hào)整數(shù)最高位的poc構(gòu)造：

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})

關(guān)于如何進(jìn)行CVE-2020-13935復(fù)現(xiàn)與淺析就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。