HTTP Headers… the Achilles’ heel of many applications, (Fri, May 5th)

When browsing a target web application, a pentester is looking for all “entry” or “injection” points present in the pages. Everybody knows that a static website with pure HTML code is less juicy compared to a website with many forms and gadgets where visitors may interact with it. Classic vulnerabilities (XSS, SQLi) are based on the user input that is abused to send unexpected data to the server. Here is a very simple GET example:

Or an HTTP POST form:

<form action=“/view.php” method="post">
  <input name=“article" id=“article">
  <input type="submit" value=“Submit">

In both cases, the pentester will have a deeper look at the values that can be passed to the article parameter.

But, there are alternative ways to interact with a website. Today, modern sites have multiple versions available. Depending on the visitor’s browser,  a “mobile” or “light” version of the website can be returned, optimised for mobile phones or tablets. Some websites react in different ways just based on the User-Agent passed by the browser. Chris John Riley developed a few years ago a nice script that I’m still using today during the reconnaissance phase of a penetration test: UA-Tester[1]. It performs multiple HTTP requests with different User-Agent strings and searches for response body, server headers, HTTP code, etc:

$ ./ -u -f my-useragents.txt -v

The HTTP referrer is also a very nice way to abuse some websites. A few years ago, I remember a Belgian newspaper which granted access to paid content based on the referrer! The HTTP headers passed in every HTTP requests are also a good source of vulnerabilities. We have a new example with two WordPress vulnerabilities released this week: CVE-2017-8295[2] and a second one based on CVE-2016-10033[3].

The first affect the password reset feature provided by WordPress (up to version 4.7.4). It might allow an attacker to get the password reset link sent via email and use it to compromise the user account then have more access to the WordPress site. The second one has been discovered in 2016 but disclosed two days ago. This one affects the PHPMailer mailer component of WordPress core 4.6. The WordPress development team initially reported as not affected by the bug discovered in 2016. They are interesting because both are vulnerable to the injection of malicious data through HTTP headers. Many web servers (Apache included) set the SERVER_NAME variable using the hostname supplied by the client.

Keep in mind: When you read “… supplied by the client”, you must understand: “… that can be altered or poisoned by the client”.

Here is the code that is vulnerable in the first vulnerability:

if ( !isset( $from_email ) ) {
  $sitename = strtolower( $_SERVER['SERVER_NAME'] );
  if ( substr( $sitename, 0, 4 ) == 'www.' ) {
    $sitename = substr( $sitename, 4 );
  $from_email = 'wordpress@' . $sitename;

WordPress just uses the “Host:” HTTP header provided by the client’s browser. PHP fills the variable SERVER_NAME based on this header.

Other techniques to abuse HTTP headers exist. By example, HTTP Header injection:

In the case of vulnerable code, the server could return headers like this:

HTTP/1.1 302 Object moved
Connection: close
Location: search.php?article=1234
Set-Cookie: MyCookie=pwn3d
Content-Length: 105

Those attacks are not new, most of them are known for years but are still relevant today. Also, think outside HTTP. Most protocols use headers that might be abuse. A good example was Postfix in 2014 which was vulnerable to the ShellShock attack via SMTP headers[4].

The Top-10 OWASP project keeps “injection” (of any kind) as the first security issue since 2010[5]. They also have a project called “Secure Headers Project” which address this problem[6]. To resume, never trust data coming from the client side!







Xavier Mertens (@xme)

ISC Handler – Freelance Security Consultant


Source: SANS Internet Storm Center, InfoCON: green @ May 5, 2017 at 02:57AM