Security Update: Authentication Bypass in MailboxImportServlet vulnerability
Re: Security Update: Authentication Bypass in MailboxImportServlet vulnerability
Hi,
the vulnerability was exploited from around mid-June.
In the meantime, Zimbra has received information about the vulnerability.
The vulnerability in this case concerns the Network Edition because it requires the mboximport module.
To check if your environment is under attack:
- check if there are any strange files in /opt/zimbra/ log, e.g. amd64 (bitcoin miner)
- check if jsp files in / opt / zimbra / jetty have been created in the last 90-120 days, e.g. test.jsp, aes.jsp, Json.jsp aes.jsp
- check the address https: //yourZimbraURL/crypt/aes.jsp <--- the attacker's webshell
- search in the access-log for requests "mboximport | python-requests" or "zmprov"
the vulnerability was exploited from around mid-June.
In the meantime, Zimbra has received information about the vulnerability.
The vulnerability in this case concerns the Network Edition because it requires the mboximport module.
To check if your environment is under attack:
- check if there are any strange files in /opt/zimbra/ log, e.g. amd64 (bitcoin miner)
- check if jsp files in / opt / zimbra / jetty have been created in the last 90-120 days, e.g. test.jsp, aes.jsp, Json.jsp aes.jsp
- check the address https: //yourZimbraURL/crypt/aes.jsp <--- the attacker's webshell
- search in the access-log for requests "mboximport | python-requests" or "zmprov"
-
- Ambassador
- Posts: 2767
- Joined: Mon Dec 16, 2013 11:35 am
- Location: France - Drôme
- ZCS/ZD Version: All of them
- Contact:
Re: Security Update: Authentication Bypass in MailboxImportServlet vulnerability
This (kind of code vulnerability being used) might soon become more and more an issue with Zimbra: https://twitter.com/securiteam_ssd/stat ... 4489655297
Re: Security Update: Authentication Bypass in MailboxImportServlet vulnerability
Zimbra OSE is not affected by this vulnerability?ohfwj wrote:Hi,
The vulnerability in this case concerns the Network Edition because it requires the mboximport module.
-
- Advanced member
- Posts: 173
- Joined: Sat Sep 13, 2014 12:54 am
- Location: Netherlands
- ZCS/ZD Version: Ubuntu 18.04, 8.8.15_P43
- Contact:
Re: Security Update: Authentication Bypass in MailboxImportServlet vulnerability
For those who want to take extra measures:
As a general security rule of thumb for an extra security measure, one should run web authentication proxies in front of web apps, in such a way that code of the hosted application is never touched by hackers. For instance, I have a secondary Apache server with this proxy configuration:
(The config is easily adapted to Nginx)
Edit: make this proxy NOT the default vhost, so that scans of the server IP won't show it. If bots then don't know the DNS name, it's not readily findable.
Then, on the Zimbra server, port 443 is only open to that proxy. This has these advantages:
As a general security rule of thumb for an extra security measure, one should run web authentication proxies in front of web apps, in such a way that code of the hosted application is never touched by hackers. For instance, I have a secondary Apache server with this proxy configuration:
Code: Select all
<VirtualHost *:80>
RewriteEngine on
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [L,R]
ServerName webmailproxy.example.net
</VirtualHost>
<VirtualHost *:443>
ServerName webmailproxy.example.net
ServerAdmin webmaster@localhost
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/webmailproxy.example.net/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/webmailproxy.example.net/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/webmailproxy.example.net/chain.pem
SSLProxyEngine On
ProxyPass / https://mail.example.net/
ProxyPassReverse / https://mail.example.net/
# Let's Encrypt
<Location /.well-known/>
Satisfy any
Require all granted
</Location>
# DAV bypass block (for calendar en contacts sync), which you may not need.
<Location /dav>
Satisfy any
Require all granted
</Location>
<Location /principals/>
Satisfy any
Require all granted
</Location>
<Location /SOGo/>
Satisfy any
Require all granted
</Location>
<Location /groupdav.php>
Satisfy any
Require all granted
</Location>
# END DAV block
<Location />
AuthType Basic
AuthName "Foobar"
AuthUserFile /etc/apache2/htpasswd/webmailproxy
Require valid-user
Require ip 1.2.3.4
</Location>
ErrorLog ${APACHE_LOG_DIR}/webmailproxy.example.net/error.log
CustomLog ${APACHE_LOG_DIR}/webmailproxy.example.net/access.log combined
</VirtualHost>
Edit: make this proxy NOT the default vhost, so that scans of the server IP won't show it. If bots then don't know the DNS name, it's not readily findable.
Then, on the Zimbra server, port 443 is only open to that proxy. This has these advantages:
- HTTP auth is used to control access, and if you don't have the password, you can't touch Zimbra (except in this case, the DAV URLs).
- You can run the webmail proxy invisibly: there is no trace of its hostname or IP address in mail you send. And if you make sure you can't do AXFR on your DNS, you won't guess you run your mail on 'ponyexpress.example.net'.
- Related to the above point: it won't show in search engines like Shodan, as connected to your Zimbra. If an exploit gets known, all private and public databases resulting from internet scans are accessed to see where they can find Zimbra installations. Your proxy won't be in it, because it doesn't look like Zimbra.
Last edited by halfgaar on Sat Aug 13, 2022 12:12 pm, edited 1 time in total.
Re: Security Update: Authentication Bypass in MailboxImportServlet vulnerability
GlooM wrote:Zimbra OSE is not affected by this vulnerability?ohfwj wrote:Hi,
The vulnerability in this case concerns the Network Edition because it requires the mboximport module.
I managed to recreate this attack on the NE environment, on the same FOSS version the attack does not work because FOSS does not have the zmmboximport module.
However, I recommend updating your FOSS to the latest versions.
Re: Security Update: Authentication Bypass in MailboxImportServlet vulnerability
Thanks a bunch for sharing the article. It looks like it confirms that p31 protected against the RCE portion of the exploit, which is good.andras0602 wrote:check this article https://www.volexity.com/blog/2022/08/1 ... 022-27925/khawkins wrote:Are there any known indicators of an attempted/successful/unsuccessful exploit of this that you can share? I'm now on p33, but I waited longer than was advisable... p32 left me gun-shy.
They even made a Yara rule to find potential webshells, huge thumbs up for them!
I see similar POST requests in my servers access.log
Unfortunately, my oldest logs are from 13/Jul/2022 and I already see this Vultr owned attacker IP 45.77.77.50 in all my servers. Here is an example:The paches have been built a few days later and became available more later on. IMHO it's time for me to put all this java-based thing behind a VPN/firewall/whatever.Code: Select all
access_log.2022-07-13:45.77.77.50 - - [13/Jul/2022:08:51:57 +0000] "POST /service/extension/backup/mboximport?account-name=admin&ow=1&no-switch=true HTTP/1.1" 401 657 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:101.0) Gecko/20100101 Firefox/101.0" 67 access_log.2022-07-13:45.77.77.50 - - [13/Jul/2022:08:53:32 +0000] "POST /service/extension/backup/mboximport?account-name=admin&ow=1&no-switch=true HTTP/1.1" 401 657 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:101.0) Gecko/20100101 Firefox/101.0" 7
-
- Posts: 20
- Joined: Sat Sep 13, 2014 2:16 am
Re: Security Update: Authentication Bypass in MailboxImportServlet vulnerability
That is interesting, as this was not mentioned in the article. So I before I read this, i went ahead earlier today to check one of my FOSS installations. It had these "mboximport" lines in the log file, so that had me worried a bit. I then installed a fresh Zimbra installation (same version) on a new server, dumped md5 hashes of all jsp files and compared those to the one on my live installation. They all matched, and there were no "rogue" jsp files present. I have no idea how to use the "yara rules" though.ohfwj wrote:GlooM wrote:Zimbra OSE is not affected by this vulnerability?ohfwj wrote:Hi,
The vulnerability in this case concerns the Network Edition because it requires the mboximport module.
I managed to recreate this attack on the NE environment, on the same FOSS version the attack does not work because FOSS does not have the zmmboximport module.
However, I recommend updating your FOSS to the latest versions.
I also still have an installation running on CentOS 6 (with iptables blocked web facing ui ports), and I wish (especially since 2022 has seen multiple severe zimbra exploits) there would be a patch for CentOS 6 as well. I know the OS is EOL, but imho software like zimbra could still be patched, especially in case of serious seciurity issues.
- cayaraa
- Outstanding Member
- Posts: 341
- Joined: Sat Sep 13, 2014 12:33 am
- ZCS/ZD Version: ZCS 8 NE & ZCS 8 FOSS
Re: Security Update: Authentication Bypass in MailboxImportServlet vulnerability
I put this in a different thread but wanted to put it over here as it was probably a better place for it.
I was trying to come up with temporary mitigation before patching. On a Zimbra 8 test system (not sure about 9 as we haven't gone there yet) I've edited the Nginx templates ( /opt/zimbra/conf/nginx/templates/ ) nginx.conf.web.https.default.template and nginx.conf.web.https.template and added in the following code:
Before putting the above in nginx a post with curl would give me a 401 auth error after touching the mailbox:
After the code I now get 403 forbidden and the mailbox doesn't appear to get touched:
Checking with curl:
I was trying to come up with temporary mitigation before patching. On a Zimbra 8 test system (not sure about 9 as we haven't gone there yet) I've edited the Nginx templates ( /opt/zimbra/conf/nginx/templates/ ) nginx.conf.web.https.default.template and nginx.conf.web.https.template and added in the following code:
Code: Select all
location ^~ /service/extension/backup/mboximport {
# Location block to mboximport
allow 127.0.0.1;
allow ::1;
deny all;
}
Code: Select all
<title>Error 401 no authtoken cookie</title>
Code: Select all
<head><title>403 Forbidden</title></head>
Code: Select all
$ curl -X POST --data-binary test.txt "https://zimbrasitename.com/service/extension/backup/mboximport?account-name=admin&account-status=active&ow=true&no-switch=true"
-
- Outstanding Member
- Posts: 263
- Joined: Thu May 12, 2016 1:56 pm
- Location: Belgium
- ZCS/ZD Version: 9.0.0
Re: Security Update: Authentication Bypass in MailboxImportServlet vulnerability
Yes, we did the same on 8.8.15 (we don't want to go to P33 yet because of this regression).
Code: Select all
# block MailboxImportServlet requests for CVE-2022-37042 exploit
location = /service/extension/backup/mboximport {
return 403;
}
Re: Security Update: Authentication Bypass in MailboxImportServlet vulnerability
sempiterna wrote:That is interesting, as this was not mentioned in the article. So I before I read this, i went ahead earlier today to check one of my FOSS installations. It had these "mboximport" lines in the log file, so that had me worried a bit. I then installed a fresh Zimbra installation (same version) on a new server, dumped md5 hashes of all jsp files and compared those to the one on my live installation. They all matched, and there were no "rogue" jsp files present. I have no idea how to use the "yara rules" though.ohfwj wrote:GlooM wrote:
Zimbra OSE is not affected by this vulnerability?
I managed to recreate this attack on the NE environment, on the same FOSS version the attack does not work because FOSS does not have the zmmboximport module.
However, I recommend updating your FOSS to the latest versions.
I also still have an installation running on CentOS 6 (with iptables blocked web facing ui ports), and I wish (especially since 2022 has seen multiple severe zimbra exploits) there would be a patch for CentOS 6 as well. I know the OS is EOL, but imho software like zimbra could still be patched, especially in case of serious seciurity issues.
Hi,
In the FOSS version, the response code for mboximport in the access-log is 404 e.g .:
Code: Select all
- - [16/lip/2022:02:54:34 +0000] "POST /service/extension/backup/mboximport HTTP/1.0" 404 267 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36" 17
- - [22/Jul/2022:13:27:54 +0000] "GET /service/extension/backup/mboximport?account-name=admin&account-status=maintenance&ow=true HTTP/1.0" 404 417 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.0 Safari/605.1.15" 3
In the NE version, the response code was 401 or 500, because the endpoint exists, the query, although it ended with an error, allowed any file to be placed on the server with Zimbra privileges.
Code: Select all
- - [20/Jun/2022:07:26:01 +0000] "POST /service/extension/backup/mboximport?account-name=admin&account-status=active&ow=1&switch-only=0&no-switch=1&append=1 HTTP/1.0" 401 299 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.0.0 Safari/537.36" 45
- - [20/Jun/2022:08:27:49 +0000] "GET /service/extension/backup/mboximport HTTP/1.0" 500 273 "-" "Mozilla/5.0 (Windows NT 6.0) AppleWebKit/535.0 (KHTML, like Gecko) Chrome/51.0.881.0 Safari/535.0" 1
In the vulnerable version of NE, it was enough to send a crafted zip archive via POST to the mboximport endpoint, without authentication !!!!
Zimbra in the first patch released a patch with the information that the attack required authentication, but it was not correct information, the attack did not require authorization.
If the moderator allows, I can describe step by step how to recreate this attack.