[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Zimbra zero-day exploit



Hi,

See Quanahs answer (#4) here: http://www.zimbra.com/forums/administrators/67005-zimbra-0-day.html


M Morén


----- Ursprungligt meddelande -----
> I did some more checking - I have access to a server running 8.0.4 and one
> running 8.0.1. The one running 8.0.1 is vulnerable, while 8.0.4 is not. I
> don't know what version it was fixed it, but presumably it was a Jetty
> upgrade that fixed it (by rejecting any URLs with embedded null chars)
> 
> ----- Original Message -----
> > 
> > Steve,
> > 
> > Shouldn't 7071 only open to some internal network/bastion host? The
> > quick fix probably is to tighten up the port 7071 access.
> > 
> > I also tried to run the code on a system that has access to a test
> > ZCS 8.0.5 server's port 7071.
> > 
> > ruby run.rb -t testserver  -u someuser -p Test123_23
> > 
> > #########################################################################################
> > Zimbra Email Collaboration Server 0day Exploit by rubina119
> > #########################################################################################
> > 
> > 
> > [+] Looking if host is vuln...
> > 
> > 
> > The test server's log shows:
> > 
> > 013-12-08 14:21:04,832 INFO
> >  [qtp1649104388-754965:https://127.0.0.1:7071/service/admin/soap/GetDomainInfoRequest]
> > [ip=127.0.0.1;ua=ZCS/8.0.5_GA_5839;] soap - GetDomainInfoRequest
> > elapsed=2
> > 2013-12-08 14:21:04,836 WARN
> >  [qtp1649104388-754964:https://171.67.219.153:7071/res/I18nMsg,AjxMsg,ZMsg,ZmMsg,AjxKeys,ZmKeys,ZdMsg,Ajx%20TemplateMsg.js.zgz?v=091214175450&skin=../../../../../../../../../opt/zimbra/conf/localconfig.xml%00]
> > [] misc - Rejecting request containing null character in query
> > string
> > 
> > 
> > So the request was rejected. What version of ZCS are affected by
> > this?
> > 
> > Xueshan
> > 
> > ----- Original Message -----
> > > Hi folks,
> > > A zero day exploit for Zimbra was released on Friday. I found out
> > > about it
> > > late last night and spent the night trying to come up with a
> > > temporary
> > > workaround. The details of the exploit are here:
> > > http://www.exploit-db.com/exploits/30085/ . Basically anyone,
> > > through a
> > > simple URL, can gain access to your site's localconfig.xml file
> > > which has
> > > all your Zimbra system passwords. From there they can create an
> > > admin-level
> > > account and, if port 7071 is exposed, login to the admin console.
> > > 
> > > 
> > > My workaround involves adding a rewrite rule to nginx to look for
> > > localconfig
> > > being passed in as an argument and block it. To implement, in
> > > /opt/zimbra/conf/nginx/templates, edit
> > > nginx.conf.web.http.default.template
> > > and nginx.conf.web.https.default.template and insert this inside
> > > the
> > > 'location' block before the 'include' statement:
> > > 
> > > 
> > > 
> > > if ($args ~ skin=.*localconfig) {
> > > rewrite ^/.* / redirect;
> > > }
> > > 
> > > 
> > > This is a brute force rewrite and will actually create a redirect
> > > loop
> > > because it doesn't actually replace the args upon doing the
> > > redirect, so the
> > > URL will still match. If you're more well versed in nginx config
> > > than I am,
> > > feel free to refine it.
> > > 
> > > 
> > > Unfortunately this workaround won't work for a single-server
> > > install that's
> > > not using the zimbra-proxy package. I've been messing around trying
> > > to add a
> > > rewrite rule to jetty.xml.in but that doesn't appear to work as the
> > > rewrite
> > > rule can't see the arguments - only the URL after the arguments
> > > have been
> > > stripped off. My only other alternative is to install and configure
> > > the
> > > proxy package on the existing server (which involves messing with
> > > SSL certs
> > > and such)
> > > 
> > > 
> > > I will keep playing, but if anyone has any suggestions for
> > > non-proxy Zimbra
> > > installs, I'd love to hear them.
> > > 
> > > --
> > > 
> > > Steve Hillman IT Architect
> > > hillman@sfu.ca Institutional, Collaborative, & Academic
> > > Technologies (ICAT)
> > > 778-782-3960 Simon Fraser University
> > > 
> > > 
> > 
> > --
> > 
> > Xueshan Feng <sfeng@stanford.edu>
> > Technical Lead, IT Services, Stanford University
> > 
> > 
> > 
> 
> --
> Steve Hillman        IT Architect
> hillman@sfu.ca       Institutional, Collaborative, & Academic Technologies
> (ICAT)
> 778-782-3960         Simon Fraser University
> 
> 

-- 
Magnus Morén________________________________________________
IT-avdelningen, Högskolan i Halmstad,Box 823,301 18 HALMSTAD
tel: 035-167383, mob: 070-2880544, epost: magnus.moren@hh.se