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
