Briefly Exploring HTTP Header Vulnerabilities

I’ve recently come across (or read about) several vulnerabilities dealing with HTTP headers so I decided to briefly write about them. Each vulnerability involved a different header, was discovered differently, and had a different result. Vulnerabilities involving HTTP headers are often missed by automated scanners, so I try to mention how the flaws were discovered by me and others.

Host header

Inspired by this blog post, I started testing the Host header on my target site. I noticed the host name was reflected on the page:

I had previously seen odd behavior when changing the host header to a local IP address, so I changed my host header to 127.0.0.1, which was reflected in the response:

I was previously aware of a welcome page, so I tried browsing to it with my host header set to 127.0.0.1. Unfortunately, I was redirected back to login. Next step was changing the header to localhost. Once again, I browsed to the welcome page and was granted administrative access to the application:

Connection header

This vulnerability is a heap buffer overflow and affects HP iLO 4 platform. It was discovered by Alexandre Gazet from Airbus and Fabien Perigaud (detailed here). It is an interesting read and worth your time, but the short of it is that if a Connection header of greater than 28 characters is sent, then access is granted via the API. You can test this by sending an unauthenticated request to https://<target iLO system>/rest/v1/AccountService/Accounts with a Connection header of greater than 28 characters. If vulnerable, the response will be a 200. Otherwise, you’ll get a 401.

An exploit was released (here) that sends a request to the API and creates an administrative user on the system. It works:

X-Forwarded-For header

My friend Adam Willard found that he could bypass an IP blacklist via the X-Forwarded-For header. While on the network we were testing, a request to https://www.exploit-db.com/ returned this:

He thought it was strange that a username was shown, so he used the X-Forwarded-For header to see if he could make it display a different user name:

It worked:

So naturally, we put the request in Burp Intruder and started cycling through IP addresses in order to enumerate user names, however we noticed a few of the requests were not getting blocked:

Turns out several of the IP addresses (or associated user accounts) were exempt from any blacklist, and changing the header value to any of those IP addresses allowed a user to bypass restrictions:

Authorization header

I haven’t got a chance to play with this one, but RedTeam Pentesting GmbH discovered an RCE vulnerability in CyberArk via the Authorization header (detailed here). Once again worth a read, but to summarize: ysoserial.exe can be used to create a serialized command (for example ‘ping attackersystem.com’), which will be executed when used as the value of the Authorization header.

Fuzzing headers

Of course, Burp Suite scanner will scan headers, but like most scanners it is limited in its payloads and often does not have the context needed to discover header related vulns. That being said, the scanner and the extension Collaborator Everywhere are pretty great (excellent blog post on collaborator everywhere).

In addition to utilizing Burp, I decided to write a Python3 tool to fuzz various headers. The tool, http_header_fuzzer.py, is a multithreaded scanner that conducts multiple tests against various headers. The type of test determines the payloads that are used in each header value, and for each request several attributes of the response are recorded (HTTP status code, response length, response time, and whether the input reflected into the response). Analyzing these attributes against the input can help you find many potential bugs. The code is available on my GitHub, along with usage instructions. Of course, feedback is welcome.

Leave a Reply

Your email address will not be published. Required fields are marked *