This document discusses the practicality of timing attacks against web applications. It begins by explaining what a timing attack is and detailing the author's plan to conduct one against a target application. The plan involved studying the application's code, pinpointing an exploitable function, collecting timing data, filtering noise, and reducing the search space. The author was able to measure response times and identify spikes but encountered challenges averaging server performance. They demonstrate conducting a timing attack to recover hashed credentials over many requests. Ultimately, while timing attacks can be efficient, they are difficult to execute remotely and most applications and servers have protections that render the attacks impractical. Constant-time algorithms and rate limiting are presented as solutions to prevent these types of attacks.

1. Timing attacks against web applications:
Are they still practical? 09.11.2018
Ivan Petrov
Penetration tester

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. What is a timing attack?
Basic string comparison in PHP
3/29

4. What is a timing attack?
is_identical_function()
4/29

5. What is a timing attack?
memcmp()
5/29

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. 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. General scenario:
Attacker Hop 1 Hop .. Hop N
Web
server
Application
Our plan
8/29

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. 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. 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. 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. Calculating the RTT
13/29

14. Calculating the RTT
14/29

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. 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. The target? More specifically.
17/29

18. Timing different functions
18/29

19. Timing different functions
19/29

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. 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. 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. Demo

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. 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. 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. 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. 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. Questions & Feedback
Thank you
Bibliography available upon request
www.tadgroup.com
info@tadgroup.com