Friday 2 May 2014

Exploiting XSS using OWASP Xenotix XSS Exploit Framework

Before i begin, i would like to take this opportunity to thank Ajin Abraham and the team behind the creation of the OWASP Xenotix XSS Exploit Framework Project for making the life of penetration testers everywhere easier to perform Web Application assessments and allowing us to conduct Proof of Concept of XSS via this amazing framework.

What is OWASP Xenotix XSS Exploit Framework?
"OWASP Xenotix XSS Exploit Framework is an advanced Cross Site Scripting (XSS) vulnerability detection and exploitation framework. It provides Zero False Positive scan results with its unique Triple Browser Engine (Trident, WebKit, and Gecko) embedded scanner. It is claimed to have the world’s 2nd largest XSS Payloads of about 1500+ distinctive XSS Payloads for effective XSS vulnerability detection and WAF Bypass. It is incorporated with a feature rich Information Gathering module for target Reconnaissance. The Exploit Framework includes highly offensive XSS exploitation modules for Penetration Testing and Proof of Concept creation." - OWASP

What is XSS (Cross Site Scripting) ?
According to OWASP, Cross Site Scripting (XSS) is a vulnerability that allows malicious scripts to be injected in a form field, a search field or a parameter which will generate an output to the client side browser. These flaws occur when user input are not being properly validated by the server side.
An attacker can use the XSS vulnerability to send a malicious script to an unsuspecting user. The user will have no way to identify whether or not the script came from a trusted source and upon executing it, the malicious script can access any cookies, session tokens, or other information from the browser used on that site. Exploit frameworks such as XSS Xenotix Exploit Framework could allow an attacker to do more such as keylogging, sending a file to the user's browser to automatically download and execute and could even take advantage of the browser to perform a port scan of the machine or the network where the machine is located.

Reflected Cross Site Scripting
Reflected cross-site scripting vulnerability is by far the most common type in web applications. A typical attack is performed by delivering a URL with the injected script to an unknown user either via email or through online chat mediums. When a curious user clicks on the link containing the XSS vector, the script will be executed and the attack can be visibly seen such as an alert pop up from the browser or worse, a malicious payload gets executed without the user knowing what is happening.

Objective
The objective of this article is to demonstrate and illustrate the use of the OWASP XSS XENOTIX Exploit Framework and how it can be used to perform proof of concept (POC) on how far the damage can be with the XSS vulnerability. This article will explore some of the common options in this framework and how it can be used (a website with a XSS vulnerability) to perform information gathering and exploitation of a victim's system.



Getting Started
The framework can be downloaded for free at https://www.owasp.org/index.php/OWASP_Xenotix_XSS_Exploit_Framework




                                           Figure 1: The GUI of the Framework


Exploring the Tabs
The View Source tab gives the same look as one would look when a user right clicks on a page and click 'View Source'. It allow users to view the HTML or other source code of any of the web pages they visit.

The Scanner tab is the framework to search and test for XSS vulnerabilities in a website. It will test against the 1000 plus inbuilt scripts and can be done either manually or automatically.

The Information Gathering tab is the reconnaissance of the victim's system. The options include the ability to find out information of the browser, the IP address, the hostname, the ISP and can also perform port scans on the victim's machine.

The XSS Exploitation tab provides options to perform various attacks including phishing, tab nabbing, keylogging and also has the ability to spawn a shell of a victim's machine!

The Tools tab has options such as encoder and decoder utilities, the ability to detect hash and calculate hashes as well.

The Settings tab is where we configure the settings of the attack server. It also has the option to import custom made payload into their database.

The XSS Buzz tab provides options that are linked to various XSS information such as cheatsheets from OWASP and PacketStorm and also a link to a compilation of various XSS vectors.

Configuring the Server First
To begin, we will need to first configure our machine to be the server where potential victims will have their browsers 'hooked' to our attacking system. To configure, click on Settings and Configure Server.

Figure 2: The Settings option


Input the IP address of your attacking machine and click Start.


Figure 3: Inputting the IP address


After that, a script will be provided and copied to the clipboard.


Figure 4: Generating the HOOK Script


Copy the script below to a notepad:


Figure 5: Copying the script to inject in the Parameter


Without configuring the server, a pentester will not be able to utilize the framework to perform the proof of concept on the XSS vulnerability.

Scanning for XSS Vulnerabilities
Next we will need to find a website that is vulnerable to Cross Site Scripting. In this example, we will choose a .PHP site that has a visible parameter on the URL.

To scan the site for XSS vulnerabilities, we will go to the Scanner tab and choose the Manual Mode option.

Figure 6: The Manual Mode option

Input the URL into the URL option:

                             

Figure 7: Inputting the link in the URL option


And then click Start

                               

Figure 8: Click Start to start the Scanner


This will start the injecting of scripts into the parameter 'q='. You can also perform this in the Auto mode. What this process will do is to inject scripts into the parameter to see whether or not when executed will generate an output. A successful injection will show a Javascript Alert.


Figure 9: A Cross Site Scripting Vulnerability found


With this alert, we can confirm that the website is vulnerable to cross site scripting.

Hooking Up a Victim's Browser
To proceed and understand the severity of XSS vulnerability, we will need to 'hook up' the victim's browser. Copy the script from Figure [5] and paste it to the parameter of the link. It will look like this:


Figure10: The full link included with the Hook up Script

On the victim's browser, execute the link above in the browser. For proof of concept (POC), copy the entire link to the victim's Firefox browser and execute the link. Of course, traditionally, hackers will use various techniques from sending an email or sending a link via chat channels and sweet talk the victim into clicking the link. As this article is a walkthrough of the Xenotix framework, we will directly click the link from the victim's browser.


Let The Fun Begins - Information Gathering
After the link is executed, we go back to our attacker's machine to explore the Information Gathering options of the framework.

Victim Fingerprinting: This feature when selected will provide information such as the Country Code, the Public IP address, the Public Hostname and the ISP used.

 
 Figure 11: The Victim Fingerprinting option




Figure 12: The Information Gathered through Victim Fingerprinting


Browser Fingerprinting: This feature will gather information about the browser, its version and the operating system used on the victim's machine.


Figure 13: The Browser Fingerprinting Option



Figure 14: The Information Gathered through Browser Fingerprinting


Port Scanning: This is one of my favourite features. It has the ability to perform a port scan of the victim's machine. While the result is not as comprehensive as other port scanning tools like NMAP, it is enough to enumerate the lists of open or closed ports of the victim's machine.


Figure 15: The Port Scan option



Figure 16: The list of open/closed ports gathered through Port Scanning


Let The Games Begin - XSS Exploitation
This is of course the best part of the whole framework. Exploitation! This option is one of the best way to perform a POC for the clients to show how serious it is or how much damage it can inflict with a XSS vulnerability.

Send Message: The Send Message option allows an attacker to craft custom messages and send it over to the victim compromised browser.

Figure 17: The Send Message option


In this example, we crafted a simple message "Lovely Day Isnt it?" and click Send.

Figure 18: A sample message


The output of the message received on the victim's browser screen.

Figure 19: The Output of the message on the victim's browser screen.


Stealing Cookie: As the name suggests, this option allows the stealing of the cookie of the pages visited by the victim.


Figure 20: The Cookie Thief option


Stolen cookies could be used to hijack sessions and it's even worse if its an authenticated session.


Figure 21: The stolen cookie information


Load File: This option allows an attacker to inject a file into the body of the page.


Figure 22: The Load File option


This option allows you to select what type of file we want to inject or embed into the page. We can either generate a code and send the whole link to the victim to execute or simply click Inject and it will automatically inject the file into the page.


Figure 23: Injecting of the PDF into the browser


The output of a PDF file injected into the page of the compromised site.


Figure 24: The injected PDF in the web page


Keylogger: This option will work on site that has a form field to accept input such as a search field.


Figure 25: The Keylogger option



When this option is selected, any words typed into the field, in this case, the search field will be logged to the attacker's machine view.


Figure 26: Typing words in the search field


In this case, the words 'please dont logged my keystrokes' on the search field is logged and reflected on the attacker's keylogging console.


Figure 27: The typed words being keylogged to the attacker's console


Getting Shell Access: What better way to own a machine than to get a shell access? The option 'Firefox Add-on Reverse Shell' allows an attacker to gain shell access from the victim's machine.


Figure 28: The Firefox Add-on Reverse Shell option


Once we select the option, we will need to specify the port for the reverse shell to connect to. The default port is sufficient for this POC. We will first need to start the listener. Once the listener is started, click Inject.


Figure 29: Setting the Listener and the Server IP address of the attacker's machine


On the victim's browser, there will be a notification from Firefox to install a software or an addon for the browser. For this POC to work, we will click 'Allow'.


Figure 30: The notification from Firefox browser


And when the victim clicks on 'Install Now', nothing seems to be happening. At least from the victim's side.


Figure 31: The standard Firefox Add On installation window


When we go back to our attacking machine, we will be able to see a shell being spawned on our console! When this happens, we are already in control of the victim's machine.


Figure 32: The Spawned Shell


Prevention Against Cross Site Scripting Attacks
There are no 100% guarantee for a solution to stop a website against XSS attacks. While there are solutions such as WAF (Web Application Firewalls), from experience in performing Web Application assessments, it is not a guarantee that these WAFs could prevent everything. Input filtering, validation and also server side validation configuration are also important to prevent XSS attacks. Another way to deter away from amateur hackers is by hiding the parameters and not reflected with the inputs on the URL itself. There are also browser addons that can be added to the browser to protect the browser from executing scripts such as the 'No Script' addon for Firefox. It is also recommended for organizations to perform security assessments with updated version of security tools to ensure the latest trends of XSS attack vectors are tested on the applications.

Conclusion
XSS is by far, one of the most dangerous website vulnerabilities almost as dangerous as SQL Injection. As demonstrated using the Xenotix framework, it has the capability to take advantage of this vulnerability and manipulate it into something far more damaging. While patching is possible, it can never be a guarantee that the filter can be broken into or bypassed. For web developers, it is very important to keep up with the latest trends of XSS vectors and from there create tough filters making it harder for hackers to compromise. Nevertheless, for penetration testers, this tool is great to perform a POC (Proof of Concept) to the client in showing the serious possibilities from the XSS vulnerability.

References


No comments:

Post a Comment