Internet Timing Attacks: Real World Examples

TL;DR

Yes, timing attacks have been successful over the internet, though they’re complex to pull off. They exploit subtle variations in how long it takes a server to respond to requests, revealing information about internal processes like password checking. This guide explains what they are, real-world cases, and how to protect against them.

What is a Timing Attack?

A timing attack isn’t about breaking encryption directly. Instead, it measures the time it takes for a server to process information. Even small differences in response time can give clues. For example, if password verification takes longer when you enter correct characters compared to incorrect ones, an attacker could slowly guess your password character by character.

Real-World Cases

1. OpenSSL Heartbleed (2014): While not a *pure* timing attack, Heartbleed exposed memory contents which included sensitive data used in cryptographic operations. Timing attacks could then be used to refine guesses about the exposed information.
2. BREACH Attack (2013): This targeted HTTP compression. By injecting content into HTTPS traffic and observing changes in compressed response sizes based on timing, attackers could recover cookies containing session IDs. It worked because some web servers didn’t properly handle compression with encrypted data.
3. Lucky Thirteen Attack (2013): This attack exploited weaknesses in TLS implementations to recover plaintext from encrypted traffic by analysing the timing of cipher block chaining operations.
4. Password Guessing on Remote Servers: Numerous cases involve attackers remotely guessing passwords, character-by-character, using timing differences as feedback. This is more common against older systems or poorly configured applications.

How Timing Attacks Work (Simplified)

Imagine a simple password check:

if (enteredPassword == storedPassword) {
  // Password correct - takes slightly longer due to more processing.
} else {
  // Password incorrect - faster response.
}

An attacker sends many requests with different passwords. By measuring the time each request takes, they can identify which characters are likely correct.

Protecting Against Timing Attacks: Steps You Can Take

1. Constant-Time Programming: This is the most effective defence. Write code that takes the same amount of time to execute regardless of the input data. This eliminates timing variations.
   • Avoid conditional branches (if statements) based on secret data within critical sections.
   • Use bitwise operations instead of comparisons where possible.
2. Regularly Update Software: Keep your operating systems, web servers, and applications patched with the latest security updates. Vendors often fix timing vulnerabilities in new releases.
3. Use Strong Cryptographic Libraries: Employ well-vetted cryptographic libraries that are designed to resist timing attacks (e.g., OpenSSL, BoringSSL).
4. Disable Compression on Sensitive Data: As demonstrated by BREACH, compression can introduce vulnerabilities. If you don’t need it for sensitive data, turn it off.
5. Implement Rate Limiting: Limit the number of requests from a single IP address within a given timeframe. This makes brute-force timing attacks more difficult.

   # Example using iptables (Linux)
   iptables -A INPUT -p tcp --dport 80 -m recent --name TIMING_ATTACK --set
   iptables -A INPUT -p tcp --dport 80 -m recent --update seconds 60 --hitcount 10 -j DROP

6. Add Noise/Random Delays: Introduce small, random delays to all responses. This makes it harder for attackers to accurately measure timing differences.
   • Be careful with this approach; excessive noise can impact performance.
7. Monitor Server Performance: Look for unusual patterns in response times that might indicate an attack is underway.

Further Resources

• OWASP Timing Attack Cheat Sheet: https://owasp.org/www-project-timing-attack/