OWSAP WebGoat - vulnerable web application Attack

WebGoat Week 9

Exploit Unchecked Email
This lesson has two steps: first you are to send a malicious script to the website admin and second you are to send a malicious script to a ‘friend’ from OWASP.
So the first thing you are going to do is put the input shown below into the Questions or Comments textbox and click send:
<script>alert(“XSS”)</script>


Next we need to send it to a ‘friend’ from OWASP.
Again put the script into the same textbox as before but before you click Send open up Tamer Data and start the tamper service. Intercept the request and change the to field to another email address.

You can see here that the email was going to webgoat.admin@owasp.org (40 is the ASCII for @, you need to put the % for URL encoding). So let’s send this to friend@owasp.org. You will need to enter this:
Friend%40owasp.org

Click the OK button and you should see this:

Bypass Client Side JavaScript Validation
For this lesson you are given seven JavaScript validation mechanisms, all of which must have valid values in to submit successfully. You are told that both client-side and server side validation occur on these mechanisms; break the client-side validation.

Open WebScarab and check off request intercepts make sure to have everything highlighted.  Now go the page and hit submit. Go to the WebScarab window and check the encoded url tabbed, and you will see the values. Simply modify them, in the screenshot below I simply added the @ to each field and then press accept.


Session Management Flaws
Hijack a Session
For this lesson you are attempting to gain access to a user’s session.
You will need the jhijack tool available at http://sourceforge.net/projects/jhijack/.  Go head and startup WebScarab and set your proxies. Turn on request intercepts, view hidden fields and finally launch the Jhijack.  Now reload the page and we will look at webscarab.

Let’s take a moment and configure out jHijack. We need put our Host, and port into it first.  In the example below we see the IP address of this particular VM and port number, yours maybe different. Now we need to find a success message of some kind. So far we have noticed in Webgoat, that every time we complete a mission we get a “Congratulations” so let’s use that in our Grep (it’s case sensitive).  The last part we need to fill in is the URL.  See below.

Now we need to go back to WebScarab and select the Session ID tab (if you don’t see it make sure you are using WebScarab in it’s full version. Select previous requests and choose the appropriate url (picture below).  Now select the cookie weakid and remove it.

Go to the bottom of the screen and hit test. You should receive this success message.

Now we need to collect some data. Set the fetch number to 50 and hit fetch. Go up to the Analysis tab and set the session ID and you should receive the list of cookies out there.  We want to look specifically at the Session ID numerical value. Not that it is incrementing by 1.  Now, there is a gap there, between 19400 and 19402. That’s an open session so let’s focus on that.

The second part of the values has a large gap between them so we need to “guess” at what that value is, but we have JjHijack to make this really simple. Copy out the one above and below the target and  paste them into a notepad. Doing this makes it easier to see and copy.  See the example below. Notice the [] is a range.

Now it’s simply filling in the missing information in jHijack. Go back to WebScarab and gather the JsessionID, parameters and  enter them in. Note we want to place a $ at the end of our WEAKID value. Finally, take the range and enter that in.  Then hit hijack. See below.

We refresh the page one last time and go back to the WebScarab intercept and swap out the weakid.

And hit accept and we have our congratulations message.

Spoof an Authentication Cookie
For this lesson you are told to login using either webgoat/webgoat or aspect/aspect as the username/password combination. Next you are told to edit the cookie to change your identity to alice.
So first off log in as webgoat and click the Login button.

On the top of the webgoat page you should see a link that says Show Cookies. Click on the Show Cookies option and you will see the cookie that was created when you logged in as webgoat.

The authorization cookie or the user webgoat is 65432ubphcfx as shown above.
Go ahead and click the Logout button and then login with aspec/aspect next:

Click on the Show Cookies link again (might have to click twice) and you should get your authorization cookie:

For this authorization cookie we see that aspect has a value of 65432udfqtb.
So the different between the two logins is the letters after 65432.
The key to this attack is that the username is a really basic cipher. Let’s take a look at these authorization cookies versus their usernames:

The first thing that I noticed was that both the aspect and webgoat ciphers both start with u as the first character. The second thing that I noticed is that both webgoat and aspect both end in t. Next you can see that the last character of the webgoat cipher is x and x is one letter ahead of w. Also u is one character ahead of t which explains why both ciphers tart with u. The cipher pattern is a reverse of the login name and all letters are shifted up one. Now that we know this we can begin editing the cookie to change our login name to alice.
To do this lets first do the cipher by hand:

Ok now open up Firebug and edit the cookie value so that it is 65432fdjmb
To do this right click on the AuthCookie value when the menu for it is expanded and click Edit:

You will see a popup window called Edit Cookie. Change the value to the one we determined for user alice:

Click the OK button and refresh the page.