Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Timing attacks against web applications: Are they still practical?

4 views

Published on

Ivan Petrov in Bucharest, Romania on November 8-9th 2018 at DefCamp #9.

The videos and other presentations can be found on https://def.camp/archive

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Timing attacks against web applications: Are they still practical?

  1. 1. Timing attacks against web applications: Are they still practical? 09.11.2018 Ivan Petrov Penetration tester
  2. 2. Timing attacks against web applications: Are they still practical? - What is a timing attack? - What was our plan? - What did we do differently? - What did we achieve? - How practical are timing attacks (over the internet)? - Who are subjects to an attack? - What is an acceptable solution? 2/29
  3. 3. What is a timing attack? Basic string comparison in PHP 3/29
  4. 4. What is a timing attack? is_identical_function() 4/29
  5. 5. What is a timing attack? memcmp() 5/29
  6. 6. What is a timing attack? 2 5 6 c d 21 ns 16 ns 19 ns 2 5 6 e 18 ns 20 ns Key: 256c27ad3cd09366e9884a8c93747900 … Total execution time: 95 ns Total execution time: 80 ns 17 ns 22 ns 22 ns … 20 ns 6/29
  7. 7. 2 5 6 c d 21 ns 16 ns 19 ns Key: 256c27ad3cd09366e9884a8c93747900 Total execution time: 95 ns 17 ns 22 ns … What is a timing attack? 2 5 6 c 8 16 ns 14 ns 24 ns 18 ns 19 ns … 2 5 6 c 2 18 ns 21 ns 16 ns 21 ns 17 ns ? 22 ns Total execution time: 91 ns Total execution time: 115 ns 7/29
  8. 8. General scenario: Attacker Hop 1 Hop .. Hop N Web server Application Our plan 8/29
  9. 9. Prerequisite - We had access to the source code - A pass-the-hash vulnerability was present - A weak hash function was used (and without a salt) - There was no WAF/IDS/IPS in place - There was no reverse proxy, CDN, caching 9/29
  10. 10. Our plan Step 1: Step 2: Step 3: Step 4: Step 5: Study the application’s source code in details Pinpoint a particular function to exploit Conduct basic data collection (timing) Work to improve noise filtration Reduce the search space for the timing attack 10/29
  11. 11. Our plan What worked: - Application profiling using a profiler (xdebug, xhprof etc) - Measuring RTT via TCP timestamps - Making observations from user-space What didn’t work: - Timing different PHP functions used by the application - Average out web server’s performance (per version) 11/29
  12. 12. Calculating the RTT - Must NOT be done in user-space - Packet capturing yields reliable results (SYN,ACK) - TCP timestamps’ granularity – 1 ms-100 seconds - Tracing system calls (e.g. strace(1)) can be tricky - Different protocols can be routed differently 12/29
  13. 13. Calculating the RTT 13/29
  14. 14. Calculating the RTT 14/29
  15. 15. Calculating server response time 0.000978360 X.X.X.X → Y.Y.Y.Y HTTP 146 GET / HTTP/1.1 0.001722918 Y.Y.Y.Y → X.X.X.X TCP 66 80 → 33930 [ACK] Seq=1 Ack=81 Win=29056 Len=0 TSval=1737072019 TSecr=3816704019 0.004035262 Y.Y.Y.Y → X.X.X.X HTTP 481 HTTP/1.1 301 Moved Permanently (text/html) Packet capturing with tshark(1) 15/29
  16. 16. What else? Spikes. - Mirroring the target environment - Application profiling (function timing) - Execution timing per different environments - Calculating median absolute deviation (MAD) What do we use to identify them? 16/29
  17. 17. The target? More specifically. 17/29
  18. 18. Timing different functions 18/29
  19. 19. Timing different functions 19/29
  20. 20. Attack resources - On average: 14 000 requests per character - The hash is hexadecimal - utilizes a character set of 16 elements: a-f0- 9 - Hash length is 40 characters Rough statistics for the attack: ~ 224 000 per each position … or ~ 8 960 000 requests for full hash recovery 20/29
  21. 21. Difference to brute-forcing? Works for any user-supplied password no matter the complexity It’s simple. However… Brute-forcing would be preferable if the user has used a predictable password 21/29
  22. 22. Reducing the search space - It’s not necessary to go for a full hash (in some cases) - We can use rainbow tables to lookup partial hashes Some more basic statistics Estimation: elements to pick from * number of requests per element * length - First 10 characters are expected to be recovered with 2 240 000 requests - First 13 characters are expected to be recovered with 2 912 000 requests - First 20 characters are expected to be recovered with 4 480 000 requests 22/29
  23. 23. Demo
  24. 24. Is this practical? Advantages - Timing attacks can be more efficient than brute-forcing - A lot of developers are not paying attention to them Disadvantages - In most cases are easy to detect - Hard to execute and easy to fail - Require a MASSIVE amount of requests - Can be hindered by any standard WAF/IDS - A reverse proxy will almost completely render them useless 24/29
  25. 25. Who is vulnerable? - Applications that are not using timing-safe comparisons (constant-time algorithms) - Applications that have no rate limiting and/or monitoring in place - Shared hosting environments and virtualization can aid a timing attack 25/29
  26. 26. What can the consequences be? - Ranging from useless traffic to a complete server takeover depending on the timing differences - Resource exhaustion if costly operations are performed on the back-end and continuously abused over a period of time 26/29
  27. 27. Solution to timing attacks? - Do not solely rely on network jitter - Use constant-time algorithms for critical operations (auth, crypto) - Enforce a rate limiting policy 27/29
  28. 28. Opportunities and Limits of Remote Timing Attacks (2009) SCOTT A. CROSBY, DAN S. WALLACH and RUDOLF H. RIEDI Rice University Some astonishing researches Nanosecond Scale Remote Timing Attacks On PHP Applications: Time To Take Them Seriously? (2010) Padraic Brady 28/29
  29. 29. Questions & Feedback Thank you Bibliography available upon request www.tadgroup.com info@tadgroup.com

×