Security Update: Authentication Bypass in MailboxImportServlet vulnerability

Discuss your pilot or production implementation with other Zimbra admins or our engineers.
User avatar
andras0602
Advanced member
Advanced member
Posts: 62
Joined: Sat May 21, 2022 3:11 pm
ZCS/ZD Version: 8.8.15

Re: Security Update: Authentication Bypass in MailboxImportServlet vulnerability

Post by andras0602 »

ghen wrote:One should wonder why most of the /opt/zimbra tree is owned - and thus writable - by the zimbra user by default.

If /opt/zimbra/jetty/webapps/zimbra/public (and the files in it) were owned by root, the impact of this exploit would have been much less, as an attacker then couldn't write any files that he can execute remotely.

As a best practice, only logs, databases, and other runtime data (like jetty workdir) should be owned by the service user, and everything else, in particular executables, owned by root.

Can Zimbra please reconsider this?
I don't know Geert... Ofc you are right, but it seems like the root owned files for an attacker shouldn't be a huge obstacle either because how Zimbra works: https://packetstormsecurity.com/files/1 ... ation.html
IMHO mandatory access control (like SELinux) could be one solution.
Ephemeral containers could be an another. And I know, containers are not sandboxes but 1 container / 1 component could prevent these things like a crafted zip/rar archive to write anywhere.
But let's say I implement any or both of these. None of them supported (what I pay for btw) so how should I ask for help when Zimbra has some bugs, like now it has...
So instead I'm firewalling the whole thing like hell now and after a clean reinstall I'll put a certificate based authentication or sg. similar before it. It will "hurt" in the beginning for the users but the only other option I see is... forget about Zimbra completely -> They should reconsider this too. :oops:
rainer_d
Advanced member
Advanced member
Posts: 86
Joined: Fri Sep 12, 2014 11:40 pm

Re: Security Update: Authentication Bypass in MailboxImportServlet vulnerability

Post by rainer_d »

IIRC, Zimbra-Cloud is indeed container-based.

That version was never released to the public.
User avatar
JDunphy
Outstanding Member
Outstanding Member
Posts: 889
Joined: Fri Sep 12, 2014 11:18 pm
Location: Victoria, BC
ZCS/ZD Version: 9.0.0_P39 NETWORK Edition

Re: Security Update: Authentication Bypass in MailboxImportServlet vulnerability

Post by JDunphy »

andras0602 wrote:
ghen wrote:One should wonder why most of the /opt/zimbra tree is owned - and thus writable - by the zimbra user by default.

If /opt/zimbra/jetty/webapps/zimbra/public (and the files in it) were owned by root, the impact of this exploit would have been much less, as an attacker then couldn't write any files that he can execute remotely.

As a best practice, only logs, databases, and other runtime data (like jetty workdir) should be owned by the service user, and everything else, in particular executables, owned by root.

Can Zimbra please reconsider this?
I don't know Geert... Ofc you are right, but it seems like the root owned files for an attacker shouldn't be a huge obstacle either because how Zimbra works: https://packetstormsecurity.com/files/1 ... ation.html
IMHO mandatory access control (like SELinux) could be one solution.
Ephemeral containers could be an another. And I know, containers are not sandboxes but 1 container / 1 component could prevent these things like a crafted zip/rar archive to write anywhere.
But let's say I implement any or both of these. None of them supported (what I pay for btw) so how should I ask for help when Zimbra has some bugs, like now it has...
So instead I'm firewalling the whole thing like hell now and after a clean reinstall I'll put a certificate based authentication or sg. similar before it. It will "hurt" in the beginning for the users but the only other option I see is... forget about Zimbra completely -> They should reconsider this too. :oops:
+1 for both of these comments.

I need to move to zero trust with zimbra. Isolate all services and only allow access from known ip addresses to mitigate some of these attack vectors. Thinking about trying something like this https://www.cloudflare.com/plans/zero-t ... /#overview which is free for less than 50 users. I do something for my own server with some wireguard access points for my family that I manage so only a handful of /32's have access to zimbra services on that server.

BTW, running a tripwire is no fun with zimbra. Watch a admin login or even some normal stuff just once and observe the files created/changed/etc.

Jim
small
Posts: 1
Joined: Sun Aug 14, 2022 8:54 pm

Re: Security Update: Authentication Bypass in MailboxImportServlet vulnerability

Post by small »

sadly i'm lost at how to clean mine up. i definitely was compromised, disappointed in zimbra's support.
BradC
Outstanding Member
Outstanding Member
Posts: 265
Joined: Tue May 03, 2016 1:39 am

Re: Security Update: Authentication Bypass in MailboxImportServlet vulnerability

Post by BradC »

halfgaar wrote:I don't have the network edition, so for me that would only be DAV. But, for any protocol over HTTP, the hope is those URLs are distinguisable and you can allow bypasses for them, as I showed for the DAV URLs. Of course, if there are security exploits in a DAV or other endpoints that go over HTTP, you're not as protected, but then you can still rely on the obscurity part of it: as I said, there is no trace externally visible that you're using a proxy.

You could even set up a proxy mywebmail.ponyexpress.com without a password, and make that the only source that is allowed to access the HTTPS port on your Zimbra server. Then, when you make the proxy NOT the default vhost on your webserver, scans of the IP won't show it, and you can only access it if you know the domain name. If you don't advertise that anywhere, bots won't readily find it.
As a quick viability test I spooled up a test server and put a basic SSL Apache2 reverse proxy in front of it with everything open, but not the default vhost. Everything seems to work excepting that which relies on websockets. That seems to be the ZeXtras stuff (Drive, Connect & Docs). I don't have the time or inclination to try and figure that out right now, but at least the basics work and blocking specific elements becomes easier.

Edit :

Code: Select all

	
	AllowEncodedSlashes On
	RewriteEngine	On
	RewriteCond %{HTTP:Upgrade} =websocket [NC]
	RewriteRule /(.*)	wss://myserverurl.com:443/$1 [P,L]
AllowEncodedSlashes is required because Drive encodes slashes in the URL and Apache 404s those by default.
The rewrite allows Drive websockets to work. I don't pretend to understand it, I just found it somewhere and modified it to work.
I'm not setting up Connect or Docs on a test system to see if they work also.
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 »

I was going to comment on your websocket problem, but I see you fixed it.

Websockets are designed to be proxyable. I do it all the time, but then with Nginx. Perhaps I should also supply a working Nginx config. Generally, I prefer Nginx for this kind of task.

Don't forget to close the original 443 and 7071 (admin port) in the Firewall.
BradC
Outstanding Member
Outstanding Member
Posts: 265
Joined: Tue May 03, 2016 1:39 am

Re: Security Update: Authentication Bypass in MailboxImportServlet vulnerability

Post by BradC »

halfgaar wrote:I was going to comment on your websocket problem, but I see you fixed it.

Websockets are designed to be proxyable. I do it all the time, but then with Nginx. Perhaps I should also supply a working Nginx config. Generally, I prefer Nginx for this kind of task.

Don't forget to close the original 443 and 7071 (admin port) in the Firewall.
Does anyone expose 7071? I'd have thought that was "a bit nuts".

I'm not familiar enough with either Apache or Nginx to put it together reliably, but I believe Nginx can also proxy IMAP which would be handy.
I just wanted to spin up a quick test to see if it was viable and learn a bit in the process based on your example. Thanks!

Edit : Well, it was a heck of a lot easier to spool up Nginx to do the same thing. The problem with trying to proxy IMAP is the authentication, and that looks like it hasn't documented sucessfully. A few links to threads that always seemed to result in nobody getting it working.

I might have a poke at it when I get some time. The built in Zimbra Nginx does it, so surely an external instance can do it.
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 »

Does Zimbra's built-in Nginx do so called 'streams' for IMAP? That would be the only way to proxy that, because it's not HTTP based. But the advantages kind of disappear.

TCP streams are for SSL termination, load balancing, etc. Because it's not HTTP, you can't add a layer of password on it, and people scanning the proxy's IP from the outside, will still see it's Zimbra.
BradC
Outstanding Member
Outstanding Member
Posts: 265
Joined: Tue May 03, 2016 1:39 am

Re: Security Update: Authentication Bypass in MailboxImportServlet vulnerability

Post by BradC »

JDunphy wrote:Guess I need to look into why ZmSettings.js was interesting to this attacker.
I had a play with that using the default ssl proxy as a honeypot. In several instances here it queried ZmSettings.js and if it got a 404, just moved on. When I put a copy of a modified ZmSettings.js in the appropriate place then the attack proceeded to query the list of urls. So seems like a bit of a "zimbra liveness detector".
User avatar
JDunphy
Outstanding Member
Outstanding Member
Posts: 889
Joined: Fri Sep 12, 2014 11:18 pm
Location: Victoria, BC
ZCS/ZD Version: 9.0.0_P39 NETWORK Edition

Re: Security Update: Authentication Bypass in MailboxImportServlet vulnerability

Post by JDunphy »

BradC wrote:
JDunphy wrote:Guess I need to look into why ZmSettings.js was interesting to this attacker.
I had a play with that using the default ssl proxy as a honeypot. In several instances here it queried ZmSettings.js and if it got a 404, just moved on. When I put a copy of a modified ZmSettings.js in the appropriate place then the attack proceeded to query the list of urls. So seems like a bit of a "zimbra liveness detector".
Hi Brad,

Interesting discovery.

It also looks like zimbra will tell a lot about the release and level we are running from this file. I pulled the file with curl today and this is what I saw. If I am not mistaken, that identifies sites running P33 if we extrapolate the date. I am guessing, they know exactly who to attack based on the version since Zimbra is so kind to tell them. ;-) ;-) ;-)

Code: Select all


    // next 3 are replaced during deployment
        this.registerSetting("CLIENT_DATETIME",                                 {type:ZmSetting.T_CONFIG, defaultValue:"20220726-0911"});
        this.registerSetting("CLIENT_RELEASE",                                  {type:ZmSetting.T_CONFIG, defaultValue:"20220726082327"});
        this.registerSetting("CLIENT_VERSION",                                  {type:ZmSetting.T_CONFIG, defaultValue:"8.8.15_GA_4372"});
Wonder how long this has been going on?

Jim
Post Reply