Aggregator

As security professionals, we often feel like we’re fighting a losing battle when it comes to cyber security.

This past year is one for the digital record books. As incredible as it sounds, adults — not those impulsive,...

The post Trends: Adult Cyberbulling is No Laughing Matter appeared first on McAfee Blog.

最近看到个好玩的东西ThreatPinch，一个开源情报的Chrome插件。

When someone from the IT group gets promoted into security management, a common first lesson is that “geek culture” is ineffective in the boardroom.

2016年年底，司法部发布了《司法部关于印发司法鉴定文书格式的通知》，其中包含了《司法鉴定委托书》等7种文书格式。本地将就新旧两版的司法鉴定文书的格式规范的区别展开解读。

分享一个有意思的远程system提权漏洞。

In just four short years, encryption estimates have gone from almost non-existent (in the low single digits before 2013) to just over 50% by the end of 2016. How much of a victory is this?

One of the pillars of DevOps is automation. Along with that comes orchestration, which some might guess to be automation at a higher level of abstraction.

Hi. I’m Mike Convertino, CISO of F5 Networks, and I want to welcome you to an experiment we’re conducting here at F5. We’ve laid the foundation of this CISO to CISO portal on an idea that has traditionally been somewhat controversial in the security community: openness.

I’ve mentioned before how important strong risk management is to a CISO. When it comes to risk, the applications our users depend on are a big concern. In F5's 2016 State of Application Security survey, a majority of respondents cited security around applications as an area of great concern.

Chrome浏览器“自动填充”功能安全性研究

So far, we’ve seen IoT DDoS attacks on a Death Star scale. What's next for those of us that may be caught in the blast?

刚刚手贱不小心把前两篇 Python 的文章给删了，关键是我还没有备份！心里一万只草泥马奔腾而过。。。这件事情告诉我们，记得备份！记得备份！记得备份！重要的事情说三

两只web 🐶开了个公众号~

2016 has been an exciting year on the tech front, with our hearts being won over by technology ranging from...

The post What You Need to Know About Security Threats in 2017 appeared first on McAfee Blog.

Most people in the performance engineering field agree that our skillset is derived from an intersection of disciplines that include testing, optimization, and systems engineering.

Racing for everyone: descriptor describes TOCTOU，苹果iOS/OSX内核中的新型漏洞介绍

dirtycow官网上几个获得rootshell的exp大都会导致机器死机，在原作者的基础上改进了一下，做个记录:

前言

在一次滲透測試的過程中，我們遇到了用 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 官方網站為何執行兩次。 ↩