Aggregator

還記得在上一篇文章 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 保護機制吧！

晚上突然接到社群朋友傳 LINE 的訊息過來，定睛一看並不單純。這網址看起來就是釣魚網站啊？怎麼會這樣呢？難道是朋友在測試我們的警覺心夠不夠嗎？讓我們看下去這個釣魚網頁怎麼玩。

此 LINE 釣魚訊息說只要幫忙轉發 15 次訊息，就會贈送貼圖。先不論 LINE 有沒有這樣的機制，我們先直接點選連結看看葫蘆裡賣什麼藥。

瀏覽器打開之後，跳出了領取貼圖的「網頁」，而且還有詭異的紅字。各種跡象都跟一般領取貼圖的模式不同，太令人起疑了。點了圖就會跳到 Facebook 登入頁面。

明眼人看到這個 Facebook 登入頁面就會發現太假了，破綻多多。Logo、網址、網頁格式破板、簡體字，太多令人懷疑的地方了。在這邊我們只要隨便輸入帳號跟密碼，就能到下個畫面。

結果當然是不會給你貼圖啦！而且網址「cuowu」是「錯誤」的拼音，也暴露了網站作者的身分。直接用瀏覽器看傳遞的頁面叫做「tj.asp」，「tj」正好是「提交」，畫面上的錯誤訊息更是大剌剌的直接秀出簡體字。

事後友人直接說 LINE 帳號被盜用發訊息了，而且密碼可能過於簡單、也沒有設定換機密碼。因此在這邊呼籲大家做好 LINE 的安全設定：

1. 加強密碼長度、複雜度
2. 設定「換機密碼」
3. 若只在手機使用 LINE，可將「允許自其他裝置登入」關閉
4. 如果有帳號被盜狀況，趕快聯絡 LINE https://line.naver.jp/cs/

大家在享受通訊軟體與朋友傳訊貼圖的同時，也必須要注意有心人士利用這些管道竊取你的帳號密碼喔！

The Government Communications Security Bureau (GCSB) is responsible for administering the network security provisions of the TICSA.

最近很多人都收到了一個看起來很像釣魚網站的核四投票站台簡訊，如下圖：

我們也收到了，但是剛吃飽飯實在很想睡覺，不太想理他，於是就忍不住趴下睡覺，竟然做了個夢…..

在夢中手滑打開了網頁，內容長得像這個樣子：

看了真是非常的義憤填膺！馬上就想投下神聖的一票！但是忽然聽到周公指示說網站底下有奇怪的目錄，照著神諭一試，發現有 .svn 目錄跟 entries 檔！

這時候三太子哪吒剛好路過，說他剛剛在 Pastebin 看到有人貼了一篇跟這個網站好像有關聯的內容，講完他就開著水車跑去鎮壓龍宮了。點開那篇內容一看，內容有一些很奇怪的網址，讓人看了就很想點！隨便選了一個 http://vote.tw.am/2N9E6V4E5R4BABC0647469FF213F2D94A27FA/chose_vote.include.php 打開來看：

哇塞！原來從服貿就已經開始了呢！讓我們繼續點進去看看：

看起來是個後台，可以瀏覽使用者的投票記錄、留言等資料，那就點個投票記錄來看看：

果然裡面存著眾多民眾的投票記錄，那麼用戶反饋應該就是留言了…

從這些內容看來，應該是有個集團擁有大量的民眾個資，並且一一發送訊息給這些人，背後目的尚不得而知。有可能是大陸人想利用這個熱潮確認這些電話號碼是否真實、可用，也有可能是不知名的黑手正在策劃下一個打壓動作？正當我們想搞清楚對方究竟是透過電話號碼還是信箱傳送 iMessage 時，哪吒忽然又路過了，丟了這張圖之後叫我們不要再瞎忙了趕快回家洗洗睡：

果然有電話！究竟這件事，是有網站大量洩漏個資，還是有人在民運期間利用這股熱潮蒐集個資，抑或是背後有什麼不可告人的秘密呢？讓我們繼續看下去～

上班時間不能午睡太久，於是周公就把我們叫醒了…..

對於這樣的夢境我們有以下建議：

• 不要隨意點擊來路不明的簡訊內容
• 在網路上填寫任何內容之前先查證該網站是否可疑
• 對於 [email protected] 這種可疑帳號所傳來的任何資料，請保持高度警戒
• 對於 vote.tw.am 這種看起來疑似要偽裝成 .tw 網域的站台，也請保持高度警戒

歡迎大家轉發這個消息到各大網站、粉絲團、BBS，告訴各個熱心公益的鄉民們別再點擊與回應來路不明的簡訊囉！

DNS 是在 1983 年由 Paul Mockapetris 所發明，相關規範分別在 RFC 1034 以及 RFC 1035。其主要作用是用來記憶 IP 位址與英文之間的對應關係，讓人類可以用較簡單的方式記得主機名稱。目前一般民眾大多使用 ISP 或國際知名公司提供的 DNS server，如中華的 168.95.1.1 或是 Google 的 8.8.8.8 等等。

然而對於企業而言，可能需要架設大量機器或內部系統，又希望以簡單的方式記憶主機名稱，因此許多企業有自行架設 DNS server 的需求。同時企業通常也會建立幾台備援 DNS server，以避免 DNS 服務忽然中斷。但是當企業有多台 DNS server 時，就必須考量 DNS 記錄的同步問題，通常會使用 zone transfer 這個功能來同步記錄。

然而若管理者未做好相關設定，使所有來源皆可對企業的 DNS 主機進行 zone transfer 查詢，則有機會讓此功能成為企業遭受攻擊的起點。用現實生活情境舉例的話，對外開放 zone transfer 就如同所有人都可以任意查詢你名下的所有房地產位在何處，假如有人要針對性的攻擊你，隨時都可以去看你某個房地產有沒有哪扇門窗沒關好，伺機入侵你的家園。一般我們對企業資訊系統進行滲透測試時，在資訊搜集的階段也會先從 domain name 下手，因此 DNS 相關資料的重要性可見一斑。

Zone transfer 的資安議題早在 1999 年就已有人提出，理應成為各企業進行資安稽核的步驟之一。然而十五年過去了，在近期我們卻發現許多國內大企業仍有此問題，令人非常驚訝！究竟企業該如何檢測自身是否存在這種安全漏洞？此問題目前在台灣網路環境佔有多大的比例？Zone transfer 會對企業造成什麼影響？讓我們繼續看下去～

首先需感謝 DigiNinja 提供了一個讓大家自由測試的 zonetransfer.me 網域，以下我們分別在 Linux 及 Windows 環境下進行檢測。

在 Linux 環境內，我們可利用 dig 指令查詢目標 domain 使用哪些 name server：

Name server 查詢結果：

從結果可得知有 ns12.zoneedit.com 或 ns16.zoneedit.com 這兩個 DNS server，接著我們即可測試是否可從外部網路對這兩個 DNS server 進行 zone transfer，測試方式如下：

Zone transfer 測試結果：

從上面的測試結果中我們可發現，zonetransfer.me 這個網域的所有 DNS 設定已全部被列出。

若是在 Windows 環境，可在命令提示字元環境內使用 nslookup 指令查詢目標 domain 使用哪些 name server：

Name server 查詢結果：

輸入指令後我們如同先前使用 dig 一樣，得知目標有 ns12.zoneedit.com 與 ns16.zoneedit.com 這兩個 name server，接著再如下圖依序輸入三道指令查詢：

註：Linux 版的 nslookup 沒有實作 ls 這個功能喔！

Zone transfer 測試結果：

測試結果與 Linux 環境所得到的資料雷同，可成功列出該網域的所有 DNS 設定。

當然，並不是每個人都熟悉上述指令的操作方式，因此除了介紹手動檢測方法之外，在這裡也提供幾個線上檢測的服務，讓大家可以迅速檢測自家公司或者你正在使用的服務是否有此問題：

• UltraTools
• HackerTarget
• Digital Point

如同上次 HTTP Headers 資安議題所探討的對象，我們從 TIEA 成員以及 Alexa TW top 525 觀察 zone transfer 問題分別在這些族群中佔有多少比例。

根據我們監測的結果，在目前 TIEA 的 132 名成員中，有 20 個網域存在 zone transfer 問題，佔了 15.15%。而在 Alexa TW top 525 當中，有 48 個網域存在 zone transfer 問題，佔了 9.14%。乍看之下比率似乎不高，但是在上述兩個族群的網域當中，包括：

• 電信商
• 多家電視媒體
• 多家網路新聞媒體
• 多家線上購物網站
• 知名團購網站
• 知名金流公司
• 知名線上音樂服務

台灣企業不夠注重資訊安全，罔顧客戶資料安全性，早已不是新聞。然而若企業不顧自身商業利益與責任，當彼此無商業往來時，我們也無法一一咎責。但若連台北市政府、教育部、多間大專院校都有此問題，就令人不太能接受了，這些政府單位與教育機構理當為我們的個人資料安全性負起全部的責任，不應該漏掉任何一個資安環節。上述結果顯示出台灣從政府到企業可能都沒有徹底落實 DNS 的資安設定，而且目前的數據僅僅是針對 TIEA 成員以及 Alexa TW top 525 進行檢測，若是對全台灣或是全世界進行大範圍的檢測，恐怕會發現更多驚人的案例！

• 洩漏網域名稱

  一般企業在進行滲透測試時，通常只會挑幾個最重要、最常面對客戶的網域進行測試，但是入侵者可不會這麼乖。當有人嘗試要入侵企業時，必定是先進行全面的偵查，觀察企業哪幾個網域所執行的 service 有潛在的弱點，或是看哪幾個網域防禦力道較弱，再從該處下手。因此 zone transfer 問題所提供的完整 DNS 記錄，就為入侵者省下了許多偵查的工夫。

• 洩漏外網 IP 範圍

  當攻擊者取得 zone transfer 所洩漏的資料後，可合理推斷哪些網段是屬於該企業，進一步對該網段進行掃描，嘗試找尋有機會入侵之標的物。

• 洩漏內網 IP 範圍

  有些管理人員、開發者為求內部開發方便，經常會將網域名稱跟內網 IP 位址綁在一起，例如將 phpmyadmin.example.com 設定為 192.168.1.100，攻擊者就可根據此類資訊猜測內網哪些網段存在重要服務。這種設定平常也許不會造成重大損害，但是當管理者疏於建立內網防禦機制，恰好企業又被入侵至內網時，造成一連串重大損失的機率將會大幅提高。

若使用 Linux，可在 /etc/named.conf 內加入下列選項，以限制可存取 zone transfer 的來源：

設定完畢後，將 DNS 服務重啟即可生效。

在 Windows server 當中，我們可到伺服器管理員修改網域的相關設定，如下圖：

在伺服器管理員中，選定想要修改的網域（此處以 test.com 為例），按右鍵點選內容，將會跳出選單如下圖：

接著就是觀看「允許區域轉送」選項是否有勾選，若已勾選，則確認轉送對象是否為下列兩種：

• 只到列在「名稱伺服器索」引標簽上的伺服器
• 只到下列伺服器

DNS 在做 zone transfer 時是使用 TCP 53 port（有別於一般 DNS query 的 UDP 53 port），因此有些人會認為將 TCP 53 port 關閉就可以對付 zone transfer，而不想修改 zone transfer 的設定。其實這個觀念只對了一半，若 zone file 的資料小於 512 byte，仍然可以透過 UDP 傳輸。即使 zone file 的資料大於 512 byte，也可以用 Incremental Zone Transfer (IXFR) 的方式取得部分資料。

如果企業今天非常有自信能夠替所有網域都準備好完善的安全措施，那麼 zone transfer 所洩漏的資料對該企業就不會有太嚴重的影響。然而，在現今這個入侵手法日新月異的世界裡，又有誰能夠永遠保證自己的安全防護已經做足了呢？在前陣子火紅的 OpenSSL CVE-2014-0160 Heartbleed 問題被爆出來之後，我們就藉由許多 zone transfer 的記錄觀察到全世界有非常多企業只修復了主要網站的 OpenSSL 漏洞，卻忽略了企業內其他的服務與設備可能也有此漏洞，像是 DB、Email、VPN、NAS 等等，直到今日仍遲遲未修復。

千萬別以為你所購買的各種資安設備能防禦所有資安弱點，也別忽略了各項古老的資安弱點，更別小看了你所不熟悉的駭客們的組合各式各樣弱點的能力，只要有一個資安環節疏漏，隨時都有可能對企業造成致命危機。

不安全的引用物件 (Insecure Direct Object Reference) 是個非常常見的資安漏洞，在 OWASP 公布的十大網站應用程式安全漏洞 中高居第四名。通常發生在網站應用程式上沒有針對輸入的參數做好檢查，就把參數丟入 include 或 readfile 等函數當中引用，使得攻擊者可以藉此存取任意文件的原始碼。

今天這個案例就發生在 PHP 的官方網站 (http://www.php.net/)，消息來源是知名的 0-Day 黑市 1337day，發佈的日期是 2014/4/4 ，原始的內容是這樣的：

可以看到這個弱點是不公開的，想要知道內容的話要支付 82 美元相當於新台幣 3500 元呢！在強烈的好奇心屈使之下，自己打開工具來找看看：

透過簡單的分析和一點點運氣，找到了 「http://www.php.net/cached.php」 這隻程式，發現它傳入了「t」和「f」這兩個參數。「t」直覺上就是個 rand 數值，而「f」應該就是檔案位置了。這時候對 f 參數小小修改一下，神奇的事情發生了：

index.php 的原始碼被完整的讀出來，當然也要來看一下 cached.php 是怎麼寫的：

可以看到此處並未對 $_GET[“f”] 進行檢查，所以修改了 $_GET[“f”] 後，與 $abs 組合完，最後就直接丟入 readfile 讀取檔案。比較值得研究的是這邊使用了 realpath 與 strncmp 來比較 f 及 DOCUMENT_ROOT，確保 $abs 只能在網站目錄之下，所以無法使用 ../../ (Path Traversal) 的方式跳脫目錄進行更進一步的滲透。

最後我們將此發現回報給 [email protected] ，得到的回應是他們是「故意的 (intentional)」。且後來也知道 PHP 官網是開放原始碼（Open Source）的，可以到 http://git.php.net/?p=web/php.git;a=tree 下載整個官網的原始碼。

雖然在這個案例中並沒有造成實質上的危害，沒有帳號、密碼、系統設定等機敏資料，但若把此種寫法用在其他地方，則可能造成很大的資安風險。就連 PHP 官方網站都有這樣的失誤，身為開發人員的你們更不可不慎！

在一陣 OpenSSL Heartbleed 淘金潮中，又有一個技術門檻低、後果嚴重、也同樣需要些運氣的漏洞被揭發－CVE-2014-0166。CVE-2014-0166 是 WordPress 上面驗證登入 cookie 的弱點，攻擊者可以暴力偽造出合法 cookie，藉此獲得 WordPress 最高權限，進而拿到 shell 取得系統操作權。 讓我們來分析一下這次的弱點是發生了什麼事吧！

這次出問題的程式碼在這邊，關鍵程式碼如下：

問題主要發生在比較運算子 != 上面，!= 運算子是 non-strict，會在比較前先做型態轉換，所以下面看似應該是回傳 true 的例子，全部都顯示為 false，細節請參閱官方手冊。

進入正題，WordPress 認證身分用的 cookie 內容是這樣的：『username|expiration|hmac』。
username 是使用者名稱，
expiration 是有效期限(timestamp)，
hmac 值用來驗證 cookie 是否合法。
從上面程式碼可以看到，hmac 的算法是經過 username、pass_frag、expiration、key 綜合得出。若有辦法控制 cookie 中的 hmac 使伺服器認為該 cookie 合法，就可以成功偽造成 username。

利用稍早提到的比較運算子問題，若我們讓 cookie 中的 hmac 值為 0，很有可能讓判斷式變成下面這樣：

如此便可以通過驗證，成功偽造合法 cookie。
而為了讓 $hash == 0，可以不斷改變 cookie 中的 expiration，讓產生的 MD5 值($hash)經過型態轉換後剛好變成 0。
符合 $hash == 0 的 MD5 $hash 值有 0eXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX、00eXXXXXXXXXXXXXXXXXXXXXXXXXXXXX….000000000000000000000000000eX、00000000000000000000000000000 (X = 0,1,2,3,4,5,6,7,8,9)

故出現 $hash == 0 的機率為 Sum(10^n,n=0,30)/16^32 = 3.265262085617465e-09

每次偽造的成功機率約為三億分之一，並不會很高，但已經足夠在一個月內拿到最高權限，而且所耗成本並不會很高。

為了驗證此方法之可行性，我們架設了 WordPress 3.8.1 環境。並且寫程式將登入 cookie 中的 hmac 設為 0，不斷調整 expiration 值測試是否已經登入，程式如下：

註：此程式為 POC，請自行調整為多執行緒版本，不然速度會很慢。

經過一段長時間的等待，得到的結果如下：

得知當 cookie 中的 username 為 admin 且 expiration 值為 1421818232 時，伺服器算出來的 hmac 經過型態轉換會變成 0。我們將測試成功的 cookie 值： admin%7C1421818232%7C0 貼到瀏覽器上。成功變成 admin 如下圖，實驗成功！

註：一般狀況，若不知道 WordPress 最高權限的帳號，可以利用 WordPress 的 feature 在 http://your.WordPress.com/?author=$id ($id: 1,2,3,4…,999,…) 頁面中列舉所有使用者帳號。通常 $id = 1 的 author 都有 WordPress 的管理權限。

最近出現了一個高風險通報 CVE-2014-0166，其中提及 WordPress 在舊版驗證 cookie 的部分出現弱點，可以偽造合法 cookie，進而取得 WordPress 管理權限。本文分析了其原理，並且證實之。

對於攻擊者而言，雖然每次偽造 cookie 成功的機率約為三億分之一並不高，但發送三億個 request 後或許能拿到最高權限，已經是值得投資的級數。

對於 WordPress 管理者而言，建議立即更新至 3.8.2 以後版本，以免受到此風險攻擊。

從此事件也提醒了 PHP 開發者，在撰寫重要的驗證行為，要特別注意 PHP 比較運算子的特性，請使用 === (不等於請用 !==)來保證等式左右型態與值為一樣，避免因為轉型造成的資安風險。