Security Update: Authentication Bypass in MailboxImportServlet vulnerability

Discuss your pilot or production implementation with other Zimbra admins or our engineers.
ohfwj
Posts: 3
Joined: Thu Aug 11, 2022 11:40 am

Re: Security Update: Authentication Bypass in MailboxImportServlet vulnerability

Post by ohfwj »

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"
Klug
Ambassador
Ambassador
Posts: 2747
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

Post by Klug »

This (kind of code vulnerability being used) might soon become more and more an issue with Zimbra: https://twitter.com/securiteam_ssd/stat ... 4489655297
GlooM
Advanced member
Advanced member
Posts: 127
Joined: Sat Sep 13, 2014 12:50 am

Re: Security Update: Authentication Bypass in MailboxImportServlet vulnerability

Post by GlooM »

ohfwj wrote:Hi,
The vulnerability in this case concerns the Network Edition because it requires the mboximport module.
Zimbra OSE is not affected by this vulnerability?
halfgaar
Advanced member
Advanced member
Posts: 171
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

Post by halfgaar »

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:

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>
(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:
  • 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.
This also protects/protected against the previous severe vulnerability, of unsafe XML serialization through the admin panel.
Last edited by halfgaar on Sat Aug 13, 2022 12:12 pm, edited 1 time in total.
ohfwj
Posts: 3
Joined: Thu Aug 11, 2022 11:40 am

Re: Security Update: Authentication Bypass in MailboxImportServlet vulnerability

Post by ohfwj »

GlooM wrote:
ohfwj wrote:Hi,
The vulnerability in this case concerns the Network Edition because it requires the mboximport module.
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.
khawkins
Posts: 12
Joined: Sat Dec 11, 2021 12:25 am
ZCS/ZD Version: 8.8.15

Re: Security Update: Authentication Bypass in MailboxImportServlet vulnerability

Post by khawkins »

andras0602 wrote:
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.
check this article https://www.volexity.com/blog/2022/08/1 ... 022-27925/
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 :shock:
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:

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
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.
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.
sempiterna
Posts: 20
Joined: Sat Sep 13, 2014 2:16 am

Re: Security Update: Authentication Bypass in MailboxImportServlet vulnerability

Post by sempiterna »

ohfwj wrote:
GlooM wrote:
ohfwj wrote:Hi,
The vulnerability in this case concerns the Network Edition because it requires the mboximport module.
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.
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.

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.
User avatar
cayaraa
Outstanding Member
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

Post by cayaraa »

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:

Code: Select all

    location ^~ /service/extension/backup/mboximport {
        # Location block to mboximport
       
        allow 127.0.0.1;
        allow ::1;
        deny all;
    }
Before putting the above in nginx a post with curl would give me a 401 auth error after touching the mailbox:

Code: Select all

<title>Error 401 no authtoken cookie</title>
After the code I now get 403 forbidden and the mailbox doesn't appear to get touched:

Code: Select all

<head><title>403 Forbidden</title></head>
Checking with curl:

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"
ghen
Outstanding Member
Outstanding Member
Posts: 258
Joined: Thu May 12, 2016 1:56 pm
Location: Belgium
ZCS/ZD Version: 9.0.0

Re: Security Update: Authentication Bypass in MailboxImportServlet vulnerability

Post by ghen »

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;
 	     }
 
ohfwj
Posts: 3
Joined: Thu Aug 11, 2022 11:40 am

Re: Security Update: Authentication Bypass in MailboxImportServlet vulnerability

Post by ohfwj »

sempiterna wrote:
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.
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.

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
 
The error code is 404 as there is no mboximport module in the FOSS version.

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
We analyzed the attack and on many FOSS environments we were unable to reproduce it.
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.
Post Reply