1

Penetration Test Report

Target: Jarvis (HTB)

Report by

3/25/2022
 2

Table of Contents

1.0 Introduction and Objective 3

1.1 Introduction

1.2 Objective

2.0 Report – High-Level Summary 4

2.1 High-Level Summary

2.2 Recommendations

3.0 Report – Methodologies 6

3.1 Enumeration 6

3.2 RCE via Website SQLi 11

3.3 Lateral Movement via simpler.py 15

3.4 Privilege Escalation via systemctl SUID 19

 3

1.0 Introduction and Objective

1.1 Introduction

This report contains complete and detailed documentation of all steps necessary to compromise
the target machine. This machine is identified by IP address 10.10.10.143, known under the simple
name of “Jarvis.” Any associated vulnerabilities, proof of concept scripts, CVEs, etc. will be
sourced and linked for further background information. Screenshots of the exploitation process
will be included for demonstration of specific commands used.

1.2 Objective

The objective of this black-box penetration test was to discover and exploit vulnerabilities in the
aforementioned machine, with the ultimate target being unrestricted root-level access. The scope
was not to exceed this specific box, nor were denial of service attacks permitted in the test. This
report’s objective is to demonstrate the process used in a clear, concise and easily reproducible
manner as well as explain any steps necessary to patch associated vulnerabilities and properly
secure the machine.
 4

2.0 Report – High-Level Summary

2.1 High-Level Summary

I was tasked with performing a penetration test against the Jarvis box on the HTB network. This
penetration test served as a simulated attack against this specific machine.

The focus of this test was to perform attacks, similar to those of a malicious entity, in order to
exploit the Jarvis box to obtain unrestricted root-level access on its domain. My overall objective
was to evaluate the network, identify active systems and exploit any discovered flaws in such
systems as necessary, all while remaining within the agreed-upon scope and reporting all findings.

While conducting this test, multiple vulnerabilities were discovered. An SQLi vulnerability was
discovered for the website, and various sqlmap tools were used to bypass the WAF and get a shell
as www-data. From there, simpler.py was found to have insufficient input sanitization and abused
for a shell as pepper. systemctl had the SUID bit enabled, and this was abused for root-level access.

2.2 Recommendations

It is my firm recommendation that all vulnerabilities found are thoroughly patched as follows:

• Input sanitization should be implemented on the website to prevent SQLi. Unexpected

and/or potentially malicious characters such as ‘ should not be accepted in the cod
parameter’s input, nor should inputs undergo any kind of processing until validated.
o SQLi vulnerabilities are extremely dangerous and very easily exploitable; therefore
this patch should be given high priority.
• simpler.py should have its input sanitization adjusted to prevent command injection. The
characters used in this test, $(), should obviously be blacklisted; additionally, consider
using Python’s ping module instead of an os.system call so as to further prevent command
injection. Otherwise, www-data’s sudo permissions might be adjusted to prevent priv esc
via the script.
o Any of the options here might be implemented. Overall, patching this script should
be treated with medium priority.
• The systemctl SUID bit should be turned off, as enabling it allows for an easy and
commonly-known privilege escalation vulnerability.
 5

o Disabling the systemctl SUID bit should be treated with medium priority as well.
Securing the point with which most users will be interacting (here, the web app) is
of the highest priority.
 6

3.0 Report – Methodologies

3.1 Enumeration

nmap finds ports 22, 80, and 64999 open; the latter is an HTTP server.

The website is for Stark Hotel.

 7

There are both “rooms” and “dining & bar” pages; hyperlinks don’t seem to work on the latter.
 8

On the former page, room rental pages can be accessed. I’ll look at this more in a moment.
 9

Enumerating the rest of the site, a phpMyAdmin directory can be found.

Visiting it returns a login page, and default/common credentials don’t work.

 10

The robots.txt found in dirb is empty.

Quickly looking at port 64999, it returns a ban message. Nothing else can be found on this port.

Revisiting the room rental page, I noted a parameter in the URL. Adjusting this parameter and
adding an apostrophe causes the page to break, indicating a potential SQLi vulnerability.
 11

3.2 RCE via Website SQLi

I run sqlmap against the page, and it quickly detects some form of WAF or IPS.

Returning to the website gives the same message as on port 64999. If I want to use sqlmap to
enumerate, I’ll have to use some tricks.

These tricks are some extra flags, including –random-agent to mess with the User Agent string.
 12

This new command works, and an SQLi vulnerability is found.

With this, I can dump usernames and passwords from the database.

I find credentials for a single user: DBadmin.

 13

These credentials let me log into phpMyAdmin. I note the version as 4.8.0, which is vulnerable to
CVE-2018-12613. With an NVD risk score of 8.8/10, it allows for LFI as well as RCE, the former
of which can be seen here:

I won’t be exploiting this for RCE, as I obtain it by a different means, but I still very highly
recommend updating phpMyAdmin to version 4.8.2 or later (preferably the latest secure patch to
prevent against other potential vulnerabilities).

For my method of RCE, I simply write a PHP backdoor file onto the website.
 14

From there, curl can be used to execute commands on the box.

nc can be used to obtain a full shell.

 15

3.3 Lateral Movement via simpler.py

There is one user on the box: pepper. I can access their folder, but I don’t have permission to read
the user flag.

Running sudo -l, one of the best commands to start with for box enumeration, quickly gives me a
potential priv esc vector: I have permission to run a Python script as pepper.
 16

The script is in /var/www/Admin-Utilities and has a couple IP-related capabilities.

The ping function is done via an os.system call, which opens a door for command injection. There
is some level of input sanitization, wherein a number of special characters typically used in
commands are forbidden.
 17

These characters, however, do not include $(), which can be abused to execute bash commands,
as seen here. whoami returns “pepper,” which then causes the system to run ping pepper. This
obviously returns a name resolution failure, but it proves that command injection is possible.

I can’t execute a bash nc command on its own, but I can write the command into a script and then
call that.
 18

Executing the malicious script gives me a reverse shell as pepper.

 19

3.4 Privilege Escalation via systemctl SUID

I’ll run LinPEAS to find potential priv esc vectors.

 20

Interestingly, systemctl’s SUID bit is set, giving me a perfect priv esc path.
 21

I configure a malicious service file, which will execute a nc command.

Since systemctl is set to be an SUID, it runs as root. Linking the service and starting it will execute
the nc command at a root level.

Just as you’d expect, this gives me a root shell.

 22

I note an interesting Python script in the root folder.

 23

This script seems to function as the WAF. It checks the logs regularly, and if in the course of eight
seconds, five or more requests containing room.php?cod are made from the same IP address, it
adds the IP to the ban list for 90 seconds, which causes all requests from that IP to be redirected to
port 64999.