前言

在一次滲透測試的過程中，我們遇到了用 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-3957¹

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 值不同而有所延遲，證明網站的確執行了（兩次）我們偽造的物件內容。²

其他洩漏導致 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)

總結

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

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 版本

附註