Aggregator

晚上突然接到社群朋友傳 LINE 的訊息過來，定睛一看並不單純。這網址看起來就是釣魚網站啊？怎麼會這樣呢？難道是朋友在測試我們的警覺心夠不夠嗎？讓我們看下去這個釣魚網頁怎麼玩。

此 LINE 釣魚訊息說只要幫忙轉發 15 次訊息，就會贈送貼圖。先不論 LINE 有沒有這樣的機制，我們先直接點選連結看看葫蘆裡賣什麼藥。

瀏覽器打開之後，跳出了領取貼圖的「網頁」，而且還有詭異的紅字。各種跡象都跟一般領取貼圖的模式不同，太令人起疑了。點了圖就會跳到 Facebook 登入頁面。

明眼人看到這個 Facebook 登入頁面就會發現太假了，破綻多多。Logo、網址、網頁格式破板、簡體字，太多令人懷疑的地方了。在這邊我們只要隨便輸入帳號跟密碼，就能到下個畫面。

結果當然是不會給你貼圖啦！而且網址「cuowu」是「錯誤」的拼音，也暴露了網站作者的身分。直接用瀏覽器看傳遞的頁面叫做「tj.asp」，「tj」正好是「提交」，畫面上的錯誤訊息更是大剌剌的直接秀出簡體字。

事後友人直接說 LINE 帳號被盜用發訊息了，而且密碼可能過於簡單、也沒有設定換機密碼。因此在這邊呼籲大家做好 LINE 的安全設定：

1. 加強密碼長度、複雜度
2. 設定「換機密碼」
3. 若只在手機使用 LINE，可將「允許自其他裝置登入」關閉
4. 如果有帳號被盜狀況，趕快聯絡 LINE https://line.naver.jp/cs/

大家在享受通訊軟體與朋友傳訊貼圖的同時，也必須要注意有心人士利用這些管道竊取你的帳號密碼喔！

The Government Communications Security Bureau (GCSB) is responsible for administering the network security provisions of the TICSA.

最近很多人都收到了一個看起來很像釣魚網站的核四投票站台簡訊，如下圖：

我們也收到了，但是剛吃飽飯實在很想睡覺，不太想理他，於是就忍不住趴下睡覺，竟然做了個夢…..

在夢中手滑打開了網頁，內容長得像這個樣子：

看了真是非常的義憤填膺！馬上就想投下神聖的一票！但是忽然聽到周公指示說網站底下有奇怪的目錄，照著神諭一試，發現有 .svn 目錄跟 entries 檔！

這時候三太子哪吒剛好路過，說他剛剛在 Pastebin 看到有人貼了一篇跟這個網站好像有關聯的內容，講完他就開著水車跑去鎮壓龍宮了。點開那篇內容一看，內容有一些很奇怪的網址，讓人看了就很想點！隨便選了一個 http://vote.tw.am/2N9E6V4E5R4BABC0647469FF213F2D94A27FA/chose_vote.include.php 打開來看：

哇塞！原來從服貿就已經開始了呢！讓我們繼續點進去看看：

看起來是個後台，可以瀏覽使用者的投票記錄、留言等資料，那就點個投票記錄來看看：

果然裡面存著眾多民眾的投票記錄，那麼用戶反饋應該就是留言了…

從這些內容看來，應該是有個集團擁有大量的民眾個資，並且一一發送訊息給這些人，背後目的尚不得而知。有可能是大陸人想利用這個熱潮確認這些電話號碼是否真實、可用，也有可能是不知名的黑手正在策劃下一個打壓動作？正當我們想搞清楚對方究竟是透過電話號碼還是信箱傳送 iMessage 時，哪吒忽然又路過了，丟了這張圖之後叫我們不要再瞎忙了趕快回家洗洗睡：

果然有電話！究竟這件事，是有網站大量洩漏個資，還是有人在民運期間利用這股熱潮蒐集個資，抑或是背後有什麼不可告人的秘密呢？讓我們繼續看下去～

上班時間不能午睡太久，於是周公就把我們叫醒了…..

對於這樣的夢境我們有以下建議：

• 不要隨意點擊來路不明的簡訊內容
• 在網路上填寫任何內容之前先查證該網站是否可疑
• 對於 [email protected] 這種可疑帳號所傳來的任何資料，請保持高度警戒
• 對於 vote.tw.am 這種看起來疑似要偽裝成 .tw 網域的站台，也請保持高度警戒

歡迎大家轉發這個消息到各大網站、粉絲團、BBS，告訴各個熱心公益的鄉民們別再點擊與回應來路不明的簡訊囉！

DNS 是在 1983 年由 Paul Mockapetris 所發明，相關規範分別在 RFC 1034 以及 RFC 1035。其主要作用是用來記憶 IP 位址與英文之間的對應關係，讓人類可以用較簡單的方式記得主機名稱。目前一般民眾大多使用 ISP 或國際知名公司提供的 DNS server，如中華的 168.95.1.1 或是 Google 的 8.8.8.8 等等。

然而對於企業而言，可能需要架設大量機器或內部系統，又希望以簡單的方式記憶主機名稱，因此許多企業有自行架設 DNS server 的需求。同時企業通常也會建立幾台備援 DNS server，以避免 DNS 服務忽然中斷。但是當企業有多台 DNS server 時，就必須考量 DNS 記錄的同步問題，通常會使用 zone transfer 這個功能來同步記錄。

然而若管理者未做好相關設定，使所有來源皆可對企業的 DNS 主機進行 zone transfer 查詢，則有機會讓此功能成為企業遭受攻擊的起點。用現實生活情境舉例的話，對外開放 zone transfer 就如同所有人都可以任意查詢你名下的所有房地產位在何處，假如有人要針對性的攻擊你，隨時都可以去看你某個房地產有沒有哪扇門窗沒關好，伺機入侵你的家園。一般我們對企業資訊系統進行滲透測試時，在資訊搜集的階段也會先從 domain name 下手，因此 DNS 相關資料的重要性可見一斑。

Zone transfer 的資安議題早在 1999 年就已有人提出，理應成為各企業進行資安稽核的步驟之一。然而十五年過去了，在近期我們卻發現許多國內大企業仍有此問題，令人非常驚訝！究竟企業該如何檢測自身是否存在這種安全漏洞？此問題目前在台灣網路環境佔有多大的比例？Zone transfer 會對企業造成什麼影響？讓我們繼續看下去～

首先需感謝 DigiNinja 提供了一個讓大家自由測試的 zonetransfer.me 網域，以下我們分別在 Linux 及 Windows 環境下進行檢測。

在 Linux 環境內，我們可利用 dig 指令查詢目標 domain 使用哪些 name server：

Name server 查詢結果：

從結果可得知有 ns12.zoneedit.com 或 ns16.zoneedit.com 這兩個 DNS server，接著我們即可測試是否可從外部網路對這兩個 DNS server 進行 zone transfer，測試方式如下：

Zone transfer 測試結果：

從上面的測試結果中我們可發現，zonetransfer.me 這個網域的所有 DNS 設定已全部被列出。

若是在 Windows 環境，可在命令提示字元環境內使用 nslookup 指令查詢目標 domain 使用哪些 name server：

Name server 查詢結果：

輸入指令後我們如同先前使用 dig 一樣，得知目標有 ns12.zoneedit.com 與 ns16.zoneedit.com 這兩個 name server，接著再如下圖依序輸入三道指令查詢：

註：Linux 版的 nslookup 沒有實作 ls 這個功能喔！

Zone transfer 測試結果：

測試結果與 Linux 環境所得到的資料雷同，可成功列出該網域的所有 DNS 設定。

當然，並不是每個人都熟悉上述指令的操作方式，因此除了介紹手動檢測方法之外，在這裡也提供幾個線上檢測的服務，讓大家可以迅速檢測自家公司或者你正在使用的服務是否有此問題：

• UltraTools
• HackerTarget
• Digital Point

如同上次 HTTP Headers 資安議題所探討的對象，我們從 TIEA 成員以及 Alexa TW top 525 觀察 zone transfer 問題分別在這些族群中佔有多少比例。

根據我們監測的結果，在目前 TIEA 的 132 名成員中，有 20 個網域存在 zone transfer 問題，佔了 15.15%。而在 Alexa TW top 525 當中，有 48 個網域存在 zone transfer 問題，佔了 9.14%。乍看之下比率似乎不高，但是在上述兩個族群的網域當中，包括：

• 電信商
• 多家電視媒體
• 多家網路新聞媒體
• 多家線上購物網站
• 知名團購網站
• 知名金流公司
• 知名線上音樂服務

台灣企業不夠注重資訊安全，罔顧客戶資料安全性，早已不是新聞。然而若企業不顧自身商業利益與責任，當彼此無商業往來時，我們也無法一一咎責。但若連台北市政府、教育部、多間大專院校都有此問題，就令人不太能接受了，這些政府單位與教育機構理當為我們的個人資料安全性負起全部的責任，不應該漏掉任何一個資安環節。上述結果顯示出台灣從政府到企業可能都沒有徹底落實 DNS 的資安設定，而且目前的數據僅僅是針對 TIEA 成員以及 Alexa TW top 525 進行檢測，若是對全台灣或是全世界進行大範圍的檢測，恐怕會發現更多驚人的案例！

• 洩漏網域名稱

  一般企業在進行滲透測試時，通常只會挑幾個最重要、最常面對客戶的網域進行測試，但是入侵者可不會這麼乖。當有人嘗試要入侵企業時，必定是先進行全面的偵查，觀察企業哪幾個網域所執行的 service 有潛在的弱點，或是看哪幾個網域防禦力道較弱，再從該處下手。因此 zone transfer 問題所提供的完整 DNS 記錄，就為入侵者省下了許多偵查的工夫。

• 洩漏外網 IP 範圍

  當攻擊者取得 zone transfer 所洩漏的資料後，可合理推斷哪些網段是屬於該企業，進一步對該網段進行掃描，嘗試找尋有機會入侵之標的物。

• 洩漏內網 IP 範圍

  有些管理人員、開發者為求內部開發方便，經常會將網域名稱跟內網 IP 位址綁在一起，例如將 phpmyadmin.example.com 設定為 192.168.1.100，攻擊者就可根據此類資訊猜測內網哪些網段存在重要服務。這種設定平常也許不會造成重大損害，但是當管理者疏於建立內網防禦機制，恰好企業又被入侵至內網時，造成一連串重大損失的機率將會大幅提高。

若使用 Linux，可在 /etc/named.conf 內加入下列選項，以限制可存取 zone transfer 的來源：

設定完畢後，將 DNS 服務重啟即可生效。

在 Windows server 當中，我們可到伺服器管理員修改網域的相關設定，如下圖：

在伺服器管理員中，選定想要修改的網域（此處以 test.com 為例），按右鍵點選內容，將會跳出選單如下圖：

接著就是觀看「允許區域轉送」選項是否有勾選，若已勾選，則確認轉送對象是否為下列兩種：

• 只到列在「名稱伺服器索」引標簽上的伺服器
• 只到下列伺服器

DNS 在做 zone transfer 時是使用 TCP 53 port（有別於一般 DNS query 的 UDP 53 port），因此有些人會認為將 TCP 53 port 關閉就可以對付 zone transfer，而不想修改 zone transfer 的設定。其實這個觀念只對了一半，若 zone file 的資料小於 512 byte，仍然可以透過 UDP 傳輸。即使 zone file 的資料大於 512 byte，也可以用 Incremental Zone Transfer (IXFR) 的方式取得部分資料。

如果企業今天非常有自信能夠替所有網域都準備好完善的安全措施，那麼 zone transfer 所洩漏的資料對該企業就不會有太嚴重的影響。然而，在現今這個入侵手法日新月異的世界裡，又有誰能夠永遠保證自己的安全防護已經做足了呢？在前陣子火紅的 OpenSSL CVE-2014-0160 Heartbleed 問題被爆出來之後，我們就藉由許多 zone transfer 的記錄觀察到全世界有非常多企業只修復了主要網站的 OpenSSL 漏洞，卻忽略了企業內其他的服務與設備可能也有此漏洞，像是 DB、Email、VPN、NAS 等等，直到今日仍遲遲未修復。

千萬別以為你所購買的各種資安設備能防禦所有資安弱點，也別忽略了各項古老的資安弱點，更別小看了你所不熟悉的駭客們的組合各式各樣弱點的能力，只要有一個資安環節疏漏，隨時都有可能對企業造成致命危機。

不安全的引用物件 (Insecure Direct Object Reference) 是個非常常見的資安漏洞，在 OWASP 公布的十大網站應用程式安全漏洞 中高居第四名。通常發生在網站應用程式上沒有針對輸入的參數做好檢查，就把參數丟入 include 或 readfile 等函數當中引用，使得攻擊者可以藉此存取任意文件的原始碼。

今天這個案例就發生在 PHP 的官方網站 (http://www.php.net/)，消息來源是知名的 0-Day 黑市 1337day，發佈的日期是 2014/4/4 ，原始的內容是這樣的：

可以看到這個弱點是不公開的，想要知道內容的話要支付 82 美元相當於新台幣 3500 元呢！在強烈的好奇心屈使之下，自己打開工具來找看看：

透過簡單的分析和一點點運氣，找到了 「http://www.php.net/cached.php」 這隻程式，發現它傳入了「t」和「f」這兩個參數。「t」直覺上就是個 rand 數值，而「f」應該就是檔案位置了。這時候對 f 參數小小修改一下，神奇的事情發生了：

index.php 的原始碼被完整的讀出來，當然也要來看一下 cached.php 是怎麼寫的：

可以看到此處並未對 $_GET[“f”] 進行檢查，所以修改了 $_GET[“f”] 後，與 $abs 組合完，最後就直接丟入 readfile 讀取檔案。比較值得研究的是這邊使用了 realpath 與 strncmp 來比較 f 及 DOCUMENT_ROOT，確保 $abs 只能在網站目錄之下，所以無法使用 ../../ (Path Traversal) 的方式跳脫目錄進行更進一步的滲透。

最後我們將此發現回報給 [email protected] ，得到的回應是他們是「故意的 (intentional)」。且後來也知道 PHP 官網是開放原始碼（Open Source）的，可以到 http://git.php.net/?p=web/php.git;a=tree 下載整個官網的原始碼。

雖然在這個案例中並沒有造成實質上的危害，沒有帳號、密碼、系統設定等機敏資料，但若把此種寫法用在其他地方，則可能造成很大的資安風險。就連 PHP 官方網站都有這樣的失誤，身為開發人員的你們更不可不慎！

在一陣 OpenSSL Heartbleed 淘金潮中，又有一個技術門檻低、後果嚴重、也同樣需要些運氣的漏洞被揭發－CVE-2014-0166。CVE-2014-0166 是 WordPress 上面驗證登入 cookie 的弱點，攻擊者可以暴力偽造出合法 cookie，藉此獲得 WordPress 最高權限，進而拿到 shell 取得系統操作權。 讓我們來分析一下這次的弱點是發生了什麼事吧！

這次出問題的程式碼在這邊，關鍵程式碼如下：

問題主要發生在比較運算子 != 上面，!= 運算子是 non-strict，會在比較前先做型態轉換，所以下面看似應該是回傳 true 的例子，全部都顯示為 false，細節請參閱官方手冊。

進入正題，WordPress 認證身分用的 cookie 內容是這樣的：『username|expiration|hmac』。
username 是使用者名稱，
expiration 是有效期限(timestamp)，
hmac 值用來驗證 cookie 是否合法。
從上面程式碼可以看到，hmac 的算法是經過 username、pass_frag、expiration、key 綜合得出。若有辦法控制 cookie 中的 hmac 使伺服器認為該 cookie 合法，就可以成功偽造成 username。

利用稍早提到的比較運算子問題，若我們讓 cookie 中的 hmac 值為 0，很有可能讓判斷式變成下面這樣：

如此便可以通過驗證，成功偽造合法 cookie。
而為了讓 $hash == 0，可以不斷改變 cookie 中的 expiration，讓產生的 MD5 值($hash)經過型態轉換後剛好變成 0。
符合 $hash == 0 的 MD5 $hash 值有 0eXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX、00eXXXXXXXXXXXXXXXXXXXXXXXXXXXXX….000000000000000000000000000eX、00000000000000000000000000000 (X = 0,1,2,3,4,5,6,7,8,9)

故出現 $hash == 0 的機率為 Sum(10^n,n=0,30)/16^32 = 3.265262085617465e-09

每次偽造的成功機率約為三億分之一，並不會很高，但已經足夠在一個月內拿到最高權限，而且所耗成本並不會很高。

為了驗證此方法之可行性，我們架設了 WordPress 3.8.1 環境。並且寫程式將登入 cookie 中的 hmac 設為 0，不斷調整 expiration 值測試是否已經登入，程式如下：

註：此程式為 POC，請自行調整為多執行緒版本，不然速度會很慢。

經過一段長時間的等待，得到的結果如下：

得知當 cookie 中的 username 為 admin 且 expiration 值為 1421818232 時，伺服器算出來的 hmac 經過型態轉換會變成 0。我們將測試成功的 cookie 值： admin%7C1421818232%7C0 貼到瀏覽器上。成功變成 admin 如下圖，實驗成功！

註：一般狀況，若不知道 WordPress 最高權限的帳號，可以利用 WordPress 的 feature 在 http://your.WordPress.com/?author=$id ($id: 1,2,3,4…,999,…) 頁面中列舉所有使用者帳號。通常 $id = 1 的 author 都有 WordPress 的管理權限。

最近出現了一個高風險通報 CVE-2014-0166，其中提及 WordPress 在舊版驗證 cookie 的部分出現弱點，可以偽造合法 cookie，進而取得 WordPress 管理權限。本文分析了其原理，並且證實之。

對於攻擊者而言，雖然每次偽造 cookie 成功的機率約為三億分之一並不高，但發送三億個 request 後或許能拿到最高權限，已經是值得投資的級數。

對於 WordPress 管理者而言，建議立即更新至 3.8.2 以後版本，以免受到此風險攻擊。

從此事件也提醒了 PHP 開發者，在撰寫重要的驗證行為，要特別注意 PHP 比較運算子的特性，請使用 === (不等於請用 !==)來保證等式左右型態與值為一樣，避免因為轉型造成的資安風險。

你跟上了 OpenSSL Heartbleed 的祭典了嗎？如果還沒有，別忘記詳細閱讀一下我們的前文「OpenSSL CVE-2014-0160 Heartbleed 嚴重漏洞」。

這幾天不少企業、民眾都不斷來詢問我們相對應的解決方案：

• Heartbleed 跟我有關嗎？我該怎麼知道？
• 我該怎麼更新 OpenSSL？
• 我如果不能更新，要怎麼防止攻擊？
• Heartbleed 漏洞攻擊者會怎麼利用？
• 目前受害的狀況如何？
• 我只是一般民眾，該如何應對？

我相信不少人都有類似的疑問，我們以這篇專文補遺上次沒提到的資訊。

大家都說 OpenSSL Heartbleed 漏洞可望為本年度最嚴重的漏洞，到底有多嚴重呢？我相信沒有看到攻擊的範例是沒有感覺的。大家可以先看看以下的影片，利用最先釋出的兩個簡單的 PoC exploit （弱點利用程式）「ssltest.py」以及「check-ssl-heartbleed.pl」，來檢測伺服器是否有 Heartbleed 問題。檢測的同時可以獲取伺服器記憶體中的資訊，其中就可能包含了機敏資訊。

讓我們來看看吧！

首先利用 ssltest.py 來測試，來看伺服器是否有被 heartbleed 漏洞影響，fbi.gov 在第三天已經修復這個問題。

如果是檢測一個有漏洞的網站，這個工具會直接把記憶體的內容顯示出來，其中可能包括 http 傳輸的資料、帳號密碼、私密金鑰等。在這個例子中，攻擊程式讀取到使用者送出的 form，若其中包含個資將會被一覽無遺，非常危險。

另一個工具 check-ssl-heartbleed.pl 可以使用 -R 參數做更有效的利用。直接執行指令可以快速顯示伺服器有無問題。

如果使用「-R」參數並且指定特定的正規表示式，可以抓出想要獲取的資料。例如 Cookie、帳號密碼等。以此例，我們知道這個網站提供 phpMyAdmin 套件，因此直接鎖定「pmaPass」資料來抓取，沒想到第一次就抓到了。

接著攻擊者只要把這個獲取到的 Cookie 存入自己的瀏覽器中，就可以如影片中盜用這個帳號。是否很危險呢？

除了這種利用方法之外，還有更多情況是直接把使用者登入的帳號密碼直接顯示出來的，因此如果伺服器沒有做好防禦或更新，整個網站的使用者資料都可以因此外洩。這也是為什麼我們一直強調伺服器管理者必須要更新金鑰、全站使用者帳號密碼等，以防有心人士借此撈取資料。

由 github 上面的 commit 記錄，出問題的那行程式碼是在 2011-12-31 22:59:57 commit 的，不知道是開發者太累還是 NSA 的陰謀。根據 Bloomberg 的報導指出，知情人士表示 NSA 早在兩年前就已經知道此漏洞，並且利用這個漏洞竊取許多網站的機敏資料。這代表 NSA 在一開始就知道這個漏洞，令人不禁有其他聯想。

The U.S. National Security Agency knew for at least two years about a flaw in the way that many websites send sensitive information, now dubbed the Heartbleed bug, and regularly used it to gather critical intelligence, two people familiar with the matter said.

在之前台灣駭客年會 (HITCON) 2013 的講師 Rahul Sasi (Garage4Hackers) 公布了大量掃描 Heartbleed 漏洞的程式，也可以供研究人員自行研究，或者是尋找自己管理的主機中有多少包含這個風險的。

OpenSSL 是一個函式庫（Library），在 UNIX 系列的服務若有使用 SSL，通常都會使用 OpenSSL。因此這次的漏洞並未影響微軟 IIS。

你聽過 BEAST, BREACH, CRIME, Lucky 13 嗎？

。。。

不只！只要使用 OpenSSL 支援 STARTTLS 的服務都在影響範圍，包括 HTTPS、IMAPS、POPS、SMTPS 等伺服器。

當然不只！目前已經出現各大設備廠商都遭遇到這樣的問題。各大設備廠商、作業系統等影響狀況，可以參閱以下文章。

CERT: OpenSSL heartbeat extension read overflow discloses sensitive information http://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=720951&SearchOrder=4

廠商的設備目前狀況特別嚴重，因為所有同個版本的設備都會受影響，而在廠商釋出更新之前，只能被動的等待更新。若沒有繼續簽訂維護約的設備，也只能繼續跟廠商簽約更新，或者是看廠商是否可以直接提供更新檔。如果有 VPN Server 等服務更要注意，如果被攻擊者取得帳號密碼，等於如入無人之境，直接使用你的帳號登入到企業內網，不可不慎。

引述自好朋友 Ant 的文章，各家作業系統、網站的更新速度，代表著企業重視資安的程度以及針對資安事件緊急應變的效率，也可以作為我們挑選系統、網站、廠商的依據。

二、作業系統的更新進度

從資安事件的處理可以推敲出各作業系統商對於緊急事件的反應速度。 時間軸，按照修復的先後排列：

1. OpenSSL (資安弱點的主角) 第一次公開揭露的時間約在 2014年4月6日 0時。
2. RedHat 在 2014年4月7日 07:47:00 正式修復。
3. OpenSSL 正式確認並修復的時間約在 2014年4月7日16時。
4. OpenBSD 約在 2014年4月7日 20:17 正式修復。
5. Arch Linux 約在 2014年4月7日 20:36 正式修復。
6. Debian 約在 2014年4月7日 21:45 正式修復。
7. FreeBSD 約在 2014年4月7日 21:46 正式修復。
8. Ubuntu 約在 2014年4月7日 21:48 正式修復。 (2014年4月8日分隔區)
9. Fedora 約在 2014年4月8日 00:33 正式修復。
10. CentOS 約在 2014年4月8日 02:49 正式修復。
11. OpenSUSE 約在 2014年4月8日 05:32 正式修復。
12. Scentific 約在 2014年4月8日 08:27 正式修復。
13. Gentoo 約在 2014年4月8日 09:36 正式修復。

重點整理：

1. RedHat 修復的速度比 OpenSSL 官方還快。
2. RedHat 派系的修復時間，除了 RedHat 外都算慢，如 Fedora 及 CentOS、Scentific，他們都比 RedHat 慢 16 小時以上。
3. Debian 派系的修復時間，如 Debian 及 Ubuntu，都比 RedHat 慢上至少 12 小時以上。
4. Gentoo 是列表中修復最慢的。
5. 若以資安黃金 6 小時來說，Fedora、CentOS、OpenSUSE、Scentific 及 Gentoo 都不及格。

三、大公司更新的速度

同樣地，從資安事件的處理可以推敲出各公司對於緊急事件的反應速度。

雲端相關公司

• Cloudflare 約在 2014年4月7日 11時修復。
• DigitalOcean 約在 2014年4月8日 12時修復。
• AWS 約在 2014年4月8日 12時修復。
• Linode 約在 2014年4月8日 14時修復。
• Heroku 約在 2014年4月8日 16時修復。

有些公司直到 2014年4月8日 16時都還沒修復。此時已離官方正式修復整整一天，也比上述機器數很多的雲端相關公司還慢。這些公司為，

• Yahoo.com / Flickr.com
• Kaspersky.com (資安公司)
• stackoverflow.com
• stackexchange .com
• php.net

感謝 StackNG 的補充：Cloudflare 於 2014 年 4 月 7 日 11 時公告，但在漏洞公告之前已經修復。

根據 ZMap 的研究報告指出，他們針對 Alexa 前一百萬個網站進行檢測，大約有 36% 的伺服器支援 TLS、7.6% 的伺服器含有此漏洞。ZMap 並提供了一個完整的清單列出在 2014/4/11 17:00 尚未修復漏洞的網站。

via Facebook

根據不同的 Linux Distribution 有不同的更新方式，若有自己客製化一些程式設定，可能就需要自行更新。以下我們簡單介紹更新步驟：

RedHat / CentOS / Fedora 系列更新套件：

Debian / Ubuntu 系列更新套件：

若只要更新 OpenSSL 則可以執行以下指令

注意 OpenSSL 是否已經更新為修復的版本：

接著請記得撤銷原本的簽章金鑰，重新簽署，並記得提交 CSR (Certificate Signing Request) 給 CA (Certification Authority)。

結束後記得重新啟動相關服務

最後再使用檢測工具看自己的網頁伺服器或其他相關服務是否已經不在漏洞受害範圍。

若你使用 Snort IDS，官方已經釋出 SID 30510 到 30517 來偵測，並且在 Community Rules 中也有包含。 http://www.snort.org/snort-rules/#community

不少朋友來信、留言洽詢，到底自己該怎麼針對這次的漏洞應變？我們簡單就一般民眾以及系統管理者說明。

• 注意常用的重要網站服務，是否有針對 Heartbleed 漏洞的更新措施。不少大公司都有發出公告、公告信等。
• 若常用網站服務有遭遇此風險，記得更換帳號密碼。
• 若這段時間有網站通知更換密碼，也請注意是否為釣魚信件。
• 注意自己的帳號是否有異常活動。
• 若使用的網站服務就是不更新，一天一信友善提醒管理者。

• 更新 OpenSSL 至 1.0.1g 或 1.0.2-beta2，並密切注意有無後續更新。
• 重新產生金鑰（Private Key 可能外洩）、Session（Session ID 可能外洩）、密碼（密碼也可能外洩），並且撤銷原本的金鑰。
• 若無法更新，重新編譯 OpenSSL 以關閉 heartbeat 功能。
• 使用 Perfect Forward Secrecy (PFS)，在未來類似風險發生時減低傷害。

許多業者抱持著僥倖的心態，想說外洩的目標不會輪到自己。如果大家看到這幾天全世界資安人員 / 駭客不眠不休的撈取資料，應該會徹底消滅僥倖的想法乖乖做好防護。在漏洞揭露的頭幾天，就已經陸續看到不少駭客進入 Google、Facebook、Yahoo! 等伺服器，並且撰寫大規模掃描工具大量攻擊。除非你有把握自己的伺服器沒有任何連線，不然還是請乖乖更新吧。

還記得之前我們提到的「使用第三方套件所要擔負的資安風險」？這次的事件就是一個血淋淋的案例。不管是廠商、社群、個人開發者的粗心失誤，或者是國家機器 NSA 的強力滲透，使用各種第三方的套件都需要承擔極大的風險。但可悲的是，我們卻無法不使用。從這次的事件我們可以學到幾件事情：

1. 不管哪種攻擊手法、多老舊的攻擊手法，在未來都可能會再度發生。
2. 程式碼的 review 非常重要，一定要在開發過程中導入程式碼 review 機制，以免開發者寫出含有安全疑慮的程式碼。
3. 加密、Session 控管、金鑰控管等議題，是永遠的課題。一天沒處理好，在未來的風險中會再度受害。
4. 風險永遠會發生在你猜不到的地方，可能是程式、可能是函式庫、可能是加密協定、更可能是亂數產生器。

不斷的增強資安意識、不停的分享新知、廠商做好資安控管及安全檢測、民眾對企業和政府要求資訊安全，集合大家的力量，是改善資安大環境的不二法門。

你以為自己逃過一劫了嗎？也許你的身體已經血流如柱，而嗜血的鯊魚正游向你。

OpenSSL 今天公告了一個極度嚴重的漏洞（CVE-2014-0160），被稱為「Heartbleed」，而他確實也如同心臟噴出血般嚴重。這個漏洞能讓攻擊者從伺服器記憶體中讀取 64 KB 的資料，利用傳送 heartbeat 的封包給伺服器，在封包中控制變數導致 memcpy 函數複製錯誤的記憶體資料，因而擷取記憶體中可能存在的機敏資料。記憶體中最嚴重可能包含 ssl private key、session cookie、使用者密碼等，因此可能因為這樣的漏洞導致伺服器遭到入侵或取得使用者帳號。

詳細的分析可以參閱 existential type crisis : Diagnosis of the OpenSSL Heartbleed Bug

• 軟體名稱：OpenSSL
• 影響範圍：1.0.1 至 1.0.1f / 1.0.2-beta ~ 1.0.2-beta1
• 修復版本：1.0.1g / 1.0.2-beta2
• 影響系統版本
  • Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4
  • Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11
  • CentOS 6.5, OpenSSL 1.0.1e-15
  • Fedora 18, OpenSSL 1.0.1e-4
  • OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012)
  • FreeBSD 10.0 - OpenSSL 1.0.1e 11 Feb 2013
  • NetBSD 5.0.2 (OpenSSL 1.0.1e)
  • OpenSUSE 12.2 (OpenSSL 1.0.1c)
• 影響服務：HTTP、SMTPS、IMAPS、POP3S 等使用 OpenSSL 之服務

OpenSSL 的公告如下：https://www.openssl.org/news/secadv_20140407.txt

要如何測試自己的網站有沒有這樣的漏洞呢？可以利用以下的網站或工具直接查詢。

• Heartbleed test http://filippo.io/Heartbleed/

直接輸入 Domain 即可查詢，例如「fbi.gov」。

• 自我測試工具 http://s3.jspenguin.org/ssltest.py （或 http://pastebin.com/WmxzjkXJ）

使用方法直接執行「python ssltest.py ifttt.com」，或是用「-p」指定特定 SSL 連接埠。畫面上會顯示出記憶體資料，可能內含機敏資料例如 private key、session cookie 等。

原始碼如下：

• 自我測試工具 https://github.com/noxxi/p5-scripts/blob/master/check-ssl-heartbleed.pl

使用方法直接執行「perl check-ssl-heartbleed.pl mail.XXXXXX.gov.tw:443」，可在網域名稱後指定特定 SSL 連接埠。

使用說明：

如果發現自己的伺服器有這樣的漏洞，該怎麼辦呢？

1. 確認自己的 OpenSSL 版本是否在受害範圍
2. 使用 ssltest.py 檢測工具檢測是否含有漏洞
3. 更新 OpenSSL 至 1.0.1g 或 1.0.2-beta2
4. 重開所有與 OpenSSL 函式庫相關之服務
5. 重新產生 SSL Private Key (因為 Private Key 可能藉由漏洞外洩)
6. 將網站舊憑證撤銷
7. 清除所有目前網頁伺服器上的 Session （因為可能遭到竊取）
8. 必要時更換網站內使用者密碼，或是密切追蹤網站是否有帳號盜用的情況發生

詳細討論與建議可以參考 Heartbleed: What is it and what are options to mitigate it? http://serverfault.com/questions/587329/heartbleed-what-is-it-and-what-are-options-to-mitigate-it

真的會有攻擊者利用這樣的攻擊手法嗎？目前在烏雲 wooyun平台上已經滿滿的資安研究員開始回報網站含有 OpenSSL 漏洞。也有駭客在嘗試撰寫更有效的攻擊利用程式，想要藉此把平常打不下來的網站一舉攻陷。

怎樣的站台會是重點目標呢？含有會員機制的網站特別如此，例如 Web Mail、社群網站等等。因此不少企業要多注意了，例如全世界最大的社群網站 Facebook、SlideShare、台灣知名電信公司網站、社交平台、網路銀行、NAS，都會在這波的攻擊範圍之內。如果沒有儘速修復，等到更有效的攻擊程式出現，就真的等著失血了。

就連 OpenSSL 這種歷史悠久而且重要的函式庫，都可能犯這種基本的 C 語言程式設計錯誤，老舊的程式碼一定有不少陳年遺毒，如果沒有徹底清查，類似的心臟噴血事件會不斷上演。大家快點止血吧！

還記得在上一篇 HTTP headers 的資安議題 (1) 文章中，我們提到了多種資安相關的 HTTP headers 嗎？接下來的幾篇文章我們會介紹幾個專門對付 XSS 的 HTTP headers，首先就由 Content-Security-Policy 打頭陣。

Content-Security-Policy（以下簡稱 CSP）是從 2010 年被提出來的一項 Web 規格，主要目的是用來防止 Cross-Site Scripting（以下簡稱 XSS）跟網頁樣式置換（例如科技部被惡搞就是一個最好的例子）。經過五年發展，CSP 1.0 已從 W3C 的 TR (Technical Report) 變成 Candidate Recommendation，應該不久就會將成為 W3C 推薦標準。新的 CSP 1.1 則仍在草案階段。

CSP 家族龐大，總共有三個類別，六個項目：

• Content-Security-Policy
• Content-Security-Policy-Report-Only
• X-Content-Security-Policy
• X-Content-Security-Policy-Report-Only
• X-WebKit-CSP
• X-WebKit-CSP-Report-Only

在 CSP 發展初期，主流瀏覽器並未全部依照同一標準來開發，因此發展成這三種類別。目前由於 CSP 1.0 即將成為標準，大多數瀏覽器已支援 Content-Security-Policy 這個類別，因此狀況已逐漸收斂。主流瀏覽器的支援列表如下圖：

從列表中可看到，只要使用 Content-Security-Policy 與 X-Content-Security-Policy 就已有很高的覆蓋率，除非要支援 Safari 6，否則不用特意使用 X-WebKit-CSP。更詳細的瀏覽器支援列表可參考 Can I use。

• 載入來源白名單

  宣告一組受信任的白名單與資源種類（如 JavaScript, CSS, image 等等），使瀏覽器只能從此白名單中載入資源，藉此防止攻擊者從外部引入含有惡意程式碼的資源。

  例：Content-Security-Policy: default-src ‘self’; script-src ‘self’ http://js.devco.re; style-src ‘self’ http://css.devco.re; img-src ‘self’ data:; frame-src ‘none’

  效果：限定 script 資源只能從 http://js.devco.re 載入；限定 style 資源只能從 http://css.devco.re 載入；限定 img 只能從相同 domain 載入，並且支援 data scheme；限定 frame 不能從任何來源載入；除了 script、style、img、frame 之外的資源，則只能從同樣 domain 以及同樣協定的來源載入。

• 禁止 inline 程式碼

  一般人開發網站時為求便利，經常會在 HTML 中寫入一些 inline 程式碼，但攻擊者意圖入侵網站時也常用此手法。然而瀏覽器其實無法分辨這些 inline 程式碼究竟是開發人員寫的，還是攻擊者植入的。因此 CSP 乾脆強迫開發者必須把所有 inline 程式碼移到外部檔案，完全杜絕在 HTML 中出現 inline 程式碼的狀況。因此除非你在 CSP 宣告時有註明 ‘unsafe-inline’，否則 CSP 預設禁止使用 inline script 或 inline CSS。

  例：Content-Security-Policy: default-src ‘self’; script-src ‘unsafe-inline’

• 禁止 eval 函式

  eval() 對許多開發者來說一直是個非常方便的函式，然而若缺乏資安觀念，使用此函式時很可能會導致潛在的 XSS 風險。因此除非你在 CSP 宣告時有註明 ‘unsafe-eval’，否則 CSP 預設禁止使用 eval() 函式。

  例：Content-Security-Policy: default-src ‘self’; script-src ‘unsafe-eval’

• 防止 sniffer

  由於 CSP 可指定載入資源時強制使用 https 協定，因此可降低被 sniffing 的機率。

  例：Content-Security-Policy: default-src http://devco.re; img-src https:

  效果：限定圖片只能從 https 協定載入，不限定 domain。而除了圖片之外的資源則可從任意來源載入。

下面這一段程式碼，使用 default-src * 讓相關資源可正常顯示：

接下來我們將 php header 的那一行程式碼修改如下並且 reload 瀏覽器頁面：

使用 CSP 限制 img 與 frame 的來源種類後，我們可以從上圖 Chrome Inspector 的紅字觀察到，網站的圖片與 iframe 影片已被瀏覽器擋掉，無法載入。

如果擔心直接使用 CSP 會影響網站營運，但又想嘗試 CSP，可以先使用 Content-Security-Policy-Report-Only，示範如下：

由上圖可以看到，此 header 不會直接阻擋不符合 CSP 規範的資源，但是會根據使用者所違反的規則發送相對應的 POST request 至指定的 URI，發送內容如下：

由發送內容可看出這個 request 因為違反了「img-src https:」規則而將「http://devco.re/」這個來源擋掉。經由此方式，可一邊修改網站一邊觀察是否仍有不符合 CSP 規範之處，等到所有違規的內容都修正完畢後，再將 CSP 套用到正式上線環境。

由於宣告方式非常多種，在這邊就不一一條列，若有興趣可前往 Content Security Policy Reference & Examples、Using Content Security Policy - Security | MDN 等網頁，有更完整的使用情境與範例可供參考。另外也有 Slide (by Ben Vinegar) 跟 YouTube 影片 (by Adam Barth) 可參考。

目前採用 CSP 的案例較少，比較知名的使用案例是 GitHub，在 2013 年 4 月 GitHub 還寫了一篇專文公告表示他們已開始採用 CSP。另外一個案例廠商可能較廣為人知，是在 2013 年當紅的免費儲存空間 MEGA。兩個案例的實際內容可見於下圖：

另一項知名使用案例是 Google 明定開發 Chrome Extension 時必須使用 CSP，以追求更高的安全性。Mozilla 也在 MozillaWiki 開了一頁存放相關技術細節。若您想觀察其他使用案例，可使用 Chrome Inspector 或 curl 觀察以下幾個網站：LastPass，Twitter，1Password。

• directives 後面不需加冒號

  錯誤：default-src: ‘self’

  正確：default-src ‘self’

• directives 之間以分號區隔

  錯誤：default-src ‘self’, script-src ‘self’

  正確：default-src ‘self’; script-src ‘self’

• 多個 source 之間僅以空白區隔

  錯誤：default-src ‘self’; img-src ‘self’, img1.devco.re, img2.devco.re

  正確：default-src ‘self’; img-src ‘self’ img1.devco.re img2.devco.re

• 某些 source 必須加冒號（https:、data:）

  錯誤：default-src ‘self’; img-src ‘self’ https data

  正確：default-src ‘self’; img-src ‘self’ https: data:

• 某些 source 必須用單引號括起來（’none’、’self’、’unsafe-inline’、’unsafe-eval’）

  錯誤：script-src self unsafe-inline unsafe-eval

  正確：script-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’

使用 CSP 可以有效提升攻擊難度，讓許多常見的 XSS 攻擊失效，是一個非常推薦開發者使用的 HTTP header。但由於目前的開發者在 HTML 裡面寫 inline script 及 inline CSS 的比例非常高，同時也有一些網路服務預設都需要使用 inline script（例如 Google Analytics，相關解法可參考這裡），因此要享受這樣的安全之前，可能需要先付出許多時間與心力將網站大幅整理，套用 CSP 規範後網頁才能正常運作。