TryHackMe Include: From BOPLA to LFI and RCE

Introduction

In this write-up, I'll walk through my experience solving the Include room on TryHackMe[https://tryhackme.com/room/include], covering the process from initial reconnaissance to exploiting multiple web application vulnerabilities and achieving Remote Code Execution (RCE).

Stage 1: Reconnaissance

1.1. Scanning Open Ports

As usual, I started with port scanning to identify the services running on the target machine.

I used Nmap with service version detection and scanned all TCP ports:

nmap 10.129.165.138 -sV -p-

nmap 10.129.165.138 -sV -p-

The -p- option scans all TCP ports, while -sV attempts to identify the services and their versions.

1.2. Accessing the Web Applications

My first attempt was to access the target through the standard HTTP port, 80. However, I couldn't access the application there.

Instead of assuming the web server was unavailable, I returned to the scan results and investigated the other open ports.

I discovered web applications accessible through ports 4000 and 50000.

This was an important reminder: web applications don't necessarily run on the default HTTP and HTTPS ports. Whenever a scan reveals unusual open ports, it's worth investigating whether they host additional web services.

1.3. Directory Enumeration

Next, I performed directory enumeration to discover additional resources and potentially interesting endpoints.

Enumerating the web application to identify accessible directories and resources.

At this point, I had identified the web applications and established a starting point for further investigation.

The next step was to examine their functionality and determine whether any of the exposed features could be exploited.

Stage 2: Discovering the Administrative Credentials

I started by opening the application on port 50000 in Firefox using HTTP.

The application presented a login page, so I began investigating its authentication mechanism.

My first idea was to test whether SQL injection could bypass the login process.

However, my initial attempts didn't succeed. I couldn't establish a working SQL injection vulnerability from the login form.

Rather than spending more time forcing an unsuccessful attack, I returned to the other application running on port 4000.

2.2. Accessing the Second Web Application

I opened the application on port 4000 and explored its functionality.

Investigating the second web application exposed by the initial scan.

During this stage, I identified an opportunity to use the credentials discovered during my investigation of the authentication functionality.

After authenticating, I was able to access the application as the guest user.

Although I had access to the application, I still needed to investigate whether the current account had access to functionality intended for administrators.

2.3. Inspecting the Profile and Session

I opened my profile and examined the information associated with the authenticated user.

The profile exposed several properties, includingisAdmin property caught my attention.

I wanted to determine whether the application properly enforced authorization over individual user properties or whether it trusted values that could be manipulated by the client.

I also inspected the session cookie. My initial investigation didn't reveal an obvious way to modify the session by Base64-decoding it or exploiting insecure deserialization.

This led me to investigate the profile data itself.

2.4. Exploiting BOPLA (Broken Object Property Level Authorization)

While examining the profile functionality, I discovered that the isAdmin property could be manipulated.

I changed the property to:

{
  isAdmin: True
}

{
  isAdmin: True
}

The application subsequently displayed the modified property in the profile.

This finding indicated a potential Broken Object Property Level Authorization (BOPLA) vulnerability.

After manipulating the property, I noticed additional navigation options in the application, including the API and Settings tabs.

This gave me more functionality to investigate.

Stage 3: Exploiting SSRF to Retrieve SysMon Credentials

3.1. Exploring the API and Settings

After investigating the profile functionality, I explored the newly accessible tabs.

The API section revealed information about the application's functionality and the services it interacted with.

I then moved to the Settings section , the settings page contained a feature for updating the banner image URL.

At first glance, this appeared to be an ordinary feature that allowed the application to retrieve an image from a specified URL.

However, any server-side feature that fetches user-supplied URLs deserves further investigation. If the application doesn't validate the destination properly, an attacker may be able to make the server send requests to internal services that aren't directly accessible from outside.

This is the basic idea behind Server-Side Request Forgery (SSRF).

3.2. Testing for SSRF

The banner image setting allowed me to provide a URL.

I investigated whether the application would fetch resources from internal services rather than restricting requests to trusted external destinations.

I used the following internal URL in the banner image field:

http://127.0.0.1:5000/getAllAdmins101099999

http://127.0.0.1:5000/getAllAdmins101099999

3.3. Discovering Encoded Configuration Data

After submitting the request, I observed that the application returned content formatted as a Base64-encoded data URL.

I copied the encoded content and opened CyberChef to decode it.

After decoding the Base64 data, I discovered configuration information containing credentials for the SysMon application.

The relevant fields were:

This finding provided the credentials needed for the next stage.

3.4. Accessing SysMon

With the recovered credentials, I returned to the SysMon application and attempted to authenticate.

The credentials provided access to the application, allowing me to continue investigating its functionality.

After gaining access, I located the first flag.

Stage 4: Exploiting Local File Inclusion

4.1. Investigating SysMon Functionality

While exploring SysMon, I encountered a feature related to logging.

This caught my attention because log files can sometimes become an entry point for further exploitation when an application has a Local File Inclusion vulnerability.

The idea is straightforward: if an application allows an attacker to include or read arbitrary local files, and the attacker can influence the contents of a log file, it may be possible to turn file inclusion into code execution.

This technique is commonly known as LFI-to-RCE through log poisoning.

The logging functionality provided a useful lead, so I began investigating the application for a vulnerable file inclusion endpoint.

4.2. Identifying the File Inclusion Endpoint

I examined the application's source and available functionality to identify how it handled files and user-controlled parameters.

The objective was to find an endpoint that accepted a file path or resource identifier and determine whether the application properly restricted which files could be accessed.

After experimenting with different inputs, I found a payload that allowed me to retrieve /etc/passwd.

This confirmed that the application had a Local File Inclusion vulnerability.

The next question was whether I could influence a file that the vulnerable application would subsequently interpret as PHP code.

Stage 5: From LFI to RCE Through Log Poisoning

5.1. Understanding the Attack Path

During my initial reconnaissance, Nmap had identified a mail service on port 25.

I connected this finding with the logging functionality I had discovered earlier.

Mail services commonly write information about incoming messages and mail activity to log files. On some Linux systems, these logs may be stored in locations such as:

/var/log/mail.log

/var/log/mail.log

If an attacker can inject controlled content into a log file, and a vulnerable PHP application subsequently includes that file, the attacker may be able to cause the PHP interpreter to execute the injected code.

The success of this technique depends on the target's configuration, the permissions of the relevant files, and how the application processes the included file.

The objective was to introduce a PHP payload into the log and then use the previously identified LFI vulnerability to include it.

5.2. Achieving Remote Code Execution

After attempting the log-poisoning technique, I used the file inclusion vulnerability to trigger the processing of the modified log.

I then tested command execution using:

id

id

The command returns the identity of the user under which the process is executing.

In this context, it provided a straightforward way to determine whether the injected PHP code was being executed by the server.

The original LFI vulnerability had allowed me to read a local file. By combining it with the ability to influence a log file, I was able to extend the impact to Remote Code Execution.

5.3. Locating the Second Flag

After confirming command execution, I continued investigating the filesystem to locate the remaining flag.

My objective was to identify hidden files and directories that might contain the requested evidence.

During this stage, I located the file containing the second flag.

With both flags located, I had completed the main objectives of the room.

At the end, I hope you enjoyed reading this write-up and found it useful and informative.

Happy hacking!

Contents