HTB Walkthrough within, ctrl+F for “Root Flag” to quick search
Findings/Recommendations at bottom
Key Takeaways
In this assessment, the team was able to gain an initial point of entry from an admin account to a particular service having credentials left set to default (admin:admin) (See Ref 1.2).
Another major finding was the software version of said service being vulnerable to a simple and well-known attack that has since been patched by the vendor, though left out-of-date on the infrastructure. This lack of staying up to date allowed for more privileges and movement within the system (See Ref 1.3).
Finally, a lack of proper configuration of user accounts allowed the assessing team to modify a task that was running in order to grant themselves access to essentially perform whatever task they wanted (See Ref 1.4).
Objectives
Obtain the user flag by gaining any kind of remote access to the target machine/environment and extract the “user flag” string of characters, then escalate privileges, often to the “root” user or system owner to then get the “root flag,” typically only accessible by this user.
Attack Path
Enumeration
To begin, we ran an nmap scan on this box, as we typically do. This shows us what ports and services are available and running on this target machine.
nmap -sV -sC -p- 10000 10.129.235.188
This output gave us some interesting clues about the target machine. The most interesting perhaps, was the port 8031 service — ManageEngine Desktop Central DesktopCentralServer.
“ManageEngine Desktop Central is a Unified Endpoint Management solution that helps in managing servers, desktops, laptops and mobile devices from a single console1. It has different editions with different features, such as the UEM edition that supports both legacy and modern management for Windows and macOS1. To configure ManageEngine Desktop Central, you must download the metadata file from the Certificate Management page in the AuthPoint management UI2.[1]”
[1] https://www.watchguard.com/help/docs/help-center/en-us/Content/Integration-Guides/AuthPoint/ManageEngine-Desktop-Central-saml_authpoint.html?TocPath=Integration-Guides%7CAuthPoint%7C_____99
With this in mind, we began to see what other possible points of discovery we could look into. The first of which was the port 8022 http service, which we navigated to in our browser.
Port 8022 Enumeration — ManageEngine
This led us to a login page for the service we discovered earlier.
Immediately, we tried logging in with some default credentials, which we found from https://cirt.net/passwords.
The first combination we tried was admin:admin.
This was successful, and we had logged in as administrator.
From here, we had much enumeration and poking around to do to find our next steps.
Luckily, there was an admin tab we could start at to see any weaknesses.
After a good bit of poking around, we realized we missed an important step — to take note of the version of software and to look online for vulnerabilities with the version.
We had found good news, there was a CVE[1] published affecting this version with a severity score of 9.8.
[1] https://nvd.nist.gov/vuln/detail/CVE-2020-10189
CVE-2020–10189
To use this exploit, we had to learn more about what it was. “Zoho ManageEngine Desktop Central before 10.0.474 allows remote code execution because of deserialization of untrusted data in getChartImage in the FileStorage class. This is related to the CewolfServlet and MDMLogUploaderServlet servlets.” (See reference 4 for citation). If we could exploit this, we could be granted RCE, allowing us to poke around even more.
We had found another page detailing how to exploit this[1], and there was a Metasploit module for it as well, which we could use to perform this exploit more efficiently.
[1] https://packetstormsecurity.com/files/156730/ManageEngine-Desktop-Central-Java-Deserialization.html
It appears as though the user-input validation is not properly built, and user inputted items are not properly sanitized, allowing users to upload files other than images (like scripts) to the ChartImage locations, which can then likely be ran.
“The specific flaw exists within the FileStorage class. The issue results from the lack of proper validation of user-supplied data, which can result in deserialization of untrusted data. An attacker can leverage this vulnerability to execute code under the context of SYSTEM.[1]”
[1] https://srcincite.io/advisories/src-2020-0011/
Using Metasploit
With Metasploit fired up, we could search for this CVE to make it easier to find.
From here, we had to set a few basic options and parameters, including the RHOST, LHOST, LPORT, TARGET URI, and a couple others before hitting run.
After entering these items, all we had to do was run the exploit and then launch a shell from our meterpreter.
We now had a shell as user “manageengine”
Shell as manageengine
Before anything we made sure to grab the user flag on user manageengine’s desktop.
User Flag: 82a569c7562ca195701c85f48483b41d
Now, we needed to see what this user could do, that way we could find our best path to escalate privileges.
We could impersonate a client after authentication, which is good to know, but we needed to see what other vulnerabilities were present on the machine, so we brought in a copy of winPEAS to run.
WinPEAS
We hosted an http server on our local machine in the directory holding winPEAS, and then grabbed it on our target machine.
We then ran winPEAS, and discovered a few things to note:
Above confirmed what we already knew, but Winpeas also found something interest, a potential CVE we could exploit.
We also had to see what was currently running with tasklist /svc.
This output a long list, but of interest was the windscribeservice.exe we found. This is not a windows native application, and can possibly be exploited, dependent on the version of it. To find this, we first needed to find the location:
We then navigated to this directory to see if we could find anything:
Not having much luck with a few different PowerShell commands, we checked what versions are vulnerable, if any. Since we did not have a Windows VM properly set up to export this exe file to and simply check it there, we used some guesswork to determine.
Fortunately, there were only 3 different exploits, 2 of which are for the same version, though not verified. The bottom one is for a privilege escalation, which was our goal, so we be began performing that exploit.
Windscribe — WindscribeService Named Pipe Privilege Escalation (Metasploit)
Fortunately for us, there was a exploit-db module made for this[1]. Even more fortunate, was the fact that there was a Metasploit module for this as well. This exploit was also a CVE[2].
[1] https://www.exploit-db.com/exploits/48021
[2] https://nvd.nist.gov/vuln/detail/CVE-2018-11479
After trying this strategy, we were unable to start a session.
This was very frustrating, as we now had to find a workaround.
Exploiting Weak Service Permissions
Since we couldn’t use msfconsole to do this for us, we had to do it manually.
We had to backtrack a bit, going back to where we first got a foothold, since we first did it with Metasploit. We downloaded this exploit (https://www.exploit-db.com/exploits/48176) and then grabbed a copy of GreatSCT, a tool used to create payloads that won’t be seen as malicious.
We then ran the following command to do this, after setting GreatSCT up:
We then had to copy the DLL payload to a directory where we could stand up an http server to host files from:
From here, we entered the following command to execute a command to our http server that would launch a shell on our meterpreter, bypassing the Windows Defender:
We were back in with access as manageengine.
From here, we had to change the path of the binary used in WindscribeService to something we had put on the machine, like our wolf.dll file.
We also had to find the PID of Winlogon, the binary we would be modifying to:
Taking note of the 548, we could back out.
Since restarting the WindscribeService had launched a new session in our meterpreter, we could change sessions to that session, then migrating to the PID 548 that we took note of:
We now were in with a shell as system authority. From here, we could go to the admin desktop and grab the flag.
Root flag: 9c6ab3eb0e22d73722a9b6e914497b0c
Note from Professional:
Basically, the WindScribe Service can be rewritten and point to the wolf.dll file that was used for the initial foothold. And since services have to be ran with admin privileges usually, simply stopping the service, pointing the service to the dll, and restarting the service should trigger the dll and reverse shell as root back to the kali box.
The trick is timing. When the service is started in the foothold session, it will launch a meterpreter session back to the kali box. You need to background the foothold session and get into the root shell meterpreter session within 30 seconds and migrate to a new process. At 30 seconds, the service fails to start by design of the Windows services process (since we are pointing now to a dll file instead of an exe file) and the shell closes…..unless you have migrated to a process to maintain the connection such as winlogon.
Make sure you are starting the listener with the wolf.rc file as created by GreatSCT.
Keywords
Ethical hacking case study, Penetration testing findings, HTB box analysis, Vulnerability assessment report, HTB answers, Cybersecurity testing insights, Hack The Box report, Penetration tester’s analysis, HTB challenge resolution, Ethical hacking techniques, Security assessment report, Hacker’s perspective on HTB, Network penetration testing, Exploitation and remediation, Hack The Box success story, Ethical hacking best practices, Vulnerability identification, Real-world hacking scenario, Penetration testing case study, Practical hacking lessons, htb wolf
