就是資安

ReDoS? 可不是再次的阻斷服務攻擊 (Re-DoS)，而是正規表示式阻斷服務攻擊 (Regular Expression DoS)，是阻斷服務攻擊的一種手法。對於一般的程式開發，雖然不見得常使用到正規表示式的應用，但是正規表示式卻常見於各式各樣的過濾器上。所以像是網站應用程式的輸入檢查、快取伺服器或其他類型閘道器的存取過濾功能，通常都有正規表示式的存在。 正規表示式最基本的應用就是用來尋找資料中是否含有特定樣式的內容，例如我們可以透過正規表示式來判斷一個文字檔內是否含有手機號碼，而判斷條件就是以0為開頭的連續10個數字 (這個條件可能不適合用來找出所有可能的手機號碼，但是無損於說明性)。也因此正規表示式的應用至少含有兩個部分，一個就是用來當做搜尋的樣式 (Pattern，通常這部份也稱為正規表示式)，以前述的例子而言就是”以0為開頭的連續10個數字”。另外一部分則是用來被搜尋的輸入目標，以前述的例子而言就是文字檔的內容。而正規表示式阻斷服務攻擊發生在利用某些樣式進行搜尋時將有可能會產生大量消耗運算資源的情況，因而使得系統無法處理其他的請求。這也是它為什麼被稱為阻斷服務攻擊的原因了。 至於”某些樣式”是哪些樣式，在 OWASP 上面的說明文件舉了一些例子，包含 (a+)+ ([a-zA-Z]+)* (a|aa)+ (a|a?)+ (.*a){x} | for x > 10

在上個月的一篇文章中，我們看到 WhiteHat Security 對於避免 SQL Injection 的危害提出了 10 個手法。其中第 7 個手法，使用”參數化的查詢 (在 Java 的程式語言中主要是透過 PreparedStatement 來提供) 並避免使用動態式的查詢”對許多人來說應該算是老生常談了。事實上，程式內未採用參數化查詢大多不是因為技術上的考量，因為除了極少數的情況 (通常與效能有關) 外，參數化查詢都是可以順利運作的。在無法採用參數化查詢的原因中，最常見的情況就是使用了預儲程序 (Stored Procedure)。預儲程序如果小心使用，對於 SQL Injection 其實也有一定的防護能力。但是預儲程序畢竟不像參數化查詢那般嚴謹，所以提供這些功能的程式碼無法事先做太多的防範措施，大多數防護的責任還是落在系統開發者自行開發的程式上。而參數化查詢因為會嚴格限制每個參數的型別，所以提供此一功能的程式就可以做好萬全的準備，讓系統開發者在撰寫自己的程式時不需太過擔心。所以除非被限制必須使用預儲程序來存取資料，否則我們就應該採用參數化查詢來存取資料。 參數化查詢與預儲程序之間的取捨，往往還有許多其他非技術的因素，但是這並不是我這篇文章的重點，所以這個問題就在此打住。當我們確實採用了參數化的查詢後，是否就可以對 SQL Injection 高枕無憂了呢?很可惜的是，答案依舊是否定的。如果我們仔細審視第一段的藍色文字，可以發現後半段是避免使用動態式的查詢。而前、後段文字使用”並”加以連結，所以一旦使用者違反了後半段文字的限制，即使使用參數化查詢依舊會遭受 SQL Injection 的攻擊。因為這點對於部分的系統開發者來說或許並不是那麼熟悉，所以接下來我將以實際的例子 (Java 語法) 來加以說明。我假設我們擁有一個稱為 users 的資料表，內含 name 與 password 兩個欄位，分別表示使用者的姓名與密碼。而在此資料表中有一個使用者的姓名與密碼分別為 ‘cyril wang’ 與 ’1234’。

在上一篇的文章中，我們了解到何謂 CSRF 以及其運作原理，在這篇的文章中我想要談談網站開發者與使用者該如何做才能避免 CSRF 的威脅。 要避免 CSRF 的攻擊，目前公認最有效的方式就是所謂的 Synchronizer Token Pattern。簡單來說，Synchronizer Token Pattern 指的是每次使用者發出請求時 (不管是透過 POST 還是 GET) 都必須傳回一個網站系統所指定的亂數，而這個亂數可以設計成適用於整個 Session 階段，也可以設計為只能使用一次。以安全性而言，後者的作法確實可以達到相當好的效果，但是卻也會為使用者帶來極大的不便性，所以在大部分的情況下前者反而是比較常用的作法。其實後者的作法除了應用在增加安全性之外，也常被用來作為避免使用者重複發出請求的保護措施。使用者重複發出請求尤其容易出現在反應較慢的系統中，使用者因為失去耐心或不知所措之下往往只好重複之前的動作 (請求)。 等等，在使用 GET 的情形下，Synchronizer Token 不就等於直接擺在 URL 參數中讓人取用，那怎麼還有安全性可言？別忘了在 CSRF 攻擊中，通常駭客是無法取得受害者與目標網站之間溝通的訊息，所以這樣的作法依舊大幅增加駭客產生合法請求的困難度。再加上 Synchronizer Token 的有效期僅存在單一 Session、甚至是單一請求中，因此就算駭客取得 Synchronizer Token 後也往往無濟於事了。此外，透過 SSL 進行連線可以讓 Synchronizer Token 被”看到”的機會大大降低。 Synchronizer Token 的一個特例就是直接把 Session Token 當作 Synchronizer Token 使用，這種方法又稱之為 Double Submit Cookies。使用 Double Submit Cookies 的好處是比較方便，網站系統不需要另外維護一份 Synchronizer Token 的對應關係表，但是這樣做卻會讓 Session Token 處於一個較危險的狀況，增加了 Session Hijacking 攻擊的成功機會。

Cross-site Request Forgery，常縮寫為 CSRF (或 XSRF)，中文翻譯稱之為跨網站的偽造要求。除了這些稱呼，其他像是 Cross-site Reference Forgery、Session Riding、One-click Attack 等等各式各樣的名稱，其實指的都是同一種攻擊手法。 CSRF 跟 XSS (Cross-site Scripting) 都是跨網站的攻擊手法，但是 CSRF 利用的是使用者對於瀏覽器的信任而達到攻擊目的，而 XSS 則是利用使用者對於網站本身的信任。 簡單來說，CSRF 就是在使用者不知情的情況下，讓瀏覽器送出請求給目標網站以達攻擊目的。 對於 HTTP 協定有所了解的讀者，看到這句話可能會覺得很困惑。因為在預設的情況下，任何人只要知道 URL 與參數都可以對網站發出任何請求，如此說來不是所有的網站都會遭受 CSRF 的攻擊了嗎？可以說是，也可以說不是。因此嚴格來說，CSRF 通常指的是發生在使用者已經登入目標網站後，駭客利用受害者的身分來進行請求，如此一來不但可以獲得受害者的權限，而且在系統的相關紀錄中也很難發現可疑之處。 在進一步談到 CSRF 的攻擊手法之前，我要先談一下一般網站應用程式是如何識別使用者的身分。對於需要辨別使用者身分的網站而言，最常見的方法就是依靠帳號/密碼。凡使用者想要進行受限制的動作時，就必須先經過帳號/密碼的驗證。但是如果在每次進行受限制動作前都要輸入一遍帳號與密碼，我想沒有多少使用者可以忍受這樣的不便。所以所有的網站系統都會把使用者輸入且通過驗證的帳號資訊記錄下來，之後就不再進行驗證的動作了。然而因為 HTTP 協定的限制 (Stateless)，所以如何紀錄這個驗證過的帳號資訊就成了棘手的問題。早期有些系統會將帳號本身紀錄在 Cookie 中，因為 Cookie 的特性就是瀏覽器在每次存取網站的同時會將內容傳回去，所以網站系統就可以從 Cookie 中獲得帳號的資訊。然而因為 Cookie 存放在使用者的電腦中，算是一個極不安全的環境，因此後來的網站系統都是在 Cookie 中存放一個隨機亂數產生的代號，網站系統再經由這個代號找出相對應的帳號資訊，這個代號我們通常稱之為 Session Token。Session Token 的概念與實作雖然很簡單，但是安全性卻依舊不足，所以為了提昇 Session 的安全性就必須採用其他補強措施。像是 Session Token 自動失效、定期更新 Session Token 的數值、加上檢查 Session Token 來源 IP 位址等方式，都可以用來增加 Session 的安全性 (主要是避免 Session Hijacking)。除了利用 Cookie 來紀錄 Session Token 外，其他像是把 Session Token 放在 URL 參數中，或是使用 Basic Authentication 的方式，雖然細節上有些不同，但是基本的原理卻都是一樣的。

前一陣子在一次偶然的機會中，被一位高手問到 (應該說是考到) 什麼是 Clickjacking，又要怎麼防備？老實說，雖然 Clickjacking 這個手法剛被提出時我就注意到相關的新聞，但是當時尚未公布實際的手法，再加上 Clickjacking 一直不像 SQL Injection、XSS 這些手法這麼普及 (OWASP Top 10 還排不上)，所以後來我就一直沒有動力去研究 Clickjacking 這個手法。因此，只記得當時我真的是比穿黑衣還掉了滿身的頭皮屑還糗。不過話說回來，學習永遠不嫌晚，所以我趕緊惡補了一下，並透過這篇文章跟各位分享一下 Clickjacking 這個很危險卻還沒有被廣泛應用的攻擊手法。 Clickjacking，簡單來說就是將使用者在瀏覽網頁的點擊動作進行綁架，讓點擊動作產生非使用者所預期的行為。Clickjacking 最初公布的 例子，也是最著名的例子，就是利用隱形頁框 (invisible iframe) 的方式，讓受害者在不知不覺中”自己”修改 Flash 的安全設定，以利駭客可以遠端控制受害者電腦的攝影機與麥克風，進而進行遠端的監聽/監視。目前常見的資料將 Clickjacing 分為 frame-based clickjacking (又稱為 UI readressing) 與 plugin-based clickjacking 兩大類，但是在阿碼外傳上的 範例 使用修改 onclick 事件處理程序的方式，也可算是另外一種實現的手法。

之前我在分享有關釣魚攻擊的手法時，提到了 CEH 的分類。而根據 Aza Raskin 於日前所發表的網誌中，他提到了一種稱之為 Tabnabbing 的新攻擊手法。簡單來說，這種攻擊手法就是利用瀏覽器的頁籤功能，當使用者切換至其它頁籤時，將原先頁籤的內容導到另外一個假冒的網頁，當然，這個假冒的網頁會要求你輸入帳號/密碼。
網誌中提到的攻擊情境為：

使用者瀏覽你 (含有惡意程式) 的網頁。
利用程式偵測網頁是否已經失去焦點 (也就是切換到別的頁籤) 並持續一段時間。如果一失去焦點就執行攻擊，被使用者發現的機會相對增加不少。
將網址列的圖示 (favicon) 改為 gmail 的圖示，並將標題修改成相關的字樣。
當使用者發現到修改過標題的頁籤時，會以為這是 gmail 的畫面。而當看到畫面呈現登入選項時，將會輸入 gmail 的帳號/密碼進行登入。
你的程式取得使用者的 gmail 帳號/密碼之後，將畫面導回到真正的 gmail 網址。如果原先使用者已經成功登入過 gmail 的帳號，這樣的導向將會更加容易。

之前我提到有關釣魚攻擊的研究報告與防範之道，這次我想要針對釣魚攻擊本身做個解釋。釣魚攻擊英文是 Phishing，我沒有拼錯，確實不是 Fishing，據聞這可能是 Phreaking 與 Fishing 的合體字。釣魚攻擊 (原始) 指的是利用假冒成合法的通訊對象，以騙取對方機密資料的手法。常見的例子為透過電子郵件或即時通訊等方式，誘騙使用者進入一個外觀很像合法網站 (如 eBay) 的假網站，之後使用者輸入的帳號/密碼就會被這個假網站所記錄。比較簡單的假網站可能在取得帳號/密碼之後就將使用者導回真正的目標網站，而有些假網站的模擬程度就更高了。但是一般而言，除非有別的安全機制，不然只要取得使用者的帳號/密碼就已經足夠取得使用者所有的資訊，所以假網站通常並不需要很複雜的功能。 魚叉式釣魚攻擊與社交網站 早期的釣魚攻擊多屬於大量散發的形式，所以目標網站的選取除了具備高價值外，也需要具備足夠的使用者。但是現在已經有越來越多針對特定目標 (如某某公司的員工) 的釣魚攻擊，這類攻擊又稱為魚叉式釣魚攻擊 (Spear Phishing)。而因為目標網站必須具備高價值，所以釣魚攻擊主要以假冒拍賣網站、金流或財務服務網站為主。而隨著社交網站的盛行，這類網站也漸漸受到釣魚攻擊者的重視。這類網站本身或許沒有多少直接的金錢利益，但是因為使用者眾，所以可以取得不少珍貴的個人資料，此外找到名人的機會也大了許多。除此之外，因為大部分使用者會有重複使用密碼的習慣，所以透過社交網站取得的帳號/密碼，也可以用來當作入侵其他系統的基礎。

根據 Betanews 文章的揭露，資訊安全專家 Kurt Seifried 將在下個月的 Linux Magazine 講解有關 CA 憑證申請易遭濫用的問題。簡單來說，步驟如下： 找尋一個免費的 webmail 服務供應商。 註冊一個帳號，例如 ssladmin。 到 RapidSSL.com 購買憑證，記得使用上述註冊的 email 帳號作為申請驗證的帳號。 完成後續的申請步驟。 步驟完成後你將會獲得這個 webmail 網域的合法憑證。 好吧，嚴格來說整個過程跟 CA 機制沒有關係，而是在於申請的流程中，CA 憑證發放單位為了便宜行事而採用了簡單的驗證機制，也就是僅檢查 email 帳號。email 會被竊取，對於 webmail 的網域來說更方便，甚至連竊取都不需要。對這些 CA 憑證發放的單位而言，越簡單方便的申請流程不但可以減省成本，還可以順便增加收入，所以何樂而不為。但是這樣的機制卻因為過於簡化而容易遭到濫用，或許是 CA 憑證發放單位始料未及的事情，也有可能是其已知卻不想去面對的問題。事實上，很多廠商在設計業務或產品時，都一再忽略安全的重要性，因為這些東西對大部分的客戶是沒有 (直接的) 價值、甚至是根本感覺不到的。即便是在安全產業內，這種現象也是很普遍，畢竟賺錢這個終極目標，對身處任何產業的公司來說都是一樣的。

三位在密西根大學的學生於日前發表了一份有關破解 RSA 私鑰的論文，在論文中他們採用錯誤為主 (Fault-based) 的攻擊手法，以運行於 FPGA 上的 Linux 系統在 100 個小時之內成功地破解了 1024-bit 的 RSA 私鑰。Fault-based 的攻擊手法簡單來說就是想辦法讓攻擊目標產生錯誤，進而由攻擊目標的行為或輸出結果來找到隱含的秘密。在這次的攻擊手法中，三位學生利用改變系統電壓的方法，造成處理器運算錯誤而產生錯誤的結果。在收集到足夠的錯誤資料後，就可以利用這些資料進行破解私鑰的攻擊。1024-bit 的 RSA 依舊是目前 SSL 常使用的金鑰長度，不過還好這種攻擊手法需要先能夠取得實體環境的控制能力才行。除了硬體式的攻擊手法外，Fault-based 的攻擊方式也可以是軟體式的，亦即不需要取得實體環境的控制就可以進行攻擊。除此之外，許多攻擊手法也都會利用到 Fault-based 的觀念，想辦法讓系統產生錯誤並加以觀察，以找到可能有效的破壞管道。例如在登入頁面輸入一些特殊字元到使用者的帳號欄位中，觀察系統是否會產生錯誤以及相關的錯誤訊息，以便猜測系統是否存有 SQL Injection 之類的安全漏洞。所以如何做好 Fault Protection，不單只是產品穩定性的議題，同時也是安全性的議題。   相關連結： 1024-bit RSA encryption cracked by carefully starving CPU of electricity Fault-Based Attack of RSA Authentication

雖然有越來越多的廠商與產品試著去解決惡意程式所帶來的問題，但是不可否認惡意程式的威脅與影響依舊越來越大。除此之外，惡意程式也越來越有”創意”，讓這場官兵與強盜之間的遊戲更加精采。儘管惡意程式變化之多，我們仍舊可以將大多數惡意程式的行為(至少)分為兩個階段，第一個階段是感染 (Infection) 階段，第二個階段則是攻擊 (Attack) 階段。 在感染階段中，最重要的事項就是如何避免被發現。在此前提下，其次才是感染的速度與數量。而實際感染的途徑，也從早期的實體方式 (如磁碟片、光碟片等)演進到透過網路的方式。在網路的感染方式中，News Group、Email、IM、Web則陸陸續續被有心人士所利用。今天我們要談的是一種稱之為 Drive-by Downloads 的方式，簡單說來就是讓使用者在瀏覽網頁(或是閱讀HTML格式的信件)時，不知不覺地下載惡意程式並因而遭受感染。也許 Drive-by Downloads 這個名詞對許多人有些陌生，換個說法或許大家就比較清楚，這個說法就是網頁掛馬攻擊。聽起來也許很神奇，但是基本上所謂的”不知不覺”都還是得利用應用程式的漏洞加以遂行。只是跟傳統上利用作業系統漏洞加以感染相比較，現在會被加以利用的則包含了各式各樣的應用程式，尤其是像 Flash 、 PDF 、 影像播放器這類大量被應用在網際網路服務的相關軟體。此外，瀏覽器本身當然也是一個會遭受攻擊的明顯目標。