“心臟滴血漏洞”測(cè)評(píng)經(jīng)驗(yàn)分享

1 前言

1.1 編寫目的

經(jīng)驗(yàn)分析貼，賺C幣買文章；

1.2 讀者對(duì)象

本文檔讀者對(duì)象為：測(cè)評(píng)相關(guān)工程師、項(xiàng)目管理者、測(cè)試工程師、質(zhì)量管理人員、文檔工程師等技術(shù)人員。

讀者對(duì)象閱讀重點(diǎn)與建議

測(cè)評(píng)工程師	建議閱讀全部?jī)?nèi)容。
項(xiàng)目管理者	建議閱讀軟件介紹概要性文檔。
質(zhì)量管理人員	建議閱讀介紹等概要性文檔。
文檔工程師	建議閱讀介紹概要性文檔。

1.3 名詞術(shù)語

名詞、術(shù)語解 釋

緩沖區(qū)過讀	緩沖區(qū)過讀是一類程序錯(cuò)誤，即程序從緩沖器讀出數(shù)據(jù)時(shí)超出了邊界，而讀取了（或試圖讀取）相鄰的內(nèi)存。
OpenSSL	OpenSSL是一個(gè)開放源代碼的軟件庫包，應(yīng)用程序可以使用這個(gè)包來進(jìn)行安全通信，避免竊聽，同時(shí)確認(rèn)另一端連接者的身份。這個(gè)包廣泛被應(yīng)用在互聯(lián)網(wǎng)的網(wǎng)頁服務(wù)器上。
完全正向保密	完全正向保密（perfect forward secrecy）是信息安全中提出的觀點(diǎn)。要求一個(gè)密鑰只能訪問由它所保護(hù)的數(shù)據(jù)；用來產(chǎn)生密鑰的元素一次一換，不能再產(chǎn)生其他的密鑰；一個(gè)密鑰被破解，并不影響其他密鑰的安全性。設(shè)計(jì)旨在長期使用密鑰不能確保起安全性的情況下而不影響過去會(huì)話的保密性。

1.4 參考文檔

編號(hào)文檔、資料名稱來源備注

1	Rix Tox（知乎）	https://www.zhihu.com/question/23328658/answer/24236735	無

2 測(cè)評(píng)前的準(zhǔn)備

2.1 心臟滴血漏洞是什么？

? ?? ? Heartbleed漏洞，也叫“心臟滴血漏洞”。是OpenSSL加密軟件庫中的一個(gè)嚴(yán)重漏洞。這個(gè)漏洞允許竊取正常情況下使用SSL/TLS加密保護(hù)的信息；

? ?? ?自2011年12月31日，漏洞就已經(jīng)存在，而且隨著OpenSSL版本1.0.1于2012年3月14日釋出，有缺陷的代碼被互聯(lián)網(wǎng)廣泛使用；Heartbleed漏洞允許互聯(lián)網(wǎng)上的任何人不受限制的讀取受OpenSSL漏洞保護(hù)系統(tǒng)的內(nèi)存。攻擊者可根據(jù)漏洞竊聽信息，直接從服務(wù)和用戶那里竊取潛在的敏感數(shù)據(jù)，甚至包括服務(wù)器的專用主密鑰；

? ?? ?如果存在此漏洞；攻擊者可以通過被動(dòng)中間人攻擊，獲取此時(shí)服務(wù)器內(nèi)存中存儲(chǔ)的信息（如果服務(wù)器和客戶端未使用完全正向保密，或使用了完全正向保密時(shí)攻擊方發(fā)動(dòng)“主動(dòng)中間人攻擊”）。攻擊者無法控制服務(wù)器返回的數(shù)據(jù)，因?yàn)榉?wù)器會(huì)使用一個(gè)隨機(jī)內(nèi)存塊（最大64KB）作為響應(yīng)；而且攻擊者可以不斷發(fā)送攻擊請(qǐng)求報(bào)文，獲取服務(wù)器內(nèi)存中的數(shù)據(jù)。

? ?? ?安全公司Codenomicon和Google工程師Neel Mehta最早于2014年4月8日發(fā)現(xiàn)（公布）了 OpenSSL的Heartbleed漏洞；安全公司Codenomicon為這個(gè)漏洞制作了一個(gè)符合漏洞形象的logo；Codenomicon公司的工程師“Ossi Herrala”為漏洞名起了很炫的名字：“Heartbleed”；心臟滴血的名稱由此而來。

2.2 漏洞范圍

? ?? ?Heartbleed于2011年12月被引入到OpenSSL中，自O(shè)penSSL于2012年3月14日發(fā)布1.0.1以來就一直存在。2014年4月7日發(fā)布的OpenSSL 1.0.1g修復(fù)了這個(gè)漏洞。.

說明存在漏洞的SSL/TLS相關(guān)版本

存在漏洞的版本	OpenSSL1.0.1、1.01a、1.01b、1.01c、1.01d、1.01e、1.01f、Beta 1 of OpenSSL1.02等版本
不存在漏洞的版本	OpenSSL1.0.1g、OpenSLL1.0.0、OpenSSL 0.9.8、OpenSSL 1.0.2-beta2、和以上SLL高版本

? ?? ?漏洞詳細(xì)說明見：https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160

? ?? ?自2014年漏洞發(fā)布起即全球%30的網(wǎng)站存在被攻擊的風(fēng)險(xiǎn)，漏洞影響的范圍到底有多大? 根據(jù)以下當(dāng)年發(fā)布的信息可以說明情況；

? ?? ?節(jié)選來自Heartbleed的官方說明：OpenSSL在Web容器如Apache/Nginx中使用，這兩款中間件的全球份額超過66%。一些大型的互聯(lián)網(wǎng)公司常使用 OpenSSL，而這曾經(jīng)被認(rèn)為是最安全的數(shù)據(jù)傳輸手段之一；

? ?? ?眾多網(wǎng)絡(luò)路由器廠商包括 Cisco Systems 與 Juniper Networks等，在漏洞公布當(dāng)天紛紛發(fā)布了緊急公告，列出一系列受此漏洞影響的路由器產(chǎn)品。雖說這些產(chǎn)品由于使用舊版SSL，廠商也表示會(huì)盡快更新補(bǔ)洞，據(jù)悉，有的黑客在漏洞發(fā)布一年前就已經(jīng)在利用這個(gè)漏洞了，獲取到了不少大網(wǎng)站的敏感信息；

? ?? ?國內(nèi)知名企業(yè)如淘寶、阿里、360、京東(滾動(dòng)資訊)、微信、支付寶等公司的技術(shù)團(tuán)隊(duì)也在漏洞發(fā)布當(dāng)天徹夜奮戰(zhàn)，和黑客們開展起了一場(chǎng)“你盜我堵”的賽跑，在黑客竊取更多用戶數(shù)據(jù)前趕緊予以修復(fù)…

? ?? ?下面圖片反應(yīng)了2014年在發(fā)布漏洞后的緊急情況：

2.3 漏洞描述

? ?? ?Heartbleed漏洞，這項(xiàng)嚴(yán)重缺陷(CVE-2014-0160)的產(chǎn)生是由于未能在memcpy()調(diào)用受害用戶輸入內(nèi)容作為長度參數(shù)之前正確進(jìn)行邊界檢查。攻擊者可以追蹤OpenSSL所分配的64KB緩存、將超出必要范圍的字節(jié)信息復(fù)制到緩存當(dāng)中再返回緩存內(nèi)容，這樣一來受害者的內(nèi)存內(nèi)容就會(huì)以每次(每次SSL心跳報(bào)文請(qǐng)求)64KB的速度進(jìn)行泄露；原理如下圖所示：

2.4 漏洞原理

2.4.1 心跳檢測(cè)報(bào)文（Heartbeat）

? ?? ?要對(duì)心臟滴血漏洞進(jìn)行更好的理解，首先需要知道心跳檢測(cè)報(bào)文的作用和運(yùn)行原理，這里做簡(jiǎn)要解釋；

（A）心跳檢測(cè)報(bào)文的作用

? ?? ?TLS心跳擴(kuò)展報(bào)文為TLS/DTLS提供了一種允許在不重新進(jìn)行商議和發(fā)送路徑MTU探索包(PMTU)的情況下而使用保持持續(xù)通信功能的新協(xié)議。
所謂心跳檢測(cè)，就是建立一個(gè) Client Hello 問詢來檢測(cè)對(duì)方服務(wù)器是不是正常在線 ，服務(wù)器發(fā)回 Server hello，表明正常保持SSL通訊。就像我們打電話時(shí)會(huì)問對(duì)方“喂聽得到嗎？”一樣；

? ?? ?每次問詢都會(huì)附加一個(gè)問詢的字符長度“pad length”，如果這個(gè)“pad length” 大于實(shí)際的長度，應(yīng)答方仍是會(huì)返回相同字符長度的字符信息。

（B）TLS/DTLS心跳檢測(cè)報(bào)文的結(jié)構(gòu)

? ?? ?TLS數(shù)據(jù)包格式如下：

心跳包字段長度說明

ContentType	1byte	心跳包類型，IANA組織把type編號(hào)定義為24（0x18）
ProtocolVersion	2bytes	TLS的版本號(hào)，目前主要包括含有心跳擴(kuò)展的TLS版本：TLSv1.0，TLSv1.1，TLSv1.2
length	2bytes	HeartbeatMessage的長度
HeartbeatMessageType	1byte	Heartbeat類型 01表示heartbeat_request 02表示heartbeat_response
payload_length	2bytes	payload長度
payload	payload_length個(gè)bytes	payload的具體內(nèi)容
padding	>=16bytes	padding填充，最少為16個(gè)字節(jié)

? ?? ?DTLS數(shù)據(jù)包格式如下：

心跳包字段長度說明

pe	1byte	心跳包類型，IANA組織把type編號(hào)定義為24（0x18）
ProtocolVersion	2bytes	DTLS的版本號(hào)，DTLS1.0基于TLS1.1，DTLS1.2基于TLS1.2
epoch	2bytes	為一個(gè)計(jì)數(shù)器，每一個(gè)加密狀態(tài)改變時(shí)加一。主要用來區(qū)分在一個(gè)多次重新協(xié)商的情況，多個(gè)記錄包文可能會(huì)具有相同的序列號(hào)，因此再用這個(gè)域來區(qū)分，接收者可以用來區(qū)分不同的包。epoch初始值為0，每發(fā)送一個(gè)changeCipherSpec消息后加一
sequence_number	6bytes	記錄層的序列號(hào)，在每一個(gè)ChangeCipherSpec消息發(fā)送之后，sequence_number都設(shè)置為0
length	2bytes	HeartbeatMessage的長度
HeartbeatMessageType	1byte	Heartbeat類型 01表示heartbeat_request 02表示heartbeat_response
payload_length	2bytes	payload長度
payload	payload_length個(gè)bytes	payload的具體內(nèi)容
padding	>=16bytes	padding填充，最少為16個(gè)字節(jié)

（C）TLS/DTLS心跳檢測(cè)報(bào)文抓包示范

? ?? ?心跳檢測(cè)報(bào)文包括A、請(qǐng)求包（heartbeat Request）和B、響應(yīng)包（heartbeat Response）；本文以常見TLS數(shù)據(jù)包為例，通過wireshark進(jìn)行抓包獲取信息如下：

A、TLS請(qǐng)求包抓包示例如下：

B、TLS響應(yīng)包抓包示例如下：

? ?? ?通過對(duì)比心跳檢測(cè)請(qǐng)求報(bào)文和響應(yīng)報(bào)文不難看出，響應(yīng)報(bào)文和請(qǐng)求報(bào)文使用相同的報(bào)文格式；如果仔細(xì)觀察請(qǐng)求報(bào)文，可以發(fā)現(xiàn)請(qǐng)求報(bào)文請(qǐng)求的報(bào)文長度是16384，但實(shí)際的載荷（Payload）值為0；但應(yīng)答方回復(fù)請(qǐng)求方的實(shí)際載荷（Payload）為16381（約64KB）；這里，就是心臟發(fā)生滴血的地方；即可以發(fā)現(xiàn)攻擊方通過制造畸形心跳檢測(cè)請(qǐng)求報(bào)文進(jìn)行了攻擊；

? ?? ?如果打開應(yīng)答報(bào)文Payload字段，可以看到因漏洞產(chǎn)生內(nèi)存溢出的數(shù)據(jù)；溢出的數(shù)據(jù)是隨機(jī)的，但是攻擊方可以通過多次進(jìn)行攻擊，從而獲取更多應(yīng)答方內(nèi)存中的數(shù)據(jù)，直到獲取有價(jià)值的數(shù)據(jù)；而且64KB是可以泄露出足夠多的信息的；如下圖攻擊方通過偽造報(bào)文已經(jīng)獲取了關(guān)鍵的用戶賬戶和口令信息：

? ?? ?這里還想說一些題外話，此類漏洞主要是因?yàn)楣舴街圃炝嘶螆?bào)文進(jìn)行了攻擊，目前可以抵御的手段可以通過IPS、WAF等安全防護(hù)規(guī)則庫進(jìn)行攔截；但根本上最好的修復(fù)方法還是更新SSL/TLS版本；后續(xù)的SSL/TLS版本中對(duì)協(xié)議代碼進(jìn)行了優(yōu)化（對(duì)輸入內(nèi)容作為長度參數(shù)之前正確的進(jìn)行了邊界檢查）。

2.4.2 代碼原理示例

? ?? ?漏洞出現(xiàn)在SSL服務(wù)ssl/d1_both.c中，對(duì)用戶傳入的payload長度沒有檢查就進(jìn)行內(nèi)存拷貝；下面是代碼示意：

漏洞出現(xiàn)在SSL服務(wù)ssl/d1_both.c中，對(duì)用戶傳入的payload長度沒有檢查就進(jìn)行內(nèi)存拷貝；下面是代碼示意： 1)基本結(jié)構(gòu) ------------------------------------------------------------------------- int dtls1_process_heartbeat(SSL *s){ unsigned char *p = &s->s3->rrec.data[0], *pl;unsigned short hbtype;unsigned int payload;unsigned int padding = 16; /* Use minimum padding */ } ------------------------------------------------------------------------- 2）p指向一條SSLv3的記錄，結(jié)構(gòu)如下: ------------------------------------------------------------------------- typedef struct ssl3_record_st{int type; /* type of record */unsigned int length; /* How many bytes available */unsigned int off; /* read/write offset into 'buf' */unsigned char *data; /* pointer to the record data */unsigned char *input; /* where the decode bytes are */unsigned char *comp; /* only used with decompression - malloc()ed */unsigned long epoch; /* epoch number, needed by DTLS1 */unsigned char seq_num[8]; /* sequence number, needed by DTLS1 */} SSL3_RECORD; ------------------------------------------------------------------------- 3）回到上面的程序，接下來對(duì)指針進(jìn)行一些操作： ------------------------------------------------------------------------- /* Read type and payload length first */ hbtype = *p++; n2s(p, payload); pl = p; -------------------------------------------------------------------------4）這里先讀取個(gè)type，然后n2s把下一個(gè)length的兩個(gè)字節(jié)放到payload里面，作為后面內(nèi)存拷貝的長度； ------------------------------------------------------------------------- unsigned char *buffer, *bp; int r;/* Allocate memory for the response, size is 1 byte* message type, plus 2 bytes payload length, plus* payload, plus padding*/buffer = OPENSSL_malloc(1 + 2 + payload + padding); bp = buffer;/* ... *//* Enter response type, length and copy payload */ *bp++ = TLS1_HB_RESPONSE; s2n(payload, bp); memcpy(bp, pl, payload); ------------------------------------------------------------------------- 注意這個(gè)payload長度是用戶請(qǐng)求的，而在分配的時(shí)候完全沒有對(duì)于實(shí)際的SSL記錄長度進(jìn)行審查，bp會(huì)直接返回給用戶，所以攻擊者可以dump出任意長度（最大為65535(payload)+1+2+16(padding)=64k）的數(shù)據(jù)，而pl也是用戶傳入的，只要把pl設(shè)置的很小，dump出來的數(shù)據(jù)就會(huì)包含更多別的敏感數(shù)據(jù)。具體的利用方法見exploit demo，就不詳細(xì)分析了。作者：Rix Tox 鏈接：https://www.zhihu.com/question/23328658/answer/24236735 來源：知乎

3 測(cè)評(píng)實(shí)施要點(diǎn)

? ?? ?通過上文對(duì)心臟滴血漏洞的理解，測(cè)評(píng)過程中無非是存在四個(gè)需要解決的問題；一是怎么發(fā)現(xiàn)，二是怎么測(cè)試，三是怎么寫；四是怎么判定風(fēng)險(xiǎn)。本文不涉及滲透類測(cè)試，不提供漏洞POC測(cè)試工具下載。

3.1 發(fā)現(xiàn)漏洞的方法

（A）通過協(xié)議版本判斷

? ?? ?如本文2.2章節(jié)漏洞范圍中【=存在心臟滴血漏洞的SSL/TLS相關(guān)版本】所示，當(dāng)前存在心在滴血漏洞的版本有OpenSSL1.0.1、1.01a、1.01b、1.01c、1.01d、1.01e、1.01f、Beta 1 of OpenSSL1.02等版本；如果當(dāng)前所使用SSL技術(shù)包括以上版本，則可能存在漏洞。

3.2 測(cè)試漏洞的方法

（A）通過Wireshark抓包測(cè)試（包分析）

? ?? ?1）異常的SSL心跳檢測(cè)請(qǐng)求報(bào)文會(huì)在Wireshark軟件中自動(dòng)標(biāo)識(shí)出來，這里不得不說測(cè)評(píng)工具的重要性；如下圖，Wireshark在發(fā)現(xiàn)異常報(bào)文后，將會(huì)用紅色覆蓋異常字段；再通過人工判斷可以發(fā)現(xiàn)當(dāng)前載荷和請(qǐng)求載荷內(nèi)容明顯存在問題；

? ?? ?2）找到應(yīng)答報(bào)文，可以發(fā)現(xiàn)內(nèi)存溢出的信息，其中包括了用戶名和口令；

（B）通過Wireshark抓包測(cè)試（TCP追蹤）

? ?? ?根據(jù)心跳檢測(cè)報(bào)文原理我們知道心跳檢測(cè)報(bào)文是用于保證單次會(huì)話的連通性；因此我們可以根據(jù)TCP流追蹤取，可以獲取到未通過TLS加密的部分（其實(shí)是內(nèi)存溢出，和加密無關(guān)）；如下圖：

3.3 描述漏洞的方法

? ?? ?知道了怎么發(fā)現(xiàn)、測(cè)試的方法，描述方面即只要包括關(guān)鍵截圖和發(fā)現(xiàn)的過程內(nèi)容即可；重點(diǎn)是描述出當(dāng)前使用的SSL/TLS協(xié)議版本；指出存在心臟滴血漏洞，然后將測(cè)試過程截圖保存再結(jié)果記錄表后面，相關(guān)描述見“結(jié)果記錄表“編寫規(guī)范，這里不多做概述。

3.4 判定風(fēng)險(xiǎn)的方法

? ?? ?依據(jù)公開的“信息系統(tǒng)密碼應(yīng)用高風(fēng)險(xiǎn)判定指引”；此類漏洞風(fēng)險(xiǎn)被歸類到密碼產(chǎn)品和密碼服務(wù)，且屬于高風(fēng)險(xiǎn)項(xiàng)；依據(jù)截圖如下：

? ?? ?判定方面，因?qū)嶋H采用了密碼技術(shù)，因此不能給不符合；在本文中，密碼套件為TLS_EDCDHE_RSA_WITH_AES_256_CBC_SHA（0xc014）；不考慮密鑰管理方面，這里應(yīng)該給部分符合；

? ?? ?即：部分符合，存在高風(fēng)險(xiǎn)（高風(fēng)險(xiǎn)判定指引第5.3章，hearbleed高風(fēng)險(xiǎn)漏洞）。

4 總結(jié)

? ?? ?以上是本次相關(guān)心臟滴血漏洞的分享內(nèi)容，通過對(duì)漏洞的歷史、重要性、原理、測(cè)試方法等進(jìn)行了回顧，有助于我們對(duì)漏洞進(jìn)行更好的理解，并根據(jù)漏洞情況編寫結(jié)果記錄；本文沒有關(guān)于滲透類POC相關(guān)測(cè)試的內(nèi)容，理論篇借鑒了CDSN和知乎上各類文章，比較重要的文章已標(biāo)注內(nèi)容來源；個(gè)人理解部分歡迎指出問題；

? ?? ?需要說明的是，雖然是2014年曝光的漏洞，但是目前依然可能有不少使用低版本的TLS/SSL協(xié)議的情況，因此此類漏洞，需要及時(shí)發(fā)現(xiàn)。

總結(jié)

以上是生活随笔為你收集整理的“心脏滴血漏洞”测评经验分享的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。