當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

hash_hmac函数使用不当造成的安全问题

發(fā)布時間：2025/3/21 编程问答 27 豆豆

生活随笔收集整理的這篇文章主要介紹了 hash_hmac函数使用不当造成的安全问题小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

2019獨(dú)角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔn)>>>

近期有國外安全人員挖掘到api.wordpress.org的一個RCE漏洞，可以影響到遠(yuǎn)程更新的Wordpress網(wǎng)站。Wordpress開發(fā)者利用Github的WebHooks功能來進(jìn)行源碼的更新迭代，但是在服務(wù)端實(shí)現(xiàn)WebHooks的功能時hash_hmac未安全使用，造成了認(rèn)證繞過，再利用后面代碼的邏輯了進(jìn)行了遠(yuǎn)程代碼執(zhí)行漏洞攻擊。

有安全問題的代碼

function verify_github_signature() {if ( empty( $_SERVER['HTTP_X_HUB_SIGNATURE'] ) )return false;list( $algo, $hash ) = explode( '=', $_SERVER['HTTP_X_HUB_SIGNATURE'], 2 );// Todo? Doesn't handle standard $_POST, only application/json$hmac = hash_hmac( $algo, file_get_contents('php://input' ), FEATURE_PLUGIN_GH_SYNC_SECRET );return $hash === $hmac; }

以上代碼出現(xiàn)在Wordpress開發(fā)者利用GitHub的WebHooks功能來進(jìn)行代碼自動化部署，修復(fù)后的代碼可以點(diǎn)擊這里查看。

為了驗(yàn)證POST請求是來自Github服務(wù)器，而不是來自惡意用戶，GitHub使用SHA1生成散列并在頭部提供簽名：

X-Hub-Signature：sha1 = {hash}

通過計算hmac的只是否一致來進(jìn)行判斷。

php中的hash_hmac函數(shù)是什么

簡單理解為一個帶密鑰的hash算法。

具體的實(shí)現(xiàn)流程

HMAC（K，M）=H（K⊕opad∣H（K⊕ipad∣M））

K代表密鑰，M代表消息，H代表hash函數(shù)，opad為0x5c，ipad為0×36

當(dāng)H為md5是，相應(yīng)的python實(shí)現(xiàn)代碼如下

from hashlib import md5trans_5C = bytearray((x ^ 0x5c) for x in range(256)) trans_36 = bytearray((x ^ 0x36) for x in range(256)) blocksize = md5().block_size # 64def hmac_md5(key, msg):if len(key) > blocksize:key = md5(key).digest()key = key + bytearray(blocksize - len(key))o_key_pad = key.translate(trans_5C)i_key_pad = key.translate(trans_36)return md5(o_key_pad + md5(i_key_pad + msg).digest())

尋找?guī)в腥毕莸墓：瘮?shù)

正如上面指出的，webhook讓允許自己選擇哈希算法。 PHP提供了許多非加密安全散列函數(shù)，可以通過hash_algos查詢獲知支持的函數(shù)列表，如crc32，fnv32和adler32，它們生成32位散列。這些散列函數(shù)是校驗(yàn)和，其被設(shè)計為檢驗(yàn)數(shù)據(jù)傳輸時是否出現(xiàn)了差錯，它們不是為了提供安全而設(shè)計的。如果可以找到一個足夠弱的散列算法，然后采用窮舉的手法去猜測發(fā)送的數(shù)據(jù)能被服務(wù)端檢驗(yàn)通過發(fā)的哈希值，從而繞過服務(wù)端的驗(yàn)證。

分析下adler32，它實(shí)際上是兩個16位哈希函數(shù)，其輸出連接在一起。當(dāng)處理短的數(shù)據(jù)時，它有一個已知的實(shí)現(xiàn)缺陷。當(dāng)與PHP的hash_hmac函數(shù)組合時，第二輪哈希將只傳遞68字節(jié)的數(shù)據(jù)到adler32，這嚴(yán)重限制了哈希過程開始時產(chǎn)生的哈希量。不僅散列的總數(shù)受到限制，而且在散列空間中也存在顯著的不均勻性。即使提供不同的數(shù)據(jù)也會導(dǎo)致許多散列是相同的。可能的校驗(yàn)和值的分布類似于滾動骰子，其中7是最可能的結(jié)果，并且滾動該范圍中的任何值的概率將從中值出來（6和8將具有下一個最高概率）。

poc中的代碼能夠?qū)⒄埱罅繌? ^ 32減少到大約100,000到400,000。?

本地測試

帶上X-Hub-Signature，且使用哈希函數(shù)adler32，訪問github-webhook-handler.php，為了方便驗(yàn)證在服務(wù)端打印了當(dāng)前的哈希值。

然后再利用po.php去生成哈希值，可以看到找到了服務(wù)端生成的hash值。?

總結(jié)

以上是生活随笔為你收集整理的hash_hmac函数使用不当造成的安全问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。

上一篇： bzoj2653: middle
下一篇： oracle如何清空一个用户下的所有表中