hash hashcode变化_没想到 Hash 冲突还能这么玩，你的服务中招了吗？
圖 by: 石頭
背景
其實(shí)這個問題我之前也看到過，剛好在前幾天，洪教授在某個群里分享的一個《一些有意思的攻擊手段.pdf》，我覺得這個話題應(yīng)該還是有不少人不清楚的，今天我就準(zhǔn)備來“實(shí)戰(zhàn)”一把，還請各位看官輕拍。
洪強(qiáng)寧(洪教授)，愛因互動創(chuàng)始人兼 CTO，曾任豆瓣首席架構(gòu)師，為中國 Python 用戶組(CPUG)的創(chuàng)立者之一。這才是真大佬，原來洪教授在宜信的時候，就有分享過這個內(nèi)容，可惜當(dāng)初不知道沒參加。看了之后才知道原來我上一篇的文章中講的 計時攻擊(Timing Attack) 也是其中的內(nèi)容之一。哈哈，后面有空再研究研究繼續(xù)講其他內(nèi)容。
Hash 沖突
啥叫 Hash 沖突？我們從 Hash 表(或者散列表)講起，我們知道在一個 hash 表的查找一個元素，期望的時間復(fù)雜度為 O(1)，怎么做到的呢？其實(shí)就是 hash() 函數(shù)在起作用。
初略來講，hash 表內(nèi)部實(shí)際存儲還是跟數(shù)組類似，用連續(xù)的內(nèi)存空間存儲元素，只要通過某種方法將將要存儲的元素映射為數(shù)組的下標(biāo)，即可像數(shù)組一樣通過下標(biāo)去讀取對應(yīng)的元素，這也是為什么能做到 O(1) 的原因。
Hash 示例以上圖為例，假設(shè)是我設(shè)計的一個 hash 函數(shù)，恰好滿足如下條件：
- hash("hello")=0：字符串 "hello" 就存儲數(shù)組下標(biāo)為 0 的地方；
- hash("world")=2："world" 存儲數(shù)組下標(biāo)為 2 的地方；
- hash("tangleithu")=5："tangleithu" 存儲數(shù)組下標(biāo)為 5 的地方；
目前來看一切好像很完美，但這終歸是假設(shè)，我不能假設(shè)這個 hash 都很完美的將不同的字符串都映射到了不同的下標(biāo)處。
另外來了個字符串，hash("石頭") = 2，怎么辦？這就是所謂的 “Hash 沖突”，最常見 Hash 沖突的解決方案其實(shí)就是“開鏈”法，其實(shí)還有比如線性試探、平方試探等等。
類似講解 HashMap 的文章滿大街都是，一搜一大把，本文就不詳述了。為了方便讀者理解，就簡單來個例子。
Hash沖突開鏈法開鏈法如上圖所示，我們存儲元素的時候，存儲形式為一個鏈表，當(dāng)沖突的時候，就在鏈表末尾直接添加沖突的元素。上圖示例恰好運(yùn)氣比較差，字符串 shitou，stone 算出來的下標(biāo)都為 2。
這樣一來，問題大了。原本我們期望 O(1) 的時間復(fù)雜度查找元素，現(xiàn)在變成在鏈表中線性查找了，而如果這個時候插入 個數(shù)據(jù)，最壞的情況下的時間復(fù)雜度就是 了。(這里就不討論鏈表轉(zhuǎn)樹的情形)
壞人可乘機(jī)而入這就又給壞人留下了想象空間。只要壞人精心設(shè)計一組要放進(jìn) hash 表的字符串，且讓這些字符串的 hashcode 都一樣，這就會導(dǎo)致 hash 沖突，結(jié)果會導(dǎo)致 cpu 要花費(fèi)大量的時間來處理 hash 沖突，造成 DoS(Denial of Service)攻擊。
而用 hash 表存儲的情形太常見了。在 Web 服務(wù)中，一般表單的處理都是用 hash 表來保存的(后端往往要知道通過某個具體的參數(shù) key 獲取對應(yīng)的參數(shù) value)。
實(shí)戰(zhàn)
本文石頭哥將以 Java SpringBoot 為例，嘗試進(jìn)行一次攻擊。
不過別以為這種 “Hash 沖突 DoS” 以為只有 Java 才有哦，什么 Python，Apache Tomcat/Jetty，PHP 之類都會有這個問題的。其實(shí)早在 2011 年年末的時候就被大量爆出了，有的框架陸陸續(xù)續(xù)有一些改進(jìn)和修復(fù)。詳細(xì)情況可以看這篇文章：oCERT-2011-003 multiple implementations denial-of-service via hash algorithm collision[1]。
這里，咱們給列舉其中一個 Apatch Tomcat，來自 CVE-2011-4858[2]。
Apache Tomcat before 5.5.35, 6.x before 6.0.35, and 7.x before 7.0.23 computes hash values for form parameters without restricting the ability to trigger hash collisions predictably, which allows remote attackers to cause a denial of service (CPU consumption) by sending many crafted parameters.
下面截圖來自洪教授的 PPT，但內(nèi)容的具體來源不詳了(嘗試找了下，沒找到)，大家參考參考就好。
實(shí)現(xiàn) hash 沖突 DoS 攻擊所須帶寬左邊表示用不同的語言(框架)實(shí)現(xiàn)這種攻擊所需要的帶寬，右邊是攻擊的 cpu 目標(biāo)。可以看出，實(shí)施這種攻擊成本其實(shí)挺低的(后文石頭的試驗也佐證了這一點(diǎn))。
不得不說 “PHP 是世界上最好的編程語言”(大家別打架)，還是有一定道理的，哈哈哈哈哈哈 ?(一張圖還不夠，再加一張)上面的語言排序，不一定對，大家參考一下即可，不用糾結(jié)具體的準(zhǔn)確性。
其實(shí)要驗證，方法當(dāng)然也相對簡單，只要找出產(chǎn)生沖突的不同字符串即可，具體語言可能不一樣。
talk is cheap
現(xiàn)在跟著我來嘗試進(jìn)行一次攻擊吧，本人用自己的筆記本進(jìn)行試驗(配置：MBP 13-inch，2.5 GHz Intel Core i7，16 GB 2133 MHz LPDDR3)。
首先構(gòu)造一把 hash 沖突的字符串，下面代碼是 hash 沖突的字符串對的實(shí)例，后面的其實(shí)可以通過前面排列組合生成。
System.out.println("Aa".hashCode());System.out.println("BB".hashCode());
System.out.println("BBBBBBBBBBBBBBBBBBBBBBBBAaBBBBAa".hashCode());
System.out.println("BBBBBBBBBBBBBBBBBBBBBBBBAaBBBBBB".hashCode());
//?輸出
2112
2112
2067858432
2067858432
具體生成過程本文不詳述了，感興趣可以看看 StackOverflow 上的這篇文章 Application vulnerability due to Non Random Hash Functions[3]，或者參考耗子叔的這篇 Hash Collision DoS 問題[4]。
然后我啟用一個 SpringBoot(2.2.2.RELEASE) 的 Web 服務(wù)，JDK 1.8(其實(shí)用 1.7 效果更明顯)。
@RequestMapping("/hash")public?String?hash(HttpServletRequest?request)?{
????//?Demo，簡單返回參數(shù)大小和其對應(yīng)hashCode
????int?size?=?request.getParameterMap().size();
????String?key?=?(String)(request.getParameterMap().keySet().toArray())[0];
????return?String.format("size=%s,?hashCode=%s",?size,?key.hashCode());
}
先試水一把(如下圖)，看看基本功能正常，用 curl 發(fā)送請求即可，然后將 post 的字段放在文件里面(太長也只能放文件中)。
curl 實(shí)驗結(jié)果生成的字符串不夠的話，還可以增加并發(fā)請求，可以借用類似 “Apache Benchmarking” 壓測的工具發(fā)送請求，我之前也有一篇文章介紹了這個命令 性能測試工具 - ab 簡單應(yīng)用，感興趣的可以參考一下。
沖突的 hashcode 一樣打個斷點(diǎn)看看效果，如上圖所示，確實(shí)所有的 hash 值都是一樣的。不過一次請求好像并沒有影響我電腦 cpu 的明顯變化。
我測試的字符串已經(jīng)是 29859 個了，正準(zhǔn)備生成更多的沖突的字符串進(jìn)行嘗試時，結(jié)果仔細(xì)一看才發(fā)現(xiàn)請求被截斷了，請求返回的參數(shù) size 大小為 10000。原來 SpringBoot 內(nèi)置的 tomcat 給做了手腳，看下圖，因為默認(rèn)的請求的參數(shù)個數(shù)大小被限制成 10000 了。
More than the maximum number of request parameters (GET plus POST) for a single request ([10,000]) were detected. Any parameters beyond this limit have been ignored. To change this limit, set the maxParameterCount attribute on the Connector.
post參數(shù)數(shù)量被限制一種方法當(dāng)然是去修改這個請求參數(shù)個數(shù)的限制。另外其實(shí)可以嘗試用 JDK 1.7 去驗證，應(yīng)該效果會更好(原因，聰明的讀者你肯定知道吧？)。這里石頭哥就懶得去折騰了，直接嘗試以量來取勝，用前文說的 ab 進(jìn)行并發(fā)提交請求，然后觀察效果。
這是我用如下參數(shù)跑的壓測結(jié)果：
ab?-c?200?-n?100000?-p?req.txt?'localhost:8080/hash'壓測的結(jié)果如圖所示：
ab 壓測 hash 沖突結(jié)果然后我們來看看 CPU 的變化情況，特意錄屏做了個動圖，可以看出還是相對比較明顯的。從基本不占用 cpu 到 39.6%，然后突然就漲到 158% 了。
hash-collision-demo動圖實(shí)際試驗中這個過程沒有一直持續(xù)(上面是重試過程中抓到的其中一次)，一方面因為本人用的 JDK 1.8，本來沖突后的查找過程已經(jīng)優(yōu)化了，可能效果并不明顯，另外也猜測可能會有一些 cache 之類的優(yōu)化吧，另外對于 10000 的量也還不夠？具體我也沒有深究了，感興趣的讀者可以去嘗試一下玩玩。
到這里實(shí)驗算成功了吧。
實(shí)驗成功就是拽我這還是單機(jī)，要是多搞幾個 client，不分分鐘把 Web 服務(wù)搞死啊。
防御方法
上面實(shí)驗算是成功了，那么防御方法呢？其實(shí)就是：
- 改 hash 算法算一種了；例如像有的用隨機(jī)算法作為 hash 函數(shù)的情況，可以用不同的隨機(jī)種子嘗試生成；但事實(shí)上并沒有完美的 hash 算法的。
- 本文實(shí)驗中的也遇到這個了，就是要限制請求的參數(shù)個數(shù)，以及請求長度。在不影響業(yè)務(wù)的情況下，限制盡可能更小；
- 上 WAF(Web Application Firewall)，用專業(yè)的防火墻清洗流量。
最后
本文只供學(xué)習(xí)交流使用，請大家不要輕易嘗試線上服務(wù)，不要輕易嘗試線上服務(wù)，不要輕易嘗試線上服務(wù)。
本人才疏學(xué)淺，如果有不對的地方，還望大家指出。
原創(chuàng)真心不易，希望你能幫我個小忙，如果本文內(nèi)容你覺得有所啟發(fā)和收獲，不要白piao，請幫忙點(diǎn)個“在看”(你至少應(yīng)該來個點(diǎn)贊吧)，或者轉(zhuǎn)發(fā)分享就更好啦，這將是我持續(xù)輸出更多優(yōu)質(zhì)文章的最強(qiáng)動力。?
推 薦?閱?讀當(dāng)程序猿解決完一個 Bug 后……
有了這幾個神器，瞬間逼格就上去了
面了 7 輪Google，最終還是逃不脫被掛的命運(yùn)
面試官：會玩牌吧？給我講講洗牌算法和它的應(yīng)用場景吧！
這 10 行比較字符串相等的代碼給我整懵了，不信你也來看看
震驚! 阿里的程序員也不過如此,竟被一個簡單的 SQL 查詢難住
參考資料
[1]oCERT-2011-003 multiple implementations denial-of-service via hash algorithm collision:?http://ocert.org/advisories/ocert-2011-003.html
[2]CVE-2011-4858:?https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4858
[3]Application vulnerability due to Non Random Hash Functions:?https://stackoverflow.com/questions/8669946/application-vulnerability-due-to-non-random-hash-functions
[4]Hash Collision DoS 問題:?https://coolshell.cn/articles/6424.html
—?【 THE END 】—本公眾號全部博文已整理成一個目錄，請在公眾號里回復(fù)「m」獲取3T技術(shù)資源大放送！包括但不限于：Java、C/C++，Linux，Python，大數(shù)據(jù)，人工智能等等。在公眾號內(nèi)回復(fù)「1024」，即可免費(fèi)獲取！！
總結(jié)
以上是生活随笔為你收集整理的hash hashcode变化_没想到 Hash 冲突还能这么玩，你的服务中招了吗？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： javascript json_Java
- 下一篇： python远程桌面控制_手把手教你如何