CyberLens
Can you exploit the CyberLens web server and discover the hidden flags? - by TeneBrae93 and tgreenMWR
Last updated
Can you exploit the CyberLens web server and discover the hidden flags? - by TeneBrae93 and tgreenMWR
Last updated
The following post by 0xb0b is licensed under CC BY 4.0
We start with a Nmap scan and find several open ports on the system, including common services such as Microsoft RPC (135/tcp), NetBIOS (139/tcp), Microsoft-DS (445/tcp), Remote Desktop Protocol (3389/tcp) and Windows Remote Management (5985/tcp and 47001/tcp). Additionally, several ports (49664/tcp to 49670/tcp and 49677/tcp) are open but have unknown services running on them, mostly associated with RPC. Furthermore, there is a web server running on port 80.
A subsequent default script and version scan gives us more details; not only do we have a web server running on port 80, but also on port 61777.
Let's take a look at the page on port 80 first. A one-pager page.
We have a contact form, but it was not vulnerable to XSS, tested by some payloads.
If we scroll further, we have a form for entering images in order to extract metadata about the image. The first thoughts here were a simple reverse shell upload, an exploit via ImageMagick, and a reverse shell via the metadata, created using exiftool. But none of this was successful.
Looking at the source, we find the end point at 61777. We may be able to make progress here. But let's take another look via Burp.
The 61777 endpoint is responsible for metadata extraction.
When visiting the index page of the endpoint, we have a direct hit that we can check for possible vulnerabilities. We are dealing with Apache Tika 1.17.
This machine is vulnerable to CVE-2018-1335.
After a short search using Searchsploit, we find two POCs that implement a command injection and match our version. We look at the first hit and see that it is a metasploit module. Let's continue with this for now.
We are looking for Tika and the module we found earlier is available in our installation. We use it and look at which options we have to set.
We set the options LHOST, RHOST and RPORT.
Next, we run the exploit and get a reverse shell as cyberlens.
On the user's desktop, we find user flag.
Using tree /f, we enumerate the user's file system and find their credentials under C:\Users\CyblerLens.
CVE-2018-1335 is a remote code execution vulnerability in Apache Tika. It allows an attacker to execute arbitrary code on the server by sending a specially crafted HTTP request. This exploit leverages the way Tika handles OCR (Optical Character Recognition) processing, where it can be tricked into executing malicious scripts.
A detailed explaination of this vulnerabilty can be found at the following resource (do not miss out on that):
Like the blog entry, the script comes from Rhino Security Labs and allows us to execute commands on the system.
We use revshells.com to create a PowerShelle reverse shell.
And set up a listener on 445. Execute it using the script...
... we get a connection back as cyberlens.
We can also do it manually...
The exploit can be triggered by the request below. With that, we can pop a calc.exe. But that's all we can do here, since we cannot pass multiple commands or arguments with this. The command is being passed to Java ProcessBuilder as an array and all we can do is to pass the command as a single string.
Since we want to spawn a reverse shell, which requires more than one parameter, we need a workaround discussed in the blog and used in the script.
To pass multiple arguments in the command line exploited by Tika-server, the X-Tika-OCRTesseractPath header is set to "cscript.exe" and X-Tika-OCRLanguage is set to //E:Jscript, allowing the first argument (a temp file containing the script) to be executed by cscript.exe with the specified script engine. The "image" file uploaded contains Jscript or VBS code, which is then processed by Tika-server, enabling full script execution.
With the following cURL request we are able to pop a reverse shell.
To enumerate windows host scripts like winpeas, powerup or privesccheck can be used.
Furthermore, we can check if any protection, like antivirus or Windows Defender, is up and running. Using Get-MpComputerStatus, we can see neither of the protection mechanisms is enabled or running. So we are free to use any scripts and malicious payloads, like msfvenom. There is no hustle to bypass anything.
With a quick run of PrivescCheck.ps1 ...
... we see that AlwaysInstallElevated might be enabled. If AlwaysInstallElevated is enabled on a target, it allows us to exploit it by crafting our own malicious MSI file that gets executed in the context of the local SYSTEM account.
Once created, we can download and execute the malicious file on the victim as ANY user, and it will run under the context of the local SYSTEM account. This means that by placing malicious shell code in an MSI file, we are able to obtain a reverse shell as SYSTEM.
A detailed walkthrough on how to detect and exploit this misconfiguration can be looked up here:
We can check the registry entries regarding AlwaysInstallElevated and see that this is indeed allowed.
We craft a simple Windows reverse shell via msfvenom in the file format of an MSI.
Next, we set up a listener, and after executing the MSI...
... we receive a connection as nt authority\system and find the root flag at
C:\Users\Administrator\Desktop\admin.txt.
Don't miss out on gravereaper2038s writeup, where he makes use of CVE-2021-40449 to gain elevated privileges in the last section of his writeup:
