Microsoft Office scripting malware has become more and more common and aggressive lately as malware authors constantly develop new techniques...
The post ‘Banking’ Malware Dridex Arrives via Phishing Email appeared first on McAfee Blog.
Microsoft is on a roll with its cloud strategy. In the past two quarters, the software giant has posted triple-digit...
The post Office 365 Ascent Is Security Opportunity appeared first on McAfee Blog.
Speech to the Institute of Directors Breakfast by Ian Fletcher, Director, Government Communications Security Bureau
Cookie 是開發網頁應用程式很常利用的東西，它是為了解決 HTTP stateless 特性但又需要有互動而產生的。開發者想把什麼資訊暫存在用戶瀏覽器都可以透過 Cookie 來完成，只要資訊量不大於約 4KB 的限制就沒問題。在這樣的空間裡，可以放購物車內的暫存商品、可以儲存讀者閱讀記錄以精準推薦產品、當然也可以寫入一些認證資訊讓使用者能保持登入狀態。
Cookie 有一些先天上的缺點，在於資料是儲存在瀏覽器端，而使用者是可以任意修改這些資料的。所以如果網站的使用者身分認證資訊依賴 Cookie，偷偷竄改那些認證資訊，也許有機會能夠欺騙網站，盜用他人身分，今天就來談談這樣的一件事情吧！
問題與回報會想要聊這個議題，主要是因為最近很紅的宏碁雲端售票系統就是採用 Cookie 認證。上週在註冊該網站時看了一下 Cookie，發現該網站沒有使用 Session 機制的跡象，也就是單純利用 Cookie 的值來認證。
於是開始好奇認證主要的依據是什麼？從圖中可以看到 Cookie 值並不多，猜測該網站大概會是看 USER_ID、USER_ACCOUNT 來判斷你是哪個使用者，稍作測試後會發現有些頁面只依據 USER_ACCOUNT 的值來確認身分，而 USER_ACCOUNT 這個值其實就是使用者的身分證字號，也就是說任何人只要跟網站說我的身分證字號是什麼，網站就會認為你是那個身分證字號的使用者。利用這點設計上的小瑕疵，就可以竊取他人個資，更進階一點，甚至可以用來清空別人的志願單讓其他使用者買不到票。
發現這個問題後，決定通報 VulReport 漏洞回報平台，由該平台統一通知開發商。這是我第一次使用這個平台，對我而言這是一個方便且對整體資安環境有助益的平台。方便點在於，過去常常困擾於發現一些網站有設計上的疏失卻不知該不該通報，如果認識該網站的開發者倒是還好可以直接講，但對於其他不認識的，一來沒有明確窗口，二來礙於工作關係怕被認為是敲竹槓，所以影響不大的漏洞可能就放水流了。這樣放任其實不是一件健康的事情，漏洞在風險就在，有了這樣的回報平台至少可以告訴企業可能存在風險，自己也可以放心通報。事實上，對岸有類似的平台已經行之有年，最顯著的效果，就是對岸網站在 0 day 被揭露後能在一週左右全國修復，而以往可能好多年過去了漏洞還在。這真的能夠加速保護企業和使用者，很高興台灣也有了這樣的平台！
昨天早上收到了平台回報宏碁雲端售票已經修復的消息，既然已經修復且公開了，就順便講解這個問題的細節吧！希望其他開發者可以從中體會到攻擊者的思維，進而做洽當的防禦。
驗證及危害為了方便驗證解說這個問題，這邊特別用兩個不存在的身分證字號在宏碁雲端售票申請帳號，分別是 Z288252522 和 Z239398899。測試目的是登入帳號 Z288252522 後看看是否能利用上述 Cookie 問題讀取 Z239398899 的個資。
首先登入帳號 Z288252522，找到一個會回傳個資的頁面：
https://www.jody-ticket.com.tw/UTK0196_.aspx
此時的 Cookie 值如下
從圖中發現 Cookie 的值其實是經過加密的，這點在上面說明攻擊觀念時刻意沒有提及。把 Cookie 值加密是一種防止別人修改 Cookie 值的方式，攻擊者不知道 Cookie 值的內容，自然也無法修改了。
然而這樣做還是存在些微風險，一旦這個加解密方式被找到，攻擊者就得以修改 Cookie 內容，進而盜用別人身分。在本例中，若想憑著改變 Cookie 盜用別人身分其實可以不用花時間去解加密法，這裡有一個小 trick，我們從觀察中馬上就能發現所有 Cookie 值都是用同一套加密方式，而且其中 USER_EMAIL、USER_NAME 這些還是我們可以修改的值。這也意味著如果我們把姓名改成我們想要加密的身分證字號，伺服器就會回傳一個加密好的值給 USER_NAME。我們直接來修改姓名看看：
當姓名改成目標 Z239398899 時，Cookie 中的 USER_NAME 值就會改變成我們要的加密結果。耶！是一種作業不會寫找出題老師幫忙寫的概念 XD
接著直接把 USER_NAME 的值拿來用，複製貼上到目標欄位 USER_ACCOUNT 中，之後就是以 Z239398899 的身分來讀取網頁了。我們再讀取一次 https://www.jody-ticket.com.tw/UTK0196_.aspx 看看：
成功看到 Z239398899 的資料了！如此，就可以只憑一個身分證字號讀到他人的地址電話資訊，甚至可以幫別人搶票或取消票券。這個流程寫成程式後只要兩個 request 就可以嘗試登入一個身分證字號，要大量偷取會員個資也是可行的了。
說到這邊，也許有人會質疑要猜中註冊帳戶的身分證字號是有難度的，但其實要列舉出全台灣可能在使用的身分證字號並不困難，再加上宏碁雲端的硬體其實是很不錯的，事實也證明它能夠在短時間處理四千萬個請求系統仍保持穩定，只要攻擊者網路不要卡在自家巷子口，多機器多線程佈下去猜身分證字號效率應該很可觀！
建議原則這次的問題是兩個弱點的組合攻擊：
宏碁雲端售票為了效率和分流，使用 Cookie 認證是相當合理的設計，所以要解決這個問題，從第二點來解決會是最有效且符合成本的方式，怎麼改呢？推測原本的 SQL 語句應該類似這樣：
select * from USER where account=USER_ACCOUNT由於 USER_ACCOUNT 是身分證字號，容易窮舉，更嚴謹的作法可以多判斷一個 id，像是這樣：
select * from USER where account=USER_ACCOUNT and id=USER_ID從只需要告訴伺服器身分證字號就回傳會員資料，到變成需要身分證字號和會員編號同時正確才會回傳會員資料，至此，攻擊者已經很難同時知道別人的會員編號和身分證字號了，因此大大降低了被猜中的機率，增加了安全性。
Cookie 一直以來都是 Web Application Security 領域的兵家必爭之地，攻擊者無不絞盡腦汁想偷到或偽造它，前陣子舉辦的 HITCON GIRLS Web 課堂練習題第一題就是改 Cookie 來偽造身分，足見這個問題有多基本和重要。
關於 Cookie，這裡提供一點原則和概念供大家參考：
首先，Cookie 是存在客戶端的，所以有機會被看到、被竄改、被其他人偷走。基於這些原因，不建議在 Cookie 中儲存機敏資料，或是存放會影響伺服器運作的重要參數，需評估一下這些暫存資料被人家看到或修改是不是沒差，這是儲存的原則。如果權衡後還是要在 Cookie 中存放重要資料，那就需要對值加密避免被讀改，而且要確保加密的強度以及其他人是否能透過其他方法解析修改。最後，Cookie 最常被偷走的方式是透過 JavaScript，所以建議在重要的 Cookie 加上 HttpOnly flag 能有效的降低被偷走的機率。也來試著整理一下這一小段的重點：
沒想到信手拈來就是三不一沒有，前面再加個勾勾，感覺好像很厲害呢！
結論由於 Cookie 存在瀏覽器端，有被竄改的可能，所以如果網站使用 Cookie 認證就會有一些安全上的風險。本篇就以宏碁雲端售票為例，說明這種小疏忽可能會造成被盜用帳號的風險。開發者在面對使用者可以改變的變數一定要特別小心處理，做好該有的防護，還是老話一句：使用者傳來的資料皆不可信！只要掌握這個原則，開發出來的產品就能夠少很多很多風險！
行文至此，預期中是要再推廣一下漏洞回報平台，順便稱讚宏碁非常重視資安，修復快速，是良好的正循環。不過前兩天看到一些關於宏碁雲端售票的新聞時，上線發現此弱點仍未修復，這好像真的有點不應該，畢竟官方上週已經接收到通報，要修復這個弱點也只需一行判斷式…。能理解這次的弱點在短時間開發過程中很難被注意到，對於這樣一個一週不眠不休完成的售票網站，我其實也是給予滿高的評價，但如果官方能再增兩分對資安事件的重視，相信下次定能以滿分之姿呈現在使用者面前！
戴夫寇爾部落格停載了快兩個月，非常抱歉，讓各位常常催稿的朋友們久等了 <(_ _)>
今天就乘著全臺瘋買票的浪頭，來談談一些常被忽略的資訊安全小概念吧！
江蕙引退演唱會一票難求，隔岸觀了兩天火， 也忍不住想要當個鍵盤孝子。無奈運氣不好一直連不上主機，『Service Unavailable』畫面看膩了，只好看看暫存頁面的網頁原始碼，不看還好，一看我驚呆了！
（特別聲明：此流程中並無任何攻擊行為，該頁面是正常購票流程中出現的網頁）
在結帳網頁原始碼當中竟然看到了疑似資料庫密碼 SqlPassWord 在表單裡面！這件事從資安的角度來看，除了表面上洩漏了資料庫密碼之外，還有兩個我想講很久但苦無機會談的資安議題，分別是金流串接常見的弱點以及駭客的心理。藉著寬宏售票網頁洩漏密碼這件事情，順道與大家分享分享吧！
談台灣網站的金流串接在本篇的例子中，寬宏售票網頁表單出現了疑似資料庫密碼，這狀況就好像去銀行繳款，櫃檯給你一把鑰匙跟你說：『這是金庫的鑰匙，麻煩你到對面那個櫃檯把鑰匙給服務員，請他幫你把錢放進金庫裡面』。
是不是有點多此一舉，銀行本來就會有一份鑰匙，幹嘛要請你（瀏覽器）幫忙轉交？
如果今天壞人拿到了這把鑰匙，是不是只要繞過保全的視線，就可以打開金庫為所欲為？
類似的狀況也滿常發生在電子商務與第三方金流服務的串接上。
許多電子商務網站專注於商務，選擇將付款步驟委託第三方金流服務處理，一般常見的流程是這樣的：
如果現在有一個惡意使用者，他做了以下惡搞：
(聲明：為求精簡，電子商務與金流服務串接流程有經過簡化，有抓到精髓就好XD)
不管是寬宏售票出現密碼欄位還是上例電子商務網站的金流串接，最大的問題在於他們都相信使用者會正常幫忙轉交，即靠客戶端的瀏覽器來轉址傳值。要知道，利用瀏覽器轉址傳值是不可靠的，一來，重要的資訊就會被客戶知道，例如寬宏售票疑似洩漏資料庫密碼；二來中間的內容可以修改，例如修改訂單金額。另外，可能有人會發現到，在惡意使用者的步驟三裡面，電子商務網站竟然沒有確認付款金額是否正確，沒錯，這是會發生的事情，在過去經驗中，像這樣沒有比對付款金額的台灣系統比例還不少，這些疏忽都會造成企業很多成本損失，不可不注意。
台灣目前還滿常見到這種根據使用者傳來單據來收費的狀況，導致單據可竄改造成企業損失，某部分原因可以歸咎到早期第三方金流的範例都是這樣寫的，工程師也就直接延續這樣的寫法直到現在。以金流串接為例，比較好的處理方式有下面兩種：
以上兩種作法，將可以有效防止惡意使用者修改訂單金額。此外，建議電子商務網站在收到金流回傳的付款資訊後，能夠比對收取款項與訂單款項是否相符，如此雙重檢查，能大大避免惡意行為，減少企業處理惡意金流問題的成本。
談駭客心理很明顯的，寬宏售票洩漏密碼的狀況是工程師的小疏漏。在不知道資料庫確切位置的前提下，知道疑似資料庫密碼的東西確實也無法做什麼，頂多就是了解了一家公司制定密碼的策略。然而，看在駭客眼裡，這點疏失會代表著一個網站面對資安的態度。連顯而易見的問題都沒有注意，那後端程式應該也有可能出現漏洞。一旦駭客決定要攻擊這個網站，勢必會搬出比平常還要多的資源去嘗試，因為他們認為這個投資報酬率很高。
一般駭客基本上會不斷的從所看到的網頁資訊來調整自己攻擊的強度，如果他們不斷看到了奇怪的登入畫面：
或是防火牆的登入畫面
就很有可能會增加攻擊的力道。上面這種登入頁面就是就是一種常見的資訊洩漏，在今年台灣駭客年會的議程－「被遺忘的資訊洩漏」就提及了這類資訊洩漏在台灣是很普及的。注意，出現這樣的頁面並不意味著網站會有漏洞，只是網站容易因此多受到一些攻擊。反之，如果一個網站前端頁面寫的乾淨漂亮，甚至連 HTTP 安全 header 這種小細節都會注意到，駭客可能就會認為這個網站寫的很嚴謹，甚至連嘗試的慾望都沒有了。
一個經驗豐富的駭客，通常光看首頁就能夠判斷該網站是否可能存有漏洞，憑藉的就是這些蛛絲馬跡。為了不讓自家網站常被路過的惡意使用者攻擊，加強網頁前端的呈現、網頁原始碼乾淨有架構、沒有太多資訊洩漏，這些都是很好的防禦方法。
結論在使用最近熱門的寬宏售票網站時，我們發現網頁原始碼存在一些疑似密碼的資訊。從這件事情出發，我們分別延伸探討了兩個工程師應該注意的議題：
希望開發者看到上面這兩個議題有掌握到『別相信客戶端』、『駭客會因網站前端寫法不嚴謹而嘗試去攻擊』的重點，提昇自家網站的安全度吧！
最後說個題外話，身為一個工程師，我認為資訊系統該帶給世界的好處是節省大家的時間，而這次搶票卻讓無數人徹夜排隊或守在電腦前不斷的『連不上、買票、失敗』循環。這也許能夠賺到大量的新聞版面，最終票也能全部賣光，但想到台灣有數十萬小時的生產力浪費在無意義的等待上，就覺得這個系統好失敗。現在的技術已經可以負荷這樣大規模的售票，KKTIX 甚至可以一分鐘處理 10 萬張劃位票券！世界在進步，過去的技術也許就該讓它留在過去。有人說：『真正幸福的人：不是搶到票，是可以像江蕙一樣選擇人生』，希望我也可以變成一個幸福的人，可以選擇一個不塞車的售票系統。
From the Heartbleed bug to large-scale (and highly publicized) data breaches, Shellshock to mobile threats—2014 did not leave us wanting...
The post 2014: Security Year in Review appeared first on McAfee Blog.