免責宣告：本文僅供學習研究，嚴禁從事非法活動，任何後果由使用者本人負責。
0x00 背景知識
傳輸層安全協議SSL
安全套接字協議SSL（Secure Sockets Layer），及其繼任者傳輸層安全協議TLS（Transport Layer Security）是為網路通訊提供安全及資料完整性的一種安全協議，它們在傳輸層與應用層之間對網路連線進行加密。
例如，常見的HTTPS協議，就是由HTTP加上SSL/TLS協議構建的可進行加密傳輸、身份認證的網路協議，實現網際網路資料傳輸安全。當使用者訪問安全網站時，在URL地址旁會有一個“鎖”，就表明我們與該網站之間的通訊資訊都被加密。在 Microsoft Edge 中安全瀏覽 Web。
另外，這兩種協議沒有固定的埠。根據是否使用了傳輸層安全協議，應用層協議的埠會有不同。例如：http協議是80埠，https是443埠，常用的郵件伺服器SSL/非SSL協議埠號。
OpenSSL
OpenSSL是一個開源的SSL安全軟體包，是SSL協議的實現程式。網站的開發者要使用SSL，就會選擇在自己的網站中匯入openSSL軟體包，實現網站資料加密。
0x01 漏洞介紹
影響版本
漏洞原理
OpenSSL有一個叫Heartbeat（心跳檢測）的擴充，它允許連線SSL一端的電腦發出一條簡短的資訊Client Hello問詢來檢測對方伺服器是否正常線上，若伺服器返回Server hello，則表明可以正常SSL通訊。
每次問詢，A都會向伺服器B傳送請求包，其中含有包的型別(type)和資料長度(Length)等資訊，而伺服器B返回一個包含有請求包內容的響應包。OpenSSL心臟出血漏洞產生的主要原因是，OpenSSL的心跳處理邏輯沒有檢測心跳包中的長度欄位值是否和實際長度相吻合，導致攻擊者可以構造異常資料包，來直接獲取心跳資料所在的記憶體區域的後續資料，於是形成了記憶體資料的越界訪問（資訊洩露）。通過不斷進行心跳檢測，就能一點點洩露伺服器的資料，這就是心臟滴血（Heartbleed）漏洞。
當B收到A的請求包後，並沒有的驗證A包的實際長度，而是簡單的把請求包data中說明的長度當作data的實際長度，於是當請求包中說明的長度與請求包資料實際長度不同時，問題就產生了。假設A構造一個請求包，它的實際內容長度只有1，而卻告訴B的它的長度是65535，那麼B接受到這個包後就會把A的內容完全當作65535來處理，其實到這裡，問題還並不嚴重，最嚴重的問題出在，心跳的響應包還需要附帶請求包的全部內容，這就需要程式做一次將請求包的資料從它所在的記憶體拷貝到響應包的記憶體裡的操作。
這下就出大問題了，當拷貝的時候，程式認為A包的內容長度是65535個位元組，結果A包在記憶體裡面實際只有1個位元組，於是程式不僅拷貝出了A包的內容，還“傻傻”地將A包資料在記憶體中位置後額外的65534個位元組拷貝進了響應包裡，並將這個響應包發還給了A，於是A便輕易地獲得了B記憶體中這65534個位元組的資料。想象一下，如果這65534個位元組資料中包括一些敏感資訊，那麼後果將非常嚴重。而且A還可以簡單地通過連續的傳送心跳包，獲取B機器記憶體中n個65534位元組的資料。
摘自：https://blog.csdn.net/weixin_39190897/article/details/106879383
漏洞危害
攻擊者可以利用該漏洞，遠端讀取伺服器記憶體中64K的敏感資料（OpenSSL分配的快取為64KB），這些資料裡可能包括使用者的登入賬號密碼、電子郵件甚至是加密私鑰，使用者cookie等資訊。
由於網際網路應用最廣泛的安全傳輸方法就是SSL，而OpenSSL又是多數SSL加密網站使用的開源軟體包，所以漏洞影響範圍廣大，一時間席捲全球各個網際網路相關領域，網銀、線上支付、電商網站、入口網站、電子郵件等無一倖免。
0x02 漏洞復現
環境搭建
漏洞掃描/檢測
- URL“心臟滴血”漏洞檢測網站
- 使用Nmap掃描指令碼對靶機進行漏洞檢測：
- 使用AWVS對目標伺服器進行漏洞掃描
使用Vulnhub官方POC復現
Python2執行ssltest.py，拿到敏感資料：
使用MSF進行漏洞利用
- 搜尋openssl_heartbleed
- 使用auxiliary/scanner/ssl/openssl_heartbleed模組，設定好常規選項後還要使用
set verbose true設定verbose引數為真，才能顯示詳細資訊看到獲取到的伺服器記憶體資訊。
- 實際攻擊需要多次獲取記憶體資訊並進行整理，提取有用資訊。
0x03 漏洞修復
升級openssl，還可以配合措施：修改伺服器密碼、重新配置私鑰、重新配置證照。