Aggregator

WEB2PY 反序列化的安全問題－CVE-2016-3957

DEVCORE 戴夫寇爾
8 years 2 months ago
前言

在一次滲透測試的過程中，我們遇到了用 web2py 框架建構的應用程式。為了成功滲透目標，我們研究了 web2py，發現該框架範例應用程式中存在三個資訊洩漏問題，這些洩漏都會導致遠端命令執行 (RCE)。由於範例應用程式預設是開啟的，若沒有手動關閉，攻擊者可以直接利用洩漏資訊取得系統執行權限。這些問題編號分別為：CVE-2016-3952、CVE-2016-3953、CVE-2016-3954、CVE-2016-3957。

背景－老生常談的 Pickle Code Execution

在繼續說明前必須要先認知什麼是反序列化的安全問題？反序列化的安全問題在本質上其實是物件注入，它的嚴重性取決於所注入的物件本身是否會造成危險行為，例如讀寫檔。一般來說要透過反序列化建構一個成功的攻擊有兩個要點：

  • 是否可控制目標所要反序列化的字串。
  • 危險行為在反序列化後是否會被執行。這在實務上大概有下面兩種情形：
    • 危險行為是寫在魔法方法 (Magic Method) 裡面，例如 PHP 的 __construct 在物件生成時一定會執行。
    • 反序列化後覆蓋既有物件，導致正常程式流程出現危險結果。

反序列化的問題在每個程式語言都會發生，但通常需要搭配看程式碼拼湊出可以用的攻擊流程，比較難利用。不過，某些實作序列化的函式庫會將程式邏輯也序列化成字串，因此攻擊者可以自定義物件直接使用，不再需要拼湊，例如今天要提的 Python Pickle。

直接舉個 Pickle 的例子如下，我們製造了一個會執行系統指令 echo success 的物件 Malicious，並且序列化成字串 "cposix\nsystem\np1\n(S'echo success'\np2\ntp3\nRp4\n."。當受害者反序列化這個字串，即觸發執行該系統指令，因此印出 success。

>>> import os >>> import cPickle >>> class Malicious(object): ... def __reduce__(self): ... return (os.system,("echo success",)) ... >>> serialize = cPickle.dumps(Malicious()) >>> serialize "cposix\nsystem\np1\n(S'echo success'\np2\ntp3\nRp4\n." >>> cPickle.loads(serialize) success 0

這就是 Pickle 誤用反序列化所造成的命令執行風險。攻擊者很容易可以產生一個含有任意命令執行的序列化字串，進而讓受害者在進行反序列化的過程中觸發執行惡意命令。

反序列化 ＋ 序列化字串可控

本次發現的問題主要來自 web2py 本身的 session cookie 使用 Pickle 處理序列化需求 (CVE-2016-3957)，而且因為 session cookie 的加密字串固定 (CVE-2016-3953)，攻擊者可任意偽造惡意的序列化字串造成前面所介紹的命令執行風險。細節如下。

CVE-2016-39571

web2py 的應用程式如果使用 cookie 來儲存 session 資訊，那麼在每次接到使用者請求時會將 session cookie 用一個 secure_loads 函式將 cookie 內容讀入。 [Ref]

gluon/globals.py#L846 if response.session_storage_type == 'cookie': # check if there is session data in cookies if response.session_data_name in cookies: session_cookie_data = cookies[response.session_data_name].value else: session_cookie_data = None if session_cookie_data: data = secure_loads(session_cookie_data, cookie_key, compression_level=compression_level) if data: self.update(data) response.session_id = True

secure_loads 函式內容如下，在一連串解密後會用 pickle.loads 方法將解密內容反序列化，在這裡確定 cookie 內容會使用 Pickle 處理。[Ref]

gluon/utils.py#L200 def secure_loads(data, encryption_key, hash_key=None, compression_level=None): if ':' not in data: return None if not hash_key: hash_key = sha1(encryption_key).hexdigest() signature, encrypted_data = data.split(':', 1) actual_signature = hmac.new(hash_key, encrypted_data).hexdigest() if not compare(signature, actual_signature): return None key = pad(encryption_key[:32]) encrypted_data = base64.urlsafe_b64decode(encrypted_data) IV, encrypted_data = encrypted_data[:16], encrypted_data[16:] cipher, _ = AES_new(key, IV=IV) try: data = cipher.decrypt(encrypted_data) data = data.rstrip(' ') if compression_level: data = zlib.decompress(data) return pickle.loads(data) # <-- Bingo!!! except Exception, e: return None

因此，如果知道連線中用以加密 cookie 內容的 encryption_key，攻擊者就可以偽造 session cookie，進而利用 pickle.loads 進行遠端命令執行。

CVE-2016-3953

很幸運的，我們發現 web2py 預設開啟的範例應用程式是使用 session cookie，並且有一個寫死的密鑰：yoursecret。[Ref]

applications/examples/models/session.py session.connect(request,response,cookie_key='yoursecret')

因此，web2py 的使用者如果沒有手動關閉範例應用程式，攻擊者就可以直接在 http://[target]/examples/ 頁面發動攻擊取得主機操作權。

Proof of Concept

我們嘗試用 yoursecret 作為 encryption_key 偽造一個合法的 session cookie，並將一個會執行系統指令 sleep 的物件塞入其中。帶著此 session cookie 連入 web2py 官網範例應用程式(http://www.web2py.com/examples)，情形如下：

當插入的物件會執行指令 sleep 3 時，網站回應時間為 6.8 秒

當插入的物件會執行指令 sleep 5 時，網站回應時間為 10.8 秒

確實會因為塞入的 session cookie 值不同而有所延遲，證明網站的確執行了（兩次）我們偽造的物件內容。2

其他洩漏導致 RCE

此外，在 web2py 範例應用程式為了示範框架的特性，因此洩漏了許多環境變數。其中有兩個變數較為敏感，間接也會導致端命令執行，分別如下。

CVE-2016-3954

在 http://[target]/examples/simple_examples/status 頁面中，response 分頁內容洩漏了 session_cookie_key 值。這個值就是用來加密前面所介紹的 session cookie，搭配 CVE-2016-3957 Pickle 的問題可直接遠端命令執行。

無論使用者是否自行更改 session_cookie_key，或是該值是系統隨機產生。此介面仍然可以取得機敏資訊藉以造成危害。

CVE-2016-3952

http://[target]/examples/template_examples/beautify 頁面洩漏了系統環境變數，當使用者是使用 standalone 版本時，管理者的密碼就會在環境變數裡出現。這個密碼可登入 http://[target]/admin 管理介面，管理介面內提供方便的功能得以執行任意指令。

官方修復

Version 2.14.1 移除洩漏的環境變數。[Ref]

Version 2.14.2 使用不固定字串作為 session_cookie_key，並移除洩漏頁面。

applications/examples/models/session.py from gluon.utils import web2py_uuid cookie_key = cache.ram('cookie_key',lambda: web2py_uuid(),None) session.connect(request,response,cookie_key=cookie_key) 總結

web2py 框架預設會開啟一個範例應用程式，路徑為 http://[target]/examples/。
由於這個應用程式使用 Pickle 來處理序列化的 session cookie，且因為加密字串為寫死的 yoursecret，任何人可竄改 session cookie 的內容，藉此進行 Pickle 命令執行攻擊。
該範例程式介面中也存在 session_cookie_key、管理者密碼洩漏問題，兩個都會導致任意命令執行。除此之外，在這個應用程式中洩漏許多系統配置、路徑等資訊，有機會被拿來做進階攻擊。
在 2.14.2 版本後已經修復所有洩漏問題，當然最好的解決辦法就是關閉這個範例應用程式。

最後，來整理從開發者的角度在這個案例中該注意的要點：

  1. 小心處理序列化字串，使用者若有機會改變該字串值，有機會被插入未預期的惡意物件，造成惡意的結果。
  2. 正式產品中切記要移除任何跟開發相關的配置。
時間軸
  • 2016/03/08 發現問題與其他研究
  • 2016/03/09 回報官方 GitHub Issue
  • 2016/03/15 成功與開發者 email 聯繫
  • 2016/03/15 官方修復管理者密碼洩漏問題 (CVE-2016-3952)
  • 2016/03/25 官方修復其他弱點並發佈 2.14.2 版本
附註

  1. 其實 CVE-2016-3957 並非不安全的設計，在跟 CVE team 溝通的過程中發現 web2py 開始使用 JSON 取代 Pickle [Ref]，因此判定 web2py 認為目前的設計是不洽當的，給予此編號。後來官方因故將 Pickle 改了回來，不過在沒有洩漏加密字串的前提下已經是安全的了。 ↩

  2. 在自行架設的 web2py 環境中只會執行一次，沒有去細追 web2py 官方網站為何執行兩次。 ↩

IoT設備商別成為幫兇 從Dyn DDoS攻擊事件看IoT安全

DEVCORE 戴夫寇爾
8 years 2 months ago
萬物皆聯網成為萬物皆可駭

2016年10月21日知名網路服務 Dyn 遭受殭屍網路發動三波巨大規模 DDoS 攻擊，世界各大網站服務皆因為此攻擊而中斷，包括 Amazon、Twitter、Github、PayPal 等大型網站都因此受到影響。資安人員研究發現，本次 DDoS 攻擊的發起者未明，但多數攻擊流量來自殭屍網路「Mirai」，利用 IPCAM、CCTV、DVR、IoT 裝置等系統進行 DDoS 攻擊。為什麼這些設備會成為攻擊的幫凶呢？我們又該如何自保呢？

一個攻擊事件，一定有背後的原因。攻擊者一定是有所求，才會進行攻擊，可能是求名、求利或求樂趣。因為 DDoS 攻擊會直接影響目標系統的運作，對系統營運造成影響，在黑色產業的循環中通常會利用這種攻擊來勒索錢財。例如針對營運線上遊戲的公司進行 DDoS 攻擊，讓遊戲服務中斷，逼迫企業將主機的連線花錢「贖」回來。但 Dyn 這次的事件各家都沒有收到類似的勒索信，因此資安專家們推測，這可能是一次練兵，或者甚至是 DDoS 攻擊服務的行銷手法。如果我們用黑色產業的角度去思考一個攻擊行為，就會有截然不同的看法。試想，如果這是一次駭客組織的商業行銷行為，目的是展現這個團隊的 DDoS 攻擊火力，這樣的成果是否可以稱作是一個成功案例呢？如果你是服務購買者，是否對這樣的服務有信心呢？

利用 IoT 裝置及網通設備佈建殭屍網路 (botnet) 已經不是新聞。Internet Census 2012 是一次資安圈的大事件，一個稱為 Carna 的 botnet 利用了全世界 42 萬台裝置，掃描全世界整個 IPv4 設備，蒐集 IP 使用狀況、連接埠、服務標頭等資訊，並且提供共計 9TB 資料開放下載研究。而這個 botnet 多數利用路由器 (router) 的漏洞，利用預設密碼、空密碼登入設備，植入後門供攻擊者控制。而後的幾次大型攻擊事件都與 IoT 及嵌入式裝置有關係，讓 IoT 的口號「萬物皆聯網」成為「萬物皆可駭」，也讓資安研究人員對於研究這類型設備趨之若鶩。近年智慧車輛不斷發展，國際間也不少智慧車輛被駭的事件。車輛被駭影響的就不單是資訊系統，更會波及人身安全甚至整個城市的交通，資安考量的影響也遠比以前嚴重。

連網裝置成為駭客下手的主要原因

究竟是怎樣的安全漏洞讓攻擊者這麼輕易利用呢？目前攻擊者及 botnet 多數利用的還是使用預設密碼、或甚至是沒有設定密碼的裝置。網站 Insecam 揭露了全世界數萬支未修改密碼的攝影機，再再顯示不少民眾或公司行號購買了監視器，卻沒有健全的資安意識，讓監視器暴露於全世界之中。更多攝影機、監視器等的資安議題可以參考我們的文章「網路攝影機、DVR、NVR 的資安議題 - 你知道我在看你嗎？」。除了預設密碼之外，設備中的後門也是一個大問題。不少路由器、無線基地台廠商被爆出系統中含有測試用的登入帳號，該帳號無法關閉、無法移除，且容易被攻擊者進行研究取得。除了等待廠商升級韌體來修補該問題之外，沒有其他解法，因此成為攻擊者大量取得控制權的方式之一。

IoT 裝置為什麼會成為攻擊者下手的目標呢？我們可以分成幾點來探討。

第一，嵌入式裝置以往的設計都是不連網，IoT 的風潮興起之後，各廠商也為了搶市場先機，加速推出產品，將原本的產品加上網路功能，甚至 App 控制功能。而求快的結果就是犧牲資安考量，加上廠商可能原本並非網路專長，也沒有足夠的資安人員檢視安全性，導致設計出來的產品資安漏洞層出不窮。產品的設計必須嚴守 Security by Design 的原則，在開發初期的每個環節都納入資安考量，並且遵守 Secure Coding 規範，避免在產品後期疊床架屋，造成要釐清資安問題的根源更難如登天。

第二，產品的更新機制問題。IoT 裝置的更新機制在早期並沒有謹慎考量，需要使用者自行下載韌體更新，甚至有些裝置必須回廠才能進行更新。不少使用者只要產品沒有出問題，並不會主動進行韌體更新，甚至覺得更新只會造成更多問題。在沒有便利更新機制的情況之下，設備的資安問題更難以被妥善處理。近期因為資安事件頻傳，FOTA (Firmware Over-The-Air) 機制才逐漸被重視，但其他資安問題也隨即而來。如何確保韌體的完整性？如何防止攻擊者下載韌體進行研究修改？這些都是廠商需要不斷去反覆思量的。

第三，敵暗我明，也是我們認為最重要的一點。我們認為資安就是攻擊者與防禦者的一場資訊不對稱戰爭，防禦者（廠商）通常只會憑藉著自己的知識跟想像進行防禦，但卻不知道攻擊者的思維跟手法。就像春秋時代公輸般，建造雲梯協助楚國攻擊宋國的城池。唯有了解攻擊者，化解這個不對稱的資訊，才能有效的進行防禦，如同墨子了解雲梯的攻擊方式，模擬各種對應防禦的手法，才成功讓楚王放棄攻擊。不僅是 IoT 廠商，所有企業都必須了解攻擊者的思維、手法，知曉這個黑色產業的運作，甚至針對攻擊的方式進行模擬演練，將每一個防禦的缺口補足，才可以正面迎戰攻擊者。

設備商避免成為幫凶，消費者也應自保

身為使用者，我們該如何確認自己的設備有沒有被感染呢？若被感染該怎麼有效清除呢？建議先搜尋網路上目前已公開有漏洞的廠牌及型號，若在問題清單之內，先將整台設備備份設定後，回復原廠初始設定，以確保攻擊者放置的惡意程式都被清除。接著更新廠商所釋出的新版韌體，並記得在更新安裝完畢後立即更換密碼以防二度被入侵。若廠商無釋出更新，可能是資安不被重視，也可能是廠商已經結束營運。如果還是選擇要使用這個設備，建議將設備轉放在內部網路，或者是在前面增加防禦設備，避免攻擊者入侵。

至於廠商該怎麼跟上資安的腳步呢？我們認為目前廠商最重要的就是資安意識。這已經是老生常談，以往網路產業逐漸重視資安，但跨入網路的其他資訊產業恐怕還沒意識到資安的嚴重性。凡舉傳統家電轉為智慧家電、車輛轉為智慧車輛、甚至基礎建設也逐漸資訊化的現在，若這些踏入網路的產業沒有相對應的資安意識，恐怕很難在初期就預防風險的發生。企業也必須盤點風險的所在，透過人工滲透測試模擬攻擊者的攻擊思維及路徑，如同軍事演習一般，將入侵的途徑一一封鎖。我們認為 IoT 等嵌入式裝置、智慧家電、甚至網通資安設備本身，未來都會是駭客組織攻擊的對象，利用更新的困難度跟管理者的疏於管理，建置一個個大規模殭屍大軍，成為未來戰爭的棋子。我們期許未來廠商建構產品時，都能優先納入資安考量，不成為黑色產業的幫凶，也讓國際認可台灣產品是資安至上的優良品質。

贪心算法之字符串的完美度

她和她的猫
8 years 2 months ago
最近在 51Nod 学习贪心算法入门，就把做题目的思路一些记录下来，欢迎指正。 题目详情我们要给每个字母配一个1-26之间的整数，具体怎么分配由你决定，但不同字母的

一言不和就造轮子之 CookieHelper

她和她的猫
8 years 3 months ago
最近开始学 ASP.NET，然后发现 Cookie 的设置不像 PHP 简单粗暴(PHP Cookie用法)，于是就造个轮子省事，注释很详细，这里就不再赘言。 using System; using System.Collections.Generic; using System.Linq; using System.Net; using

Managed ad