Get Practical mobile forensics book for just $5 now!

5 Dollar - Social Media


Packt Publishing will be celebrating the holiday season with $5 offer.  From Thursday 18th December, every eBook and video will be available on the publisher’s website for just $5 till 6th January. Here is the link to grab a copy of Practical mobile forensics book for just $5!!


Posted by on December 24, 2014 in iPhone

1 Comment

Win A Free Copy of Packt’s Practical Mobile Forensics

We are pleased to announce that Packt publishing is organizing a giveaway especially for you. All you need to do is just comment below the post and win a free e-copy of Practical Mobile Forensics. Two lucky winners stand a chance to win an e-copy of the book. Keep reading to find out how you can be one of the Lucky One.

Practical Mobile Forensics cover

Overview of Practical Mobile Forensics

  • Clear and concise explanations for forensic examinations of mobile devices
  • Master the art of extracting data, recovering deleted data, bypassing screen locks, and much more
  • The first and only guide covering practical mobile forensics on multiple platforms

How to Enter ?

Simply post your expectations from this book in comments section below. You could be one of the 2 lucky participants to win the copy.


The contest will close on 09/25/2014. Winners will be contacted by email, so be sure to use your real email address when you comment!

Update – 09/26/2014 : The contest is over. Will announce the winners shortly.

Update – 09/28/2014 : Lucky winners are listed below. Congrats.

Simon Lang


Posted by on September 17, 2014 in Android, iPhone



LaunchKey Mobile Vulnerabilities : Bug Bounty Experience

Below are the vulnerabilities which I have found in the LaunchKey iPhone application.

Insecure Storage – passcode & auth token are stored in clear text

LaunchKey app allows its users to set a passcode to protect their information. This passcode is stored in clear text in the keychain, which can be obtained using keychain_dumper tool.

launchkey pin in plaintext

The app also stores the authentication token in clear text in the keychain.LaunchKey Auth Token in cleartext

Passcode Lock Bypass

Once a passcode lock is set, whenever the app is relaunched it prompts for the passcode. This passcode lock can be bypassed by manipulating the iOS runtime with cycript. Before manipulating the runtime, I have decrypted the app using clutch and obtained the class information using class-dump-z.

Steps followed to bypass the passcode lock:
1. Connected to the iPhone over SSH.
2. Launched the app and noticed that it prompts for a passcode.
LaunchKey pin lock
3. Attached LaunchKey process to cycript and obtained the view controller instance of current displaying screen. 
$cycript -p LaunchKey
<LKPinViewController: 0x1f5d5d00>
4. Looked at the class dump for LKPinViewController interface and didn’t find any interesting methods/variables.
@interface LKPinViewController : LKLockViewController <UITextFieldDelegate> {
	NSString* pinNumber;
	BOOL creation;
	NSString* firstPin;
	int tries;
	UITextField* pinDigitOneTextField;
	UITextField* pinDigitTwoTextField;
	UITextField* pinDigitThreeTextField;
	UITextField* pinDigitFourTextField;
	UIView* pinView;
	UIImageView* background;
	UIButton* cancelButton;
	UILabel* pinLabel;
	UINavigationBar* navigationBar;
	UIImageView* lkNavLogo;
	UILabel* notMatchLabel;
	UITextField* pinField;
@property(retain, nonatomic) UITextField* pinField;
@property(assign, nonatomic) __weak UILabel* notMatchLabel;
@property(assign, nonatomic) __weak UIImageView* lkNavLogo;
@property(assign, nonatomic) __weak UINavigationBar* navigationBar;
@property(assign, nonatomic) __weak UIView* pinView;
@property(assign, nonatomic) __weak UIImageView* background;
@property(assign, nonatomic) __weak UITextField* pinDigitFourTextField;
@property(assign, nonatomic) __weak UITextField* pinDigitThreeTextField;
@property(assign, nonatomic) __weak UITextField* pinDigitTwoTextField;
@property(assign, nonatomic) __weak UITextField* pinDigitOneTextField;
@property(assign, nonatomic) __weak UIButton* cancelButton;
@property(assign, nonatomic) __weak UILabel* pinLabel;
-(void)animationDidStop:(id)animation finished:(BOOL)finished;
-(BOOL)textField:(id)field shouldChangeCharactersInRange:(NSRange)range replacementString:(id)string;
-(id)initWithNibName:(id)nibName bundle:(id)bundle;

LKPinViewController inherits LKLockViewControllerHence, methods in the parent class (LKLockViewControllerclass) can be invoked from the child class (LKPinViewControllerinstance. So looked at the class dump for LKLockViewController interface and noticed an interesting method pinIsValid.

@interface LKLockViewController : GAITrackedViewController {
	NSNumber* AppId;
	BOOL removing;
	MBProgressHUD* hud;
	BOOL verifying;
	int yOffset;
@property(retain) MBProgressHUD* hud;
@property(assign) int yOffset;
@property(assign) BOOL verifying;
@property(assign) BOOL removing;
@property(retain, nonatomic) NSNumber* AppId;
-(id)initWithNibName:(id)nibName bundle:(id)bundle;

5. Invoking the pinIsValid method directly from the the cycript prompt, logged me into the app without entering the passcode.

&nbsp;&gt; [v pinIsValid]
launchkey pin bypass


Combination Lock Bypass

LaunchKey app allows its users to set a combination lock as an alternative to the passcode lock. Once a combo lock is set, whenever the app is relaunched it prompts the user to enter combo code to unlock. This combo lock can be  bypassed by manipulating the iOS runtime with cycript.

Steps followed to bypass the combo lock:
1. Connected to the iPhone over SSH.
2. Launched the app and noticed that it displays the combo lock.
LaunchKey combo lock
3. Attached LaunchKey process to cycript and obtained the view controller instance of currently displaying screen. 
$cycript -p LaunchKey
> UIApp.keyWindow.rootViewController.visibleViewController
> l=_
<LKComboLockViewController: 0x1e1c9680>

4. Looked at the class dump for LKComboLockViewController interface and noticed an interesting method comboDismissed.

@interface LKComboLockViewController : LKLockViewController {
	BOOL creation;
	int tries;
	UIImageView* background;
	UINavigationBar* navigationBar;
	UIImageView* lkNavLogo;
	UILabel* combinationLabel;
	UIButton* cancelButton;
	UILabel* detailsLabel;
	LKCombinationLock* combo;
@property(retain, nonatomic) LKCombinationLock* combo;
@property(assign, nonatomic) __weak UILabel* detailsLabel;
@property(assign, nonatomic) __weak UIButton* cancelButton;
@property(assign, nonatomic) __weak UILabel* combinationLabel;
@property(assign, nonatomic) __weak UIImageView* lkNavLogo;
@property(assign, nonatomic) __weak UINavigationBar* navigationBar;
@property(assign, nonatomic) __weak UIImageView* background;
-(id)initWithNibName:(id)nibName bundle:(id)bundle;

5. Invoking the comboDismissed method directly from the the cycript prompt, logged me into the app without entering the combo lock code.

> [l comboDismissed]
launchkey combolock bypass


Passcode bruteforce limit bypass

When a passcode lock is set, LaunchKey app provides an option to unpair the device after 10 failed passcode attempts. The app is keeping track of the number of attempts in a variable. This bruteforce restriction can be bypassed by changing the variable value in runtime using cycript.
LaunchKey unpair after10


Steps followed to bypass the bruteforce limit:
1. Connected to the iPhone over SSH.
2. Turned on PIN lock and selected unpair after 10 option.
3. Closed and reopened the app. It prompted for a passcode.
4. Entered wrong passcode for 9 times.
5. Attached LaunchKey process to cycript and obtained the view controller of currently displaying screen.
$cycript -p LaunchKey
> UIApp.keyWindow.rootViewController
> n=_
> n.visibleViewController
> v=_
 <LKPinViewController: 0x1f5d5d00>
6. Looked at the class dump for LKPinViewController interface and noticed an interesting variable tries.
@interface LKPinViewController : LKLockViewController <UITextFieldDelegate> {
	NSString* pinNumber;
	BOOL creation;
	NSString* firstPin;
	int tries;
	UITextField* pinDigitOneTextField;
	UITextField* pinDigitTwoTextField;
	UITextField* pinDigitThreeTextField;
	UITextField* pinDigitFourTextField;
	UIView* pinView;
	UIImageView* background;
	UIButton* cancelButton;
	UILabel* pinLabel;
	UINavigationBar* navigationBar;
	UIImageView* lkNavLogo;
	UILabel* notMatchLabel;
	UITextField* pinField;
7. Printed the value stored in tries variable and confirmed that it is the variable keeping track of passcode failed attempts.
&gt; v.tries
8. Changed the value to 0.
> v.tries=0
Now you can try another 9 attempts. This would allow to bruteforce the passcode without unpairing the device.

LaunchKey security team is very friendly and they fixed all the vulnerabilities within short time.  I have received 800$ in total for all the vulnerabilities as a bounty. Happy Hunting 🙂


Posted by on May 28, 2014 in iPhone


Tags: , ,

A brief overview of same-origin policy

Can My JavaScript Access Your Page Elements?

We all know that using JavaScript you can do many things for example read elements on a page, analyze the DOM etc. Now assume that you logged into and in another browser tab visited The question is can a script present in access the elements on the page loaded by The answer is a big NO. Imagine the chaos it would have caused if the answer is yes! But the scripts loaded by can happily access the page elements. So how does the browser decide which script can access which page? This is where Same Origin Policy comes in! SOP is one of the most important security concepts that govern how the modern web browsers work. This article explores about SOP, SOP rules and some techniques to bypass SOP.

Same-Origin Policy

Same-Origin Policy permits scripts running on pages originating from the ‘same site’ or ‘same origin’ to access each other’s DOM with no specific restrictions, but prevents access to DOM on different sites. So the how does browser identify whether the script and the page are from ‘same origin’ or not? The origin is calculated based on the combination of scheme, host and port. For example the scheme, host and port for are calculated as below:

Scheme: https || Host: facebook || Port: 8080

Browsers consider two resources to be of the same origin if and only if all these values are exactly the same. For example and are not same origin because the host is different.

Note: IE browser has 2 exceptions while checking for same origin

  1. IE doesn’t include port while calculating ‘origin’
  2. Same origin policy is not applied for sites which are under highly trusted zone.

Also note that SOP is not just limited to JavaScript. It also applies for XMLHttpRequest, Cookies, and Flash etc. We will see more about the same in the below sections.

Exceptions to SOP and their risks

SOP poses significant problems to large website which use multiple domains (due to the difference in the hostname).  Hence there are some exceptions which can be used to relax it.

Scripts that set domain to the same value:

You can use JavaScript to set the value of document.domain property. If two pages contain scripts which set domain to the same value, the SOP is relaxed for these two windows, and each window can interact with the other. For example, consider the earlier scenario where a script present on cannot access the DOM of a page loaded by Now if this script (present on sets its document.domain to then the script can happily access the DOM. Also note that a script cannot set the value of document.domain to any hostname. It can set the value only to a suffix of the current domain.

Risk: This is relatively safe because we are only talking about sub domains of a site. So scope for someone exploiting this is relatively low unless the sub domain is compromised.

CORS [Cross Origin Resource Sharing]:

CORS is a HTML5 feature that allows one site to access another site’s resources even if both are of different domains. Hence with CORS, JavaScript on a webpage can initiate an AJAX request to another site. To allow this process, the server which implements CORS, adds a HTTP header named ‘Access-Control-Allow-Origin:’ in the response. Now the even though is not of same origin can access this server’s pages.

Risk: Developers often tend to use ‘*’ to get the things working. CORS, being relatively new concept, is often misunderstood. If a site sets Access-Control-Allow-Origin:* it means an attacker can initiate AJAX request to this site with his JavaScript and can access the resources.  Hence while security testing a HTML5 site which has CORS enabled, look for Access-Control-Allow-Origin header to check if it allows only the allowed sites.

CDM [Cross Document Messaging]:

CDM or Cross Document Messaging is also one of the features introduced in HTML 5. This feature allows documents to communicate with one another across different domains. For example, Document A present on can communicate with document X present on (assume its present as an iframe) by issuing the below request from JavaScript:

var c = document.getElementsByTagName(‘iframe’)[0];
c.contentWindow.postMessage(‘Hiee’, ‘’);

Upon receiving this request, the script present on can respond back using the event listener.

function receiver(event) {
     if (event.origin == '') {
         if ( == 'Hiee') {
            event.source.postMessage('how are you?', event.origin);
         else {
               } } }

Risk: If the origin checking of the sender site is not done properly, there is a chance to run malicious code from other domains. It is also recommended to check the format of the incoming data to make sure that it is in the expected format.


Repeating the golden rule – You cannot make a cross domain Ajax request to update a current page. Here it is important to note that SOP does not restrict a site from loading JavaScript files from a different domain. With JSOP, by adding a <script> element to the page you can load JSON response from different domain. Because the code is loaded by the <script> tag, it can be normally executed. The below figure sums up everything!


Risk: Suppose a page hosted on uses JSONP to access services provided by then, the site has to completely trust From security perspective, excessive trust on other sites is never good. If is malicious it can run malicious code on the page loaded by Also a malicious page can request and obtain JSON data of another site by using the <script> tag and hence can be used to launch CSRF attacks.

Getting Around SOP

There are ways to turn off same origin policy in browsers. This can be exploited by attackers during targeted attacks on certain individuals. If an attacker can have physical access to the target system, he can turn off the SOP in that browser and can then launch his attack later on to steal certain information from the websites browsed by the user. Below are the options to turn off SOP in different browsers.

Internet Explorer:
-> Go to the Security tab. For the current zone click the ‘Custom level’ button.
-> In the next window, look for ‘Miscellaneous > Access data sources across domains’ and set it to “Disable”.

IE security settings

-> Open the Mozilla browser and enter ‘about:config’
-> Search for security.fileuri.strict_origin_policy and change the value to false by double clicking it as shown below.

firefox security settings

Google Chrome:
-> Start the chrome by passing the below argument:
C:\Program Files\Chrome\Chrome.exe –disable-web-security

-> Start the Safari by passing the below argument:
C:\Program Files\Safari\Safari.exe –disable-web-security



Posted by on April 30, 2014 in web application hacking


Tags: , ,

Elliptic Curve Cryptography: A Case for Mobile Encryption

It is needless to start this article explaining about the rise of mobile devices in the last few years. We all know about how smart phones have swept the world. But with mobiles you always look for concepts or solutions which are computationally cheap. For example, Android OS uses a dex compiler to convert the Java Byte code to .dex files before compiling them. Why? Because dex files are optimized code for low memory and low processing systems. Similarly when it comes to encryption on mobile devices we look for solutions which are computationally cheap and yet secure. ECC (Elliptic Curve Cryptography) provides exactly the same. This article explains about the why and how ECC is different from the other encryptions.

What is the need for an alternative encryption scheme when you have RSA?

Mobile phones have 2 main limitations:

  1. Computational limitations – Because the processors used on mobile devices are less capable compared to the ones used on a desktop system. Although there are a few devices which use dual core/quad core, most of the mobiles in general are not equipped with these kinds of CPU’s. 2.
  2. Battery Life – Mobile devices run throughout the day and battery consumption is one of the important aspects for the success of a device. The more computations a device has to perform the more battery life is consumed.

Consider a normal user who visits a banking site on his mobile device to transfer money to his friend. A low processing powered mobile device would struggle with the 1024 bit computations of RSA. With major financial institutions, the smallest key size allowed for RSA is 1024 bits. This activity not only takes time to complete but also eats into the battery life of the device.

What is ECC?

Elliptical curve cryptography (ECC) is a public key encryption technique based on elliptic curve theory that can be used to create faster, smaller, and more efficient cryptographic keys. So let us analyze the ECC algorithm by considering 2 factors – Security & Efficiency.


When we talk about public key encryption algorithms, the first things that come to mind are RSA and Diffie-Hellman. Both these algorithms use 1024 bit keys for major transactions. But it’s important here to note that NIST (National Institute for Standards and Technology) has recommended 1024 bit parameters only till the year 2010. The RSA algorithm is into its 40th birthday and probably regarded as the standard public key exchange on the Internet. After 2010, NIST believes that the existing systems be upgraded to a different set up to provide more security (although we no longer believe NSA or NIST :)). One option is to simply increase the key size used with these algorithms. However you are not quite sure as to what is the safe key size. Other option is to switch to a different set up which is more secure. ECC here comes to rescue. ECC generates keys through the properties of the elliptic curve equation instead of the traditional method of generation as the product of very large prime numbers.

RSA’s security is based on the principle that factoring is slow and hard i.e. it is difficult to factor a large integer composed of two or more large prime factors. With the improvements in technology, the gap between factoring and multiplying is slowly reducing. In the coming years, certainly this is bound to break. Switching to a larger key size is one option but it would only give the breathing space for a few more years.

An elliptic curve is represented as a looping line intersecting two axes. ECC is based on properties of a particular type of equation created from the mathematical group derived from points where the line intersects the axes. Multiplying a point on the curve by a number will produce another point on the curve, but it is very difficult to find what number was used, even if you know the original point and the result. For elliptic-curve-based protocols, it is assumed that finding the discrete logarithm of a random elliptic curve element with respect to a publicly known base point is infeasible –this is called as the elliptic curve discrete logarithm problem or ECDLP. Equations based on elliptic curves have a characteristic that is very valuable for cryptography purposes: they are relatively easy to perform, and extremely difficult to reverse. Despite almost three decades of research, mathematicians still haven’t found an algorithm to solve this problem. To state in simple words, for numbers of the same size, solving elliptic curve discrete logarithms is significantly very much harder than factoring. ECC was developed by Certicom, a mobile e-business security provider. RSA has been developing its own version of ECC. Other manufacturers, including Motorola, Cylink, Siemens, and VeriFone etc have already included support for ECC in their products.

The curious case of Angela Merkel’s phone tapping 🙂

A few months back, the news that German Chancellor Angela Merkel’s phone was tapped by the US government has created quite a scene. Amid this controversy there was also news that Merkel used 2 phones – one BlackBerry (encrypted) and the other Nokia (not encrypted). In September, new government phones which were manufactured by the Canadian company BlackBerry were delivered to all government officials (including Merkel) after being updated by the German company Secusmart. They contain a special encryption card that scrambles speech and data before transmitting it. So this Secusmart card used the Elliptic curve cryptography to encrypt and decrypt the mobile speech. And just because it is encrypted doesn’t mean its safe. It all depends upon how difficult it is to crack the key.


In terms of efficiency, ECC wins the race by large margin. The below table explains it all. The following table gives the key sizes recommended by the National Institute of Standards and Technology to protect keys used in conventional encryption algorithms like the (DES) and (AES) together with the key sizes for RSA, Diffie-Hellman and elliptic curves that are needed to provide equivalent security.

crypto key sizes

For instance to protect 128-bit AES keys using RSA or Diffie-Hellman you need to use 3072-bit parameters. The equivalent key size for elliptic curves is only 256 bits. Also, as the symmetric key size increases, the corresponding RSA/Diffie Hellman key size increases at a much higher rate compared to ECC key size. This is particularly a strong case for moving towards ECC on low powered environments like mobile devices, wireless devices, smart cards etc.

Real word ECC – is it safe?

The reports leaked by Edward Snowden suggested that Dual Elliptic Curve Deterministic Random Bit Generation (or Dual_EC_DRBG) had been included as a NIST national standard due to the influence of NSA, which had included a deliberate weakness in the algorithm and the recommended elliptic curve. RSA Security then issued an advisory recommending that its customers discontinue using any software based on Dual_EC_DRBG. Wikipedia mentions “Implementations which used Dual_EC_DRBG would usually have gotten it via a library. At least RSA Security (BSAFE library), OpenSSL, Microsoft, and Cisco has libraries which included Dual_EC_DRBG, but only BSAFE used it by default. According to the Reuters article which revealed the secret $10 million deal between RSA Security and NSA, RSA Security’s BSAFE was most important distributor of the backdoored algorithm. There was a flaw in OpenSSL’s implementation of Dual_EC_DRBG that made it non-working outside test mode, from which OpenSSL’s Steve Marquess concludes that nobody used OpenSSL’s Dual_EC_DRBG implementation”. All these point out the dark side of the NSA 🙂

However there are several different standards which propose ways of selecting curves for use in elliptic-curve cryptography (ECC). Each of these standards tries to make sure that the elliptic-curve discrete-logarithm problem (ECDLP – the problem of finding an ECC user’s secret key, given the user’s public key) is difficult. Below are some of the standards in use:

  • ANSI X9.62
  • IEEE P136
  • SEC 2
  • NIST FIPS 186-2
  • ANSI X9.63
  • Brainpool
  • NSA Suite B
  • ANSSI FRP256V1

Hence selecting the right curve and parameters is also important to ensure real world ECC security. More information can be found at the link:

To summarize,

-> ECC employs a relatively short encryption key. It is faster and requires less computing power than other first-generation encryption public key algorithms such as RSA, Diffie-Hellman. For example, a 160-bit ECC encryption key provides the same security as a 1024-bit RSA encryption key and can be up to 15 times faster, depending on the platform on which it is implemented.

-> Extremely helpful for use on low memory and low computing environments such as mobile devices, wireless devices etc.

-> Elliptic curves are supported by all modern browsers, and most certification authorities offer elliptic curve certificates.

Elliptic curve cryptography has proven to be a promising solution for the implementation of public-key cryptosystems. As widespread use of the internet and mobile devices continues to increase, transferring data the information with less computation and in a more secure manner has been the primary focus. With smaller key sizes and lower processing requirements, elliptic curve cryptography serves the purpose on mobile devices.


Posted by on February 28, 2014 in Android, iPhone

1 Comment

Tags: ,

Advanced Exploitation using XSS-SHELL

Before getting into XSS Shell, let us recollect few basics of XSS (Cross Site Scripting). XSS is one of the most common vulnerability that exists in many of the web applications today. XSS is a technique through which an attacker tries to compromise the web application by executing a malicious script. The attacker does this by breaking the Same-Origin policy of the web application. Same–Origin policy defines that the script which is coming from the foreign site or the script that doesn’t belongs to the same domain (i.e document.domain) should not be processed by the application.

Once if an attacker finds XSS in a web application, he can perform different kinds of attacks.
– 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
– Stored
– DOM Based

Reflected 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 renders back to the users.

For Example, consider the URL: http://www.[sample].com/error.html?value=learn+hacking

This shows the message learn hacking in the response of the application. Which means the application is extracting the message from the URL, processing it and displaying it 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: http://www.[sample].com/error.html?value=<script>alert(1)</script>

When you click on the above URL it executes the script and pops up an alert box.

Stored XSS:
This type of vulnerability exist in applications which takes input from the user, store it and later displays to other users. For example, consider Facebook application which allows commenting on any picture or status update 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 visits or views particular page or post will be effected.

So Stored XSS consists of two things to do. Initially the attacker enters 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 user click on the crafted URL, server response doesn’t consist of 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. 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.

XSS Shell

XSS Shell is a powerful tool developed in ASP .NET which runs as a XSS backdoor between the attacker and the victim. With XSS, attacker has only one shot to execute any kind of attack on victim. Once the victim navigates from the malicious page the attacker’s interaction or the communication with the victim ends, whereas using XSS Shell help 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 responds and has an ability to talk cross-domain.

Attack Process:
1. Setup XSS Shell Server.
2. Configure XSS Tunnel to use XSS Shell Server.
3. Inject malicious script into a vulnerable Website.
4. Launch XSS Tunnel and wait for victim.
5. Configure the browser or tool to use XSS Tunnel.
6. When victim visits the vulnerable page, start using XSS Tunnel.

How XSS Shell works:

xss shell process 1

As shown in the figure, initially 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 server establishes a channel to interact with the victim.

xss shell process 2

Once a channel has been created between the victim and XSS Shell Server, attacker can control the communication through XSS Shell Admin Interface. XSS Shell Admin Interface is nothing but a GUI environment which provides definite set of commands which the attacker can execute to perform certain actions.

On executing a command, necessary function or the script will be called at XSS Shell Server level and it is sent to the victim. The script will be processed and executed at victim browser and it sends corresponding results to the XSS Shell Server. XSS Shell Server stores the results in MS-Access database which is normally used by it to store the data. Attacker can extract the results from the database and look at it whenever he wants.

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 an Open Source and quite easy to implement new commands.

– An IIS Server where you can host .asp files.
– Microsoft Access database (.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
– Installation
– Configure XSS Shell

Configuring IIS:
In-order to configure IIS in windows 7 or above, follow the steps given below:

1. Click on Start Menu and goto Control Panel.
2. Click Programs and then click on Turn windows features on or off.
3. A new Windows Features dialog box will appear. Expand Internet Information Services.
4. Select default features that has to be installed with IIS.
5. You can expand the additional categories and install any additional features if required.
6. 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/

IIS 7 default page

XSS Shell uses ASP .NET and MS-Access database. So just make sure that you have installed .NET framework and MS-Access db on your machine.

Configuring XSS Shell Admin Interface:
– After downloading the file, extract the file and you can see two folders – XSSshell & XSSTunnel.
XSSshell is admin interface and you need to configure it in your machine. Copy XSSshell folder to your web server.

xss shell folder

– You can see a sub-folder named db in the XSSShell folder as shown in the above image. Copy that to a secure place because XSSshell stores complete data in that db, whatever it is either victim’s session cookies or any other attacked data that belongs to 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 know where the db is and interact with it.

xssshell source 1

– Edit the path to the location such that it should point to the place where db folder is present in your machine.xssshell source 2– The above image, shows 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)
– By default it uses port 80, but if you change the port number while configure 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.

xssshell source 3

– Above figure 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, which would contain three sections.

xss shell admin interface

As mentioned earlier XSSshell has pre-defined commands which make attacker’s life easy to perform any attack on the victim. Commands section contains all the commands supported by the shell. As it is a 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.

XSS Tunnel:

XSS Tunnel is just like a proxy tool which runs on attacker machine and captures traffic through xss channel on XSSshell server. In-order to do this XSS Tunnel should be able to understand where 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.

xss tunnel - connection success

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. The below image shows all the pages visited by the victim and actions performed.

xss tunnel - traffic capture


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.



Posted by on January 29, 2014 in web application hacking

1 Comment

Tags: , , ,