HTTP Headers... the Achilles' heel of many applications

Published: 2017-05-05
Last Updated: 2017-05-05 07:49:58 UTC
by Xavier Mertens (Version: 1)
0 comment(s)

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:

http://www.company.com/shop/view.php?article=1234

Or an HTTP POST form:

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

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:

$ ./ua-tester.py -u www.company.com -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:

http://www.company.com/shop/view.php?article=1234%0D%0ASet-Cookie%3A%20MyCookie=pwn3d

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!

[1] https://packetstormsecurity.com/files/94305/UA-Tester-User-Agent-Tester-1.03.html
[2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8295
[3] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10033
[4] https://www.exploit-db.com/exploits/34896/
[5] https://github.com/OWASP/Top10/raw/master/2017/OWASP%20Top%2010%20-%202017%20RC1-English.pdf
[6] https://www.owasp.org/index.php/OWASP_Secure_Headers_Project

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key

0 comment(s)
ISC Stormcast For Friday, May 5th 2017 https://isc.sans.edu/podcastdetail.html?id=5488

Comments

What's this all about ..?
password reveal .
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure:

<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.

<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
https://thehomestore.com.pk/
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
https://defineprogramming.com/
https://defineprogramming.com/
Enter comment here... a fake TeamViewer page, and that page led to a different type of malware. This week's infection involved a downloaded JavaScript (.js) file that led to Microsoft Installer packages (.msi files) containing other script that used free or open source programs.
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
https://clickercounter.org/
Enter corthrthmment here...

Diary Archives