Hacker lair Welcome to my blog where I write about Threat Hunting, Pentesting and Cybersecurity in general.

Pentest Report

I was recently asked to write a sample Pentest Report for a client.

1.0 Penetration Test Report Preface

  • 1.1 Introduction

This report contains all efforts that were conducted in order to fully compromise the Hack the Box “Write-up” machine. This report should contain all lab data in the report template format as well as all items that were used to own the box.

  • 1.2 Objective

The objective of this report is to perform a penetration test against one of active machines on Hack the Box network. In this scenario an active machine named Write-up with an internal IP address of 10.10.10.138 on the Hack the Box private network has been selected for this exercise. The task is to follow a methodical approach in obtaining access to the target machine from beginning to end.

  • 1.3 Technical Requirements

In order to complete the penetration test report the following technical requirements need to be met: • Computer • Internet Access • Access to Hack the Box private network (VPN)

2.0 High-Level Summary

I was tasked by Context Information Security to register with Hack the Box and complete 1-2 active machines and write a technical report. Hack The Box is an online platform that allows security analyst to test their penetration testing skills and methodologies in real time scenarios and thus helps improving not only basics but also advanced concepts of pentesting. Proof of work is done through the use of flags which contain unique hash values. All boxes contain two flags, a user flag and a root flag, user flags are tied to a low privilege vulnerability that will give a hacker an initial foothold on the target machine while root flags require a privilege escalation targeting admin accounts, preferably root on Linux machines. A Linux base machine “Write-up” was selected among the list of public available active boxes for the exercise. Overall objective was to penetrate the machine, identify the system, and exploit flaws while reporting the findings back to Context Information Security. When performing the penetration test, there were a few alarming vulnerabilities that were identified on the Write-up machine. When performing the attacks, I was able to gain access through a security flaw on the web application, and from there I gained an initial foothold on the target machine and obtained access to a user account on the system. Using the user account I was able to privilege escalate to root using a reverse shell due to another security vulnerability related to administrative level rights and path priorities. The target system was successfully exploited and access was granted. The system as well as a brief description on how access was obtained are listed below:

• User – CMS Made Simple < 2.2.10 - SQL Injection CVE: 2019-9053 • Root – PATH hijacking. Perl reverse shell

  • 2.1 Recommendations The following recommendations should be applied. The CMS Made Simple application should be upgrade to fix the vulnerability that causes the blind SQL Injection and discloses the administrator username and hashed password. In addition, administrators with root level access should avoid at all cost creating cron jobs that use relative path with root level rights. This allow malicious attackers to compromised the path execution and leverage their user rights.

3.0 Methodology

I utilized a widely adopted approach to performing penetration testing that is effective in testing how secure the Hack the Box Labs machines are. Below is a breakdown of how I was able to identify and exploit the target system.

  1. Reconnaissance
    • Information Gathering
    • Service Enumeration
  2. Exploitation
  3. Privilege Escalation
  4. Reporting (This technical report)
  • 3.1 Information Gathering The information gathering portion of a penetration test focuses on identifying the scope of the penetration test. During this penetration test, the specific IP address of the target machine was:
    Write-up Network
    10.10.10.138
    Attacking machine
    10.10.14.14
    
  • 3.2 Service Enumeration In this phase of the penetration test we focus on finding out what services are alive on our target machine. The objective is to find if there are any vulnerabilities that can be exploited on the services running or at the very least give us information on potential attack vectors into a system. We used Nmap an open-source port scanner for the service enumeration The following ports were discovered after an Nmap scan:

We noticed that port 8O is open. Most likely there is a web application is running and we should find more interesting information on this port so let’s try with another tool. This time we going to use Nikto. For those unfamiliar with this tool, Nikto is an open-source vulnerability web scanner that scans webservers for dangerous files, outdated server software, and webserver misconfigurations.

No much information is returned and the scan was particularly quick. Let’s check and find out what application is running on port 80. We get a landing page that tell us about some sort of DoS protection that might explain why or Nikto scan returned short and probably the same would happen if we try a dirbuster scan and try brute-forcing the web application

Let’s try a different approach and use a web specialized tool called OWASP ZAP.

We located some interesting pages:

  • Writeup.php
  • Ypuffy.php
  • Blue.php
  • Robots.txt
  • Sitemap.xml

We then inspect the source code

We find out the name of the application running. CMS Made Simple. Let’s google the application and see if we can find some exploits on Exploitdb and start our exploitation phase.

3.3 Exploitation

Vulnerability Exploited: CMS Made Simple < 2.2.10 - SQL Injection

System Vulnerable: 10.10.10.138

User Flag: "d4e493fd4068afc9eb1aa6a55319f978"

Vulnerability Explanation: An issue was discovered in CMS Made Simple 2.2.8. It is possible with the News module, through a crafted URL, to achieve unauthenticated blind time-based SQL injection via the m1_idlist parameter. Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

Vulnerability Fix: The publishers of the CMS made simple recommend upgrading to the latest version of their application. It can be found here: https://www.cmsmadesimple.org/downloads/

CVSS v3.0 Severity and Metrics:

  • Base Score: 8.1 HIGH
  • Vector: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
  • Proof of Concept: Python Sqlexploit.py –u http://10.10.10.138/writeup/
  • Screenshots:

We download the python file, chmod it and run it using the –u argument for the url in order to launch a blind SQL injection attack on the web application.

The exploit obtains the following sensitive information:

We use an online decoder for the hashed password and the salt: password + salt

We decoded the password:

raykayjay9

We used the obtained credentials and try login on port 22 through SSH

We were able to get a SSH shell and the user flag.

However user Jkr does not have sudo permissions, so we need to escalate.

3.4 Privilege Escalation

Vulnerability Exploited: Elevation of Privilege using PATH priorities

System Vulnerable: 10.10.10.138

Root Flag:

"eeba47f60b48ef92b734f9b6198d7226"

Vulnerability Explanation: There is a cron job named run-parts that runs as root every time a user logins into the system. The run-parts script runs all executables scripts that finds on the specified directory. However the run-parts uses relative path instead of absolute path allowing a malicious hacker to hijack the path and modified the script with a reverse shell.

Vulnerability Fix: Using absolute PATH for scripts that run with root privilege.

Severity: Critical

Proof of Concept: We create a run-parts file on usr/local/bin which will trigger a reverse shell when the run-parts script tries to execute looking for is binary file on the relative path from left to right.

Screenshots:

We download and install PSPY tool which help us to monitor the processes that run as root on our target machine

We identify the proccess running with a relative path.

The first two path the run-parts check are /usr/local/sbin and /usr/local/bin We list the permissions on /usr/local directory and we noticed that we can’t READ but we can WRITE on /sbin and /bin as we are part of the group STAFF

We create a run-parts file on usr/local/bin which will trigger a reverse shell when the run-parts script tries to execute looking for is binary file on the relative path from left to right. Downloading the Perl reverse shell

We Modified the Perl script with our IP address and listening port 9999 to catch the reverse shell

We copy the evil shell and chmod it

We set up an nectcat listener

We open a new SSH session

Finally we get a reverse shell, we upgrade it to an interactive one and we obtain our Root flag

USER "d4e493fd4068afc9eb1aa6a55319f978"
ROOT "eeba47f60b48ef92b734f9b6198d7226"