XSS tunnelling [Complete Series]
In This thread, we talk about in depth description about XSS tunnelling.
Source:- Internet & Few Security team Books.
INDEX
- What Is An XSS Tunnel?
- What Is XSS Tunnelling?
- What Is An XSS Channel?
- XSS Shell
B: Points of Interest
C: Built in Commands.
D: Key Feature.
E: Install.
F: 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.
Now In Detail:-
What is an XSS tunnel ?
XSS Tunnel is the standard HTTP proxy which 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 tunnelling of HTTP traffic through an XSS Channel to use
virtually any application that supports HTTP proxies.
Now, what is an XSS Channel.
What is an XSS Channel ?
An XSS Channel is an interactive communication channel between two systems which is opened by an XSS attack. At a technical level, it is a type of AJAX application which can obtain commands, send responses back and is able to talk cross-domain.
The XSS Shell is a tool that can be used to setup 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, responses and is able to instruct the Slave’s browser to carryout requests etc.
A sample injection attack is shown below;
Code:
http://example.com/q=">
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?
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. This code was tested under Firefox, IE6 and IE7.
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.
1. An attacker infects a website with a persistent or reflected (temporary) XSS attack which calls remote XSS Shell JavaScript.
2. The Slave follows a Icon_charly_link_green or visits the page and executes the JavaScript within that domain.
3. The Slave’s browser begins to perform periodic requests to the XSS Shell Server and looks for new commands.
4. 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.
5. The Attacker can push new commands to 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 the Slave follows a Icon_charly_link_green; XSS Shell will remain in 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 Icon_charly_link_greens 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 Internal IP Address (Firefox - JVM)
o Check visited Icon_charly_link_greens (CSS history hack)
o Crash Browser (if you don’t like your Slave!)
Key Feature.
- Regenerating Pages: this is one of the key 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 Icon_charly_link_greens in the infected page 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 Icon_charly_link_green 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
1. 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;
1. Copy the "xssshell" folder into the web server
2. Modify the hard coded password in db.asp [default password is : w00t]
3. Access the admin interface from something like:
http://[YOURHOST]/xssshell/admin/
4. Setup permissions for the database folder (write/read access for IUSR_
To Configure The XSS Shell For Communication;
1. Open xssshell.asp
2. 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 into another server.
Now a zombie in the admin interface should be visible. Write something into the "parameters" textarea and click "alert()". An alert message should appear in the Slave's browser.
Security & Extra Configuration :-
1. Copy "db" to a secure place (below root)
2. Configure "database path" from "xssshell/db.asp" (it's recommended to not enable parent paths and use full path for db path)
3. Configure your web server to not show any error.
If file names are changed;
Be sure to check the "ME", "CONNECTOR", "COMMANDS_URL" variables in xssshell.asp.
HOW CAN YOU EXTEND?
First implement the new functionality to xssshell.asp
1. Add new enum for your control
- Set a name and unique number like "CMD_GETCOOKIE"
Code:
var CMD_SAMPLE = 78;
Code:
dataTypes[CMD_SAMPLE] = TEXT;
Code:
- function cmdSample(){return "yeah working !"}- Go inside to "function processGivenCommand(cmd)"
- Add a new case such as
Code:
"case CMD_SAMPLE:"- Inside the case call log;
Code:
"log(cmdSample(), dataTypes[cmd.cmd], cmd.attackID, "waitAndRun()");"1. In db.asp just add a new element to "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 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 the JavaScript or to configure a favourite 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 bruteforcer
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?
1. The XSS Tunnel connects to a specified XSS Shell and obtains the current
active identifier (the Slave to be controlled)
2. The local HTTP client (browser, Nikto etc.) sends HTTP requests to the XSS Tunnel
o 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.
o 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).
3. 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 read. The XSS Shell uses remote JavaScript loading to bypass the same-origin policy restrictions.
o 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 XSS Shell server. Commands and responses run in a multithreaded fashion.
4. 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 a 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.
1. Setup the XSS Shell Server,
2. Configure the XSS Tunnel to use the XSS Shell Server,
3. Prepare the XSS attack (submit to a vulnerable website or send a Icon_charly_link_green
etc.),
4. Launch the XSS Tunnel and wait for a Slave,
5. Configure the tool or browser to use the XSS Tunnel,
6. When you see Slave in the XSS Tunnel, start to use your browser / tool
for the targeted domain.
