接連看到三則資安新聞:

SQL Injection是老梗中的老梗,在資安界歷久彌新,但連資料庫MySQL的官方網站捅出這種簍子還真是諷刺。這也再次驗證: 不管你寫的是ASP、PHP還是JSP,連的是SQL、MySQL、Oracle、或是什麼怪DB,只要一個不小心,人人都可能變成害網站裸奔的北七。(再次呼龥,如果你的工作是寫與DB有關的程式,卻不知道什麼是SQL Injection,請發揮良心,即日起雙手打上石膏裝殘請長假,在搞懂它的殺傷力之前,別再寫半行Code)

再來看Comodo的憑證被盜用事件。Comodo是有名的的SSL憑證發行機構(Certificate Authority),CA自身的憑證被盜用,象徵惡意人士可假冒CA簽發特定網站的SSL憑證,由於是用真實的CA憑證所簽發具有真實CA的數位簽章背書,瀏覽器無從識別真假,唯一的補救之道是透過CRL(Certificate Revocation List)撤銷被冒名簽發的憑證,但這有賴於瀏覽器或接受憑證的程式主動取得CRL查驗憑證的有效性,若是程式偷懶省略了驗證步驟,就會誤信冒牌憑證,任由使用者連上惡意網站或被竊聽而不自知。舉個粗淺的例子,報導中提到mail.google.com也在受影響之列,如此駭客就可透過Man-In-The-Middle的攻擊手法,在使用者使用HTTPS連上mail.google.com時從中攔載竊聽,並使用假冒的mail.google.com SSL憑證再加密資料傳給使用者,若使用者的瀏覽器未進一步查驗假冒SSL憑證已被撤銷,則由使用者的觀點,使用HTTPS連上mail.google.com,傳回資料又經過有名CA,Comodo公司,簽發給mail.google.com網站的SSL憑證加過密,安全亳無瑕疵,事實上帳號、密碼、信件內容早已被看光光。(最近剛好有篇文章討論到類似的攻擊手法--不要錢的無線網路 -- 最貴)

掌控資安機制信任關鍵的CA居然發生此等管控疏失,令人搖頭,但有趣的事來了---一名伊朗駭客說:Comodo憑證被盜事件是我幹的! 依據該宣告內容,該名駭客是先入侵義大利一家SSL憑證經銷商InstantSSL.it的伺服器,取得完全控制權(FULL access)後找到一個TrustDll.dll,發現它是用C#寫出用專門與CA簽發憑證API溝通的程式庫,經過反組譯,居然找到該經銷商連線GeoTrust與Comodo所用的帳號密碼,GeoTrust的API URL不能連,但Comodo的URL與經銷商帳號是有效的。駭客先生很自豪他在沒有文件的情況下,很快摸索出了AutoApplySSL與PickUpSSL兩組API的規格,並成功寫出透過這兩個API簽發SSL憑證的工具程式。宣告裡一再強調 "我好強 我好快 我好威 我好猛" "But I did it very very fast."(就尊敬他為"好快哥"吧!) 並聲稱自己只有21歲,感覺上還稚氣未脫,不是那種太陽穴隆起,目露精光的神人~~ XD (iTHome報導中說反組譯後找到"Comodo執行長與資料庫的帳號與密碼"似乎與宣告描述不符。)

總觀本次好快哥盜發Comodo憑證事件:

  • PKI機制有無重大瑕疵? 
    看來還夠可靠(事實是目前也找不到更好的替代品),但CRL機制需要客戶端程式主動驗證才會發揮效果,可能會因程式疏忽產生漏洞。
  • Comodo有無重大缺失?
    不確定。因為好快哥並沒有說自製的憑證簽發程式是放在InstantSSL.it的主機上執行(反正他說有FULL access權限),或是透過Internet就能隨意簽發憑證。若為前者,Comodo應無過失;若是後者就大有問題,簽發憑證API不鎖定來源IP,代表任何人只要取得經銷商帳號就可以在星巴克用免費無線網路生一張憑證出來,顯然不安全。
  • 誰是頭號戰犯?
    薑!薑!薑!薑! InstantSSL.it公司在本案獲頒最佳豬頭奬且當之無愧。伺服器被人攻破,程式檔案被看光光,依推測該伺服器應有具備由程式機制簽發憑證的能力,在主機已被入侵的前題下,不管經銷商帳號密碼是被Hardcode在DLL中,還是加密後寫在config裡,不管程式是用C#、Java還是組合語言寫,只要主機控制權失守,被破解只是時間早晚問題。

在資安神人Gary Hoglund落難記裡,Anonymous發動鄉民進行DDoS的部分無險可守,看來只能無奈承受,但有趣的是,駭客只靠著假造一封信"我人在國外,有急事要連回公司,請打開防火牆,root密碼設成xxxx"的社交攻擊,就騙倒IT經理,當場敞開大門,恭迎駭客大軍入城。

這幾個例子再次突顯資安工作脆弱難守的可悲特質,整個體系中只要有任何一個環節破損、發生一點人為疏忽,都會全面潰堤失守,經年累月耗資千萬打造的資安長城照樣瞬間化為烏有。十萬行的程式裡有一個漏洞跟有一百個漏洞的下場相同;一百個Developer裡只要有一個豬頭,系統照樣會萬刧不復;CA對自己的防護再嚴,只要有一家經銷商出錯,一樣假憑證滿天飛;資安神人主政的公司,警覺性不足的IT主管一時糊塗,就搞得公司搖搖欲墜;任憑各個交易網站與資安廠商苦心經營,用心規劃、細心管控,只要有幾匹害群之馬鬧出幾次入侵洩密風波,社會大眾就會對電子交易、資訊系統安全頓失信任感,形成推廣深化的障礙。

只能說,在這場資安攻防戰中,不怕神一樣的對手,只怕豬一樣的隊友...

深自提醒自己,只要從事資訊業一天,千萬千萬不要當上資安豬頭。


Comments

# by Gary

有錯誤 CRL(Certificate Revocation List)

# by Jeffrey

to Gary, 謝謝指正。( 每篇文章都一定有錯字快成為本站防偽的特色了,暈! ~"~a )

# by dnalor

好文一篇. 不是挑剔, 但這一句..."由於是用真實的CA憑證所簽發"..., 不大正確. CA 簽發的數位憑證並不是用"CA 憑證"所簽發, 應是由 CA 使用其私鑰對簽發的數位憑證進行數位簽章. 而 CA 憑證是用於驗證該 CA 所簽發的數位憑證. 請您參考. p.s.駭客也把 CA 的私鑰放出來以資佐證. http://news.netcraft.com/archives/2011/03/29/comodo-hacker-releases-mozilla-certificate.html

# by dnalor

Oh, and "TrudtDll.dll" should be "TrustDll.dll", see line 46 of http://pastebin.com/DBDqm6Km

# by Jeffrey

to dnalor, 感謝你的指正與補充,"使用CA的私鑰加上數位簽章"的確較精準,已對內文做了修正。(因先前.NET X509Certificate程式物件的經驗,憑證中可以同時保含公私鑰,實際在寫程式時會從憑證中取出私鑰進行數位簽章,結果簡化描述為"使用憑證簽發",過於含糊,謝謝指正) 另TrustDll.dll筆誤也已校正。 由駭客釋出了假SSL憑證(addons.mozilla.org)的私鑰且被驗證一事(可用假憑證的公鑰驗證),算是證明了他的確是假造者(為該假憑證公私鑰的產生者),先前的聲明看來可信度更高了。

# by khcat

Comodo...Comodo... 總覺得好熟, 咦?是也有出AntiVirus和Firewall的那ㄧ家Comodo嗎? 茄~我要來把它移除了,反正也覺得難用~~

# by 路人

不怕神一樣的對手,只怕豬一樣的老闆...

# by 路人甲

請問一下大大,下載CRL 後,需要安裝嗎,因為我想透過CRL去檢查憑證是否有效,但是不知如何使用,所謂CRL Cache表示甚麼,還有CRL要如何每天自動更新,麻煩大大指點迷津?謝謝(我是使用.Net)

# by Jeffrey

to 路人甲,Windows內建的SSL機制會自動檢查CRL,預設也會自動更新,依我的理解,預設的運作模式已具一定安全性,在遇到不安全的SSL憑證時會警示或錯誤,通常不需要自己動手。由於每次檢查SSL憑證都去網路重掀CRL太沒效率,故Windows會將CRL存在CRL Cache一段時間以提升效率。如要強迫清除Cache重抓,可以參考: http://blogs.technet.com/b/pki/archive/2007/09/13/how-to-refresh-the-crl-cache-on-windows-vista.aspx

# by sslbuyer

CRL(憑證廢止清冊)是一個檔案,固定時間由CA廠商產製放在網路上(儲存庫)給大家參考! 如果要即時取得憑證廢止的狀態,可用OCSP的方式取得!

Post a comment