OpenSSL 的 Heartbleed 漏洞的影響到底有多大？

今天在 HackersNews 上看到了這個新聞，票數和討論都非常多，看起來相當嚴重：Heartbleed Bug

另外有一個測試網站是否受到影響的服務：Test your server for Heartbleed (CVE-2014-0160) （現在長期503）

根據頁面上的介紹，這個 OpenSSL 的實現漏洞可以在握手階段獲取到主機上的敏感內存數據，甚至包括 SSL 證書私鑰！漏洞2011年底出現，昨天（2014年4月7日）才剛剛被修復。想問一下知乎上的信息安全專業人士們，這個漏洞的可利用性和影響範圍究竟有多大？如果是，那麼這個曾經的 0day 是否被廣泛利用？

---

最後更新時間：2014/4/13 21:47。來自知道創宇ZoomEye團隊的特殊視角！

寫在前面

一切權威看爆這次漏洞的官方動態：Heartbleed Bug（Heartbleed這個命名不錯，載入史冊）。

@知道創宇安全研究團隊 實測可以Dump出淘寶、微信、陌陌、某些支付類介面、某些比特幣平台、12306等各大使用OpenSSL服務的一些內存信息，裡面有用戶等的敏感內容（有些重要網站含明文密碼）。

OpenSSL這次被比做「心臟出血」。可見影響。一個安全套件不安全了……

下圖的科普可以讓大眾明白這個OpenSSL漏洞是怎麼回事：

權威統計而且還不知是否有更進一步影響（小道八卦影響比想像的嚴重）。來自Heartbleed的官方說明（大概翻譯下）：

OpenSSL在Web容器如Apache/Nginx中使用，這兩的全球份額超過66%。還在郵件服務如SMTP/POP/IMAP協議中使用，聊天服務如XMPP協議，VPN服務等多種網路服務中廣泛使用。幸運的是，這些服務很多比較古老，沒更新到新的OpenSSL，所以不受影響，不過還是有很多用的是新的OpenSSL，都受影響！

特別說明下：現在大家的聚焦都在HTTPS網站（443埠），實際上還有更多敏感服務受影響，我們的研究也是在不斷持續推進！不可草率判斷！！

1. HTTPS服務（443埠）

來自@ZoomEye 的統計（4.8號）：

全國443埠：1601250，有33303個受本次OpenSSL漏洞影響！注意這只是443埠。

全球443埠，至少受影響有71萬量級（實際應該大於這個，待修正）。

ZoomEye OpenSSL漏洞國內的趨勢監控（隨時更新，僅是443埠）：

第一天：33303 台伺服器（說明：國內是4.8號爆發的，當天的影響伺服器情況！）

第二天：22611 台伺服器（說明：辛苦一線白帽子與運維人員等的辛苦熬夜，減了1/3！而且都是知名業務，如百度、360、微信、陌陌、淘寶等，這點非常贊！）

第三天：17850 台伺服器（說明：又減少了近500台伺服器，我估計剩下的都不那麼大，不過不排除有很重要的！）

第四天：15661 台伺服器（說明：相比第一天減少了1/2！不過減少趨勢慢了……）

第五天：14401 台伺服器（說明：減少趨勢持續緩慢……）

第六天：13854 台伺服器（說明：減少趨勢持續緩慢……）

老外有個基於全球TOP1000的粗暴根域OpenSSL探測列表，僅供參考：

heartbleed-masstest/top1000.txt at master 路 musalbas/heartbleed-masstest 路 GitHub

說這個粗暴是因為：僅對「根域」。

2. 郵件服務

來自@ZoomEye 的統計（4.11號）：

最新全球受影響服務及主機 SMTP Over SSL：147292台；POP3 over SSL：329747台；IMAP over SSL：353310台。

實測可以獲取某些郵件服務的敏感數據。

3. 可視化

大家可以關注ZoomEye專門針對OpenSSL漏洞製作的全球監控頁面（在Chrome或基於Webkit內核的瀏覽器下，效果最佳，目前僅是443埠）：

OpenSSL Heartbleed Worldwide Vulnerable Distribution

我們未來會持續完善這個頁面，給大家一個專業、公正的評判結果，辛苦ZoomEye團隊的幾個小夥伴辛苦突擊！截圖兩張：

這個漏洞的全球趨勢圖，會在一周後數據量足夠的情況下給出。

瘋掉

今晚（4.8號）不知道有多少團隊要熬夜：

• 甲方，加急升級OpenSSL（如果升級真的可以的話，目前來看是可以）；
• 乙方，像我們這樣的安全公司，在給我們全線產品+客戶提供安全應急，並給社會輸出有價值的參考信息；
• 地下黑客，刷庫，各種刷！！！
• 每次這種大事，烏雲都是被各路白帽子刷分的：

我們已經聯合國家有關單位進行應急響應，我相信這次風波會很快平息。

用戶防禦建議對於普通用戶來說只要發現瀏覽器地址欄的網址是https開頭的都應該警惕，因為這次OpenSSL漏洞影響的正是https網站，本來是安全傳輸的卻也不安全了。可惜的是普通用戶來說，有時候很難發現所使用的服務背後是https，比如：

有的僅在登錄過程會https，之後都是http，典型的如百度的登錄；

如果是手機上的APP等，普通用戶就更不知道背後是不是https鏈接；

4.8號：和某銀行朋友交流，他們更新這個漏洞，需要2天時間！！這段時間，用戶謹慎吧，不登錄就不登錄（因為你登錄了你的相關明文信息，如用戶名密碼會在那萬惡的64K內存中，這段內存是可以被OpenSSL這個漏洞刷出來的……），等過3天或這些網站說修復了，大家再繼續使用服務……

如果已經登錄過，你緊張的話，就修改密碼吧。

4.10號：最新的消息是「騰訊電腦管家」聯合「安全聯盟」發布了針對用戶的解決方案：

做了兩件事情：

一方面對50萬個熱門的網站掃描是否存在漏洞；

一方面會在管家用戶訪問https站點時，雲端確認這個站點是否存在漏洞。如果用戶訪問有漏洞的站點，就出攔截頁面提示用戶，建議不要登錄。

這個非常贊！

4.12號：那些知名的大網站，現在去修改密碼會靠譜很多，因為這些大網站幾乎修復完全了。

廠家防禦建議

首先，這類攻擊日誌據Heartbleed官方說，無日誌記錄，追查不到。不過IDS/IPS等可以檢測/防禦（我們的加速樂也可以）。

別猶豫了！！儘快升級OpenSSL吧！！

如果廠家負責的話，可以學國外知名雲平台廠家Heroku的做法：

Heroku | OpenSSL Heartbleed Security Update

升級後，提醒用戶更改密碼、提醒雲服務使用者更新SSL密鑰重複證書。不過不太指望國內廠家這樣做，因為我相信用戶絕對會瘋掉。

附錄參考

0. Heartbleed Bug（爆這次漏洞的官方）

1. ZoomEye團隊的：OpenSSL Heartbleed Worldwide Vulnerable Distribution

2. 關於OpenSSL「心臟出血」漏洞的分析 - 烏雲知識庫 - 知乎專欄

3. @Evilm0 OpenSSL漏洞爆發後 - 微信公眾號：Evil-say - 知乎專欄

----------------------

這事的影響超乎想像，隨時更新。

By 知道創宇 餘弦，微信公眾號「Lazy-Thought」。

---

幾個hint，dump就不說了，sslvpn，libssl，除去web還可能影響軟體，數據，手機app，殭屍網路，甚至是內網進一步滲透（小夥伴已經打到了3個大企業的內網我會亂說？）

沒圖沒jb

這還是小的了，還有敏感的不方便放，這個洞在小黑客手裡可能就dump下，在有經驗的攻擊者手裡可以威力倍增

隨便開腦洞腦補一下，sslvpn進內網漫遊，手機app植入後門控制手機做殭屍網路，dump下來的數據做處理後撞庫，拿下域名商後泛解析做菠菜，外貿，拿下主機商後瞬間收穫成百上千肉雞，呵呵～

順便吐槽一下，知其然不知其所以然，玩個毛線，讓我想起去年s2,麻痹一群人不懂java不懂linux跟著瞎jb起鬨，黑帽子地下收錢，「白帽子」傻逼逼刷rank，呵呵

---

既然大家都這麼關注，那麼我就再爆點猛料好了。

我一駭客界的朋友Lwqn跟我說他們一年前就已經在利用這個漏洞了，獲取到了不少大網站的敏感數據，這個消息讓我徹夜難眠。

他發了一個exploit的demo給我，原鏈接已經撤掉了，所以我放到了gist上：http://gist.github.com/RixTox/10222402 Pyhton3版的在這裡OpenSSL heartbeat PoC with STARTTLS support

更新：heartleech（robertdavidgraham/heartleech 路 GitHub）可以自動利用此漏洞提取私鑰。

下圖是對DEF CON進行的Heartbleed測試

DEF CON在我測試完一個小時後已修復此漏洞。

事實證明此漏洞的確會造成嚴重的memory dump，因為與所有OpenSSL數據共享同一塊內存，dump出來的有可能是任何內容：用戶請求、密碼，甚至是伺服器的私鑰！只要不斷進行攻擊就很有可能拿到關鍵的數據。

這是一個很嚴重的漏洞，涉及開啟了Heartbeat擴展的OpenSSL版本1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1

OpenSSL: OpenSSL vulnerabilities

剛才在我們的伺服器（Gentoo）上看了一下，用的正是1.0.1c的受威脅版本，不過我們並沒有開啟Heartbeat，所以並不會受到實際威脅，但還是打上了補丁，以備不時之需。

Add heartbeat extension bounds check. 路 7e84016 路 openssl/openssl 路 GitHub

如果你只是想檢測一下你的伺服器受不受威脅，現在有一款現成的工具可以用

titanous/heartbleeder 路 GitHub

也可以直接使用下面的OpenSSL命令來判斷

/usr/local/bin/openssl s_client -connect $website:443 -tlsextdebug 2&>1| grep "TLS server extension "heartbeat" (id=15), len=1"


這個命令只告訴你是否有啟用Heartbeat，但並不能說明是否受到威脅，還需要結合OpenSSL的版本進行判斷。

Hacker News上面有人給出了這段腳本，能檢測Alexa Top Million網站開啟Heartbeat的伺服器

INPUT=websites.csv
OLDIFS=$IFS
IFS=,
[ ! -f $INPUT ] { echo "$INPUT file not found"; exit 99; }
while read rank website
do
echo "checking $website for heartbeat..."
echo -e "quit
" | /usr/local/bin/openssl s_client -connect $website:443 -tlsextdebug 2&>1| grep "TLS server extension "heartbeat" (id=15), len=1"
done &< $INPUT IFS=$OLDIFS

Download Alexa Top 1,000,000 Websites for Free

I wrote a bash script to check the top 1000 websites and huge percentage of them...

跑了一小會兒，但好像並沒發現什麼有價值的信息。其實Heartbeat作為CRM在OpenSSL中用到的機會本就不多，再加上大網站的反應都很迅速，不容易出現大的紕漏。至於0Day發布之前有沒有被人利用就不得而知了。

現在各大發行版都已經打上補丁，請各位儘快更新。

=====這個部分是寫給非專業人士的，技術控們請直接跳=====

今天接到中國之聲的採訪邀請，就硬著頭皮對這個攻擊的技術原理做了點簡單通俗的講解，希望有助於大眾正確理解並認識到這個漏洞的原理和影響。這裡把採訪的具體內容放上來作為這個答案的補充。先吐槽一下央廣硬要把我名字Rix念成「雷克薩」，發個英文就那麼難么？

先介紹一下這個漏洞是什麼時候產生的，有多大影響？

這個漏洞從2012年5月14日OpenSSL發布1.0.1版本時開始產生威脅（如果追蹤代碼更新的話應該是2011年11月份），至今已經有兩年的威脅周期，只是最近才被人發現並做出修正。在威脅期間，我們無法得知有多少黑客發現並利用這個漏洞進行大範圍的網路攻擊活動，因為這種攻擊方式是非常難以被察覺到的。因此如果做最壞的估計，也許所有大網站的用戶數據都已泄漏，影響與危害直接涉及個人利益和安全。

黑客是如何利用這個漏洞竊取用戶的個人信息的？

舉一個不太恰當但是很形象的例子來解釋，如果我們把網路伺服器比作一個郵局，每個用戶是寫信人和收信人，用戶從伺服器上接受數據就相當於收取信件，得自己拿一個袋子到郵局去取，然而這個漏洞就發生在郵局將信件裝入袋子的這個過程中。郵局的裝袋機器（節目上我說的是工作人員）出於某種原因用戶提供多大的袋子就裝多少信件，因為一般人都會提供與自己信件數量等同大小的袋子，所以正常狀態下並不會發生問題；然而如果攻擊者屬於自己的信件本就很少，卻給了郵局一個很大的袋子，裝袋機器就會鬼使神差地把別人的信件也裝入袋子里，直到袋子被裝滿。所以攻擊者可以通過這個方法看到隨機的他人信件，實際上也就是竊聽到其他用戶的敏感數據，其中可能包括了用戶名、密碼、銀行賬號等等。更嚴重的是，這個裝袋機器還有可能把自己郵局的大門鑰匙，也就是我們密碼學中所說的私鑰，也裝進袋子里，攻擊者一旦獲得這把鑰匙，就相當於能隨意進出郵局內部，查閱任何人的信件等等。（實際上是以伺服器的名義讀取和發送任何人的任何數據）當然私鑰並不是那麼容易獲取到的，要進行相當多次的攻擊才有機會得到。

用戶數據會一次性都泄漏掉嗎？

不是的。在實踐中，袋子的大小是有最大限制的，所以即使攻擊者提供一個無窮大的袋子，每次裝回來的數據也是有固定最大數量的，詳細來說黑客每次攻擊所獲得的數據僅有64KB，所以小量的攻擊是不會泄漏所有用戶的數據的。但是由於平均一台計算機一秒鐘可以執行一到兩次這樣的攻擊，黑客還是可以很輕鬆地大面積抓取用戶的敏感信息。

對那些抱有「我賬戶里又沒幾個錢，黑客不會有興趣來攻擊我，就算攻擊了也得不到什麼好處」想法的人有什麼建議？（這問題沒問，我自己擬的）

當你理解了這個攻擊背後的原理之後，你就會明白，由於黑客獲取到的是完全隨機的內存數據，他們是無法通過這個漏洞針對特定目標進行定位的攻擊的，所以他們只能採取撒網式的捕撈攻擊，撈到什麼是什麼，不求質卻求量，因此每一個用戶都是他們的目標，所有人被攻擊的概率都是一樣的，不存在「感興趣的目標」一說。我們有絕對的必要遏止事態的惡化，因為就算每個用戶損失得很少，但是積少成多，會給社會造成嚴重的負面影響。

普通用戶該如何保障自己的信息安全呢？

有很多人問我是不是改了密碼就沒事了呢，我回答是不一定。首先用戶是無法自行修補這一漏洞的，只要網站一天不修補漏洞，你的新密碼就依然會受到威脅。所以最好的辦法就是不要嘗試登錄甚至用保存了密碼的瀏覽器訪問你的服務賬戶，只要在威脅期間你以賬號登錄產生數據就可能會有隱私泄漏。然後請關注網站官方的新聞，如果有權威人士正式宣布此網站不受威脅或已經修補漏洞，再登錄賬戶，並切記要修改密碼，因為你無法確定在這兩年的威脅周期內你的密碼是否有泄露。

感謝 @亞首 下面的建議，我覺得非常重要，請各位務必相互提醒！

由於這次漏洞可能造成許多網站的證書泄露，近期內會有非常多網站甚至是CA的證書需要吊銷換新，所以請務必在瀏覽器中開啟「檢查伺服器證書吊銷狀態」的選項！！

還有什麼要補充的觀點嗎？

我覺得有必要再嘮兩句關於人們對的網路安全的誤解。

首先，我希望不要再有人說「SSL協議有漏洞」之類的話。這次的漏洞是因為OpenSSL這款軟體在實現上的紕漏造成的，並不代表SSL這一安全協議標準出現漏洞。這樣的誤解是對SSL設計者們以及廣大密碼學界研究人員的一種不敬。

其次，我見到有人因為這次的漏洞就對開源安全軟體甚至安全協議標準產生了懷疑和不信任，有人甚至覺得使用閉源軟體甚至自主研發的加密演算法會更安全。這是很多對密碼學不了解的技術從業者非常容易犯下的錯誤。從理論角度上來說，已經有非常多的例子證明了看似聰明的演算法實際擁有的脆弱的安全性，比如WEP、CSS、古老的OTP等等。就算你的演算法實現過程不為人知，也有可能僅從密文上就分析出漏洞，直接進行破譯，類似的案例也有不少。今日被標準化、模塊化的加密演算法和開源安全軟體都是經過無數研究人員多年探索分析做出來的，沒有什麼商業公司能擁有如此強大的研究實力。從開發的角度來說，開源就意味著源代碼時刻接受所有人的審查，所以出現漏洞的幾率相當少。閉源軟體雖然阻擋了大部分人對內部原理的透析，卻無法阻擋黑客們通過逆向工程的分析，反而給黑客提供了壟斷漏洞信息，拉長威脅周期的條件。所以請不要抵觸開源軟體，相反，越是遇到類似今日的情況就越是要給予開源社區鼓勵和幫助，你的一分捐助能為你換來下一個十年、二十年的安全網路。

======以下純粹是技術吐槽，不喜請繞行=======

英文版漏洞分析請看existential type crisis : Diagnosis of the OpenSSL Heartbleed Bug

漏洞出現在ssl/d1_both.c中，對用戶傳入的payload長度沒有檢查就進行內存拷貝。

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 */


p指向一條SSLv3的記錄，結構如下

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;


回到上面的程序，接下來對指針進行一些操作

/* Read type and payload length first */
hbtype = *p++;
n2s(p, payload);
pl = p;


這裡先讀取個type，然後n2s把下一個length的兩個位元組放到payload裡面，作為後面內存拷貝的長度。

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


注意這個payload長度是用戶請求的，而在分配的時候完全沒有對於實際的SSL記錄長度進行審查，bp會直接返回給用戶，所以攻擊者可以dump出任意長度（最大為65535(payload)+1+2+16(padding)=64k）的數據，而pl也是用戶傳入的，只要把pl設置的很小，dump出來的數據就會包含更多別的敏感數據。具體的利用方法見exploit demo，就不詳細分析了。

---

把內存想像成一條紙帶，所有用戶的數據都一維地排列在這條紙帶上。

Bug重現的場景：

當前紙帶上的這一段要被處理的數據是：

[數據長度+數據內容]

這段程序要做的具體的事情是：

讀取數據長度，根據長度讀取數據內容，然後原封不動地把數據內容發回給用戶。

Bug利用的過程：

如果黑客伺服器發一段「惡意數據」：

[64K, 數據內容只有1byte] //也就是說聲稱自己有64K(最大64K，可以小於)，但是其實沒有這麼多

這種情況下，server就會把紙帶上後續的[64K-1]長度的數據「原封不動」地發回給黑客

Bug的嚴重性：

那個紙帶上包含server跟所有用戶打交道的所有的數據，所以黑客能「隨機」讀取這些數據中的64k是很致命的。而且他可以不停重複這個過程。

常見的一種情況是，如果你在黑客攻擊的同時登陸網站，你的用戶名密碼就有幾率落在被竊取的內存塊里。

可以肯定已經有很多人抓了一大堆來自各大網站的熱騰騰的內存塊，但是還沒有開始分析和利用。至於可以惡劣到什麼程度，自己想像吧。

更新：

好吧看起來有擴大恐慌的嫌疑，進一步解釋一下:

1.首先如果你在漏洞出來之後修復之前沒有登錄的話，應該是安全的。

2.如果你在危險期那個(登錄)了的話，有可能中獎，但是中獎的幾率多大不好說，但是各種資金相關的敏感帳號，的確改下密碼為好。

3.對於支持並開通了雙重驗證的網站，因為有一組動態密碼，所以理論上是安全的。

---

可以用十年一遇來形容了，

OpenSSL在Linux和開源領域應用極為廣泛，這個漏洞出在SSL這種核心組件上，Dump出來的數據包含身份驗證信息的可能性極大，遠不是其他漏洞可以比的。

這個漏洞的影響將會極其深遠，從短期來看及時更新版本避開有漏洞的OpenSSL版本可以解決問題。但是在這期間泄露的身份驗證信息是無法追蹤得知的，換言之任何可能曾經存在這個漏洞的系統的所有身份驗證信息都有可能已經被泄露。這使得漏洞被修復後將造成嚴重的安全假象，很可能很多系統的管理員許可權和身份驗證已經被竊取而不所知。甚至有些密碼是無法被簡單修改的。

僅僅是修改自己的密碼並不能保證絕對的安全，因為誰也不知道你面對的是不是CSDN那種沒有節操的用明文保存密碼的網站，對於這種網站而言，利用之前因為漏洞流出的系統管理員密碼登陸則可以輕鬆地獲取你最新的密碼。

這次爆出的這個漏洞的幾個特性應該完全可以稱之為十年一遇：

廣泛性：OpenSSL組件應用範圍極其廣泛。

核心性：OpenSSL組件主要提供SSL服務，該服務經常用於傳輸敏感信息例如密碼。

不可追蹤性：黑客利用此漏洞後不會留下任何痕迹，永遠無法知道黑客通過該漏洞獲取了什麼信息。

易攻擊性：HTTPS協議是外層公開協議，沒有防火牆或者其他保護措施，任何人都可以隨意發動攻擊。

---

把我采寫樓上餘弦的內容發在這裡吧，基本是一個對整個事件的梳理過程加應對建議，專業人士讀餘弦的，不明覺厲的讀這個版本入入門……

昨晚（4月8日）是黑客和白帽們的不眠之夜。他們有的在狂歡，逐個進入戒備森嚴的網站，耐心地收集泄漏數據，拼湊出用戶的明文密碼；有的在艱苦升級系統，統計漏洞信息，還要準備說服客戶的說辭，讓他們意識到問題的嚴重性；當然還有淼叔這樣看熱鬧不嫌事大的，拚命惡補安全常識、尋找專家採訪，試圖記錄這歷史性的一夜。

這一夜，互聯網門戶洞開。

基礎安全協議「心臟出血」

北京知道創宇公司的餘弦守在電腦屏幕前徹夜未眠。作為一家高速發展的安全企業研究部總監，餘弦在國內黑客圈資歷頗深。他向淼叔介紹了這次事件的起源。該漏洞是由安全公司Codenomicon和谷歌安全工程師發現的，並提交給相關管理機構，隨後官方很快發布了漏洞的修復方案。4月7號，程序員Sean Cassidy則在自己的博客上詳細描述了這個漏洞的機制。

他披露，OpenSSL的源代碼中存在一個漏洞，可以讓攻擊者獲得伺服器上64K內存中的數據內容。這部分數據中，可能存有安全證書、用戶名與密碼、聊天工具的消息、電子郵件以及重要的商業文檔等數據。

OpenSSL是目前互聯網上應用最廣泛的安全傳輸方法（基於SSL即安全套接層協議）。可以近似地說，它是互聯網上銷量最大的門鎖。而Sean爆出的這個漏洞，則讓特定版本的OpenSSL成為無需鑰匙即可開啟的廢鎖；入侵者每次可以翻檢戶主的64K信息，只要有足夠的耐心和時間，他可以翻檢足夠多的數據，拼湊出戶主的銀行密碼、私信等敏感數據；假如戶主不幸是一個開商店的或開銀行的，那麼在他這裡買東西、存錢的用戶，其個人最敏感的數據也可能被入侵者獲取。

一位安全行業人士在知乎上透露，他在某著名電商網站上用這個漏洞嘗試讀取數據，在讀取200次後，獲得了40多個用戶名、7個密碼，用這些密碼，他成功地登錄了該網站。

發現者們給這個漏洞起了個形象的名字：heartbleed，心臟出血。這一夜，互聯網的安全核心，開始滴血。

中國有至少三萬台機器「帶病」

一些安全研究者認為，這個漏洞影響可能沒有那麼大，因為受漏洞影響的OpenSSL 1.01系列版本，在互聯網上部署並不廣泛。

國內老資格的安全工作者、安天實驗室首席架構師江海客不認同這種說法。他在微博上預警：「這一次，狼真的來了」。

餘弦則以對問題進行了精確的定量分析。4月8日的不眠之夜中，他除了在Twitter和各大論壇中實時跟蹤事態的最新進展，更重要的精力放在了ZoomEye系統的掃描上。根據該系統掃描，中國全境有1601250台機器使用443埠，其中有33303個受本次OpenSSL漏洞影響！443埠僅僅是OpenSSL的一個常用埠，用以進行加密網頁訪問；其他還有郵件、即時通訊等服務所使用的埠，因時間關係，尚未來得及掃描。

ZoomEye是一套安全分析系統，其工作原理類似Google，會持續抓取全球互聯網中的各種伺服器，並記錄伺服器的硬體配置、軟體環境等各類指標，生成指紋，定期對比，以此確定該伺服器是否存在漏洞或被入侵。在此次「心臟出血」漏洞檢測中，餘弦給該系統後面加上一個「體檢」系統，過濾出使用問題OPenSSL的伺服器，即可得出存在安全隱患的伺服器規模。

從該系統「體檢」結果看，比三萬台問題伺服器更令人驚心的，是這些伺服器的分布：它們有的在銀行網銀系統中，有的被部署在第三方支付里，有的在大型電商網站，還有的在郵箱、即時通訊系統中。

自這個漏洞被爆出後，全球的駭客與安全專家們展開了競賽。前者在不停地試探各類伺服器，試圖從漏洞中抓取到盡量多的用戶敏感數據；後者則在爭分奪秒地升級系統、彌補漏洞，實在來不及實施的則暫時關閉某些服務。餘弦說，這是目前最危險的地方：駭客們已經紛紛出動，一些公司的負責人卻還在睡覺。而如果駭客入侵了伺服器，受損的遠不止公司一個個體，還包括存放於公司資料庫的大量用戶敏感資料。更為麻煩的是，這個漏洞實際上出現於2012年，至今兩年多，誰也不知道是否已經 有駭客利用漏洞獲取了用戶資料；而且由於該漏洞即使被入侵也不會在伺服器日誌中留下痕迹，所以目前還沒有辦法確認哪些伺服器被入侵，也就沒法定位損失、確認泄漏信息，從而通知用戶進行補救。

問題的應對與新的問題

目前，ZoomEye仍在持續不斷地給全球伺服器」體檢「，這個過程需要20小時左右。相比之下，僅僅給國內伺服器體檢需要的時間短得多，僅僅需要22分鐘；而給那三萬多台」帶病「伺服器重複體檢，則只需兩分鐘。目前，餘弦已經將這份名單提交給CNCERT/CC（國家互聯網應急中心），由後者進行全國預警。但是，除了移動、聯通等這些大型企業外，CNCERT也沒有強制力確保其他公司看到預警內容，最後可能還是需要媒體持續曝光一些「帶病」伺服器，以此倒逼相關公司重視該漏洞。

而在漏洞修補期間，普通消費者與公司均應該採取相關措施規避風險。對於普通用戶來說，餘弦建議在確認有關網站安全之前，不要使用網銀、電子支付和電商購物等功能，以避免用戶密碼被鑽了漏洞的駭客捕獲。「一位銀行朋友告訴我，他們補上這個漏洞需要兩天時間。這兩天大家最好就別登錄網銀了，確認安全後再登。如果已經登錄過了，那就考慮換一下密碼吧。」

與用戶的消極避險不同，相關互聯網企業則應該儘快進行主動升級。升級到最新的OpenSSL版本，可以消除掉這一漏洞，這是目前企業最便捷的做法。但在升級後，理論上還應該通知用戶更換安全證書（因為漏洞的存在，證書的密鑰可能已泄漏），並通知用戶儘可能地修改密碼。後面這兩個措施，企業實施起來會面臨很大的代價，也只能通過媒體盡量曝光，讓意識到的用戶重新下載證書並自行修改密碼了。

由於「心臟出血」漏洞的廣泛性和隱蔽性，未來幾天可能還將會陸續有問題爆出。在互聯網飛速發展的今天，一些協議級、基礎設施級漏洞的出現，可能會打擊人們使用互聯網的信心，但客觀上也使得問題及時暴露，在發生更大的損失前及時得到彌補。作為身處其中的個人，主動應變、加強自我保護，可能比把安全和未來全部託付出去要負責任一些。

---

烏雲平台已經有白帽子研究出新的進展，任何使用OPENSSL庫的程序都可能受到攻擊

任何平台任何使用openssl庫的程序都可能受到攻擊（非https）

這個問題不會這麼簡單，應該還有後續的發展！

漏洞的作者來自老牌黑客組織TESO Security(2002年就世界有名)，此人專門找OPENSSL漏洞，之前還寫過OPENSSH溢出那位（這裡就是伏筆了！！！）。

分析了一下外界放出來的POC，作者有所隱藏，漏洞影響可以dump 64KB內存，但POC只遍歷16KB。

hb = h2bin("""
18 03 02 00 03
01 40 00
""")

for b in xrange(0, len(s), 16):


# SMTPS 受影響的截圖

---

實在是看不過去了，曬張圖吧。

小白表示不明白【知道創宇】為何沒有提一下自己的產品【加速樂】也出現此漏洞了呢？

加速樂修復很快，但是不保證沒有人對其攻擊過，加速樂修復後就開始宣傳並宣稱各大廠商有漏洞，需要修復請使用加速樂，這樣攻擊他人來提高自己形象的回答還是少發為妙！

Openssl的漏洞既然早有了，那你們之前在幹嘛？

看圖吧，加速樂的伺服器同樣存在Openssl漏洞，別到處貶低別人鼓吹自己了！

---

我覺得這個問題不算奇怪，互聯網本身的tcp/ip就有足夠多的問題了。OPENSSL根本上來說是考慮不周，沒有意料到協議會被濫用。這樣的情況許多產品都會有，SSL只能說是影響比較大的一個。

這次的事故影響大，一個重要的方面在於，不是通過補丁逐漸修復，而是突然公開。發現者本人是一個黑客，而不是一個從事安全工作的人。不知道他現在是否為此遺憾。

我相信大多數的攻擊都是在公開後的幾天內發生，最危險的應該是個人信息和各種內部介面。本來我國使用ssl的單位就不多，我覺得反而是一件好事。這使得大多數中招的公司，都是具有能力迅速應對和修復的公司。因此這件事情不會更加嚴重。對於內部介面，這是一個難說的問題，畢竟從一般對付臨時黑客的角度考慮，內部介面萬能許可權是合理的做法，只能說防火牆沒有被重視，出於管理的方便，使得內部介面可以從各種各樣的機器請求而來。

我想到discuz早期版本的google api，它是一個高許可權的介面，它的一個重要的安全特性是限制了只能從google的個別ip發起鏈接，即使是ip欺騙影響也不大。

---

這個漏洞的實際影響非常大。

比較大型的網站，登錄認證這種事情，往往是一個獨立的應用，使用https協議單獨部署。所以運行一段時間之後，應用的內存中都是跟認證相關的數據，其中就會有大量的用戶名和密碼。在小型網站上利用這個漏洞反而比較困難，一般小型網站就那麼幾台Web伺服器，所有業務都在上面跑，Web伺服器的內存裡面什麼都有，有效信息的比重會很低。

實際測試了一下，以某寶為例，用4k大小的包讀取，嘗試200次，大約拿到40個用戶名，7個密碼。隨便試了一對用戶名密碼，可以登錄成功。

這個事其實也暴露出http服務的安全有多脆弱。

http服務有完善的鏈路層安全協議，反而導致設計應用協議的人偷懶，不在協議上作任何安全考慮，這樣在應用的兩端還是存在明文密碼。明文密碼或者說不過期的密碼，存在的地方多一個就危險一分。像登錄這種事情，如果客戶端發給伺服器的是密碼加時間的hash值，這個漏洞的危害就小很多。

一個有趣的事情是，設計原生tcp應用協議的人，反而會更多的在協議上考慮安全，因為他們沒有非常好用的ssl庫。

---

我覺得，這個漏洞的嚴重性被誇太大了。

其實就是代碼的一處bug，源於沒有對heart beating包的payload實際長度進行檢查。

heartbeating包最大長度(有效載荷部分)是65535 bytes（也就是到處宣稱的可以偷到的那64K數據的長度），而且這個payload大小是調用xxx_malloc函數時由用戶給定的。

我們假設一種情況：

用戶先申請64K的內存空間，而實際構造的heartbeating包payload長度為0，卻在包頭裡頭2個位元組指定payload長度為64K。

關鍵的一處在於：OPEN SSL的代碼里調用了一次memcpy函數，從heartbeating載荷里拷貝數據出來。

問題就是出在這裡：memcpy會拷貝64K的內存數據，而實際上卻不應該有數據。那麼被拷貝走的這些數據，就是在內存里挨著heartbeating payload存放的其它數據了。memcpy可不管那麼多，即便那段內存里是渣渣，也一樣拷給你。

這樣，數據就被偷到了。至於這些數據是什麼？可能是有用的諸如帳號密碼，也可能是一句讓你臉紅心跳的調情的文字。看運氣咯。

---

給你轉一下TK教主的博客上有關這個問題的看法。
Heartbleed 這事兒還沒完，說誇張點，可能剛剛開始。1、昨天各家的安全工程師都很辛苦。但搞入侵的可能比你們更辛苦，很多人估計昨晚一宿沒睡。他們趕在各家修復前所抓到的數據會在未來幾天里被分析、提取、利用。2、據一個向來比較靠譜的同志說：OpenSSL不是唯一存在類似問題的庫。

同時告訴你庫漏洞威力是巨大的。因為通用性導致能夠多媒介觸發。IE只是其中覆蓋量最大的一個。同時可以肯定的告訴你其他庫也有類似沒有曝光的漏洞，袁哥手裡就有。這就是為什麼他的漏洞號稱全面通殺保證一直不被防禦的一個方面。

---

如果一個線程一天不停的讀，設1s一次，一天86400s，乘以64k，等於5400M，設即使有用的信息只有1%，也有54M的數據，如果是帳號密碼cookie等信息，真是龐大的數據量啊

---

影響有多大么~

給點數據吧，數據來源：SHODAN - Computer Search Engine

中國地區使用Open SSL的主機數量為 127551 。沒錯有近13萬！

全球使用Open SSL的主機數量為 5559362 。沒錯就是556萬！

可見一旦Open SSL出現全版本通殺漏洞，後果將是毀滅性的的。幸好這次的漏洞受影響版本還不算普及。

根據漏洞詳細受影響版本信息（1.0.1-1.0.1f）重新搜素的結果，確定有可能受影響的主機數量如下（不排除有大量受影響主機由於數據刷新時間較早或其他原因不在統計數據範圍內）：

全球16453 台主機。

中國地區居然只有275 台主機。

比較有趣的一點是，似乎大家都不願意升級Open SSL，根據數據統計使用1.0.1版本的主機數量僅佔0.2%，這也許恰好保護了一些缺少技術支持的網站~

---

簡單的說下來龍去脈，以及危害有多大。→來自OpenSSL項目的 「心臟出血」（Heartbleed）重大安全漏洞曝光，頓時，世界上所有的程序猿/媛都震驚了！該漏洞被「譽為」本年度互聯網上最嚴重的安全漏洞，往下讀你會發現，它真是對得起這麼恐怖響亮的名字！

漏洞發現：純屬偶然！

全球三分之二伺服器中槍，嚇尿全世界工程師！

就在今年四月初，安全公司工程師吃著火鍋唱著歌，干著和平時一樣的日常工作，一個不小心檢測到了一個名為Heartbleed的系統漏洞（騰訊科技截圖，有圖有真相）。後來隨著深入研究，工程師被嚇尿了！因為他們發現這個漏洞可以誘惑伺服器（OpenSSL）「吐」出內存信息，然後讓黑客同志有盜取信用卡密碼等敏感信息的機會！另外必須吐槽的是，這個漏洞可以影響全球三分之二伺服器，因為他們都在使用OpenSSL加密協議。（相比較，攜程的漏洞簡直是弱爆了！）

漏洞存在：已經兩年！

極強危害https開頭網址，比如……你的網銀！

聞風而來的工程師們一個接著一個被嚇尿了。因為這個外號叫「心臟出血」的漏洞對一切https開頭的網址都具有極強的危害性，可以導致網站用戶的大量隱私信息泄露。更可怕的是絕大多數網銀、電子商務、電子郵件網站，都是https開頭的有木有！！最最最糟糕的是，這並不是一個新的漏洞，而是已經存在兩年之久！這就意味著絕大多數網民的個人賬號、銀行賬號及隱私等，均將毫無保留地被黑客所掌握！此處應配樂：多麼痛的領悟。
（詳見騰訊科技文章）

漏洞預警：已上線

但，漏洞餘毒根本停不下來！

目前，騰訊電腦管家已緊急聯合安全聯盟上線OpenSSL漏洞預警功能，凡是存在此嚴重漏洞風險的網站，均被攔截。但奈何全球伺服器眾多，很難保證他們都修補了安全漏洞（尤其是一些技術實力不足的小網站），漏洞餘毒根本停不下來！

為了不讓諸位的錢袋子隨著「心臟出血」大出血，本猿主動加班吐血建議：

1、 儘快使用專業級的安全防護工具抵禦黑客入侵

2、申請安全聯盟電腦管家「雙V」認證，獲得專業安全檢測和漏洞預警服務，解除網站風險提醒；

3、 諮詢安全聯盟修復專家獲得修復支持（升級OpenSSL 1.0.1g，使用-DOPENSSL_NO_HEARTBEATS參數重新編譯低版本的OpenSSL以禁用Heartbleed模塊。）

4、請轉給不知情的單純小夥伴們，順祝：百毒不侵（此處有蠟燭）

以上

---

推薦閱讀：