Exercise: Enumeration and privilege escalation on Remote
This is a Windows machine that exposes an NFS file share which contains a file with a password for an application called Umbraco which is an open source Content Management System (CMS). The version of Umbraco running on the Remote machine has an authenticated remote code execution vulnerability and so this allows us to get a reverse shell on the box. Once on the box, enumeration using WinPEAS shows that there are a number of vulnerabilities that could allow escalation. The first is the user has the ability to edit the binary path for the UsoSvc (Update Orchestrator Service) and this allows us to run a remote shell as System. The other path is to exploit a vulnerability in an application called TeamViewer that stored its password in an encrypted form in the registry that is vulnerable to cracking. The third is to use Rogue Potato which exploits the fact that the user has the SeImpersonateToken privilege. An alternate to this is to run an exploit called PrintSpoofer.
An nmap scan shows that the Windows box is not an Active Directory domain controller (no LDAP, DNS or Kerberos). The box does have a web server on port 80 and has ftp on port 21.
PORT STATE SERVICE VERSION
21/tcp open ftp Microsoft ftpd
|_ftp-anon: Anonymous FTP login allowed (FTP code 230)
| ftp-syst:
|_ SYST: Windows_NT
80/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-title: Home - Acme Widgets
111/tcp open rpcbind 2-4 (RPC #100000)
| rpcinfo:
| program version port/proto service
| 100000 2,3,4 111/tcp rpcbind
| 100000 2,3,4 111/tcp6 rpcbind
| 100000 2,3,4 111/udp rpcbind
| 100000 2,3,4 111/udp6 rpcbind
| 100003 2,3 2049/udp nfs
| 100003 2,3 2049/udp6 nfs
| 100003 2,3,4 2049/tcp nfs
| 100003 2,3,4 2049/tcp6 nfs
| 100005 1,2,3 2049/tcp mountd
| 100005 1,2,3 2049/tcp6 mountd
| 100005 1,2,3 2049/udp mountd
| 100005 1,2,3 2049/udp6 mountd
| 100021 1,2,3,4 2049/tcp nlockmgr
| 100021 1,2,3,4 2049/tcp6 nlockmgr
| 100021 1,2,3,4 2049/udp nlockmgr
| 100021 1,2,3,4 2049/udp6 nlockmgr
| 100024 1 2049/tcp status
| 100024 1 2049/tcp6 status
| 100024 1 2049/udp status
|_ 100024 1 2049/udp6 status
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
445/tcp open microsoft-ds?
2049/tcp open mountd 1-3 (RPC #100005)
5357/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Service Unavailable
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
9685/tcp filtered unknown
47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
49664/tcp open msrpc Microsoft Windows RPC
49665/tcp open msrpc Microsoft Windows RPC
49666/tcp open msrpc Microsoft Windows RPC
49667/tcp open msrpc Microsoft Windows RPC
49678/tcp open msrpc Microsoft Windows RPC
49679/tcp open msrpc Microsoft Windows RPC
49680/tcp open msrpc Microsoft Windows RPC
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
|_clock-skew: 1h02m39s
| smb2-security-mode:
| 2.02:
|_ Message signing enabled but not required
| smb2-time:
| date: 2021-01-05T12:17:11
|_ start_date: N/AOn port 80, there is a website for ACME Widgets
The website has references to Umbraco in the source code and on the site itself as an address. Searching for Umbraco on the Internet reveals that Umbraco is a content management system (CMS) and that it has a login page that is normally located at http;//remote.htb/umbraco. Navigating to that page gets a login prompt:
This doesn't accept default credentials of admin/admin, admin/password, guest/guest etc. So turning to the FTP site, this accepts anonymous logins but there is nothing in the directory it has access to and we can't write either.
Looking at the nmap output, we can see that the machine has NFS (Network File System) running (the RPC services nfs, mountd on ports 111 and 2049). NFS is the unix network file sharing service and we can use the utility showmount (installed from the package nfs-common) to list any available shares:
We can then mount the directory /site_backups with the mount command:
The contents of this directory are:
This looks like the umbraco website files. Searching on the Internet again for details of where Umbraco stores credentials, we note that these are stored normally in the database which by default is Microsoft SQL Server Compact Edition. This database is stored in a file with an extension of sdf. For Umbraco, this is normally stored in the file App_Data/Umbraco.sdf. If you just looked at the Web.config file, this also references the data source information:
Theoretically, it should be possible to open the sdf file using a variety of different approaches on a Windows machine. When I tried this however, the database wouldn't open. An easier approach is to simply do strings on the database to extract all of the textual information and then grep for users. If we do this, we find a hash of a password for the user admin in the file:
Cracking the hash (b8be16afba8c314ad33d812f22a04991b90e2aaa) with John The Ripper reveals the password baconandcheese
Logging into the Umbraco site with user [email protected] and password baconandcheese gives us the admin site
In the help page we note that the version of Umbraco is 7.12.4
Using searchsploit, we find an authenticated remote code execution exploit for this particular version
We can copy the Python exploit to our local directory:
We need to change the cmd string and the authentication and host details
We can run a Python web server on port 8082 and run the exploit to verify that we get a hit which we do:
To get a reverse shell, we could use Metasploit but we can just as easily use Nishang (https://github.com/samratashok/nishang). We have used this before, so we can use Invoke-PowerShellTcp.ps1 and put the following line at the bottom of the file and rename it as revsh.ps1
We can then start a netcat listener on our machine and change the code of the exploit to download and execute the revsh.ps1 script. To do that, we can use the PowerShell command Invoke-WebRequest (IWR) to download the file and then execute it using Invoke-Expression (IEX). The code would then look like:
When we execute the exploit, we get a hit on the Python web server and then our netcat listener is invoked:
When we run whoami /all we find that we are the IIS user (iis apppool\defaultapppool) and that there are no other regular users on the machine other than Administrator. If we look in c:\Users\Public, we find the user.txt file with the flag. The next thing we can do is to download and run winPEAS.exe. We can use the winPEAS.exe program that is in the winPEAS/winPEASexe/winPEAS/bin/x64/Release directory. You can download it to the c:\Users\Public\Downloads using the PowerShell
Runing this, we see that winPEAS reports, we get a number of exploitable escalation paths reported. Firstly there is a list of OS level vulnerabilities related to the specific build. We will leave those for the moment to see what other options area available.
A potentially easier path to escalation is the fact that our account has access to the configuration of the UsoSvc which means that we can change the path of the binary it points to and run our own script or binary. This looks frar more exploitable. But let us continue and look if there is anything else.
This version of TeamViewer kept an encrypted version of passwords in the Windows registry and the key and IV are known (https://whynotsecurity.com/blog/teamviewer/) which means that they can be decrypted. Metasploit has a module to harvest TeamViewer credentials. So this is certainly something we can try.
A final exploit that is open to us is one that makes use of the SeImpersonatePrivilege which can be exploited using Juicy Potato which we have done on another machine earlier in this book. We will do this with another technique using an application called PrintSpoofer (https://github.com/itm4n/PrintSpoofer)
Let us start with the TeamViewer exploit. To do this, we will use Metasploit and so we need to get a meterpreter shell. So we can create a meterpreter reverse shell with msfvenom:
We can then copy that to the Remote machine as before using wget and then running the binary once we have set up a meterpreter handler in Metasploit using exploit/multi/handler and setting the options of LHOST and Payload to match what we used in msfvenom. After running the handler, we can run the meterpreter reverse shell and establish a session.
Once in the session, we can background it and then search for TeamViewer. This gives us a module windows/gather/credentials/teamviewer_passwords which we can then run to get the stored password:
This gives us the password !R3m0te!which by itself is not useful but we can see if it will work with the Administrator user using evil-winrm which it does!
To run the exploit for PrintSpoofer, download the executable from the release on GitHub (https://github.com/itm4n/PrintSpoofer). We can use our meterpreter session to upload it and then simply run it in a shell to get access to nt authority\system
Finally, the third way of exploiting this box is to change the UsoSvc path. We can use the application sc.exe to query the status of the service, stop it, change the path it is using for the service binary and then start it again. We can use the same meterpreter reverse shell we used previously.
In Metasploit, we can go back to exploit/multi/handler and run it again. We don't need to change anything and we can run using the command with the -j flag so that it runs in the background.
On the Remote machine, we then use sc.exe as outlined above:
An important thing to notice about these different approaches is that they result in becoming different things. In the case of getting the Administrator password through TeamViewer, we actually have access to the Administrator account itself. The other approaches escalate us to the LocalSystem account which is a service user account who's account token includes the SIDs of NT AUTHORITY\SYSTEM and BUILTIN\Administrators. This account does not have a password and so, although more powerful in some ways than the Administrator account, presents different challenges when using it to establish persistence and other activities.
Another important consideration is that even though winPEAS suggested CVEs that might be exploitable for this version of the operating system, all of them come with certain conditions that need to be satisfied before they are able to be exploited. CVE-2019-1130 for example suggests using a proof of concept (https://github.com/S3cur3Th1sSh1t/SharpByeBear) that exploits a race condition. This vulnerability is a timing problem that necessitates multiple cores on the machine and access to user programs Edge or Cortana. We don't have access to these programs in this situation. Likewise, a Metasploit module that exploits CVE-2019-1405 (and CVE-2019-1322) has a Metasploit module that fails to work on this machine. So just because a machine is theoretically vulnerable to a CVE because it has the correct build number doesn't mean all conditions will be present to make it exploitable.
Last updated
Was this helpful?