搜尋此網誌

2010年12月27日 星期一

[新聞時事] Apple 就是 Apple,連做 Spyware 都想獨一無二。

apple-eyespy

Apple (或者說 Steve Jobs) 持續引領風潮,不管是不是潮人,對於 Apple 這個品牌絕對都是耳熟而詳,甚至有不少人不顧一切地想要一親芳擇。這幾天 Apple 被 EFF (Electronic Frontier Foundation) 所槓上,原因在於 Apple 想要申請的專利內容。根據 EFF 的說法,Apple 這次要申請的專利,可以用來判斷手機持有者的身分。至於實際的應用嘛,美其名可以在 iPhone 或其他 Apple 產品落入它人手上時避免資料的外洩,但是 EFF 卻擔心 Apple 利用這些技術來收集個人的識別資料與追蹤行蹤。EFF 也擔心這樣的機制一旦被駭客所利用,其所產生的危害將更難以估計。其實這類軟體或功能很常見,尤其是收集個人資料早已經是許多惡意程式的主要目的,但是合法廠商這麼做倒是比較少見 (前幾年的 Sony 幹過)。這次 Apple 不但明目張膽地做,更想要為這樣的技術申請專利,真不虧是能夠不斷製造話題的 Apple。EFF 為了表示對 Apple 的敬意,更發明了一個新的名詞,叫做 Traitorware,指的是在你背後偷偷地違反你個人隱私的設備 (devices that act behind your back to betray your privacy)。雖然 EFF 對於 Apple 這個舉動表達了強烈的反對,但是 Apple 是否在產品內採用這樣的技術卻也不一定與專利的通過與否有直接的關係。話說回來,對眾多的 Apple 迷來說,也許非但不介意讓 Steve Jobs 多了解自己一些,甚至可能會覺得這真的是炫極了。

 

相關連結:

2010年12月17日 星期五

[新聞時事] WikiLeaks 不只是 WikiLeaks

WikiLeaksWikiLeaks 這幾年常常出現在政治與資安的新聞版面上,原因無它,因為 WikiLeaks 的宗旨就是揭露從各處收集而來的機密資料。在這些眾多的祕密裡,其中許多自然跟全世界最神祕的組織之一 (也就是美國政府,其他政府也都很神祕,只不過美國政府的干涉範圍實在太廣了) 有關。像是一些美軍的機密資訊以及美國在海外進行的機密外交,每次公布都引起不少的震撼。經過這些年的吞忍,美國政府終於再也按奈不住而決定展開反擊,針對相關的人、事、物加以嚴格處置。原先只是美國政府自己的行動,後來因為一些與 WikiLeaks 相關的商業組織也連帶”背叛”,所以導致 WikiLeaks 支持者的不滿,進而展開反擊。其中幾個原本提供 WikiLeaks 募款來源管道的網站 (包含 Mastercard、VISA、PayPal 等),都因為遭受 DDoS 攻擊而影響到網站的運作。其中唯一的倖存者,大概就是提供 WikiLeaks 網站服務的 Amazon 了。Amazon 受助於本身所建置的雲端架構,所以讓資源有限的 WikiLeaks 支持者知難而退,如此一來 Amazon 不但順利全身而退,甚至為其雲端平台 - EC2 找到了一個很有力的賣點。

整起事件雖然還沒有落幕,但是至今已經佔據了許多的新聞版面,只不過很多僅著重在陳述事件的經過。其中我覺得比較有思考空間的觀點有兩個,一個是有關於網路是否會衍生出自己的恐怖主義,例如在這個事件中 WikiLeaks 支持者所扮演的角色。以往所謂的網路恐怖主義,僅是原本的恐怖份子將攻擊行為轉換到網路上,但是這個事件卻衍生出了新的恐怖主義集團,而且是一個沒有國界區分的集團。當然,以恐怖主義集團來描述 WikiLeaks 的支持者或許過於嚴厲,但是難保未來的發展不會演變至此,也或者未來其他事件的發生終將導致恐怖主義的誕生。

另外一個觀點則是討論到原應屬於公眾的網際網路卻已經被少數幾個商業組織所把持,其中包含幾個網路網路運作的基本元素,如網域名稱、線路等,都早已經私人化,而不再屬於公眾的資產。在這種情況下,人民只能任由這些企業 (與政府) 所擺佈,而無法自由地使用網際網路的資源。而這更有可能成為網際網路 (概念) 本身最脆弱的一環,一旦這些元素失去應有的定位與作用,整個網際網路的開放特性將蕩然無存。

老實說,WikiLeaks 本來就充滿爭議性,其所衍生的議題都相當嚴肅,更直接挑戰許多舊有的體制。安全與自由之間,本就是兩難的抉擇,更何況還有不同角色間的衝突與矛盾。對此,我只能說雙方應該合作以找到一個平衡點,只是當一方是屬於”高高在上”的政府時,另外一方會有公平談判的機會嗎?

附註:由於 WikiLeaks 的內容實在太令人難以抗拒,再加上網站已經被關閉,所以出現了許多宣稱擁有 WikiLeaks 內容的複製網站,其中當然也包含了駭客所假冒的。所謂好奇心殺死一隻貓,在決定是否要窺視這些外洩的祕密前,請記得先好好地三思。

 

相關連結:

2010年12月15日 星期三

[工具介紹] 利用 7-zip 加密壓縮檔

7ziplogo這幾年資料外洩的問題越來越受到大家的矚目,再加上新版個資法的通過,讓防止資料外洩不再只是口號,更是必須去認真面對的課題。不管是企業或是個人,重要資料的外洩都不是令人所樂見的。現在有很多機制可以利用加密的方式來保護資料,如此一來即使資料不幸遺失 (不管是無意或是有意的),由於對方無法進行解密的動作,所以也無法窺視到資料本身的內容。這些機制包含硬碟/隨身碟本身進行整體資料的加密,作業系統進行的資料加密及各式各樣的第三方加密工具 (例如我之前分享過的 TrueCrypt)。雖然 TrueCrypt 功能強大,但是對於處理單一檔案的加解密,TrueCrypt 其實就並不適合了。

檔案的分享還是目前很常見的應用,不管是透過 Email、FTP、還是網站的形式,傳統上我們會將想要分享的所有檔案加入到一個壓縮檔中,這樣不但可以減少檔案的大小,還可以簡化分享的工作。這樣的作業方式雖然很簡單,但是也很容易造成資料的外洩。為了避免此一問題的發生,其實我們只要利用壓縮軟體的加密功能,就可以大幅減少資料外洩的可能性。以下我就以免費的壓縮工具 7-zip 為例,說明如何利用加密的功能安全地傳遞壓縮檔。

假設我們有一個存有密碼的檔案想要傳遞給朋友,我們當然不希望任何人都可以看到這個檔案的內容。7zip 001

利用滑鼠右鍵選取 7-Zip –> Add to archive。 (如果你還沒安裝 7-Zip,請至這裡<="下載<">下載並安裝)

選取 zip 格式與 AES-256 的加密方式,輸入密碼才有加密的作用。請記得選用不容易被猜到的密碼。7zip 002

產生的壓縮檔外觀與一般的壓縮檔無異。7zip 003

甚至可以點選進入壓縮檔內的目錄。7zip 004

但是當要開啟檔案時會出現錯誤訊息。7zip 005

此時你就可以放心地將這個壓縮檔傳送給遠方的朋友。你的朋友收到檔案後想要解開加密的壓縮檔,只要在壓縮檔上使用滑鼠右鍵的 7-Zip –> Extract (當然你的朋友也要先安裝 7-Zip)。

輸入剛剛選用的密碼,如果輸入正確的密碼就可以取回原先的檔案。7zip 006

如果輸入錯誤的密碼將會出現錯誤訊息。7zip 007

如果你的朋友是 Linux 的愛好者,他可能會使用 unzip 指令來解開這個壓縮檔,很可惜的是他失敗的機會很高。7zip 008

在 Linux 下可以使用 p7zip 這個套件來解開加密過的壓縮檔。如果系統採用 yum 來管理套件,就可以使用 yum –y install p7zip 的指令來安裝 p7zip 套件。

使用的指令為 7za x 壓縮檔名稱,程式會要求使用者輸入密碼。此一密碼就是壓縮時輸入的密碼。7zip 009

輸入正確的密碼後就可以順利地解開檔案。7zip 010

檔案內容正確無誤。7zip 011

透過 7-Zip 的功能,我們可以輕鬆地建立起安全的 (AES-256 加密) 壓縮檔以便於分享。除此之外,它是完全免費的,而且也沒有討厭的平台限制。一個小小的動作,將可以減少日後很多不必要的困惱與損失。

2010年11月24日 星期三

[新聞時事] 汽車性能大進化,安全能否跟的上?

gal-pic-02汽車對很多人 (尤其是男生) 來說,往往不只是一項代步工具,更是一種身分跟品味的象徵。但是在眾多感性的訴求當中,卻還是有一些比較理性的訴求,其中之一就是安全性。過去汽車的安全性,對車子本身而言,包含了車身結構、安全氣囊、ABS 以及其他的安全設計。對駕駛而言,則包含了行前的檢查 (油、水、胎壓、煞車、電池及其他) 與安全地駕駛 (開車不喝酒、不打行動電話) 等等。但是在未來,所謂的汽車安全性,或許會另外多了一個項目,那就是軟體的更新 (事實上,部分汽車廠商現在就已經具有這樣的服務)。隨著汽車工業的高度發展,現代汽車的設計已經內建越來越多的軟體 (Mercedes-Benz S-Class 擁有超過兩千萬行的程式碼) ,用以強化駕駛與乘客的乘坐經驗。但是這些軟體,卻也代表著可能存在的安全漏洞。尤其是當這些軟體可以從遠端 (利用網路) 加以控制時,其所產生的影響將可能是前所未見的。

之前我分享過幾則相關的新聞,但是其影響大多還只是侷限在造成不便,對安全尚未造成真正的危害。但是,隨著市場規模的擴大,惡意的攻擊,乃至於有利益目的的攻擊,只是早晚的問題。例如,如果駭客可以透過車載定位系統明確地掌握某大企業 CEO 的行程,或許就可以猜到這家企業暗地裡可能在進行什麼業務。又例如當駭客可以透過同樣的系統掌握到政要的出現地點,那麼想要對其不利也就容易多了。至於市井小民嘛,也許哪一天車子無緣無故自己開到荒山野地躲起來也不會是什麼令人驚訝的消息。想要找回愛車,請記得先付款給駭客。除此之外,針對那些喜歡在車上做些非正常活動的男女,或許更該多加小心,免得成了現場直播成人秀的最佳男、女主角了。

 

相關連結:

2010年11月20日 星期六

[新聞時事] Amazon 正式提供 GPU 運算能力

tesla_logo之前我分享過幾篇有關 WiFi 協定加密安全性的文章,對於使用者而言, WEP 與 WPA 應該是早就揚棄不用。但是在現實的環境中,使用 WEP 與 WPA 的設備依舊不在少數。一般而言,破解加密/密碼需要大量的運算能力,而且是不同於一般電腦設備所依賴的 CPU (中央處理器) 運算能力。提到大量運算能力,大家現在最容易聯想到的就是利用雲端架構的充沛資源,所以因而有了利用雲端平台來破解 WPA 的服務。但是雲端再強大,依舊是使用所謂的 CPU 當做主要運算能力的來源。相較於 CPU,GPU (圖型處理器) 的運算能力其實更適用於破解加密/密碼。因此雲端平台如果能夠再加上 GPU 的組合,那可真的是如虎添翼了,而這樣的夢想已經可以在 Amazon 的 EC2 平台上加以實現。Amazon EC2 於日前宣布提供 GPU (Nvidia Telsa) 運算能力的服務,讓破解加密/密碼的工作進行地更加快速。事實上,已經有人提供如何利用此一架構來執行破解密碼的程式。對我們的影響?那就是趕快換掉老舊的設備,還有就是選擇一個好的密碼

 

相關連結:

2010年11月10日 星期三

[資安觀念] 駭客利用 Honeypot 反將一軍

Bear-in-a-Honey-Pot-Puppet-1之前我在 [從電影看資安] 誰才是大將軍 - 大兵小將 這篇文章中提到資安專家利用假冒的觀念來減少危險,後來甚至演變出所謂的 Honeypot/Honeynet,這類機制不但可以用來減少駭客攻擊的有效性,甚至可以用來學習駭客的行為以利資安專家對抗駭客所發動的攻擊。我在文章最後提到假冒的觀念對於攻擊與防守的雙方都同樣重要,甚至攻擊方對於假冒更是駕輕就熟,畢竟攻擊要成功,完美的假冒往往是一個基本條件。但是像是 Honeypot 這種用來誘敵的機制,對於攻擊一方的用途卻是到了近期才被加以利用。這倒也不是說明資安專家就比駭客更加聰明,而是資安專家往往比較被動,所以對他們採用 Honeypot 的效用不大。不過一旦駭客發現這是一個好方法,他們絕對不會放棄,而且我相信駭客可以發揮出更好的效果。因為駭客只要放出足夠的煙霧彈就夠資安專家們忙上好一陣子了,而在現今的攻擊情境中,好一陣子已經可以產生決定性的效果。事情會怎麼演變,就讓我們繼續觀察吧。

 

相關連結:

2010年11月4日 星期四

[新奇玩意] 路由器 XSS 讓你無處可躲

where-are-you隨著行動設備的大量普以及隨時隨地上網的人數越來越多,地理位置資訊的應用也越來越熱門。雖然這類資訊可能讓個人的行蹤被其他人一覽無遺,但是因為這些資訊的開放大多是屬於使用者自行所決定,所以反對份子所能夠持有的立場往往顯得較為薄弱,對於一般人而言也還不致於造成過多的擔憂。但是,如果這類資訊的開放並不是使用者自願的,甚至是在使用者不知情的情況下所發生,結果或許就會有很大的轉變。

Samy Kamkar 在他自己的網站上發表了一個概念驗證的手法,他利用路由器的漏洞取得用戶端電腦的網卡卡號,然後再使用 Firefox Location-Aware Browsing 的功能,就可以在不知不覺的情況下取得使用者所在的位置。不過他的範例只針對特定的路由器才有作用,所以對於一般人倒是還沒有立即的危害。只是取得網卡卡號並不是只有一種方法,所以其所可能衍生的問題依舊不可小覷。

 

相關連結:

2010年10月27日 星期三

[技術分享] ReDoS

BlogTH78201031549ReDoS? 可不是再次的阻斷服務攻擊 (Re-DoS),而是正規表示式阻斷服務攻擊 (Regular Expression DoS),是阻斷服務攻擊的一種手法。對於一般的程式開發,雖然不見得常使用到正規表示式的應用,但是正規表示式卻常見於各式各樣的過濾器上。所以像是網站應用程式的輸入檢查、快取伺服器或其他類型閘道器的存取過濾功能,通常都有正規表示式的存在。

正規表示式最基本的應用就是用來尋找資料中是否含有特定樣式的內容,例如我們可以透過正規表示式來判斷一個文字檔內是否含有手機號碼,而判斷條件就是以0為開頭的連續10個數字 (這個條件可能不適合用來找出所有可能的手機號碼,但是無損於說明性)。也因此正規表示式的應用至少含有兩個部分,一個就是用來當做搜尋的樣式 (Pattern,通常這部份也稱為正規表示式),以前述的例子而言就是”以0為開頭的連續10個數字”。另外一部分則是用來被搜尋的輸入目標,以前述的例子而言就是文字檔的內容。而正規表示式阻斷服務攻擊發生在利用某些樣式進行搜尋時將有可能會產生大量消耗運算資源的情況,因而使得系統無法處理其他的請求。這也是它為什麼被稱為阻斷服務攻擊的原因了。

至於”某些樣式”是哪些樣式,在 OWASP 上面的說明文件舉了一些例子,包含

  • (a+)+
  • ([a-zA-Z]+)*
  • (a|aa)+
  • (a|a?)+
  • (.*a){x} | for x > 10

而前些日子 Microsoft 則推出了一個 Regex Fuzzer 的工具,宣稱可以用來驗證所輸入的正規表示式是否存在遭受正規表示式阻斷服務攻擊的隱憂。不過根據我測試的結果,這個工具的執行結果跟 OWASP 上面的例子並沒有完全一致。以目前的情況而言,想要避免正規表示式阻斷服務攻擊最保險的作法似乎就是限制被搜尋目標的內容長度。如果內容長度過長甚至無法加以限制時,自行利用 Fuzzing 的概念 (或利用 Regex Fuzzer,如果你相信它的話) 加以測試將會是比較安全的作法。

 

相關連結:

2010年10月24日 星期日

[新奇玩意] 電話來源 Fingerprinting

bruce-blog2資訊安全專家 Bruce Schneier 日前在他個人的部落格發表了一篇文章,提到了一個可以用來分析電話來源的小工具 - PinDr0p。根據部落格的內容指出,這個工具雖然沒有辦法分辨出電話來源的所在區域或 IP 位址,但是它可以用來判斷不同的電話之間是否來自同一個所在地。也就是說如果該程式知道你日常往來銀行客服電話的特徵,那麼它就可以判斷出日後宣稱來自該銀行的電話是否符合之前的特徵,也就是說它可以避免使用者接到由其他地方發出的詐騙電話而不自知。雖然 Bruce Schneier 宣稱每一個電話來源只要經過 5 次的取樣就可以達到日後 100% 的準確率,但是如何轉換成為可行的系統,而且在實際的環境下又能有多好的成效,就讓我們拭目以待吧。

 

 

相關連結:

 

2010年10月23日 星期六

[技術分享] iBatis/MyBatis 與 SQL Injection

flow前幾天無意間聽到有人提到 iBatis 使用了 PreparedStatement 的機制,所以沒有 SQL Injection 的問題,因此我特地寫了這篇文章來說明 iBatis 與 SQL Injection 的關係。在開始說明之前,我稍微解釋一下 iBatis 這個套件。根據作者的解釋,它是一個 SQL Mapping 的工具,抽象程度高於 JDBC,但是卻低於 ORM (例如 Hibernate)。簡單來說,iBatis 將系統中會使用到的 SQL 指令皆放置在 XML 檔案內,以避免利用程式本身產生與維護 SQL 指令時的困擾。相較於 JDBC,iBatis 也提供了像是 Cache、Transaction Management 等高階的功能,幫助系統開發者簡化資料庫的相關操作。而因為某些原因,iBatis 已經改名為 MyBatis,不過基本上兩者是一樣的。反倒是目前 MyBatis 有 2.x 與 3.x 兩個主要版本,兩者之間卻是不相容的。

回到 SQL Injection 本身,用了 iBatis/MyBatis 就沒有 SQL Injection 的問題了嗎?聰明的讀者,您一定想到了答案。因為如果答案是肯定的,就沒有這篇文章存在的必要性, 所以答案就是即使使用了 iBatis/MyBatis,並不能保證系統就沒有 SQL Injection 的問題。基本上,iBatis/MyBatis 會盡量以PreparedStatement 的方式加以執行,但是卻不是在所有的情況下都是如此的。主要的問題發生於在當使用 inline 方式宣告 SQL 指令的參數時,iBatis/MyBatis 允許兩種參數傳遞的宣告方式,一種是利用 #,另外一種則是透過 $,而後者正是問題所在。$ 表示將參數的內容直接附加於 SQL 指令之內,而不是使用參數化的設定。因此只要使用了 $ 的方式來傳遞參數,就有可能遭受 SQL Injection 的攻擊。

此外,iBatis/MyBatis 也支援所謂 Dynamic SQL 的功能。我們之前提到 Dynamic SQL 正是 SQL Injection 的元兇,但是使用 iBatis/MyBatis 的 Dynamic SQL 卻並不表示就有 SQL Injection 的問題,還是必須取決於參數傳遞的方式。如果使用 # 的方式傳遞參數,即使使用 iBatis/MyBatis 的 Dynamic SQL 依舊是安全的。結論知道了,接下來還是透過簡單的範例程式來看看問題是如何發生的。

首先我在資料庫內鍵入了兩筆虛擬的使用者資料:

mysql> select * from USER_ACCOUNT;
+--------+----------+----------+-----------+
| USERID | username | password | groupname |
+--------+----------+----------+-----------+
|      1 | LMEADORS | PICKLE   | EMPLOYEE  |
|      2 | JDOE     | TEST     | EMPLOYEE  |
+--------+----------+----------+-----------+
2 rows in set (0.00 sec)


 



我以 iBatis/MyBatis 2.x 為例,在設定檔中宣告了兩個功能相同的 SQL 指令,也就是根據使用者帳號與密碼來查詢使用者的資料,通常會用於使用者的登入認證過程。第一個 SQL 指令 (第 3-4 行) 採用 # 的宣告方式,而第二個 SQL 指令 (第 7-8 行) 則採用 $ 的宣告方式。



  1: <select id="checkCredential-1" parameterClass="QueryCondition"
  2:                                resultClass="hashmap">
  3:     SELECT * FROM USER_ACCOUNT WHERE username = #username# 
  4:         AND password = #password#
  5: </select>
  6: <select id="checkCredential-2" parameterClass="QueryCondition"
  7:                                resultClass="hashmap">
  8:     SELECT * FROM USER_ACCOUNT WHERE username = '$username$' 
  9:         AND password = '$password$'
 10: </select>


 



程式針對兩組 SQL 指令分別嘗試 SQL Injection 的攻擊 (第 12-13, 22-23 行)。



  1: String resource = "SqlMapConfig.xml";
  2: Reader reader = Resources.getResourceAsReader(resource);
  3: SqlMapClient sqlMap = 
  4:     SqlMapClientBuilder.buildSqlMapClient(reader);
  5: 
  6: // it's good, and the user is found
  7: QueryCondition qc = new QueryCondition("JDOE", "TEST", null);
  8: Object o = sqlMap.queryForObject("checkCredential-1", qc);
  9: System.out.println("1. " + o);
 10: 
 11: // it's bad, but the user can *NOT* be found (sanitized by iBatis)
 12: qc = new QueryCondition("JDOE' OR 1=1--'", "1234", null);
 13: o = sqlMap.queryForObject("checkCredential-1", qc);
 14: System.out.println("2. " + o);
 15: 		
 16: // it's good, and the user is found
 17: qc = new QueryCondition("JDOE", "TEST", null);
 18: o = sqlMap.queryForObject("checkCredential-2", qc);
 19: System.out.println("3. " + o);
 20: 		
 21: // it's bad, and the user is found (*SQL Injected*)
 22: qc = new QueryCondition("JDOE' OR 1=1--'", "1234", null);
 23: o = sqlMap.queryForObject("checkCredential-2", qc);
 24: System.out.println("4. " + o);


 



我們可以看到第二次的 SQL Injection 攻擊成功 (第 4 行),程式使用的是設定檔中第二個 SQL 指令。針對第一個 SQL 指令的 SQL Injection 並沒有成功 (第 2 行)。



1. {username=JDOE, groupname=EMPLOYEE, password=TEST, USERID=2}
2. null
3. {username=JDOE, groupname=EMPLOYEE, password=TEST, USERID=2}
4. {username=JDOE, groupname=EMPLOYEE, password=TEST, USERID=2}


 



接下來我們來看看 iBatis/MyBatis 的 Dynamic SQL 是如何運作的。第一個 Dynamic SQL 採用 # 的方式加以宣告,而第二個 Dynamic SQL 則採用 $ 的方式加以宣告。



  1: <select id="checkCredentialExtended-1" 
  2:     parameterClass="QueryCondition" resultClass="hashmap">
  3:     SELECT * FROM USER_ACCOUNT
  4:     <dynamic prepend=" WHERE ">
  5:         <isNotEmpty property="username">
  6:             username=#username#
  7:         </isNotEmpty>
  8:     </dynamic>
  9:     <dynamic prepend=" AND ">
 10:         <isNotEmpty property="groupname">
 11:             password=#password#
 12:         </isNotEmpty>
 13:     </dynamic>
 14:     <dynamic prepend=" AND ">
 15:         <isNotEmpty property="groupname">
 16:             groupname=#groupname#
 17:         </isNotEmpty>
 18:     </dynamic>
 19: </select>
 20: <select id="checkCredentialExtended-2" 
 21:     parameterClass="QueryCondition" resultClass="hashmap">
 22:     SELECT * FROM USER_ACCOUNT
 23:     <dynamic prepend=" WHERE ">
 24:         <isNotEmpty property="username">
 25:             username='$username$'
 26:         </isNotEmpty>
 27:     </dynamic>
 28:     <dynamic prepend=" AND ">
 29:         <isNotEmpty property="groupname">
 30:             password='$password$'
 31:         </isNotEmpty>
 32:     </dynamic>
 33:     <dynamic prepend=" AND ">
 34:         <isNotEmpty property="groupname">
 35:             groupname='$groupname$'
 36:         </isNotEmpty>
 37:     </dynamic>
 38: </select>


 



程式同樣針對兩組 SQL 指令分別嘗試 SQL Injection 的攻擊 (第 22-23, 42-43 行)。



  1: String resource = "SqlMapConfig.xml";
  2: Reader reader = Resources.getResourceAsReader(resource);
  3: SqlMapClient sqlMap = 
  4:     SqlMapClientBuilder.buildSqlMapClient(reader);
  5: 
  6: // it's good, and the user is found
  7: QueryCondition qc = new QueryCondition("JDOE", "TEST", null);
  8: Object o = sqlMap.queryForObject("checkCredentialExtended-1", qc);
  9: System.out.println(o);
 10: 
 11: // it's good, and the user is found
 12: qc = new QueryCondition("JDOE", "TEST", "EMPLOYEE");
 13: o = sqlMap.queryForObject("checkCredentialExtended-1", qc);
 14: System.out.println(o);
 15: 
 16: // it's good, but the user is not found (no such user)
 17: qc = new QueryCondition("JDOE", "TEST", "MANAGER");
 18: o = sqlMap.queryForObject("checkCredentialExtended-1", qc);
 19: System.out.println(o);
 20: 
 21: // it's bad, but the user is *NOT* be found (sanitized by iBatis)
 22: qc = new QueryCondition("JDOE' OR 1=1--'", "1234", null);
 23: o = sqlMap.queryForObject("checkCredentialExtended-1", qc);
 24: System.out.println(o);
 25: 
 26: // it's good, and the user is found
 27: qc = new QueryCondition("JDOE", "TEST", null);
 28: o = sqlMap.queryForObject("checkCredentialExtended-2", qc);
 29: System.out.println(o);
 30: 		
 31: // it's good, and the user is found
 32: qc = new QueryCondition("JDOE", "TEST", "EMPLOYEE");
 33: o = sqlMap.queryForObject("checkCredentialExtended-2", qc);
 34: System.out.println(o);
 35: 		
 36: // it's good, but the user is not found (no such user)
 37: qc = new QueryCondition("JDOE", "1234", "MANAGER");
 38: o = sqlMap.queryForObject("checkCredentialExtended-2", qc);
 39: System.out.println(o);
 40: 		
 41: // it's bad, and the user is found (*SQL Injected*)
 42: qc = new QueryCondition("JDOE' OR 1=1--'", "1234", "MANAGER");
 43: o = sqlMap.queryForObject("checkCredentialExtended-2", qc);
 44: System.out.println(o);


 



我們可以看到第二次的 SQL Injection 攻擊成功 (第 8 行),程式使用的是設定檔中第二個 SQL 指令。針對第一個 SQL 指令的 SQL Injection 並沒有成功 (第 4 行)。



  1: {username=JDOE, groupname=EMPLOYEE, password=TEST, USERID=2}
  2: {username=JDOE, groupname=EMPLOYEE, password=TEST, USERID=2}
  3: null
  4: null
  5: {username=JDOE, groupname=EMPLOYEE, password=TEST, USERID=2}
  6: {username=JDOE, groupname=EMPLOYEE, password=TEST, USERID=2}
  7: null
  8: {username=JDOE, groupname=EMPLOYEE, password=TEST, USERID=2}


 



前述是 iBatis/MyBatis 2.x 的例子,而 MyBatis 3.x 雖然與 iBatis/MyBatis 2.x 不相容,但是問題的本質卻是完全一樣的。也就是當透過設定檔指定 SQL 指令時,MyBatis 3.x 一樣有可能遭遇 SQL Injection 的攻擊。除了利用設定檔的方式外,MyBatis 3.x 還可以透過所謂 Mapper class 的機制來指定 SQL 指令,而此一機制一樣有可能遭受 SQL Injection 的攻擊。至於利用 MyBatis 3.x 提供的 SelectBuilder 與 SqlBuilder 所產生的 SQL 指令,因為並不支援以 $ 的方式宣告參數,所以並不會有上述的問題。



因此在使用 iBatis/MyBasit 的 inline 參數宣告方式時,請記得盡量採用 # 的方式加以宣告。如果確有使用 $ 的需求,則需務必做好參數的嚴格檢查,以免產生 SQL Injection 的危害。而 iBatis/MyBatis 除了使用 SQL 指令之外,也可以呼叫預儲程序 (Stored Procedure)。在這種情況下,如何避免 Stored Procedure 遭受 SQL Injection 的攻擊,就成了預儲程序自己的責任了。



2010年10月16日 星期六

[資安觀念] SaaS 與 DoS/DDoS

iStock_000005760185XSmallDoS/DDoS (阻斷服務攻擊) 對許多人來說,早已經是耳熟能詳的名詞。以 DoS 的定義來說,只要能夠讓服務中斷,不管用什麼方法都可以算是 DoS 的攻擊。所以,拿榔頭把連結伺服器的路由器給敲爛,絕對也是 DoS 攻擊的一種。這樣的攻擊方式除了被逮捕的風險高了許多,而且在效率上也不夠好。所以除非你跟某家企業有深仇大恨,而且報著必死的決心,不然請勿輕易嘗試此一作法。也因此以網路為主的遠端 DoS/DDoS 才是主要的攻擊手法,駭客想盡一切辦法讓使用者無法連結到某個企業的網路服務,像是把網路頻寬或伺服器的運算資源消耗殆盡。

而這一兩年極為熱門的話題 - SaaS (或大家比較常聽到的雲端運算),除了它本身產生的資安考量外,SaaS 與 DoS/DDoS 還有其他的關聯。首先,SaaS 的架構讓駭客擁有了更多且更便宜 (甚至免費) 的資源來對攻擊目標的資源進行消耗的行為。嚴格來說,甚至可以說是以 Botnet 為主的地下經濟本身就是一種 SaaS 的服務,只是買方甚至連軟體都不用操作就可以收到結果。另外之前提到利用 SaaS 架構提供破解 WPA 的服務,雖然不是用來進行 DoS/DDoS 的攻擊,卻也是利用 SaaS 來增強破壞力的應用。

除此之外,隨著 SaaS 架構的風行,有人預計利用 DoS/DDoS 攻擊手法來對企業進行威脅的事件將會持續增加。原因之一是很多 SaaS 架構採用用多少算多少的計費方式,這樣的方式也就表示用的越多,帳單的金額就越高。在此情況下,DoS/DDoS 攻擊就算無法癱瘓企業的網路服務,也將使得帳單金額大增。因此,駭客可以利用這樣的預期損失而對企業進行事前的勒索。我個人覺得這雖然有其道理,但是 SaaS 的服務通常可以設定帳單金額的上限,所以在最差的情況下,被攻擊企業的網路服務也”只是”完全停擺,並不會有金額大爆炸的情況發生。倒是 SaaS 的模式,讓企業遭受 DoS/DDoS 攻擊時的損失容易量化,因此方便駭客對勒索金額進行”合理的”喊價。不論如何,當 SaaS 讓資源的應用變成價格化後,DoS/DDoS 攻擊已經不再只是單純的”給他死”,而有更多的操作空間可以讓駭客獲取利益。這年頭,當駭客不但要有技術能力,還得有商業頭腦才行。

 

相關連結:

2010年10月12日 星期二

[新聞時事] 運用繪圖處理器 (GPU) 可大幅提昇解密資料的速度

images雖然大多數的人跟我一樣,都不是密碼學的專家,但是密碼學的應用卻充斥在我們的日常生活之中。從你買東西時使用信用卡付賬,到在網路上進行購物,甚至是你每天登入到作業系統,都跟密碼學有關。密碼學的中文說法,其實很容易讓人產生誤解,因為密碼學講的並不是我們平常登入各式系統所使用的密碼,而是加解密的演算法。雖然比較嚴謹的系統都會將密碼做加密的保護,但是兩者之間卻沒有必然的關係,而密碼學就是一門充滿了各式各樣演算法的學問。這些複雜的演算法,往往都不是由資訊專家所提出,而是數學家所苦心研究出來地成果,並經過外界公開的審視。儘管演算法在被公開接受並採用前往往已經經過了仔細的評估,但是卻沒有一個演算法本身是絕對安全的。所有的演算法至少都會遭遇一種手法的攻擊,那就是所謂的暴力攻擊法。簡單的說,暴力攻擊法就是利用強大的運算能力,將加密或解密的各種可能性逐一計算,最後獲得所需資訊的手法。既然所有的演算法都會遭受暴力攻擊法的攻擊,那麼為什麼密碼學的應用還會被大量採用在我們日常生活當中呢?原因很簡單,就是因為暴力破解法所需的強大運算往往在現今的技術下是無法有效地加以實現,也因此我們的資料”暫時”是安全的。

除非是很特殊的組織或個人,否則一般駭客能夠用來破解加密資料的工具還是最常見的個人電腦設備。傳統上我們常用的電腦設備主要透過中央處理器  (CPU) 處理各式各樣的運算需求,而中央處理器本身是一個通用的處理器,所以對於處理大量的數學運算並不在行。儘管隨著技術的進步,中央處理器的處理速度已經大為提昇,但是先天的定位註定中央處理器一旦遇到複雜的數學運算就是只能吃憋。

而電腦內部除了中央處理器之外,往往還有另外一個處理器,稱之為繪圖處理器 (GPU)。繪圖處理器顧名思義就是用來處理圖型顯示的運算,而圖型顯示正需要大量的數學運算,所以繪圖處理器天生就是數學運算的高手。其實繪圖處理器的存在由來已久,但是因為市場需求的關係,之前繪圖處理器的發展速度並不如中央處理器那般快速。而近年來遊戲與網路多媒體的蓬勃應用,讓繪圖能力的重要性越趨重要。再加上技術的成熟,因此繪圖處理器的處理速度大幅增進,尤其是這樣的技術應用已經相當普及,而不像過去繪圖處理器是有錢人的專屬玩具。也因為這樣的發展,所以繪圖處理器的強大數學運算能力不但可以用在繪圖功能上,更有人開始發揮創意並開發新的應用,而其中一個應用就是用來破解加密的資料。一旦這樣的運用普及化,我們對於演算法的安全性就必須重新加以思考,因為所謂的”暫時”安全可能已經不再是”暫時”,而僅僅只是一瞬間的時間。至於在實際上會有多大的影響層面,就讓我們持續觀察吧。

 

相關連結:

2010年10月8日 星期五

[技術分享] 用了參數化查詢就可以對 SQL Injection 高枕無憂? NO!

sql-injection在上個月的一篇文章中,我們看到 WhiteHat Security 對於避免 SQL Injection 的危害提出了 10 個手法。其中第 7 個手法,使用”參數化的查詢 (在 Java 的程式語言中主要是透過 PreparedStatement 來提供) 並避免使用動態式的查詢”對許多人來說應該算是老生常談了。事實上,程式內未採用參數化查詢大多不是因為技術上的考量,因為除了極少數的情況 (通常與效能有關) 外,參數化查詢都是可以順利運作的。在無法採用參數化查詢的原因中,最常見的情況就是使用了預儲程序 (Stored Procedure)。預儲程序如果小心使用,對於 SQL Injection 其實也有一定的防護能力。但是預儲程序畢竟不像參數化查詢那般嚴謹,所以提供這些功能的程式碼無法事先做太多的防範措施,大多數防護的責任還是落在系統開發者自行開發的程式上。而參數化查詢因為會嚴格限制每個參數的型別,所以提供此一功能的程式就可以做好萬全的準備,讓系統開發者在撰寫自己的程式時不需太過擔心。所以除非被限制必須使用預儲程序來存取資料,否則我們就應該採用參數化查詢來存取資料。

參數化查詢與預儲程序之間的取捨,往往還有許多其他非技術的因素,但是這並不是我這篇文章的重點,所以這個問題就在此打住。當我們確實採用了參數化的查詢後,是否就可以對 SQL Injection 高枕無憂了呢?很可惜的是,答案依舊是否定的。如果我們仔細審視第一段的藍色文字,可以發現後半段是避免使用動態式的查詢。而前、後段文字使用”並”加以連結,所以一旦使用者違反了後半段文字的限制,即使使用參數化查詢依舊會遭受 SQL Injection 的攻擊。因為這點對於部分的系統開發者來說或許並不是那麼熟悉,所以接下來我將以實際的例子 (Java 語法) 來加以說明。我假設我們擁有一個稱為 users 的資料表,內含 name 與 password 兩個欄位,分別表示使用者的姓名與密碼。而在此資料表中有一個使用者的姓名與密碼分別為 ‘cyril wang’ 與 ’1234’。

1. 這是 PreparedStatement 的標準用法,也就是利用 setXXX 的方式 (程式碼第 9, 10 行) 來明確指定資料的型別。因為使用者輸入 (參見備註1) 的帳號與密碼相對應,所以此程式執行完後可以取得該使用者的ID。

備註1:雖然在所有的程式範例中, userInputForUsername 與 userInputForPassword 兩個變數的值是固定的,但是在一般程式中此兩變數的值通常來自於一般使用者 (或駭客) 的輸入。

  1: Class.forName("com.mysql.jdbc.Driver");
  2: Connection c =
  3:     DriverManager.getConnection(url, account, password);
  4: 
  5: String userInputForUsername = "cyril wang";
  6: String userInputForPassword = "1234";
  7: String sql = "SELECT * FROM users WHERE name=? AND password=?";
  8: PreparedStatement stmt = c.prepareStatement(sql);
  9: stmt.setString(1, userInputForUsername);
 10: stmt.setString(2, userInputForPassword);
 11: ResultSet rs = stmt.executeQuery();
 12: if (rs.next()) {
 13: 	System.out.println("Your ID is " + rs.getInt(1));
 14: } else {
 15: 	System.out.println("Get out!");
 16: }


 



2. 當使用者 (或駭客) 嘗試輸入 SQL Injection 的攻擊字串,PreparedStatement 的實作會將字串內容加以過濾。因為帳號與密碼無法對應,因此無法取得使用者的 ID。



  1: Class.forName("com.mysql.jdbc.Driver");
  2: Connection c =
  3:     DriverManager.getConnection(url, account, password);
  4: 
  5: String userInputForUsername = "cyril wang' OR 1=1--'";
  6: String userInputForPassword = "aaaa";
  7: String sql = "SELECT * FROM users WHERE name=? and password=?";
  8: PreparedStatement stmt = c.prepareStatement(sql);
  9: stmt.setString(1, userInputForUsername);
 10: stmt.setString(2, userInputForPassword);
 11: ResultSet rs = stmt.executeQuery();
 12: if (rs.next()) {
 13: 	System.out.println("Your ID is " + rs.getInt(1));
 14: } else {
 15: 	System.out.println("Get out!");
 16: }


 



3. 仔細看程式碼第 5 行到第 11 行的寫法,這種常見於一般 SQL 查詢的用法對 PreparedStatement 來說也是合法的,而這種用法就稱為動態式查詢。因為使用者輸入的對應的帳號與密碼,因此可以取得 ID。



  1: Class.forName("com.mysql.jdbc.Driver");
  2: Connection c = 
  3:     DriverManager.getConnection(url, account, password);
  4: 
  5: String userInputForUsername = "cyril wang";
  6: String userInputForPassword = "1234";
  7: String sql = "SELECT * FROM users WHERE name = '" +
  8: 	         userInputForUsername +
  9: 	         "' AND password ='" +
 10: 	         userInputForPassword +
 11: 	         "'";
 12: PreparedStatement stmt = c.prepareStatement(sql);
 13: ResultSet rs = stmt.executeQuery();
 14: if (rs.next()) {
 15: 	System.out.println("Your ID is " + rs.getInt(1));
 16: } else {
 17: 	System.out.println("Get out!");
 18: }


 



4. 使用者 (或駭客) 再次嘗試輸入 SQL Injection 攻擊字串,而這將是一次成功的攻擊。儘管沒有輸入對應的密碼,使用者 (或駭客) 依舊取得 ID。



  1: Class.forName("com.mysql.jdbc.Driver");
  2: Connection c = 
  3:     DriverManager.getConnection(url, account, password);
  4: 
  5: String userInputForUsername = "cyril wang' OR 1=1--'";
  6: String userInputForPassword = "aaaa";
  7: String sql = "SELECT * FROM users WHERE name = '" +
  8: 	         userInputForUsername +
  9: 	         "' AND password ='" +
 10: 	         userInputForPassword +
 11: 	         "'";
 12: PreparedStatement stmt = c.prepareStatement(sql);
 13: ResultSet rs = stmt.executeQuery();
 14: if (rs.next()) {
 15: 	System.out.println("Your ID is " + rs.getInt(1));
 16: } else {
 17: 	System.out.println("Get out!");
 18: }


 



從上面這些簡單的範例程式中,我們可以看到如果在參數化查詢指令中使用了動態式的查詢,那麼程式依舊無法避免 SQL Injection 的問題,也因此我們應該盡力避免使用動態式的查詢。如果動態式的查詢確實有其必要性,做好輸入的檢查 (Input Validation & Sanitization) 就是不可避免的手法。其實以安全的角度來看,不管是不是使用參數化查詢,都應該做好輸入的檢查動作才是。



以目前常見的兩大網站安全問題來看,SQL Injection 的問題與解決之道相對比 Cross-Site Scripting 單純多了,因此我們實在沒有理由讓 SQL Injection 一直肆虐下去。對於已經完成或開發中的程式,採用自動化的白箱工具可以有效地找出所有有問題的程式碼,以避免花費大量時間進行人工搜尋。而透過對系統開發人員的教育訓練,則可以讓 SQL Injection 的問題防範於未然,此時白箱工具則可由原先找出問題的角色轉換為確保安全品質與稽核的角色。正確的觀念 (從單位主管到系統開發人員) 再加上合適的工具,SQL Injection 的避免並沒有想像中的那麼遙不可及。



備註2: 在多層次防禦的概念下,除了使用參數化查詢外,其他手法還是有其必要性,而前述 WhiteHat Security 的文章可作為參考。但是千萬切記勿落入”這就是全部可用的手法”的誤解中,以免因為疏忽而產生危害。

2010年9月23日 星期四

[新聞時事] Twitter 遭受跨網站腳本攻擊

Twitter_256x256 知名的微網誌 Twitter 在 21 日的 AM 2:54 收到警告,表示該網站存在一個跨網站腳本攻擊 (XSS) 的安全漏洞。但是根據其他網誌的報導,一個來自日本的資安研究員 Masato Kinugawa 表示他早在八月中就告知 Twitter 此一問題的存在,並利用此一漏洞做了一些不具破壞性的展示。Masato Kinugawa 將 Twitter 的頁面裝飾成七彩的顏色,並稱之為 Rainbow tweets。此一漏洞被揭露之後,許多人就開始發揮創意,不但產生各式各樣不同的行為,連觸發動作也由原來必須將滑鼠移到連結上 (onMouseOver) 改成自動啟動。後來甚至有了具備自動感染功能的蠕蟲出現,受害者包含前英國首相 Gordon Brown 的妻子 Sarah Brown。

這次的跨網站腳本攻擊來自於當使用者輸入的內容包含連結時 (如 http://www.twitter.com/) Twitter 會自動將其轉換成 html 的連結標籤 (<a>),但是解析程式對於 @ 這個特殊字元的處理出現問題而導致。受影響的範圍主要為使用 Twitter 主網站服務的用戶,對於使用 3rd party 程式存取 Twitter 服務的用戶則不受影響。Twitter 則對外宣稱在收到通知之後的數個小時 (AM 7:00) 之內就把漏洞修補好了。

跨網站腳本攻擊的氾濫程度與嚴重性已經是老生常談的話題,雖然解法說起來很簡單,但是在執行上卻有其困難度。這次的事件還有另外一個需要注意的重點,那就是網站安全的不中斷性。不管你的網站其使用者是否來自於世界各地,對於駭客而言絕對沒有區域與時區的限制,所以如何建立一個 24 小時不中斷的安全機制與應變機制,對所有網站的經營者而言都是必須去認真思考的一個課題。

相關連結:

2010年9月19日 星期日

[新聞時事] ASP.NET 區塊加密法因實作錯誤而導致 Cookie 產生危險

4qjbsb5pxk1lp7f1pf66w3ls2a 根據 Thai Duong 與 Juliano Rizzo 兩位資安研究員於日前所發表的資料顯示,他們已經找到 ASP.NET 當中用來加密 Cookie 演算法的實作錯誤。這個錯誤影響了包含 AES、3DES、MARS 在內的區塊演算法 (Block-Cipher),而攻擊者則可以透過 ASP.NET 所傳回的錯誤訊息計算出用來加密的 Machine Key,其所產生的危害包含攻擊者可以假冒任何合法的 Cookie 及 ViewState。因為 Cookie 是許多系統用來儲存使用者身分資料的機制,也就是表示攻擊者可利用此一攻擊手法來假冒合法的使用者、甚至是管理者。

目前 Microsoft 針對此一問題所提出的建議方案正是減少錯誤訊息所提供的資訊。例如可以在 web.config 內加上或修改成下列內容
<customErrors mode=”On” defaultRedirect=”~/error.html” />

如此一來攻擊者就只能看到固定的錯誤訊息,而無法利用錯誤訊息來計算出所需的 Machine Key。

 

這裡有示範的影片,研究員利用發現的錯誤攻擊 DotNetNuke 這個套件,並順利取得管理者的權限。

 

相關連結:

2010年9月15日 星期三

[教戰守則] 如何避免 SQL Injection?

sql_img 雖然 SQL Injection 提出至今已經經過了許多年,但是 SQL Injection 依舊是目前網站應用程式的主要弱點之一,更是資料外洩的主要管道。根據 WhiteHat Security 的一份 White Paper 的內容指出,可以採用下列 10 個方法來避免 SQL Injection 產生危害:

  1. 將資料庫與網站伺服器分別安裝在不同的機器上,並確保機器維持在最新的更新狀態。(Install the database on a different machine than the Web server or application server. Make sure all the latest patches are applied.)
  2. 應該將資料庫內所有預設帳號與密碼加以關閉,尤其是管理者的帳號更是不可掉以輕心。(The database should have all the default accounts and passwords disabled, including the super-user account.)
  3. 建立一個應用程式專用的帳號,並給予其執行任務所需的最小權限。將所有範例表格以及不需使用的 stored procedure 加以移除。(Create an application user account in your database that has minimum privileges necessary for that application to access the data. Remove all the sample tables. Disable access to any stored procedure that is not required by that application user.)
  4. 找出所有需要執行的 SQL 指令,並僅允許這些指令的執行。(Identify the list of SQL statements that will be used by the application and only allow such SQL statements from the application, e.g. Select, Insert, Update, etc.)
  5. 在不需要使用 insert 或 update 的情形下使用 view 的方式來存取資料庫,可以應用在搜尋或是登入功能。(Use read-only views for SQL statements that do not require any inserts or updates, e.g. Search functionality or Login functionality.)
  6. 檢查輸入 (包含資料類型、長度、格式等) 並去除不必要的內容。(Sanitize the input by validating it in your code.)
  7. 使用參數化的查詢並避免使用動態式的查詢。以 Java 為例,應該使用 PreparedStatement 物件而非 Statement 物件。(Use parameterized queries instead of dynamic queries. For example, in Java, use Prepared Statement instead of Statement Object.)
  8. 採用合適的錯誤處理與記錄功能以確保資料庫發生錯誤時的訊息或其他技術資訊不會因此而洩漏。(Employ proper error handling and logging within the application so that a database error or any other type of technical information is not revealed to the user.)
  9. 選擇不易猜測的資料庫表格/欄位名稱。(Choose names for tables and fields that are not easy to guess.)
  10. 盡可能的使用 stored procedures。(Use stored procedures instead of raw SQL wherever possible.)

嚴格來說,第 7 點才是目前專門針對 SQL Injection 最主要也是最有效的控制措施。然而其他控制措施雖然並不是特別針對 SQL Injection 這類威脅,但是卻可以減少當系統發生問題時所產生的危害,因此也有其實施的效益。雖說如此,對於第 9 點與第 10 點我個人倒是有一些不同的看法。

首先針對第 9 點,雖然採用較難猜測的表格/欄位名稱可以減少攻擊者成功執行 SQL Injection 的機會,但是如果因此走向極端而將所有表格/欄位名稱改成無意義的名詞,那麼對於開發人員所造成的困擾可能遠大於其所帶來效益,在執行上必須小心謹慎。

而對於第 10 點我個人則採取完全相反的意見。雖然使用 stored procedures 確實可以增加 SQL Injection 成功的難度 (stored procedures 本身還是會遭受 SQL Injection 的攻擊),但是 stored procedures 的大量使用很容易使得系統的可移植性受到不良影響。更重要的是 stored procedures 將使得程式邏輯隱含在資料庫內部,對於系統功能的模組化往往是一大傷害。我這樣說並不是說 stored procedures 完全不可使用,而是 stored procedures 要不要使用、要使用到什麼程度,不應該從安全的角度來加以考量,而是應該回歸到業務與系統本身的需求。

除了這些要項之外,採用好的自動化工具 (不管是白箱或黑箱測試工具) 對避免 SQL Injection 的威脅也是目前相當有效的一種作法,值得需要系統化管理 SQL Injection 威脅的團隊加以評估。

 

相關連結:

2010年9月5日 星期日

[研究報告] IBM X-Force 2010

ibm_x_force IBM X-Force 上個月發表了 2010 年的年中報告,報告中有幾項重要趨勢值得特別注意:

  • 攻擊者使用更多的隱匿技術來進行攻擊,例如像是 JavaScript 混淆 (Obfuscation) 的手法,而這些技術已經對 IT 安全專家造成相當程度的困惱。
  • 被發現的安全弱點數量持續成長,與去年同期相比成長了 36%,創下歷史新高點。
  • 利用 PDF 的攻擊行為隨著攻擊手法的翻新持續增加。PDF 攻擊被大量採用的原因在於其攻擊目標為防禦能力較差的終端設備 (如個人電腦),一旦入侵成功就可以作為其他入侵手法的跳板。
  • Zeus botnet 持續對企業產生莫大的影響,而新版的 Zeus 甚至開始提供攻擊者更新的功能。

至於在網站應用程式安全方面,有下列幾個重要的現象:

  • Cross-site Scripting (XSS) 與 SQL Injection 依舊是主要的弱點類型。其中 SQL Injection 雖然於前次報告發表時呈現下滑的現象,但是在這次的報告中又再次上升,顯示 SQL Injection 的問題依舊需要善加處理。
  • 在網站應用程式平台 (Web Application Platforms) 方面,其弱點數量所佔的比例就高達所有弱點的 14%。進一步加以分析,其中僅 12% 為平台本身的問題,而高達 88% 的問題則來自於擴充元件 (plug-ins),顯見擴充元件的安全品質仍與平台本身有相當程度的差距。
  • 在終端設備部分,瀏覽器依舊是問題的主要來源。但是就如前述所言,PDF 的攻擊大幅成長並緊追在瀏覽器問題之後。
  • 以瀏覽器 (包含 plug-ins) 的分類來看, Firefox 與 IE 的弱點數量依舊佔了大多數。而 ActiveX 的弱點數量雖然成長幅度較不明顯,但是其弱點數量卻遠較瀏覽器本身更高。

對於完整報告有興趣的讀者可以在這裡加以下載。

相關連結:

2010年8月21日 星期六

[新聞時事] Network Solutions 的小工具被植入惡意程式,造成大規模的網站遭受感染。

Widgets1 根據前幾天的消息指出,來自臺灣的資訊安全廠商 Armorize 發現了在著名的主機代管業者 Network Solutions 中,有大量客戶的網站遭受到惡意程式的感染,並成為惡意程式散佈的平台。而根據 Armorize 的估算,受感染網站的數量可能高達五百萬個,創下新的歷史紀錄。此次感染的方式,據悉是透過一個已被植入惡意程式的小工具 (Widget),這個小工具名為 Small Business Success Index,是由 Network Solutions 所提供。此一小工具不但可以運作在 Network Solutions 客戶的網站中,也可以安裝在 Facebook, Blogger, Twitter, iGoogle, WordPress, LinkedIn, my Yearbook 等知名的服務平台上。目前官方的建議解決方案是將此一小工具先行移除,並對你的網站進行惡意程式的掃描,以避免繼續散佈惡意程式。而 Armorize 也特別指出這類針對主機代管業者的攻擊行為對駭客來說是可以讓惡意程式快速擴散的有效方法,因此類似的事情在未來將會越來越多,值得相關業者好好地重視。

 

相關連結:

About