Chatterbox Writeup w/o Metasploit
Last updated
Last updated
Run the nmapAutomator script to enumerate open ports and services running on those ports.
All: Runs all the scans consecutively.
We get back the following result.
We have one port open.
Port 9256: ****running AChat chat system
Before we move on to enumeration, let’s make some mental notes about the scan results.
Port 9256 is running some kind of chat system that I’m not familiar with, so the first we’ll do is google it to figure out what it is. Then we’ll run searchsploit on it to see if it is associated to any known vulnerabilities.
Doing a quick google search on the service tells us that AChat is a software that enables you to chat on your local network. It can also be used to share and send files/images to other users.
Now that we know what it is, let’s run searchsploit on it.
It’s vulnerable to a remote buffer overflow and there is both apython and metasploit exploit for it. We will of course work with the non-metasploit solution.
Copy the python script to your current directory.
Looking at the exploit code we make note of the following things:
It looks like your classic stack buffer overflow that allows you to overflow the buffer and include malicious shell code that will get executed on the box.
The exploit author was nice enough to give us the msfvenom command that generates the malicious payload (‘buf’ variable) including the bad characters to avoid. This makes our life so much easier! The command simply spawns the calc.exe program on the target machine. So we’ll have to change the command to send a reverse shell back to our attack machine.
We also need to change the server_address to that of the IP address of Chatterbox.
There seems to be a length limit of 1152 bytes on the payload. Anything that exceeds that will probably not work. We’ll keep that in mind when using msfvenom to generate our reverse shell.
Use msfvenom to generate the reverse shell payload.
We get back the following result.
The payload size is 774 bytes, so within the limit. Copy the payload and add it in place of the payload included in the exploit. Also change the IP address to Chatterbox’s IP address.
Then setup a listener on the attack machine to receive the reverse shell.
Run the exploit.
We get a shell!
Grab the user.txt flag.
We’re running as a low privileged user, so we’ll need to escalate privileges.
Display the user account information.
Next, view all the users on the system.
We have three users. The user we want to compromise is the Administrator account.
Next, let’s check the system privileges that are enabled for the Alfred user.
SetImpersonatePrivilege is not enabled so we can’t use the Juicy Potato exploit to escalate privileges.
Run the systeminfo command.
The box has 208 hotfixes installed so it’s unlikely that we can escalate privileges using a kernel exploit (although it might be possible, I haven’t checked).
Let’s see if we have access to the Administrator directory.
We do. That’s odd. Let’s try and view the root.txt flag.
We don’t have permission. View the permissions on the root.txt file.
Only Administrator has full access (F) on this file. Let’s view the permissions on the Desktop directory. We must have some kind of permission on it because we’re able to enter it.
We have full access (F) on the Desktop directory. The Alfred user is also configured to own the root.txt file.
So we can simply grant ourselves access to it using the following command.
View the permissions again to confirm that the change was made.
Perfect! We should now be able to view the root.txt flag.
Alright, all we did is view the root flag, we didn’t really escalate privileges. Unfortunately our shell can’t handle running PowerShell, so in the next section, we’ll start from the beginning and send a PowerShell reverse shell back to our target machine and from there we’ll escalate our privileges to Administrator.
View the options for PowerShell reverse shells in msfvenom.
We’ll go with the powershell_reverse_tcp option.
Unfortunately, this gives us a payload that is larger than the maximum size specified in the exploit.
So instead, we’ll just use the windows/exec module to download and execute the Nishang reverse shell.
Download the Nishang repository and copy the Invoke-PowerShellTcp.ps1 script into your current directory.
Add the following line to the end of the script with the attack machine configuration settings.
When called, this sends a reverse shell back to our attack machine on port 1234.
Setup a listener to receive the reverse shell.
Next, use msfvenom to generate a payload that downloads the PowerShell script and executes it.
We get back the following result.
Good! The payload size is 684 bytes, so it’s within the limit. Copy the payload and add it in place of the payload included in the exploit.
Start up a python server in the directory that the PowerShell script resides in.
Run the exploit.
We get a PowerShell shell!
We’ll use the PowerUp.ps1 script to determine if there are any misconfigurations that lead to privilege escalation.
Upload and run the script on the target machine.
We get back two interesting results.
Viewing the Unattend.xml file, we see that the password was redacted. So let’s focus on the Autologon credentials. The default username is “Alfred” and the default password is “Welcome1!”. I don’t have much experience with Windows, so I googled Autologin credentials to learn more about it.
As stated in the article, these credentials are stored in the registry in plain text. The manual commands for extracting these credentials are:
These credentials are set by the administrator. Since users have a tendency to reuse passwords, let’s see if the administrator account is set to the same password.
To do that, first run the following command to convert the plain text string “Welcome1!” into a secure string and store the result in the $password variable.
ConvertTo-SecureString: Converts plain text to secure strings.
-AsPlainText: Specifies a plain text string to convert to a secure string.
-Force: Confirms that you understand the implications of using the AsPlainText parameter and still want to use it.
Second, create a new object to store these credentials.
Third, we’ll use these credentials to start PowerShell and send a (hopefully privileged) reverse shell back to our attack machine.
In the attack machine, copy the shell.ps1 script we used earlier and save it in the file shell-admin.ps1.
Change shell-admin.ps1 to send a reverse shell to our attack machine on port 6666.
Setup a python server in the directory that the script resides in.
Setup a listener to receive the reverse shell.
On the target machine, use the credentials to start PowerShell to download the shell-admin.ps1 script, run it and send a reverse shell back to our attack machine.
We get a shell with administrator privileges!
Now we can view the root.txt flag without having to change the ACL permissions on it.
To gain an initial foothold on the box we exploited one vulnerability.
Buffer Overflow vulnerability. The AChat chat service being used was vulnerable to a known remote buffer overflow vulnerability. This allowed us to execute shell code on the box and send a reverse shell back to our attack machine. Since this is a known vulnerability, the administrator should have used the patched version of AChat or completely disabled the service if a patch is not available.
To escalate privileges we exploited three vulnerabilities.
Security misconfiguration. The Alfred user had full access on the Administrator directory and owned the root.txt file. Although we weren’t initially able to view the root.txt file, we did own it so we simply granted ourselves access to view the file. The administrator should have conformed to the principle of least privilege when setting up user permissions.
Automatic logon credentials saved in plaintext. Again, I’m not too familiar with the Windows system, but it seems like there is an option to store automatic logon credentials in encrypted form. This way, as a non-privileged user we wouldn’t have been able to access these credentials.
Reuse of credentials. The administrator had setup his password to be the same as the password used for automatic logon. Since these credentials are saved in cleartext in the registry, we were able to view them and start up a PowerShell process that sent a privileged reverse shell back to our attack machine in the context of the Administrator user. It goes without saying that you should definitely not reuse credentials, especially when setting up a non-privileged account where the credentials will be stored in plaintext.
