沒想到 Hash 沖突還能這么玩，你的服務中招了嗎？

背景

其實這個問題我之前也看到過，剛好在前幾天，洪教授在某個群里分享的一個《一些有意思的攻擊手段.pdf》，我覺得這個話題應該還是有不少人不清楚的，今天我就準備來“實戰(zhàn)”一把，還請各位看官輕拍。

洪強寧（洪教授），愛因互動創(chuàng)始人兼 CTO，曾任豆瓣首席架構師，為中國 Python 用戶組（CPUG）的創(chuàng)立者之一。

這才是真大佬，原來洪教授在宜信的時候，就有分享過這個內容，可惜當初不知道沒參加?？戳酥蟛胖涝瓉砦疑弦黄奈恼轮兄v的 計時攻擊（Timing Attack） 也是其中的內容之一。哈哈，后面有空再研究研究繼續(xù)講其他內容。

Hash 沖突

啥叫 Hash 沖突？我們從 Hash 表（或者散列表）講起，我們知道在一個 hash 表的查找一個元素，期望的時間復雜度為 O(1)，怎么做到的呢？其實就是 hash() 函數(shù)在起作用。

初略來講，hash 表內部實際存儲還是跟數(shù)組類似，用連續(xù)的內存空間存儲元素，只要通過某種方法將將要存儲的元素映射為數(shù)組的下標，即可像數(shù)組一樣通過下標去讀取對應的元素，這也是為什么能做到 O(1) 的原因。

以上圖為例，假設是我設計的一個 hash 函數(shù)，恰好滿足如下條件：

• hash("hello")=0：字符串 "hello" 就存儲數(shù)組下標為 0 的地方；
• hash("world")=2："world" 存儲數(shù)組下標為 2 的地方；
• hash("tangleithu")=5："tangleithu" 存儲數(shù)組下標為 5 的地方；

目前來看一切好像很完美，但這終歸是假設，我不能假設這個 hash 都很完美的將不同的字符串都映射到了不同的下標處。

另外來了個字符串，hash("石頭") = 2，怎么辦？這就是所謂的 “Hash 沖突”，最常見 Hash 沖突的解決方案其實就是“開鏈”法，其實還有比如線性試探、平方試探等等。

類似講解 HashMap 的文章滿大街都是，一搜一大把，本文就不詳述了。為了方便讀者理解，就簡單來個例子。

開鏈法如上圖所示，我們存儲元素的時候，存儲形式為一個鏈表，當沖突的時候，就在鏈表末尾直接添加沖突的元素。上圖示例恰好運氣比較差，字符串 shitou，stone 算出來的下標都為 2。

這樣一來，問題大了。原本我們期望 O(1) 的時間復雜度查找元素，現(xiàn)在變成在鏈表中線性查找了，而如果這個時候插入 個數(shù)據(jù)，最壞的情況下的時間復雜度就是 了。（這里就不討論鏈表轉樹的情形）

這就又給壞人留下了想象空間。只要壞人精心設計一組要放進 hash 表的字符串，且讓這些字符串的 hashcode 都一樣，這就會導致 hash 沖突，結果會導致 cpu 要花費大量的時間來處理 hash 沖突，造成 DoS（Denial of Service）攻擊。

而用 hash 表存儲的情形太常見了。在 Web 服務中，一般表單的處理都是用 hash 表來保存的（后端往往要知道通過某個具體的參數(shù) key 獲取對應的參數(shù) value）。

實戰(zhàn)

本文石頭哥將以 Java SpringBoot 為例，嘗試進行一次攻擊。

不過別以為這種 “Hash 沖突 DoS” 以為只有 Java 才有哦，什么 Python，Apache Tomcat/Jetty，PHP 之類都會有這個問題的。其實早在 2011 年年末的時候就被大量爆出了，有的框架陸陸續(xù)續(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，但內容的具體來源不詳了（嘗試找了下，沒找到），大家參考參考就好。

左邊表示用不同的語言（框架）實現(xiàn)這種攻擊所需要的帶寬，右邊是攻擊的 cpu 目標?？梢钥闯?，實施這種攻擊成本其實挺低的（后文石頭的試驗也佐證了這一點）。

上面的語言排序，不一定對，大家參考一下即可，不用糾結具體的準確性。

其實要驗證，方法當然也相對簡單，只要找出產生沖突的不同字符串即可，具體語言可能不一樣。

talk is cheap

現(xiàn)在跟著我來嘗試進行一次攻擊吧，本人用自己的筆記本進行試驗（配置：MBP 13-inch，2.5 GHz Intel Core i7，16 GB 2133 MHz LPDDR3）。

首先構造一把 hash 沖突的字符串，下面代碼是 hash 沖突的字符串對的實例，后面的其實可以通過前面排列組合生成。

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 服務，JDK 1.8（其實用 1.7 效果更明顯）。

@RequestMapping("/hash")
public?String?hash(HttpServletRequest?request)?{
????//?Demo，簡單返回參數(shù)大小和其對應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 的字段放在文件里面（太長也只能放文件中）。

生成的字符串不夠的話，還可以增加并發(fā)請求，可以借用類似 “Apache Benchmarking” 壓測的工具發(fā)送請求，我之前也有一篇文章介紹了這個命令 性能測試工具 - ab 簡單應用，感興趣的可以參考一下。

打個斷點看看效果，如上圖所示，確實所有的 hash 值都是一樣的。不過一次請求好像并沒有影響我電腦 cpu 的明顯變化。

我測試的字符串已經是 29859 個了，正準備生成更多的沖突的字符串進行嘗試時，結果仔細一看才發(fā)現(xiàn)請求被截斷了，請求返回的參數(shù) size 大小為 10000。原來 SpringBoot 內置的 tomcat 給做了手腳，看下圖，因為默認的請求的參數(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.

一種方法當然是去修改這個請求參數(shù)個數(shù)的限制。另外其實可以嘗試用 JDK 1.7 去驗證，應該效果會更好（原因，聰明的讀者你肯定知道吧？）。這里石頭哥就懶得去折騰了，直接嘗試以量來取勝，用前文說的 ab 進行并發(fā)提交請求，然后觀察效果。

這是我用如下參數(shù)跑的壓測結果：

ab?-c?200?-n?100000?-p?req.txt?'localhost:8080/hash'

壓測的結果如圖所示：

然后我們來看看 CPU 的變化情況，特意錄屏做了個動圖，可以看出還是相對比較明顯的。從基本不占用 cpu 到 39.6%，然后突然就漲到 158% 了。

實際試驗中這個過程沒有一直持續(xù)（上面是重試過程中抓到的其中一次），一方面因為本人用的 JDK 1.8，本來沖突后的查找過程已經優(yōu)化了，可能效果并不明顯，另外也猜測可能會有一些 cache 之類的優(yōu)化吧，另外對于 10000 的量也還不夠？具體我也沒有深究了，感興趣的讀者可以去嘗試一下玩玩。

到這里實驗算成功了吧。

我這還是單機，要是多搞幾個 client，不分分鐘把 Web 服務搞死啊。

防御方法

上面實驗算是成功了，那么防御方法呢？其實就是：

• 改 hash 算法算一種了；例如像有的用隨機算法作為 hash 函數(shù)的情況，可以用不同的隨機種子嘗試生成；但事實上并沒有完美的 hash 算法的。
• 本文實驗中的也遇到這個了，就是要限制請求的參數(shù)個數(shù)，以及請求長度。在不影響業(yè)務的情況下，限制盡可能更小；
• 上 WAF（Web Application Firewall），用專業(yè)的防火墻清洗流量。

最后

本文只供學習交流使用，請大家不要輕易嘗試線上服務，不要輕易嘗試線上服務，不要輕易嘗試線上服務。

參考資料

[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

有道無術，術可成；有術無道，止于術

歡迎大家關注Java之道公眾號

好文章，我在看??