XSS tunneling [Complete Series] (migrated from the worldofhacker forum - 2011)
In This thread, we talk about in-depth descriptions of XSS tunneling.
Source:- Internet & Few Security team Books.
INDEX
1). XSS Tunnelling
- What Is An XSS Tunnel?
- What Is XSS Tunnelling?
- What Is An XSS Channel?
XSS Shell
- How Does XSS Shell Work?
- Points of Interest
- Built-in Commands.
- Key Feature.
- Install.
- Why Is It Better Than The Classic XSS Attacks?
2). Why Tunnel HTTP Traffic Through An XSS Channel?
3). Benefits Of XSS Tunnelling
4). How Does XSS Tunnel Work?
5). An Attack Process.
What is an XSS tunnel?
XSS Tunnel is the standard HTTP proxy that sits on an attacker’s system. Any tool that is configured to use it will tunnel its traffic through the active XSS Channel on the XSS Shell server. The XSS Tunnel converts the request and responds transparently to validate the HTTP responses and XSS Shell requests.
XSS Tunnel is written in .NET and requires .NET Framework to work. It is a GPL Licensed open source application.
What is an XSS Tunnelling?
XSS Tunnelling is the tunneling of HTTP traffic through an XSS Channel to use
virtually any application that supports HTTP proxies.
What is an XSS Channel?
An XSS Channel is an interactive communication channel between two systems that is opened by an XSS attack. At a technical level, it is a type of AJAX application that can obtain commands, send responses back, and is able to talk cross-domain.
The XSS Shell is a tool that can be used to set up an XSS Channel between a Slave and an attacker so that an attacker to control a Slave’s browser by sending it commands. This communication is bi-directional.
To get the XSS Shell to work an attacker needs to inject the XSS Shell’s JavaScript reference by way of an XSS attack. The attacker is then able to control the Slave’s browser. After this point, the attacker can see requests, and responses and is able to instruct the Slave’s browser to carry out requests, etc.
A sample injection attack is shown below;
http:
XSS Shell
XSS Shell is a powerful XSS backdoor and XSS zombie manager. This concept was first presented by "XSS-Proxy – http://xss-proxy.sourceforge.net/". Normally during XSS attacks, an attacker has one shot, however, an XSS Shell can be used interactively to send requests and receive responses from a Slave, it is also possible to backdoor the page and keep the connection open between the attacker and the Slave.
It is a good way of bypassing the following protections:
- Bypassing IP Restrictions
- NTLM / Basic Auth or any similar authentication
- Session-based custom protections.
How Does XSS Shell Work?
The XSS Shell is an application that has three main parts.
Firstly, the server-side part of the XSS Shell coordinates the XSS Shell between an attacker and the Slave. It is a server-side application and requires an ASP and IIS
web server. It uses an MS Access database as storage.
The second part of the tool is client-side and written in JavaScript. This loads in the Slave’s browser and is responsible for the receiving and processing of commands together with providing the channel between the Slave and the attacker.
The final part of the XSS Shell is the administration interface. An attacker can send new commands and receive the responses from a Slave(s) browser instantly from this interface. Again it is ASP and requires IIS.
All of the following steps do not wait for each other and are constantly checking for responses and requests within specified time delays.
- An attacker infects a website with a persistent or reflected (temporary) XSS attack which calls remote XSS Shell JavaScript.
- The Slave follows or visits the page and executes the JavaScript within that domain.
- The Slave’s browser begins to perform periodic requests to the XSS Shell Server and looks for new commands.
- When the Slave browser receives a new command such as (Get Cookies, Execute custom JavaScript, Get Key logger Data, etc.) it is processed and returns the results to the XSS Shell.
- The Attacker can push new commands to the Slave(s) browser and view the results from the XSS Shell administration interface.
Points of Interest
· XSS Shell communication relies on remote JavaScript loading in order to bypass the same-origin policy
· In the first execution, XSS Shell re-generates the page. Thus even if the Slave follows; XSS Shell will remain on the page and therefore, allows the attacker to keep control of the Slave’s browser. As soon as the Slave obtains that window (even if the Slave follows a to another website) the Slave’s session will be open and the browser will follow an attacker’s commands.
· It is open source and is quite easy to implement new commands such as port scanning.
· XSS Shell is especially dangerous in permanent XSS vulnerabilities. Due the fact that an attacker can easily infect hundreds of browsers and manage them simultaneously.
Built-in Commands:
o Get Cookie
o Get Current Page
o Execute custom Javascript
o Get Mouse Log
o Get Keylogger Data
o Get Clipboard
o Get an Internal IP Address (Firefox - JVM)
o Check visited (CSS history hack)
o Crash Browser (if you don’t like your Slave!)
Key Feature:
- Regenerating Pages: this is one of the keys and advanced features of XSS Shell. XSS Shell re-renders the infected page and keeps the user in a virtual environment. Thus even when a user clicks on any of the infected pages they will be still under control! (within cross-domain restrictions) In normal XSS attacks when the user leaves the page nothing can be done. Secondly, this feature keeps the session open so even the victims follow an outside from the infected page session which is not going to timeout and the attacker will be still in charge.
-Keylogger. {As Said Above in Shell Commands}
-Mouse Logger (click points + current DOM).{As Said Above in Shell Commands}
Install
- Download the Attachment, XSS Shell was written in ASP. As the backend, it uses MS Access for portability and easy installation. It requires IIS 5 or above to work.
To Install The Admin Interface;
- Copy the "xssshell" folder into the web server
- Modify the hard-coded password in db.asp [default password is: w00t]
- Access the admin interface from something like:
http://[YOURHOST]/xssshell/admin/
- Setup permissions for the database folder (write/read access for IUSR_wink
To Configure The XSS Shell For Communication;
- Open xssshell.asp
- Set the "SERVER" variable to the location of XSSShell folder, i.e: "http://[YOURHOST]/xssshell/";
You should now be able to open the admin interface from your browser http://[YOURHOST]/xssshell/admin/.
Testing should be possible by modifying the "sample_victim/default.asp" source code and replacing the "http://[YOURHOST]/xssshell/xssshell.asp" URL with a specific (i.e your own) XSS Shell URL. Open the "sample_victim" folder in another browser and may then be uploaded to another server.
Now a zombie in the admin interface should be visible. Write something into the "parameters" text area and click "alert()". An alert message should appear in the Slave's browser.
Security & Extra Configuration:-
- Copy "DB" to a secure place (below root)
- Configure "database path" from "xssshell/db.asp" (it's recommended to not enable parent paths and use the full path for DB path)
- Configure your web server to not show any errors.
If file names are changed;
Be sure to check the "ME", "CONNECTOR", and "COMMANDS_URL" variables in xssshell.asp.
HOW CAN YOU EXTEND?
First, implement the new functionality to xssshell.asp
Add new enum for your control
Set a name and unique number like "CMD_GETCOOKIE"
var CMD_SAMPLE = 78;
"log(cmdSample(), dataTypes[cmd.cmd], cmd.attackID, "waitAndRun()");"
Secondly, Implement it in the admin interface;
- In db.asp just add a new element to the "Commands" array (command name, command unique number, description).
Code:
i.e. "cmdSample()",78,"Command sample ! which just returns a message"
There are parameters and lots of helpers in the code. Investigate other commands for reference.
Enable the debug feature in order to debug the new commands easily. Debug has several levels, which can be increased in number to get more detailed debug information.
Known Bugs :-
- Keylogger is not working on IE
- Not working on Konqueror(a freeware browser for Linux.)
Why Is It Better Than The Classic
XSS Attacks?
· An attacker would have more than one shot. After controlling a Slave(s) browser the attacker is able to decide their next move based on responses and
the current environment.
· It enables you to bypass the following;
o IP Restrictions,
o Basic/NTLM Auth Based or similar authentications.
· As it is the intention to send alert(“0wned!”) to thousands of victims and build a temporary XSS powered botnet!
Why Tunnel HTTP Traffic Through An
XSS Channel?
An XSS vulnerability is exploited and the admin session is eventually obtained and it turns out that the admin pages are IP restricted. It does not matter because by using an XSS Shell it is possible to bypass this restriction. However, a Blind SQL Injection is then found in the admin part of the page; it is well known that it is quite impossible to exploit a Blind SQL Injection manually.
It is now possible to write a Blind SQL Injector into JavaScript or to configure a favorite SQL Injection tool using the XSS Tunnel and tunnel all of the traffic through previous XSS Channels and exploit it easily.
Benefits Of XSS Tunnelling
· It enables the use of virtually any tools that support HTTP Proxies!
· It is possible to use automated tools such as Nikto, SQL Injectors, HTTP brute forcer
against an IP restricted areas of the website,
· It allows the configuration of your local browser to use the XSS Tunnel and
browse the website with a Slave’s credentials from your own browser and it
does not involve the use of any kind of complicated cookie / IP / user agent
based checks,
· It is very good for demonstrating the result of an XSS attack.
How Does XSS Tunnel Work?
The XSS Tunnel connects to a specified XSS Shell and obtains the current
active identifier (the Slave to be controlled)
The local HTTP client (browser, Nikto, etc.) sends HTTP requests to the XSS Tunnel:
The XSS Tunnel converts the HTTP requests into requests which the
- XSS Shell can understand and process. It then sends these requests to
- the XSS Shell Server.
The XSS Shell Server saves this request to its database (All these requests only work for a specified Slave by the XSS Tunnel. This ID can be seen in the dashboard of the XSS Tunnel).
The XSS Shell Client (which resides in JavaScript in the Slave’s browser)
performs periodic requests for the XSS Shell Server and checks for new
commands to process.
This process requires cross-domain reading. The XSS Shell uses remote JavaScript loading to bypass the same-origin policy restrictions.
If there are new commands, it loads them and processes and sends the responses (this can be simply a confirmation code or source code of a page or a binary file) to the XSS Shell server. Commands and responses run in a multithreaded fashion.
- XSS Tunnel in the local cache, checks the XSS Shell Server for a response for previously assigned requests. If there is a response it converts the response to a valid HTTP response and sends it to the client application.
By default, the XSS Tunnel caches JavaScript, CSS, and image files for better performance. This is really required if using the XSS Tunnel with a browser. If requested the resource is already in the cached XSS Tunnel and can be obtained from the local cache and sent to the client application.
Caching can be disabled or the cache can be managed from the user interface
of XSS Tunnel.
An Attack Process.
- Setup the XSS Shell Server,
- Configure the XSS Tunnel to use the XSS Shell Server,
- Prepare the XSS attack (submit to a vulnerable website etc.),
- Launch the XSS Tunnel and wait for a Slave,
- Configure the tool or browser to use the XSS Tunnel,
- When you see Slave in the XSS Tunnel, start to use your browser/tool
for the targeted domain.
