What
A small webshop with username/password authentication to crack.
Difficulty: Easy
Flag0
Hint0: Something looks out of place with checkout
Let’s fire up Burp, set Scope, turn off intercept and just walk through the application. This will create a Site map on Target tab.
I’ve added both images to the cart and examined the checkout request.
On the Checkout page we can see “Payments temporarily disabled”.
Hint1: It’s always nice to get free stuff
Cart value is passed to the server as URL encoded string. We can use Burp Inspector’s Decode feature to read it as JSON.
[[0, {"logo": "kitten.jpg", "price": 8.95, "name": "Kitten", "desc": "8\"x10\" color glossy photograph of a kitten."}]]
How about changing the price to 0.00
? We can now turn Burp’s intercept on and hit Check Out again.
Now forward the edited request and grab the free stuff plus the first FLAG.
Flag1
Hint0: There must be a way to administer the app
It is common to have an admin page, even for small sites. They also tend to share common names, like /admin.php
.
To access admin pages, users must authenticate themselves, using pages like /login.php
.
Hint1: Tools may help you find the entrypoint
Sure. Let’s check what other pages are there. For this, I used gobuster with a command:
gobuster dir -u https://IAMSOSORRY.ctf.hacker101.com/ -w /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-small.txt -z -t 100
-u <URL>
-w </path/to/wordlist-file> (start with a smaller list for low-hanging fruits)
-t <threads> (default is 10)
-z (to turn off the annoying “Progress” messages and show only hits)
Gobuster repo and full description for dir mode here.
Check the first result (note that the results are folders):
Hint2: Tools are also great for finding credentials
To see how the page responds, I shoot admin
/ password
credentials:
You can see, the error handling gives us too much info about what’s wrong here (“Invalid username”). Better practice is to show “Invalid username or password”, as the attacker has to brute force all combinations of usernames and passwords.
In our case, we have to find a correct username first, then we can go for the valid password.
I’ll brute force username
with Hydra, using a wordlist for usernames from SecLists.
hydra -L ~/repo/SecLists/Usernames/Names/names.txt -p "password" IAMSOSORRY.ctf.hacker101.com https-post-form "/login:username=^USER^&password=^PASS^:Invalid username"
We’be got the username. Let’s go for the password. I’ll use the same wordlist.
hydra -l IAMSOSORRY -P ~/repo/SecLists/Usernames/Names/names.txt IAMSOSORRY.ctf.hacker101.com https-post-form "/login:username=^USER^&password=^PASS^:Invalid password"
We can use the credentials on /login
. It will reveal the Edit feature below the images and show us the second FLAG.
Flag2
Hint0: Always test every input
Now that we are able to edit the product’s parameters, let’s try some basic XSS on the input fields. I’ll use numbers in alert messages to see which attack was successful.
Internal Server Error.. OK, let’s try them one-by-one, starting with Name.
Saved the changes, back to Home page. The pop-up message says that Name field is vulnerable to XSS.
Restore Name to Kitten
and add payload to Description. Save.
Back to Home page. Our XSS on Description field has also worked.
Remove payload from Description and add to Price.
After saving, the Internal Server Error is back. At least, we know which field has caused it.
But, where’s my FLAG?
Hint1: Bugs don’t always appear in a place where the data is entered
Let’s put the payload back to Name field, hit Save and head to Home page. Add a Kitten to the Cart.
The FLAG is included in the Shopping Cart.
Takeaway(s)
- Look what parameters are passed with the form
- Web login hack can take some time on a VM, relax