What You Don’t Know About HTTP Header Attacks WILL Hurt You!

AUTHOR:  Howard Jeng

When running a web service, it’s pretty safe to say that anything strange you see in the logs is a hacking attempt. Some hacking attempts are fairly obvious as to how they’re trying to get into your system: trying to brute force passwords or trying to access the default admin account for a common blogging software package. One of the less obvious are HTTP header attacks. As the name suggests HTTP header attacks are HTTP requests that contain unusual data in the HTTP headers. One of the attacks that has been tried on our servers had a user agent string that looked like:

This takes advantage of the bash shellshock vulnerability to execute arbitrary code placed into an environment variable. The attack relies on the fact that some CGI implementations pass HTTP headers to subprocesses via environment variables. If you did have a vulnerable system with such a CGI implementation it would then download a perl script from the internet with wget and execute it.

Of course bash isn’t the only kind of code that can be injected through HTTP headers. Another interesting class of HTTP header attacks are SQL injection attacks. SQL injection attacks are depressingly common due to the naive way that many applications create SQL queries with basic string concatenation. One recently disclosed HTTP header SQL injection attack (from September 2015) was found in version 2.0.0 of the Limit Login Attempt plugin for WordPress. There is code that built an SQL query like so:

Where the getip() function looked like:

Here the HTTP_CLIENT_IP and HTTP_X_FORWARD_FOR values come from the HTTP header values. This basically means that the value for the header would be placed directly in the query without sanitization. So a HTTP X-Forwarded-For header could be used to execute something similar to a Bobby Tables attack.

comic
https://xkcd.com/327/

In this case the developers chose to fix the problem by escaping the string in the getip() function.

Often these kind of attacks require some knowledge of the tables on the server, which can be fairly easy to determine for open source projects. However, many databases have admin tables with well known default or fixed names that could be manipulated if the executing code has the right permissions. As such, there are a shocking number of out of the box exploits that can work on improperly sanitized inputs. Tools such as sqlmap can be used to see if any of those out of the box exploits will work on your own code.

Of course, as string data, HTTP header processing is vulnerable to all the normal string processing issues that may happen such as buffer overflows in languages where this is a problem. In particular some people have made the mistake of assuming that HTTP headers containing IP addresses will always contain a validly formatted IPv4 dot decimal string and only allocate enough space for the 15 characters required for the longest such string and then use a non-length aware string copy to place the value into the buffer.

6 Best Practices for Mitigating HTTP Header Attacks:

  1. Keep the software on your servers up to date. A vulnerability targeting Shellshock won’t work on recent versions of bash.
  2. Limit extraneous software installed on your servers. An attack on your server can’t take advantage of software that’s not there. For instance, the first exploit would also fail if wget or perl were not installed. (Admittedly getting rid of perl on many servers is impractical at best.)
  3. For maximum protection your firewalls should contain rules for both incoming and outgoing connections. An exploit relying on downloading a file from the internet won’t work if the connection is blocked.
  4. Run your services with the minimum permissions possible. The principle of least privilege can limit the damage done if an exploit does get downloaded and run on one of your servers. The principle of least privilege also applies to things like database user permissions. An SQL injection attack to drop a table won’t work if the authenticated user doesn’t have permission to drop tables.
  5. Sanitize and sanity check all user supplied inputs – and remember that for security purposes, HTTP headers should be considered user supplied input. In particular escape string data passed to APIs that require it and don’t assume that HTTP headers that should contain IP addresses always actually contain IP addresses.
  6. Try using vulnerability testing software. They won’t catch everything, but will at least let you know if you have any particularly silly issues with your code or configurations.

 

Here at Medium One we keep in mind all of the above best practices. We are constantly vigilant in protecting our services and continually look at new ways to prevent hacking attempts. This includes analyzing failed attacks on our systems and auditing not just the specific attempts but those classes of attacks against our services. We can proudly claim that we’ve never detected a successful attack on our systems and certainly have never suffered from security related downtime.

So watch your header handling and happy web development!

www.mediumone.com

Comments are closed, but trackbacks and pingbacks are open.