Aggregator

Recently, the McAfee Advanced Exploit Detection System (AEDS) has delivered some interesting RTF files to our table. These RTFs have...

The post Dropping Files Into Temp Folder Raises Security Concerns appeared first on McAfee Blog.

Review of the agencies in the core New Zealand Intelligence Community (NZIC), Unclassified Summary, July 2014.

過去談到網站安全，通常會使用防火牆或 IDS 進行防護。但近年來網站安全議題都是以網頁應用程式的漏洞居多，無法單靠防火牆阻擋。以 OWASP Top 10 2013 的第一名 Injection 而言，多半是程式撰寫方法不嚴謹所造成，因此才有了網頁應用程式防火牆 (Web Application Firewall, WAF) 的出現。

有了 WAF 就是萬靈丹了嗎？就算有各種資安設備，但缺乏安全的設定，有的時候反而會讓系統陷入安全風險中。我們就以 Reverse Proxy 或 WAF 設備來探討不佳設定帶來的安全風險。

以常見的 mod_proxy 搭配 mod_security 的方案來看，通常使用 Reverse Proxy 或 Transparent Proxy 為其架構，透過 Proxy 的方式在 Client 與 Web Server 之間，對 HTTP Request / Response 進行過濾；以 HTTP Request 為例，當 WAF 偵測到 Client 端的請求中有 SQL Injection 語法時候，將會阻斷這個連線防止駭客攻擊。

在這種架構下的 WAF 看似對後端的伺服器多了一份保障，但也並非完美。其問題是後端的 Web Server 在透過 WAF 存取的情況下，無法得知來自 Client 端的來源 IP，相反的 Web Server 能看到的 IP 都將是 WAF 的 IP (REMOTE ADDR)，在這種情況下可能造成 Client 端可以存取受 IP 來源限制的系統。延伸閱讀：如何正確的取得使用者 IP？。

以下圖為例，網站本身只允許 192.168.x.x 的網段連線，如果今天 Client IP 是 1.1.1.1，將無法存取該網站。

但在有建置 WAF 的架構之下，Client 透過 WAF 存取網站，網站得到的 IP 會是 WAF 的 IP：192.168.1.10，因此允許連線，Client 因而取得原本需在內網才能存取的資料。

我們以常見的 Web Server 整合包 XAMPP 為例，在預設的 http-xampp.conf 設定檔中限制了一些管理頁面只能由 Private IP 存取，如 /security 、 /webalizer 、 /phpmyadmin 、 /server-status 、 /server-info 等，此時 WAF 的 IP 若為 Private IP，依 XAMPP 預設設定，WAF 將可以存取這些受 IP 限制的資源，當 WAF 存取完資源後又將內容回傳給 Client 端。

http-xampp.conf 預設設定

如果照著預設的設定，以現成的案例來看，能夠存取 Apache Server 的系統狀態，其中可以看到網站所有連線以及 URI 等資料。

並且可以直接讀取 phpMyAdmin 介面，並且至資料庫中新增、修改、刪除資料，甚至直接上傳 webshell 進入主機。

XAMPP 也內建了網站記錄分析工具 webalizer，透過這個介面可以知道網站所有進入點的流量、統計數據等。

如果建置了 WAF，有關 IP 的設定必須要從 WAF 支援的 HTTP Header 中取出使用者的 IP (REMOTE_ADDR)，才能讓原本網站的 IP 限制生效。在這種設定錯誤或是對 WAF 架構不瞭解的情況下，WAF 反而成為駭客繞過 Private IP 限制的跳板，就如同為駭客開了一個後門。因此在使用資安設備時，必須瞭解其架構。別讓資安設備、安全機制，反而使得伺服器更不安全。

Not all hacking requires code-cracking programmers who can slip through complex algorithms. No, sometimes all you need to do to...

The post The Surprisingly Simple Google Maps Attack That Shut Down a Business appeared first on McAfee Blog.

今天又有不怕死的人寄來釣魚信了，這次是騙取 Apple ID。讓我們來看看這封信，其中內容有非常多破綻，也已經被 Gmail 直接定為 Spam 了，非常可憐。除了信件之外，釣魚的網頁本身也很值得我們借鏡，讓我們來看看這次的釣魚郵件案例。

先來談談要如何判別釣魚信呢。我們可以從四個要素來看：

1. 標題
2. 寄件者
3. 內文
4. 連結

首先，這封信的標題非常假，一般來說公司不會使用這類標題，這種判斷比較需要經驗。釣魚信件會使用非常聳動、吸引你去做動作的標題。例如常見的「你的帳號遭到停用」、「更換帳號資訊通知」等。點下連結就會帶你去假造的頁面騙你輸入密碼，千萬別傻傻當真。

寄件者通常是釣魚信一定會加強假造的部分，利用官方存在的信箱或是他人的信箱寄信，加強你的信任。不過需要特別注意的是：

寄件者的欄位是可以假造、隨意填寫的，千萬不要直接信任。

以這封信為例，寄件者「[email protected]」是不存在的。當然這個欄位可以假造，但連假造都錯，實在是非常不用心。

信件的內文就是精華了，要怎麼做出一封很像官方的信件，又要誘使人去點選，實在是一門藝術。精心設計的釣魚信、社交工程、APT 郵件，通常都會針對受害者客製化，調查身邊的社交圈、常談的話題、常用的服務、會點擊的郵件，來製造一個一定會中獎的信件。

當然很多時候攻擊者調查不足，還是會出現蛛絲馬跡的。例如來自中國的惡意郵件，常會出現「尊敬的用戶您好」這種在台灣人眼中看了很彆扭的詞彙。如果出現了不常見的用詞，就非常有可能是一個假造的惡意郵件，千萬不要傻傻的點選連結或附件。

再回頭來以這封信為例，最大的破綻除了非制式的內文之外，就屬署名了。明明是假造「Apple Customer Support」的來信，最下面卻簽署「Microsoft Privacy and cookies Developers」，有沒有搞錯？可以再用點心嗎？

最後的重點就是信件中的釣魚連結了，通常這個連結會帶你前往一個長得跟官方網站一模一樣的登入頁面，騙你輸入帳號密碼登入來竊取。在點選超連結之前，一定要先看一下這個連結前往的位置是不是官方的位置，例如是 Apple 的信件通常就會是前往 Apple.com 自己的網域名稱。當然更要特別注意的是假造的網域名稱，例如使用「App1e.com」來偽裝成「Apple.com」，也是非常常見的。

這封信中使用了最不用心的用法，就是直接拿釣魚網站的 URL 來當連結，一來長得跟官方網域根本不像，二來落落長的連結，到底是想要騙誰點選呢？

收到惡意郵件、釣魚郵件，一定要好好看信件的標頭檔（Header）。裡面通常可以看到攻擊者發信的來源，例如是自己架設的發信伺服器或者是使用肉雞來發信。

信件標頭最重要的就是「Received」這個部分，要由下往上閱讀。從這邊我們可以看到信件的流向，從攻擊發起者到發信伺服器，中間經過其他伺服器的轉送，最後到收到釣魚信件的郵件伺服器。因此從最下面的 Received 位置，我們可以知道攻擊者是從「[email protected]」來寄送信件的，因此 cloud.httpdns.co 很有可能就是攻擊者的伺服器，或者是被駭來發信的伺服器。

如果覺得信件的標頭太長難以閱讀，可以利用 Google 提供的工具「Google Apps Toolbox - Messageheader」。只要把信件的標頭貼上，他就會自動分析信件的流向，如下圖。

接著我們來看一下釣魚頁面。通常「正常」的釣魚頁面都會做得跟官方一模一樣，因為通常攻擊者都會直接把官方網站上面的 HTML 直接下載下來修改。如果有做得不像的，就真的是太不用心的攻擊者。

我們可以看到這個釣魚頁面做得非常像，上面要你輸入帳號、密碼、姓名、生日、信用卡號等資訊，非常惡劣。唯有網址實在是太假，希望沒有人眼拙真的以為這是 Apple 的網站。

秉持的資安研究員的好習慣，我們把網址子目錄去掉，看看網站的根目錄長什麼樣子，結果讓人跌破眼鏡。

釣魚網站也請你注重安全啊！這個網站大剌剌的開著目錄索引，讓我們可以看到網站上的各個目錄、檔案。除了 Apple 的釣魚網頁之外，甚至有釣魚網頁的原始碼「connect-info.zip」，更有著其他釣魚網頁在同個站上。

既然可以瀏覽，那我們來看看釣魚網頁的原始碼寫得怎樣。抓下來解開之後會看到完整的釣魚網頁，以及接收受騙人資料的主程式「Snd.php」。

釣魚網頁的程式寫得非常簡單，僅把網頁上接收到的被害人資料、IP，寄送到他的信箱「 [email protected] 」，寄送完畢後會自動導向到官方的頁面偽裝。

如果釣魚網頁寫得不好，甚至我們有機會可以攻擊他釣魚網頁上的漏洞，直接取得主機的權限，解救世人。從原始碼我們一目了然釣魚網頁的行為、寫法，也可以尋找有無攻擊的機會。

釣魚攻擊最早從 1995 年就開始盛行，一直到快 20 年後的今天，都還是一個非常簡單又有效率的攻擊手法。收到郵件千萬別傻傻的輸入自己的個資、帳號密碼，仔細看一下攻擊者的破綻，別讓他得逞了。

如果有發現疑似釣魚網站，又無法確認，可以到 PhishTank 來查查看，找到釣魚網站也可以投稿一下幫助其他人！

很多網站都會有偵測使用者 IP 的功能，不管是判斷使用者來自哪邊，或者是記錄使用者的位置。但是你知道嗎？網路上大多數的教學全部都是「錯誤」的。正確的程式寫法可以確保知道訪客的 IP，但是錯誤的寫法卻可能讓網站管理者永遠不知道犯罪者的來源。

這次我們單就偵測 IP 的議題來探討各種錯誤的寫法。

我們先來看一下網路上的教學，讓我們 Google 找一下「PHP 取得 IP」，就可以看到許多人熱心的教學，我們隨意挑一個常見的教學來看看。

以 PHP 為例：

以 ASP.NET 為例：

這是一個很基本的寫法、很正確的想法，如果 HTTP Header 中包含「Client-IP」，就先以他當作真實 IP。若包含「X-Forwarded-For」，則取他當作真實 IP。若兩者都沒有，則取「REMOTE_ADDR」變數作為真實 IP。因為當使用者連線時透過代理伺服器時，REMOTE_ADDR 會顯示為代理伺服器 Proxy 的 IP。部分代理伺服器會將使用者的原始真實 IP 放在 Client-IP 或 X-Forwarded-For header 中傳遞，如果在變數中呼叫則可以取得真實 IP。

但是你知道嗎？網路上 80% 的教學寫法全部都是「錯誤」的。

為什麼這樣說呢？請大家記得一件事情：「任何從客戶端取得的資料都是不可信任的！」

「X-Forwarded-For」這個變數雖然「有機會」取得使用者的真實 IP，但是由於這個值是從客戶端傳送過來的，所以「有可能」被使用者竄改。

舉例來說，我寫了一個小程式，偵測這些常見的 HTTP Header 判斷 IP。並且使用 Burp Suite 這個工具來修改 HTTP Request。

頁面上顯示目前我目前的 IP「49.50.68.17」，並且其他的 header 是空的。但如果我今天使用 Burp Suite 之類的 Proxy 工具自行竄改封包，加上 X-Forwarded-For 或是 Client-IP header：

修改完畢之後，再到原本的顯示 IP 介面，會發現網頁錯將我竄改的 header 當作正確的資料填入。

使用代理伺服器的情況下，HTTP Header 會有不同的行為。例如 Elite Proxy 如何隱藏客戶端的真實 IP。以下簡單介紹幾種常見的狀況給各位參考。

• REMOTE_ADDR: 客戶端真實 IP
• HTTP_VIA: 無
• HTTP_X_FORWARDED_FOR: 無

• REMOTE_ADDR: 最後一個代理伺服器 IP
• HTTP_VIA: 代理伺服器 IP
• HTTP_X_FORWARDED_FOR: 客戶端真實 IP，後以逗點串接多個經過的代理伺服器 IP

• REMOTE_ADDR: 最後一個代理伺服器 IP
• HTTP_VIA: 代理伺服器 IP
• HTTP_X_FORWARDED_FOR: 代理伺服器 IP，後以逗點串接多個經過的代理伺服器 IP

• REMOTE_ADDR: 代理伺服器 IP
• HTTP_VIA: 無
• HTTP_X_FORWARDED_FOR: 無 (或以逗點串接多個經過的代理伺服器 IP)

在我們測試的過程中，通常我們都會讓瀏覽器自帶 X-Forwarded-For，並且自行填入 IP。常常會發現有一些網站出現如下的警告…

有沒有搞錯？「上次登入位置 127.0.0.1」？沒錯，這個是知名論壇套件「Discuz!」的功能，抓取 IP 的功能也是不安全的寫法。也有這樣的經驗，之前開著 X-Forwarded-For 的 header 到一些網站，竟然直接出現管理者後台！

你覺得只有一般人撰寫的程式會有這樣的問題嗎？其實大型網站也可能會有類似的問題。這樣的寫法可能會讓管理者永遠抓不到犯罪者的真實 IP，甚至攻擊者可以竄改 header 插入特殊字元，對網站進行 SQL Injection 或者 Cross-Site Scripting 攻擊。

「任何從客戶端取得的資料都是不可信任的！」

請各位開發者、管理者記住這個大原則，雖然這些 Request Header 可能含有真實 IP 的資訊，但是因為他的安全性不高，因此我們絕對不能完全信賴這個數值。

那我們該怎麼處理呢？我的建議是記錄所有相關的 header 欄位存入資料庫，包含「REMOTE_ADDR」「X-Forwarded-For」等等，真正有犯罪事件發生時，就可以調出所有完整的 IP 資訊進行人工判斷，找出真正的 IP。當然從 header 存入的數值也可能會遭到攻擊者竄改插入特殊字元嘗試 SQL Injection，因此存入值必須先經過過濾，或者使用 Prepared Statement 進行存放。

可以參考的 HTTP Header（依照可能存放真實 IP 的順序）

• HTTP_CLIENT_IP
• HTTP_X_FORWARDED_FOR
• HTTP_X_FORWARDED
• HTTP_X_CLUSTER_CLIENT_IP
• HTTP_FORWARDED_FOR
• HTTP_FORWARDED
• REMOTE_ADDR (真實 IP 或是 Proxy IP)
• HTTP_VIA (參考經過的 Proxy)

「駭客思維」就是找出網站任何可能竄改的弱點，從網頁上的元素到 HTTP Header 都是嘗試的對象。因此身為防禦者一定要清楚的知道哪些數值是不能信賴的，不要再參考網路上錯誤的教學了！

還記得在上一篇文章 Zone Transfer CVE-1999-0532 - 古老的 DNS 資安議題中我們曾提到，若對全世界的網站進行 zone transfer 檢測恐怕會有更多驚人的案例嗎？正好 Alexa 提供了全球排名前一百萬名的網站資料，我們就以這份資料為基礎來做一些統計吧！

• 79133，約佔所有受測目標的 8.014%
• 上述 domain 的所有 zone file 共含有 22631804 筆 DNS 記錄

由於在 Alexa Top 1M 中有許多資料是重複的 domain，另外也有些資料是 IP，在本次的檢測當中都不列入計算，因此受測 domain 總數僅有 987447 個，而非一百萬個。另外，本次掃描為求快速犧牲了部分準確率，因此實際數量應比 79133 更多。

• 全世界 TLD 總數：567
• 受測目標的 TLD 總數：316，佔全世界總數的 55.73%
• 有 zone transfer 問題的 TLD 總數：220，佔受測目標的 69.62%

目前 TLD 總數的數據取自於 Internet Assigned Numbers Authority (IANA)，不了解 TLD 是什麼的人可以參考這篇維基百科文章。

有趣的是，連一些新的 TLD 都有 zone transfer 問題，例如 .technology、.museum 等等，可見這真的很容易被大家忽略～

• Transferable domain in this TLD：在特定 TLD 中，有多少 domain 可任意執行 zone transfer
• Same TLD in Alexa top 1M：特定 TLD 在本次 987447 個受測目標中所佔的數量
• Percentage of same TLD in Alexa top 1M：特定 TLD 在 Alexa top 1M 內所有同樣 TLD 所佔的百分比（例：.com 即為 35230 / 527203 = 6.68%）
• Percentage of all transferable domain：某特定 TLD 可任意執行 zone transfer 的數量在本次所有可任意執行 zone transfer 所占的百分比（例：.com 即為 35230 / 79133 = 44.52%）

由於原始數據太多，因此本文僅列出前 25 名。

.tw 網域排第二十一名，幸好這次不是世界第一了，否則又是另類的台灣之光。

• Number of domain：該台 name server 有多少 domain 可任意執行 zone transfer

由於原始數據太多，因此本文僅列出前 25 名。

可執行 zone transfer 且不重複的 namer server 共有 53830 個

• 有 7939172 個不重複的 IP 位址
• 在全部 IP 位址中，有 704638 個是私有 IP 位址
• 在私有 IP 位址中，有 598443 個是 10. 開頭，佔所有 IP 位址的 7.538%，佔私有 IP 位址的 84.929%
• 在私有 IP 位址中，有 66270 個是 172.16~31 開頭，佔所有 IP 位址的 0.835%，佔私有 IP 位址的 9.405%
• 在私有 IP 位址中，有 39925 個是 192.168 開頭，佔所有 IP 位址的 0.503%，佔私有 IP 位址的 5.666%

以下選出一些常被入侵者當作攻擊目標的 subdomain 來計算在 22631804 筆 DNS 記錄中分別各佔了幾筆，每個 subdomain 共有兩個統計結果，逗號左邊的統計結果代表以該 subdomain 開頭的 DNS 記錄，例如 git.devco.re。逗號右邊的統計結果則將前後有數字的 subdomain 也一併計入，例如 dns01.devco.re、01dns.devco.re、0dns001.devco.re 等等。

• 版本控制

  git: 583, 626

  gitlab: 138, 138

  svn: 1552, 1669

  subversion: 71, 72

  cvs: 284, 330

  hg: 115, 331

  mercurial: 18, 19

• 開發與測試

  test: 14691, 20001

  dev: 8300, 10959

  stage: 1329, 1628

• 資料庫

  db: 1190, 2537

  database: 150, 302

  sql: 2209, 3298

  mysql: 4045, 4998

  postgre: 11, 11

  redis: 21, 33

  mongodb: 6, 42

  memcache: 13, 72

  phpmyadmin: 455, 485

• 後台管理

  manager: 188, 222

  staff: 481, 542

  member: 331, 376

  backend: 153, 177

• 線上服務相關

  api: 1871, 2097

  search: 1469, 10987

  pic: 178, 293

  img: 1775, 3517

  service: 779, 959

  payment: 225, 238

  cache: 373, 627

• 私有服務

  erp: 275, 318

  eip: 69, 80

  log: 227, 414

  nagios: 636, 736

  mrtg: 458, 565

  cgi: 194, 261

  dns: 2634, 9085

  ns: 12198, 63431

  ftp: 197414, 199481

  blog: 5074, 5446

  mail: 238742, 254515

  email: 2484, 2706

  webmail: 24164, 25067

  owa: 798, 888

  autodiscover: 30462, 30466

  vpn: 3152, 7025

  sso: 398, 462

  ssl: 709, 932

  proxy: 1464, 2215

  cms: 1320, 1696

  crm: 1152, 1301

  forum: 3654, 4037

究竟經由 zone transfer 所得到的資料可以拿來做什麼？對於攻擊者而言，主要有以下三種利用方式：

• 建立字典檔：入侵者可利用上述資料建立一份最常見的 subdomain 的字典檔，未來利用此字典檔進行掃描時可節省許多時間成本，快速檢測某間公司有哪些 subdomain
• 旁敲側擊：入侵者可觀察哪些 name server 有開放 zone transfer 查詢，接著去蒐集還有哪些公司使用同一台 name server，再進一步掃瞄那些 domain。那些 domain 也許不是大公司、不在 Alexa top 1M 內，但你無法確保它永遠不會是入侵者的攻擊目標。
• 結合 0day 進行攻擊：當某個第三方套件被揭露 0day 弱點時，擁有上述資料的人就可以迅速執行大範圍的攻擊。例如這幾年正夯的 Rails 在去年被爆出有 Remote Code Exection 弱點 CVE-2013-0156，入侵者可直接對所有 redmine 進行攻擊。Juniper VPN 在今年也被揭露 Remote Code Execution 弱點，入侵者可找尋所有 vpn subdomain 來進行嘗試。

在上次我們提起這個古老的弱點後，已經有部分台灣企業陸續將此問題修復，但許多台灣企業仍有此問題而不自知，也許過陣子我們直接做個 Wall of Shame 條列出哪些廠商有問題會讓大家比較有感 :p

不過也別急著笑台灣企業，許多國際級的大網站同樣也有此類問題。由此可見資安問題不分新舊、不分國內外，總是容易被大家忽略，等到不知不覺被入侵者捅了重重的一刀後，才驚覺這許多的小弱點一旦串起來是多麼的可怕。你，開始有所警覺了嗎？

上次我們提到了 Content-Security-Pilicy，這次我們來聊聊同樣是為了防禦 XSS 而生的另一個技術。

Cookie 的概念雖然早在 1994 年就由 Netscape 的工程師 Montulli 提出，但當時仍未有完善的防護機制，像是 HttpOnly、Secure 等規範都是後來陸續被提出，直到 2011 年 4 月才在 RFC 6265 中正式定案。而其中的 HttpOnly 是專門為了抵禦攻擊者利用 Cross-Site Scripting (XSS) 手法來盜取用戶身份，此項 Cookie 防護設定應該是在 HTTP Headers 系列文中最廣為人知的項目。

說明 HttpOnly 主要作用之前，先談談 XSS 最常見的利用方式。XSS 攻擊早在 1990 年就被發現，此攻擊手法最常見的利用方式是存取使用者的 cookie 來獲得一些機敏資料。像是存取 session cookie 即可盜用使用者的身份（關於 session 的重要性，可以參考我們部落格的另一篇文章 HTTP Session 攻擊與防護），如果在 cookie 中記錄了其他機敏資訊，也可能會一併遭竊。因此若能阻止攻擊者存取帶有敏感資料的 cookie，就能減少 XSS 對使用者的影響，因而催生了 HttpOnly 機制。

當 cookie 有設定 HttpOnly flag 時，瀏覽器會限制 cookie 只能經由 HTTP(S) 協定來存取。因此當網站有 XSS 弱點時，若 cookie 含有 HttpOnly flag，則攻擊者無法直接經由 JavaScript 存取使用者的 session cookie，可降低使用者身份被盜用的機率。早期有些瀏覽器未完整實作 HttpOnly 所有功能，因此攻擊者仍可透過 XMLHttpRequest 讀取 cookie，但最近幾年各大瀏覽器也陸續阻擋了這個方式。因此 HttpOnly 可有效降低 XSS 的影響並提升攻擊難度。目前瀏覽器的支援列表如下：

其他瀏覽器支援列表以及各家程式語言使用 HttpOnly 的方式可參考 OWASP HttpOnly。

以下使用 PHP 程式碼為例：

在上圖中可看到 PHPSESSID 已成功被 JavaScript 存取，這也意味著網站有 XSS 弱點時，使用者的身份有較高的機率被盜用。為了使用 HttpOnly 進行防護，讓我們將 PHP 程式碼修改如下：

我們可以使用畫面中右上角的 Chrome Edit This Cookie 套件 看到 HttpOnly 已經被勾選（如紅框處），並且 PHPSESSID 已無法被 JavaScript 存取，不存在於 HTML 中。

目前 PHP 官方的教學是用 session_set_cookie_params 這個 function，可參考官方網頁的這篇說明

由於 HttpOnly 的使用方式較簡單，因此僅列舉幾個站台的使用結果圖片給大家參考，就不另外多做說明囉！

• T客邦 (www.techbang.com)，有設定 HttpOnly

• 愛料理 (icook.tw)，有設定 HttpOnly

• Mobile01 (www.mobile01.com)，未設定 HttpOnly

• Giga Circle (tw.gigacircle.com)，未設定 HttpOnly

HttpOnly 是存在已久的技術，但在我們系列文第一篇的統計當中，採用的比例仍然偏低。如同之前我們提及的 Zone Transer 問題，即使一項資安技術或資安議題存在很久，也需要大家持續關注。

但即使採用了 HttpOnly，也僅能防止惡意人士不正當存取 cookie，無法防禦其他的 XSS 攻擊方式，例如將使用者導向至釣魚網站騙取個資、導向至惡意網站植入後門、置換網頁外觀等等。同時未來仍有可能出現新的 XSS 攻擊手法，因此千萬別因設定了 HttpOnly 就掉以輕心，誤以為不會再被 XSS 手法侵害企業利益或用戶資料，仍然必須謹慎檢查每一個系統輸出輸入點，以避免未來因上述影響導致用戶或企業蒙受損失。

(本篇最後更新時間：2014.6.9 15:40 pm)

OpenSSL 團隊於 6/5 修補了六項安全漏洞，SANS 在這篇文章中整理了這幾個漏洞的摘要，這裡截圖表格如下：

其中 CVE-2014-0224、CVE-2014-0195 兩項被列為 Critical，我們分別來看看這兩個弱點到底造成了什麼危害。

加密通訊被視為預防中間人攻擊的解法之一，利用 SSL 協定防止竊聽、竄改傳輸資料是一種常見的方式。然而 OpenSSL 這次出現在 ChangeCipherSpec（更改密鑰規格）的設計瑕疵，讓攻擊者有辦法解密所有通訊內容，讓加密保護徹底失效。

該弱點原理是 OpenSSL 伺服器端在實作 handshake 時並未檢查訊息的順序（嚴格來說是 ChangeCipherSpec 的順序），所以攻擊者可以提前送出 ChangeCipherSpec 訊息，使伺服器在還未初始完畢的狀態先去做 ChangeCipherSpec 的動作，最終造成加解密可解的狀況，是以此弱點稱之為 CCS Injection。更多的細節請參考原通報者 Masashi Kikuchi 的部落格，佐以這篇附程式碼的解說，OpenSSL github 上關於 CVE-2014-0224 的 fix 也可以幫助了解。

所有靠 OpenSSL 保護連線的應用服務都需要注意。又尤其是銀行、金流服務這些連線中存在金融資訊的服務，若不注意會造成信用卡卡號洩漏，網路銀行被盜用。經過實際檢測，目前仍有銀行單位和金流單位使用有問題的 OpenSSL 版本。消費者需要特別注意，在使用前也可透過下面小工具來輔助檢查自己所使用的服務使否存在風險：

• Tripwire 提供的小程式 (python)
• 測試網站 http://ccsbug.exposed/

慶幸的是，此弱點只發生在用戶端及伺服器端皆使用有問題 OpenSSL 版本的狀況下。一般來說，桌面端的瀏覽器都不是使用 OpenSSL，所以一般使用者可以稍微安心。問題比較大的是 android 使用者，android 內建 OpenSSL，許多 app 呼叫它來進行加密傳輸，所以建議 android 用戶在 google 釋出更新前，不要使用手機連線到有問題的服務，或使用自帶 SSL 的 app，例如：firefox、最新版 Chrome (35.0.1916.141)…。

另外，若使用者常用到一些加密連線服務，例如 VPN，請自行注意所使用軟體是否使用 OpenSSL，以免受到 CCS Injection 的影響。

最後說個題外話，原來現在發表漏洞還要為漏洞出張圖，在 Hacker News 原討論串的這篇回應，就有人說：『這個漏洞有 logo 嗎？如果沒有我就不打算認真看待它！』XD

OpenSSL 在處理 DTLS 訊息上，為了避免 IP fragmentation，所以做了一些處理機制，這個處理機制並沒有好好驗證 DLTS ClientHello 中的 fragment 長度（嚴格來說是在正確的位置做驗證），若攻擊者發送一個很長的 fragment，能造成緩衝區溢位攻擊。更多的細節請參考這篇文章。

比較有趣的是那段出問題的程式碼是一位有名德國工程師 Robin Seggelmann 寫的，有名的點在於上次非常嚴重的 Heartbleed 事件也是他寫的 code XD

使用 OpenSSL 且有用到 DTLS 的服務提供者，通常是 VoIP、WebRTC、VPN 這類服務，這個風險有可能會造成伺服器被入侵。

除了上面所提及兩個嚴重風險，這次的更新也同時修復了幾個 DOS 的弱點，強烈建議伺服器端更新。 請確認 OpenSSL 已經更新到下面版本，並且有重新啟動讓其生效。

• OpenSSL 0.9.8za
• OpenSSL 1.0.0m
• OpenSSL 1.0.1h

更新資訊依據所用的系統分別如下：

• Ubuntu
• Debian
• FreeBSD
• CentOS
• Red Hat 5
• Red Hat 6
• Amazon Linux AMI

這次 OpenSSL 做了數個安全性的更新，雖然不若之前 Heartbleed 那麼嚴重，但卻也讓使用者暴露在風險中。建議有使用 OpenSSL 都應該更新到最新版本，尤其是一些大型的銀行及金流服務，更應儘速更新。

大家還記得四月份的 OpenSSL Heartbleed 事件嗎？當時除了網站本身以外，受害最嚴重的就屬 VPN Server 了。國內外不少駭客不眠不休利用 Heartbleed 漏洞竊取 VPN Server 的管理者 Session Cookie，運氣好的話就可以直接登入大企業的內網。

但是，其實這樣的風險是可以避免的，今天我們以開發者的角度來談談 Session 的攻擊與防護。

在談 Session 之前，我們要先瞭解 Cookie。你知道網站是如何辨識我們的身份嗎？為什麼我們輸入完帳號密碼之後，網站就知道我們是誰呢？就是利用 Cookie。Cookie 是網站在瀏覽器中存放的資料，內容包括使用者在網站上的偏好設定、或者是登入的 Session ID。網站利用 Session ID 來辨認訪客的身份。

Cookie 既然存放在 Client 端，那就有被竊取的風險。例如透過 Cross-Site Scripting（跨站腳本攻擊，又稱 XSS），攻擊者可以輕易竊取受害者的 Cookie。如果 Cookie 被偷走了，你的身份就被竊取了。

我們可以用一個譬喻來表示：你加入了一個秘密俱樂部，填寫完會員資料後，得到了一張會員卡。之後只要憑這張會員卡，就可以進入這個俱樂部。但是隔天，你的會員卡掉了。撿走你會員卡的人，就可以用你的會員卡進入這個秘密俱樂部，因為會員卡上沒有你的照片或是其他足以辨識身分的資訊。這就像是一個會員網站，我們申請了一個帳號（填寫會員資料加入俱樂部），輸入帳號密碼登入之後，得到一組 Cookie，其中有 Session ID 來辨識你的身分（透過會員卡來辨識身分）。今天如果 Cookie 被偷走了（會員卡被撿走了），別人就可以用你的帳號來登入網站（別人用你的會員卡進入俱樂部）。

Session 攻擊手法有三種：

1. 猜測 Session ID (Session Prediction)
2. 竊取 Session ID (Session Hijacking)
3. 固定 Session ID (Session Fixation)

我們以下一一介紹。

Session ID 如同我們前面所說的，就如同是會員卡的編號。只要知道 Session ID，就可以成為這個使用者。如果 Session ID 的長度、複雜度、雜亂度不夠，就能夠被攻擊者猜測。攻擊者只要寫程式不斷暴力計算 Session ID，就有機會得到有效的 Session ID 而竊取使用者帳號。

分析 Session ID 的工具可以用以下幾種

1. OWASP WebScarab
2. Stompy
3. Burp Suite

觀察 Session ID 的亂數分布，可以了解是否能夠推出規律、猜測有效的 Session ID。

Ref: http://programming4.us/security/3950.aspx

防護措施

使用 Session ID 分析程式進行分析，評估是否無法被預測。如果沒有 100% 的把握自己撰寫的 Session ID 產生機制是安全的，不妨使用內建的 Session ID 產生 function，通常都有一定程度的安全。

竊取 Session ID 是最常見的攻擊手法。攻擊者可以利用多種方式竊取 Cookie 獲取 Session ID：

1. 跨站腳本攻擊 (Cross-Site Scripting (XSS))：利用 XSS 漏洞竊取使用者 Cookie
2. 網路竊聽：使用 ARP Spoofing 等手法竊聽網路封包獲取 Cookie
3. 透過 Referer 取得：若網站允許 Session ID 使用 URL 傳遞，便可能從 Referer 取得 Session ID

竊取利用的方式如下圖：

受害者已經登入網站伺服器，並且取得 Session ID，在連線過程中攻擊者用竊聽的方式獲取受害者 Session ID。

攻擊者直接使用竊取到的 Session ID 送至伺服器，偽造受害者身分。若伺服器沒有檢查 Session ID 的使用者身分，則可以讓攻擊者得逞。

防護措施

• 禁止將 Session ID 使用 URL (GET) 方式來傳遞
• 設定加強安全性的 Cookie 屬性：HttpOnly (無法被 JavaScript 存取)
• 設定加強安全性的 Cookie 屬性：Secure (只在 HTTPS 傳遞，若網站無 HTTPS 請勿設定)
• 在需要權限的頁面請使用者重新輸入密碼

攻擊者誘使受害者使用特定的 Session ID 登入網站，而攻擊者就能取得受害者的身分。

1. 攻擊者從網站取得有效 Session ID
2. 使用社交工程等手法誘使受害者點選連結，使用該 Session ID 登入網站
3. 受害者輸入帳號密碼成功登入網站
4. 攻擊者使用該 Session ID，操作受害者的帳號

防護措施

• 在使用者登入成功後，立即更換 Session ID，防止攻擊者操控 Session ID 給予受害者。
• 禁止將 Session ID 使用 URL (GET) 方式來傳遞

那要怎麼防範攻擊呢？當然會有人說，會員卡不要掉不就沒事了嗎？當然我們沒辦法確保用戶不會因為各種方式導致 Cookie 遭竊（XSS、惡意程式等），因此最後一道防線就是網站的 Session 保護。一張會員卡上如果沒有任何可識別的個人資料，當然任何人撿去了都可以用。如果上面有照片跟簽名呢？偷走會員卡的人在進入俱樂部的時候，在門口就會因為照片跟本人不符而被擋下來。Session 保護也是一樣，怎麼讓我們的 Session 保護機制也能辨識身分呢？答案是利用每個使用者特有的識別資訊。

每個使用者在登入網站的時候，我們可以用每個人特有的識別資訊來確認身分：

1. 來源 IP 位址
2. 瀏覽器 User-Agent

如果在同一個 Session 中，使用者的 IP 或者 User-Agent 改變了，最安全的作法就是把這個 Session 清除，請使用者重新登入。雖然使用者可能因為 IP 更換、Proxy 等因素導致被強制登出，但為了安全性，便利性必須要與之取捨。以 PHP 為例，我們可以這樣撰寫：

除了檢查個人識別資訊來確認是否盜用之外，也可以增加前述的 Session ID 的防護方式：

1. Cookie 設定 Secure Flag (HTTPS)
2. Cookie 設定 HTTP Only Flag
3. 成功登入後立即變更 Session ID

Session 的清除機制也非常重要。當伺服器偵測到可疑的使用者 Session 行為時，例如攻擊者惡意嘗試偽造 Session ID、使用者 Session 可能遭竊、或者逾時等情況，都應該立刻清除該 Session ID 以免被攻擊者利用。

Session 清除機制時機：

1. 偵測到惡意嘗試 Session ID
2. 識別資訊無效時
3. 逾時

使用者帳號遭竊一直以來都是顯著的問題，但卻鮮少有網站針對 Session 的機制進行保護。攻擊者可以輕鬆使用 firesheep 之類的工具竊取帳號。國外已經有不少網站偵測到 Session 可能遭竊時將帳號強制登出，但國內目前還鮮少網站實作此防禦，設備商的 Web 管理介面更少針對 Session 進行保護。如果 VPN Server 等設備有偵測 Session ID 的偽造，在 OpenSSL Heartbleed 事件時就不會有那麼慘重的損失了。

立刻把自己的網站加上 Session 保護機制吧！