Advanced exploits using XSS SHELL
XSS is one of the most common vulnerabilities that exist in many web applications today. XSS is a technique through which the attacker tries to compromise the web application by executing a malicious script in the website. The attacker does this by breaking the “Same-Origin” policy of the web application. The “Same – Origin” policy states that the script which is coming from the foreign site or the script that doesn’t belong to the same domain (i.e document.domain) should not be processed by the application.
Once an attacker is able to find out the XSS in a web application, he can perform different kinds of attacks by using this vulnerability. A few of them are:
- Stealing Credentials
- Stealing Session tokens
- Defacing the Website
- Causing DOS
- Installing Key loggers and many more….
Cross-Site-Scripting exists in three different forms:
- Reflected XSS
- Stored XSS
- DOM Based XSS
This kind of vulnerability exists in the application that uses dynamic pages to display the content to the user. Normally these applications take the message into a parameter and render it back to the users.
Consider the URL: http://www.samplesite.com/error.html?value=learn+hacking
This shows the message “learn hacking” in the response of the application. This means the application extracts the message from the URL, processes it, and displays to the user. So the URL processes user-supplied data and inserts it into the server’s response. If there is no proper sanitization, then the application is vulnerable to Reflected XSS.
The URL can be crafted as:
When you click on the above URL, it pops up an alert box.
This type of vulnerability exists in the applications which take the input from the user and store it in the application, then display to the other users.
Consider a Facebook application which allows commenting on any pictures or status updates and then displays to all other users. If the application doesn’t sanitize the input properly, then an attacker can write a script in the comment area, so that the users who visit or view that particular page or post will be affected.
So Stored XSS consists of two things to do. Initially, the attackers enter the malicious script into the application. Secondly, the user visits the crafted page and the script is executed in the back-end without the knowledge of the user.
DOM based XSS
DOM stands for Document Object Model. It is quite different from the other two attacks described earlier. In DOM Based XSS, when the users click on the crafted URL, the server response doesn’t consist of an attacker’s script. Instead, the browser executes the malicious script while processing the response.
This is because the Document Object Model of the browser has a capability to determine the URL used to load the current page. The script issued by the application may extract the data from the URL and process it. Then it uploads the content of the page dynamically, depending upon the script executed through the URL.
What is XSS Shell?
XSS shell is a powerful tool developed in ASP .NET which runs as a backdoor between the attacker and the victim. With XSS, an attacker has only one shot to execute any kind of attack on a victim. Once the victim navigates from the malicious page, the attacker’s interaction or the communication with the victim ends, whereas using XSS Shell helps the attacker to open an interactive channel with the victim and communicate with him by sending its commands. Here even if the victim navigates from the vulnerable/malicious page, the attacker can continue his communication as the XSS Shell Re-generates the page.
The interactive shell or the communication channel which was established by the attacker with the victim is called “XSS Tunnel”. XSS Tunnel is used for tunneling the HTTP Traffic between two machines opened by XSS. Technically it is developed using AJAX, and that can send requests and receive responses and has an ability to talk cross-domain.
- Setup XSS Shell Server.
- Configure XSS Tunnel to use XSS Shell Server.
- Inject malicious script into a vulnerable Website.
- Launch XSS Tunnel and wait for victim.
- Configure the browser or tool to use XSS Tunnel.
- When victim visits the vulnerable page, start using XSS Tunnel.
How XSS Shell works
As shown in the figure, initially the attacker establishes a connection with the XSS Shell and injects malicious script into the web Application using Stored or Reflected XSS. Once the victim clicks or visits the vulnerable application with the malicious script a request will be sent to the XSS Shell Server. On the basis of the request, the server establishes a channel to interact with the victim.
Once a channel has been created between the victim and XSS Shell Server, the attacker can control the communication through XSS Shell Interface. The XSS Shell Interface is nothing but a GUI environment which provides a definite set of commands which the attacker executes to perform certain actions.
On executing a command, the necessary function or the script will be called at the XSS Shell Server level and it is sent to the victim. The script will be processed and executed at the victim browser and it sends corresponding results to the XSS Shell Server. The XSS Shell Server stores the results in “MS-Access” database which is normally used by it to store the data. The attacker can extract the results from the database and look it over whenever he needs.
Some of the commands that XSS Interface provides are:
- Get Cookie
- Get Current Page
- Get Clipboard
- Get Key-logger data
- Crash browser
One more advantage of using XSS Shell is: it is Open Source and quite easy to implement new commands.
- An IIS Server where you can host .asp files.
- Microsoft Access (.mdb)
- A Website which is vulnerable to XSS.
- A vulnerable site to perform attack.
Setting up the environment:
- Download the XSSShell from:
- Configure IIS to host the site.
- Configure XSS Shell.
In order to configure IIS in Windows 7 or above, follow the steps given below:
- Click on “Start Menu” and go to “Control Panel”.
- Click “Programs” and then click on “Turn Windows features on or off”.
- A new “Windows Features” dialog box will appear. Expand “Internet Information Services”, select default features that has to be installed with IIS.
- You can expand the additional categories and install any additional features if required.
- It is recommended to install additional features if you want to use IIS for evaluation purpose.
Now IIS has been configured in the machine and can be accessed using http://localhost/
Figure C shows the IIS 7 default page.
XSS Shell uses ASP .NET and MS-Access database. So just make sure that you have both of them installed in your machine.
Configuring XSS Shell Admin Interface:
- After downloading the XSSShell.zip file, extract the file and you can see two folders. “XSSshell” and “XSSTunnel”
- XSSshell is admin interface and you need to configure it in your machine. Copy “XSSshell” folder to your web server.
Figure D, shows the structure of “XSSshell” folder.
- You can see a sub-folder named “db” in the XSSShell folder as shown in above image. Copy that to a secure place because XSSshell stores complete data in that db, whatever it is either a victim’s session cookies or any other attacked data that belongs to the victim.
- After moving the “db” folder to a secure place, configure the path in “db.asp” file under “XSSshell/admin” folder, so that the interface can understand where the db is and interact with it.
Figure E shows the path where the database for XSSshell is stored or kept.
Edit the path to the location such that it should point to the place where “db” folder is present in your machine.
Figure F shows the default password to access “shell.mdb” file. You can edit to whatever you want.
- Now you can access admin interface by using the localhost url or the domain name that you have given. Ex: http://localhost/xssshell (or) http://yourhostname.com/xssshell
- By default it uses port 80, but if you change the port number while configuring the domain you need to access the site by embedding the port number.
Configuring XSS Shell:
- Open “xssshell.asp” from “XSSshell” folder.
- Configure the server path. i.e to the place where XSSshell folder is located.
Figure G shows the configuration of server path in xssshell.asp file. Edit he parameter “SERVER” to the place to the location of “XSSshell” folder in your machine.
- Now access your admin interface from the browser.
Figure H shows the admin interface of XSSshell.
In the above figure you can see three sections.
As mentioned earlier, XSSshell has pre-defined commands which make the attacker’s life easy to perform any attack on the victim. The commands section contains all the commands supported by the shell. As it is open source, you can edit it and add your own functionalities there.
Victims section shows the list of victims.
Logs show the list of actions performed on the victims.
XSSTunnel is just like a proxy tool which runs on attacker machine and captures traffic through the XSS channel on XSSshell server.
Figure I shows the configuration settings of the XSS Tunnel.
As mentioned earlier, the XSS Tunnel acts like a proxy to capture the traffic through the XSS channel opened through XSSshell server. In order to do this, the XSS Tunnel should be able to understand where the XSSshell server is running.
We can configure the XSSshell information (i.e where it is running) in XSS Tunnel from “Options” tab.
Enter the server address and password. Then just to make sure it is working fine, click on “Test Server”. You get a success message if the configuration is proper.
Figure J shows the connection established successfully.
Once done with configuration, click on “Start XSS Tunnel” on the top of the window. Then you can see all the actions performed by the victim from XSS Tunnel’s “Dashboard”.
Figure K shows all the pages visited by the victim and actions performed.
XSSshell is an interface or a tool which opens a gateway to the attacker through which he can perform various attacks on the victim without losing the connection once established.