先前提到關於 Firefox 瀏覽器的擴展套件安全問題，你或者認為這種系統入侵方式很少見，畢竟可以被破解的瀏覽器為少數。事實上，已經有些工具可以拿來養木馬，像是 BindShell 開發的 BeEF (Browser Exploitation Framework)。
BeEF 整合 Metasploit 等知識庫與工具來查找各種瀏覽器的漏洞，只要你將代碼塞到受害者可能讀取的網頁，就可以即時看到對方瀏覽器版本，以及可能的入侵方法，甚至可以利用 BeEF 線上即時送出一些指令，直接侵入對方主機。;-)
一月底開始，一些朋友開始討論 Firefox 3.6 中，將置入 CNNIC 的 CA 憑證。這件事情是去年年底，CNNIC 對 Firefox 申報納入 CNNIC 的憑證 (#476766)，目前已於 3.6 版中內建 CNNIC 憑證。
目前此事已經在 Mozilla Security Policy mailing list 公開討論，在華人網路社群也引起一陣騷動。像是 AutoProxy 等社群都提出 CNNIC CA：最最最嚴重安全警告！。在原提案 #476766 中亦有人整理了一些客觀事實。
不過根據我主觀的看法，奉勸所有人盡快移除 CNNIC 相關的 CA 憑證！CNNIC 就是中國網際網路絡信息中心，是一個中國的非營利組織，提供中國網際網路的網域名稱、網段管理。
CA 憑證對於瀏覽器使用者而言，可以用來辨識特定網域是否為合法組織，部份瀏覽器功能甚至依據有否憑證，對網頁開啟進階存取權限。前提是 CA 維持善良管理人義務，嚴格管理所核發的憑證、簽章。
CNNIC 過去最大的爭議即是曾經發布過中文上網官方版軟體，名為提供中文網址導引服務，實質則包含流氓軟體的功能，主要功能是一般輔助上網軟體，但核心卻用 rootkit 技術讓你無法刪除，與木馬/病毒程式一般。雖說這只是一項前科，但是中國政府持續拿著民族主義、國家安全為藉口，實施數種網路管制，甚至滲透國外企業、政府網路，根本是合法的網路流氓。而 CNNIC 背後支持的政府組織是中華人民共和國工業和信息化部、中國科學院、中國科學院計算機網絡信息中心 等中國政府組織。很難說，哪一天 CNNIC 不會被控制作為攻擊工具之一。
除了 CNNIC 自行發布的 CA Cert Root 外，其實 CNNIC 也已經取得 Entrust.net 所發布的次級憑證。建議所有台灣政府單位，一律移除 CNNIC 相關憑證。
若你覺得此事關係重大，可以以投票方式附議 Bug 542689 – Please Remove “CNNIC ROOT” root certificate from NSS，提高該問題的被重視程度。
其實 Mozilla 先前也曾經遭遇過亂搞的安全憑證公司。原則上，任何人要申請特定網域的簽章，必須提供書面資料，證明你是該網域的擁有者。因為 SSL 憑證一個主要功能是防止釣魚網站欺騙一般消費者，若使用假冒的憑證，使用者很容易就發現網址異常。
若安全憑證公司絲毫不做基本的驗證，任何人都可以申請想仿冒的網域，然後以中間人攻擊 (MITM) 詐騙你交出個人資料。想像，你收到一封 PCHOME 的廣告，連到一個假的網站，這個網站提供了完美的 SSL 憑證，瀏覽器沒有提示你任何異常，除非你刻意去點選確認簽章，否則很自然就會上當。
Mozilla 的事件起因，是有人回報一安全憑證公司透過廣告郵件推銷新的服務。但這個憑證公司的服務卻允許你隨意購買任一網址的簽章，於是你可以購買並假冒任何網站。Eddy Nigg 寫了一份詳盡的說明，當時並做了一個驗證概念的 Mozilla.com 憑證。在事情曝光後，Mozilla 已撤除這組組憑證了。
驗證方法是開啟 CNNIC 的網址衛士 (使用 Entrust.net) 或 CNNIC 的 ENUM 試驗平台 (使用 CNNIC Root Cert)。若你的瀏覽器絲毫不給警告的就讓你存取，你的系統即已安裝 CNNIC 憑證。
2010-02-23 更新請使用 CertAlert 與 CA Untrustworthy 等工具來移除或警示可疑憑證。
在 GNU/Linux Debian, Ubuntu 上，系統保持一份共用的 CA 憑證，許多網頁工具如 Firefox, curl, wget, Chrome 均共用同一組設定。因此最簡便的方法便是關閉系統上有問題的憑證。
作法是以 root 在終端機內重新設定以下指令
# dpkg-reconfigure ca-certificates
找到 mozilla/Entrust.net_Secure_Server_CA.crt 一列，反選取之，選擇確認即可。或者直接編輯 /etc/ca-certificates.conf，一樣找到此行後，於該行開頭加入驚嘆號 (!)，然後重新以 root 執行一次 update-ca-certificates.
另外，你也得到瀏覽器手動刪除原已匯入之憑證。注意，若該筆憑證下方有多筆簽章，你必須刪除全部簽章。見圖
按下 Delete, 重新啟動 Firefox，如此即可移除相關的 CA 憑證，其他瀏覽器需比照辦理。你若使用其他作業系統，請參考 Felix Yan 所整理之 從「受信任的根證書」裡趕走CNNIC。
以下補充說明 (20100203):
許多網友認為，即使系統有此憑證，也不至於影響系統。
事實是，若有此憑證，你將被剝奪警覺的能力，像是痛得知覺消失一樣。當攻擊事件發生時，唯一可以主動提示你的 SSL 機制也可能失效。在中國網路長城的「內部網路」，網址被攔截、轉換是很平常的事件，即使你在網外，也可能在網站轉址攻擊事件或大規模網頁綁架轉址發生時，變成受害者。
除了網址之外，這份憑證也可用於不同的連線服務加密認證。我並不想因為系統上存有一份無須有的 SSL 憑證，造成我日常認為經加密而安全的 SMTP/IMAP/IM 「可能」偷偷地遭到攔截、擷取資料。而我卻一無所知。
更新 (2010-02-23)
請使用 CertAlert 與 CA Untrustworthy 等工具來移除或警示可疑憑證。
若 Firefox 開發延伸套件時，應該會知道 Firefox 對於外掛並沒有安全防護機制的，只要你能裝進系統，大約就可以使用所有的元件或存取系統資源。延伸套件被視為可信賴的軟體，開發者應負起各延伸套件的安全性。
對此，Firefox 在 Java Script 開發環境的安全設計主要分為賦權與未賦權的兩種安全模式。賦權的環境中，軟體可以存取所有的 XPCOM，沒有任何限制，於是它可以讀取或修改使用者的歷史紀錄、Cookie 等，甚至存取所有系統檔案。而 non-privileged 則僅提供限制嚴格的 HTML DOM API 權限，Script 的存取也依照其網址與網域名稱給予嚴格限制，避免 XSS 或本地檔案讀取等安全問題發生。
無論是外部的網頁，或者是 XUL 軟體，都是使用 XML/HTML/Java Script/CSS 來撰寫，因此概念上都是由 Window 載入 XML 文件，並透過 Java Script 來存取 DOM API。
開發延伸套件時，凡是在 XUL Overlays 或 XPCOM Components 中的程式碼，都是給予完全的存取權限。而從外部網頁載入的內容，應該給於其未賦權的權限。這種安全模式的設計，乃是防止網頁上的程式可以任意存取系統資源，是一道安全保護牆。
由於 Mozilla 社群並未對安全模式定義名詞，這裡暫區分稱呼如下兩種安全模式
各個程式的安全模式可依照該載入網址作區別，例如 chrome:// 有完全權限、http://example.com 則可存取 example.com、file:/// 則可存取本地檔案。
你也可在利用 PrivilegeManager 詢問使用者後存取 XPCOM 或者讓 XMLHttpRequest 跨網域存取。除了預設依照網址判斷外，開發者可以設計不同的內容使用安全模式，開發者可以決定直接載入網路資料後在 Chrome Document 中執行，或者利用 type=”content” 之方式使其載為 web content document.
但是剪下貼上是一個開發者都會犯的錯誤，最常見的錯誤之一就是直接把外面抓回來的資料，用 innerHTML 直接塞進 chrome document 中。有時候資料中會含有一些 java script，雖然 <script /> 中的語法不會被執行，但是 <img onerror=”alert(‘xss’)”> 這種程式碼還是會被觸發，外部資料中夾帶程式碼的狀況還是相當多，因此凡是處理外部連結都要小心。
Security Assessment 的 Roberto Suggi Liverani 與 Nick Freeman 在上個月初於印度舉辦的 SecurityByte & OWASP AppSec Conference 中，與今年年中的 DefCon 17，發表了幾個 Mozilla 上的零時差漏洞。根據他們的文章與簡報，最常見的就是如 RSS Feeds 中的 <description> 的程式碼會被觸發執行、或者像是 FireFTP 1.1.4 以下的版本，會執行伺服器上的歡迎頁面。或者是熱門的 ScribeFire 3.4.3 以下版本，會以 chrome document 執行 <img onLoad=”alert(‘xss’)”>。
避免這些錯誤的方法之一是盡量使用 DOM manipulation methods 來塞入內容。在 Security best practices in extensions 一文中，講解了數個開發安全延伸套件的方法與注意事項，像是無論如何得執行他人的 Script，那就用 evalInSandbox 來執行。
另外你若得在兩種安全模式間互傳資料，正確的作法應該是盡量利用 DOM Event.
上一篇文章提到 Intel Trusted Execution Technology 害我的電腦休眠後一睡不醒，研究 TXT 時，我無意中看到原來上個月的 Black Hat DC 2009 中，Invisible Things Lab Rafal Wojtczuk 與 Joanna Rutkowska 發表了 「Attacking Intel® Trusted Execution Technology」的研究，其中 Joanna Rutkowska 是 Invisible Things Lab 的執行長，而且還是個女性，是位厲害的女駭客阿！
他們研究出可以在 SMM Memory (SMRAM) 中塞入 shell code，由於 TXT 並未檢驗或清除 SMRAM 的內容，可以讓入侵程式躲到虛擬作業系統啟動之後才執行，於是可以取得任何應該受到 TXT 保護的資料。據說 Invisible Things 還有兩個可行的 SMRAM 漏洞，會等到今年稍候的 BlackHat 研討會發表。
關於此安全問題的簡報、論文與影片可於 Invisible Things Lab 的 blog 取得，或於 BlackHat 網站下載高畫質演講錄影。簡報中明白的說明了 TXT 的運作方式與技術細節，我個人認為比 Intel 的官方文件來的簡單易懂多了，想進一步了解 TXT 的實用方式，也可詳盡參考。
話說最近換了新的 Thinkpad X200，剛拿到換裝了 Debian Sid 後，發現一個問題，重度使用的休眠功能在第二次喚醒時，系統只亮了一下硬碟燈號，然後就停止了。必須重新「冷」開機後，系統才會恢復正常。
之前查找了 ThinkWiki 還沒有人說明這類休眠的問題，而且硬體在第一次重新開機時，是絲毫沒有問題的。心中一直懷疑是某個軟體/硬體元件出了問題，怎麼會休眠一次就失敗 ?
於是便開始從 GNOME PowerManager 一路查到 hal 跟 pm-utils (README.debugging, /var/log/pm-suspend.log)。然後配合 Documentation/kernel-parameters.txt 與 Documentation/power/basic-pm-debugging.txt 文件中說明的方法，重複開關機，試用不同的 acpi 參數，絲毫看不出端倪。重開機前後，acpidump 與 dmidecode 的資料大同小異。
再瞎子摸象的鑽進 kernel acpi driver 翻找，也將 DSDT 轉成 ACPI Source Language (ASL) 來檢查，kernel 也上了 ACPI DSDT in initrd patch。差點就要開始讀 Shaohua Li 在 Linux 內核開發中文社群上寫的一篇 ACPI 除錯的技巧中的延伸參考訊息。
結果才在 bugzilla 上發現有人回報了類似的問題 Bug 11963 – S3: second resume fails unless BIOS “Intel TXT Feature” disabled。我的症狀跟回報人一模一樣，只要將 Intel TXT (Trusted Execution Technology) 關閉，系統就可以隨意的休眠、喚醒。
我手上的這台 Thinkpad X200, 使用的是 Intel Centrion 2 vPro，依照 Intel 的新聞稿，vPro (白皮書) 包含了 Trusted Execution Technology, 改良型系統防禦過濾器, 信任機制代理程式, 主動式管理技術 等等。從展示中，你可以看到 vPro 提供了強大的管理能力，資訊管理人員可以遠端的開機、收集資訊，使用 remote console 修復作業系統問題，甚至可以抓小偷 (Anti-Theft Technology)。
而造成我的問題的是 TXT，TXT 的功能是用於保護虛擬機器中的資訊，藉由 TPM 與 SME 指令集的運用，可以避免虛擬機器開機時的記憶體或儲存資料被竊取。
Intel 為了此功能開發了一個開放原碼的 tboot (Trusted Boot) 專案，可搭配 Xen 使用，Intel 的 Joseph Cihula 在 Xen Summit November 2007 時分享了一份關於 Trusted Boot 的簡報 (Trusted Boot: Verifying the Xen Launch) 。
不過對我這種個人使用者來講，真是可怕到了極點，根本是一台內建後門的筆記型電腦。既然這些功能會影響我休眠，不如一股腦全把他們關了。或許我該寫封信問問 Joseph 看看他是不是知道為什麽 TXT 會防止我重新開機。
話說這台新電腦真是多災多難，最早拿到的時候，試玩新硬體，前後嘗試 Windows Vista 會頻繁出現藍屏當機，心想這大約是正常的Vista 該死問題。結果裝了 MacOS 也會 Kernel Panic，這才開始覺的真有問題。前後用微軟的記憶體測試程式跟 Memtest86+ 測試，才證明廠商贈送的 2G 記憶體有問題，多浪費了許多時間。
最近 802.11 無線網路協定中所使用的加密演算協定 WPA 傳出了一些消息，一說可以利用常見的圖形處理硬體加速破解運算速度，另外則是說德國的學術單位研究出 WPA/TKIP 中使用的弱加密方式，足以用以塞入短封包攻擊。
首先是 Slahsdot 上提到俄國的資訊安全公司 Elcomsoft 釋出了一款商業軟體 ElcomSoft Distributed Password Recovery，這款軟體的最大特色是可以利用 NVIDIA 的圖形處理器來加速猜密碼的時間，根據 Elcomsoft 的網頁說明，運算速度可加快二十倍到百倍。若是搭配大量的硬碟、主機與顯示卡，的確是有機會快速破解 WPA (WPA2)/PSK 阿。
不過 Elcomsoft 號稱有專利申請中，不過社群中早已有人實做可以在 Linux, MacOS 上執行的版本，叫做 pyrit (對，他是 Python 寫的)。最新的開發進度與消息可以在 pyrit blog 上找到。
Slashdot 上另外一則消息，則是說德國的 Erik Tews 與 Martin Beck 成功的「破解」WPA/TKIP 加密方式，即將在 PacSec 會議上發表。不過事實是，他們利用了 TKIP 的弱驗證碼演算法與 802.11e 的漏洞，於是可以將小封包如 ARP 封包重新送入網路中。這個技術並沒有取得無線網路使用的密碼，而入侵者也無法盜用該無線網路。
詳細的說明可以參考原始的論文 – Practical Attacks against WEP and WPA，應用程式 tkiptun-ng 也可於 aircrack-ng 網站上下載。ArsTechnica 的 Glenn Fleishman 寫了十分詳盡的技術說明 – Battered, but not broken: understanding the WPA crack。
