Hash DoS Attack

4,789 views

Published on

These are the slides from a guest talk "Hash DoS Attack" held at Faculty of Electrical Engineering and Computing 2014 (Croatia / Zagreb 17th January 2014) by Miroslav Stampar

Published in: Technology, Travel
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,789
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
54
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Hash DoS Attack

  1. 1. Hash DoS Attack Miroslav Štampar (mstampar@zsis.hr) Hash DoS Attack Miroslav Štampar (mstampar@zsis.hr)
  2. 2. FER 2014, Zagreb (Croatia) January 17th, 2014 2 What is DoS (Denial of Service)? “...attack where an attacker attempts to prevent legitimate users from accessing information or services...” (source: US-CERT)
  3. 3. FER 2014, Zagreb (Croatia) January 17th, 2014 3 High bandwidth DoS Exhaustion of (network) resources using high speed packet traffic generation Bandwidth is the most important factor TCP/SYN Flood, UDP Flood, ICMP Flood, HTTP Flood, Xmas Attack, etc. Low sophistication level (i.e. script-kiddie) Low to medium success rate (mostly depending on target's security awareness) Rate limitation, signatures, traffic anomalies, traffic redirection (i.e. CloudFlare), challenge/ response, etc. Booters/Stressers (e.g. 60GBps – 24.99$/1h)
  4. 4. FER 2014, Zagreb (Croatia) January 17th, 2014 4 Low bandwidth DoS Exhaustion of resources without special bandwidth requirements In most cases one broadband line is enough Targeting higher layers of OSI model Standards, protocols and applications are (usually) made without covering all “malicious” scenarios (virtually impossible) Application Attacks, Slow Attacks, VoIP DoS, DNS Amplification, NTP Amplification, etc. Medium to high success rate Mitigation is hard (usually done at lower layers in generic manner)
  5. 5. FER 2014, Zagreb (Croatia) January 17th, 2014 5 #DoS Denial of Service through hash table (i.e. dictionary) multi-collisions (oCERT-2011-003) “...an attacker can degenerate the hash table by sending lots of colliding keys...” This issue has been known since at least 2003, but influenced only Perl and CRuby to adapt Insertion is O(n) in case of collision instead of O(1) (i.e. O(n²) for inserting n elements) POST requests are most interesting for this attack (typical malicious data is 1-4MB) 100% of CPU usage for up to several hours per single HTTP request
  6. 6. FER 2014, Zagreb (Croatia) January 17th, 2014 6 Example HTTP request
  7. 7. FER 2014, Zagreb (Croatia) January 17th, 2014 7 Consequences
  8. 8. FER 2014, Zagreb (Croatia) January 17th, 2014 8 Affected versions Apache Tomcat – 5.5.34 and prior, 6.0.34 and prior, 7.0.22 and prior Java – all versions JRuby – 1.6.5 and prior Microsoft ASP.NET – all versions (if unpatched with MS11-100) PHP – 5.3.8 and prior, 5.4.0RC3 and prior Python – 3.3.0 and prior (inadequate fix in 2.7.3 and 3.2.3) Ruby – 1.8.7-p356 and prior ...
  9. 9. FER 2014, Zagreb (Croatia) January 17th, 2014 9 Dictionary / Hash table HTTP request parameters are stored in a dictionary (i.e. {}) for fast and easy lookup Most common implementation of the dictionary is a hash table Insert, delete and lookup are (normally) being made with O(1) Hash tables must be able to deal with hash collisions (expected phenomenon) Used algorithms have to be fast and provide reasonable distribution of hashes No need for “cryptographically secure” properties (like in algorithms MD5 or SHA1)
  10. 10. FER 2014, Zagreb (Croatia) January 17th, 2014 10 Library analogy Imagine a librarian in a (huge) new library He wants to be able to do the lookups as fast as possible Instead of sequential (i.e. alphabetical) fill up, he programs a clever little “black box” that gives the location based on a book's title Result is (mostly) unique and calculated in a highly dispersed manner In case of collision he'll just put the book beside the existing or run another iteration In programming world that “black box” is called a hash algorithm
  11. 11. FER 2014, Zagreb (Croatia) January 17th, 2014 11 Insertion (oversimplified)
  12. 12. FER 2014, Zagreb (Croatia) January 17th, 2014 12 DJBX33A / DJBX31A / DJBX33X Daniel J. Bernstein “Times 33 Addition” Popular hash algorithm family used across number of programming languages uint32_t djbx33a(const char *arKey, uint32_t nKeyLength) { uint32_t hash = 5381; for (; nKeyLength > 0; nKeyLength -=1) { hash = ((hash << 5) + hash) + *arKey++; } return hash; } DJBX33A used in PHP 5, DJBX31A used in Java, DJBX33X used in PHP 4 and .NET, etc.
  13. 13. FER 2014, Zagreb (Croatia) January 17th, 2014 13 Demo #1 Brute force collision search
  14. 14. FER 2014, Zagreb (Croatia) January 17th, 2014 14 Equivalent substrings Characteristic of linear hash functions (e.g. DJBX33A) If hashes of two strings collide then hashes of strings having them as substrings (at same position) will collide too djbx33a(s)=33 n ×5381+∑ i=1 i=n 33 n−i ×si djbx33a(' ws' )=332 ×5381+331 ×119+115=5863951 djbx33a(' xR ')=332 ×5381+331 ×120+82=5863951 djbx33a(' AwsB')=334 ×5381+333 ×65+332 ×119+331 ×115+66=6383910258 djbx33a(' AxRB')=33 4 ×5381+33 3 ×65+33 2 ×120+33 1 ×82+66=6383910258
  15. 15. FER 2014, Zagreb (Croatia) January 17th, 2014 15 Counting method Popular method for linear hash functions If hashes of two strings collide then hashes of their binary permutations will collide too djbx33a(' ws' )=33 2 ×5381+33 1 ×119+115=5863951 djbx33a(' xR' )=332 ×5381+331 ×120+82=5863951 djbx33a(' wsws' )=33 4 ×5381+33 3 ×119+33 2 ×115+33 1 ×119+115=6385846681 djbx33a(' wsxR' )=334 ×5381+333 ×119+332 ×115+331 ×120+82=6385846681 djbx33a(' xRws')=33 4 ×5381+33 3 ×120+33 2 ×82+33 1 ×119+115=6385846681 djbx33a(' xRxR' )=334 ×5381+333 ×120+332 ×82+331 ×120+82=6385846681 ' ws'=0,' xR'=1 djbx33a(00)=djbx33a(01)=djbx33a(10)=djbx33a(11) djbx33a(000)=djbx33a(001)=djbx33a(010)=djbx33a(011)=djbx33a(100)=...
  16. 16. FER 2014, Zagreb (Croatia) January 17th, 2014 16 Demo #2 Counting method collision search
  17. 17. FER 2014, Zagreb (Croatia) January 17th, 2014 17 Meet-in-the-middle (1) In case of non-linear hash functions (e.g. DJBX33X) guessing (brute force) approach seems to be the obvious way Choose target string (e.g. 'XzwAr2tq') and find colliding matches by birthday (guessing) attack 50% probability for hitting a target with the chosen hash value in tries (if the hash is a 32-bit value) 50% probability for hitting a target with one of two chosen hash values in tries (if the hash is a 32-bit value) ... 2 31 230
  18. 18. FER 2014, Zagreb (Croatia) January 17th, 2014 18 Meet-in-the-middle (2) This method tries to attack more than one (intermediate) target at a time Necessity is that the final hash value uniquely represents hash internal state and that hash iterative function can be inverted Searching for all strings s of length n having a final hash value (colliding) Iterate over all possible l-sized postfix strings and match with random m-sized prefix strings hi≡33×hi−1⊕si (mod 232 ) 33×1041204193≡1(mod 2 32 ) 1041204193×(hi⊕si )≡hi−1(mod 232 ) hn
  19. 19. FER 2014, Zagreb (Croatia) January 17th, 2014 19 Meet-in-the-middle (3) Choose arbitrary values m and l such as m+l=n (value l will depend on available memory) Choose arbitrary hash value Iterate over all l-sized strings and store them into the memory together with respective hash states got by inverse iterative process Perform a birthday (guessing) attack by randomly finding m-sized strings having Combining such m-sized (prefix) string value with corresponding (stored) l-sized (postfix) string value gives a colliding result Results are fastest obtained when m=l=n/2 hn−l hn hm=hn−l s=sm+sl
  20. 20. FER 2014, Zagreb (Croatia) January 17th, 2014 20 Meet-in-the-middle (4)
  21. 21. FER 2014, Zagreb (Croatia) January 17th, 2014 21 Meet-in-the-middle (5) Splitting in the middle (m=l=n/2) reduces the complexity of this attack by square root 50% probability for hitting a target with the chosen hash value in tries (if the hash is a 32-bit value) Also works for linear hash functions (e.g. DJBX33A) Originally targeting encryption methods achieving increased security by using multiple iterations of the same algorithm (e.g. 3DES) 215.5
  22. 22. FER 2014, Zagreb (Croatia) January 17th, 2014 22 Demo #3 Meet-in-the-middle collision search
  23. 23. FER 2014, Zagreb (Croatia) January 17th, 2014 23 Demo #4 LAMP Server (PHP 5)
  24. 24. FER 2014, Zagreb (Croatia) January 17th, 2014 24 Demo #5 IIS Server (ASP.NET)
  25. 25. FER 2014, Zagreb (Croatia) January 17th, 2014 25 Mitigation (low level) Hash (seed) randomization new seed is generated on every interpreter, application and/or system start breaking code that incorrectly relies on specific ordering of dictionary keys (official explanation from Python team) CPython (-R) random seed has been successfully remotely recovered (by Jean-Philippe Aumasson and Daniel J. Bernstein :) Changing hash algorithm (e.g. to SipHash chosen by Python, Ruby, Perl, Rust, FreeBSD, Redis, etc.)
  26. 26. FER 2014, Zagreb (Croatia) January 17th, 2014 26 Mitigation (high level) Limiting CPU time (e.g. max_input_time in PHP, CGITimeout in IIS, etc.) Limiting maximum POST size (e.g. post_max_size in PHP, suhosin.post.max_value_length in Suhosin hardened PHP, maxAllowedContentLength in ASP.NET, etc.) Limiting maximum number of HTTP request parameters (e.g. suhosin.request.max_vars in Suhosin hardened PHP, org.apache.tomcat.util.http.Parameters.M AX_COUNT in Tomcat, etc.)
  27. 27. FER 2014, Zagreb (Croatia) January 17th, 2014 27 Questions?

×