Zimbra Desktop Vulnerable to Man-in-the-Middle Attack

tiffanydanica writes "For all the flack Mozilla gets about its new security warnings for https sites, at least it warns the user when a mismatch occurs. Sadly the new Yahoo! Zimbra Desktop (released in part to fix some security issues), doesn't bother validating the SSL certificate on the other side before sending along the username and password, making it vulnerable to a man-in-the-middle attack. This is certainly a step up from transmitting the information in the clear, since the attacker must switch from being passive to active, but with all of the DNS security problems, it would be fairly trivial for a malicious attacker to grab a large number of Yahoo! accounts (be it for phishing or spaming). Hopefully this issue will get fixed shortly, but for now Yahoo! Zimbra Desktop users may wish to use the webmail interface."

Comments

Phorm reads your Email?

[corsec67]

Since BT is giving Phorm a MitM position in their network, does this mean that Phorm would be able to read the email of anyone that uses Yahoo Zimbra, even if they try to use https?

Re:Phorm reads your Email?

[Sorthum]

The first post is redundant? Odd.

Anyhoo, no-- Phorm couldn't read it unless they're attempting to MITM SSL by default-- which would get the living crap sued out of them by just about everbody...

Re:Phorm reads your Email?

[Tubal-Cain]

You must be very new here.

Re:Phorm reads your Email?

[ReedYoung]

The first post is redundant? Odd.

Not even. Pardon me. What I meant to say is that it might seem weird to judge the first post "redundant" until you consider the definition of a nerd to be one who "has nothing better to do" than do whatever we do, right. Assuming that standard of attention to detail is prevalent here, a first post can truly be redundant if it's been said before about the same subject. This is most commonly used for disinformation that's been debunked, especially debunked prominently on /. A re-run of MythBusters can be fun, so I wouldn't use a derogatory term like "redundant." But if they start to routinely re-tread myths they've already covered, without a good explanation of what they thought they might have missed the first time, and if what they missed the first time didn't really call their first verdict into question, then I would use the pejorative "redundant." So when /.ers come back with statements that have already been disproved they do get modded "redundant." I'm not sure without checking what the regs say about that, but it does happen.

To avoid inadvertent offense, I don't know that any of that is true of the FP. If that question has even been discussed on /. I don't recall it. To explain how a first post can be redundant, I chose an extreme case, which oh, by the way, is also hypothetical.

This is certainly a step up from transmitting the information in the clear, since the attacker must switch from being passive to active, but with all of the DNS security problems, it would be fairly trivial for a malicious attacker to grab a large number of Yahoo! accounts (be it for phishing or spaming[sic]).

Then again, maybe that "redundant" mod was intended for the summary, by a moderator with low aim.

Spaming is fun.

[_Shorty-dammit]

And also cool.

Re:Spaming is fun.

[HTH NE1]

SPAME: Single Product Arcade Machine Emulator

A MAME cabinet set up to play only one game. SPAME cabinets are slowly replacing true original classic arcade games as the original systems fall into disrepair. Of increasing concern of buyers of classic intact games on on-line auction sites.

Re:man in the middle

[Sorthum]

There's always DNS cache poisoning...

flamebait?

[RiotingPacifist]

i noticed the flamebait tag? i dont quite get it though, sure its a Hard attack to pull off but given yahoo have ~1/3 of all webmail clients i think people would be up for giving it a try

Re:man in the middle

[calmofthestorm]

Or captive networks. There is a guy at your college/company that controls your DNS, unless you explicitly set an external DNS.

This doesn't mean that anyone can trivially get into your mail, but it does man that more people than should can, and furthermore that this is trivial to prevent.

Re:man in the middle

[MichaelSmith]

I am pretty sure my workplace is trying to pull this off but it includes providing their own versions of certificate providers certs by controlling the client binaries.

Re:man in the middle

[aussie_a]

So a man in the middle would decompile the program, change the address it goes to, then recompile it, and that's going to be stopped if it used HTTPS?

I do realise man-in-the-middle attacks are possible. But what you described certainly isn't one.

Re:man in the middle

[x_MeRLiN_x]

As aussie_a said, what you describe is in no way similar to a man-in-the-middle attack. 'MITM' refers to be the ability to eavesdrop on and forge network traffic. Fake login pages is part of 'phishing'.

http://en.wikipedia.org/wiki/Man-in-the-middle_attack
http://en.wikipedia.org/wiki/Phishing

Re:man in the middle

[wirelessbuzzers]

How do you just jump in the middle of someone's connection?

There are a number of ways to do it. You can:

• Be the victim's ISP.
• Run an open wireless AP.
• Break WEP or WPA (there's a known flaw in that too, now, at least if you use RC4).
• Hack or spoof the victim's router.
• Mess with the victim's DHCP.
• Spoof mobile IPv6.
• Several other attacks on a hub network.
• ARP spoofing.
• BGP spoofing.
• Poison DNS caches.
• Exploit the Kaminski flaw.

There are probably a few other ways to do it, but that's all off the top of my head.

Responsible disclosure?

[Cow Jones]

First of all, I don't see any reason why this would be on the Slashdot front page. Many vulnerabilities like this one are discovered every day, and many are more critical and interesting, and concern products that are more widely used than Zimbra. Just take a look at Bugtraq to see a few samples.

More importantly, we shouldn't promote any random blogger who posts about security vulnerabilities to get t-shirts from Yahoo:

For anyone from Yahoo! reading this, I'm still waiting for the shirt I was promised from the first time I reported a vulnerability, but its all good :)

There's such a thing as responsible disclosure, and that's not blogging happily about everything you find, on a Friday no less, and then mentioning in passing that "At the time of the writing Yahoo! security has been notified." You have to give the vendor at least a chance to get the bug fixed.

CJ

Re:Responsible disclosure?

[Anonymous Coward]

You have to give the vendor at least a chance to get the bug fixed.

No, you don't. For all we know, some black-hat hacker may have already found this vulnerability and be actively exploiting it. Now that he's given a heads-up to everyone, people can use the workaround he suggested - access Yahoo mail through the webmail interface rather than the proprietary binary.

I accept that it would be nice if he'd informed the vendor first & given them a week to get a patch out, but researchers are not obliged to do that. (E.g. see RFP policy, for one example of a well-reasoned disclosure policy).

Re:Responsible disclosure?

[Cow Jones]

You have to give the vendor at least a chance to get the bug fixed.

No, you don't. For all we know, some black-hat hacker may have already found this vulnerability and be actively exploiting it.

It's the same old discussion every time. There are arguments for and against releasing vulnerabilities without notifying the vendor in advance, I know, but from a developer's standpoint (and from a user's), it's preferrable to give at least a grace period before releasing the details.

The advantages of releasing immediately are:

• Users can be told about possible workarounds.
• There's a better chance of the vendor releasing a patch/fix in a timely manner.
• You can show off your l33t zero-day skillz.

The disadvantages are:

• Any black-hat who hadn't noticed the problem now knows about it and can write an exploit.
• The entire user base is immediately at risk from script kiddies. If there was no exploit of the bug in the wild, there soon will be.
• The vendor does not get time to send a security alert and workaround instructions to its registered users or to its security mailing list.
• The vendor may have to rush the bugfix release before proper testing and QA is complete.

In this specific case, the Zimbra users are definitely worse off, unless they happen to read Holden Karau's blog (or Slashdot).
But maybe Holden will get his t-shirt now, so that's ok.

CJ

Re:Responsible disclosure?

[Albanach]

"At the time of the writing Yahoo! security has been notified."

I do wonder what route he chose to notify them? Maybe an email to postmaster@... ?

I don't see anything on Zimbra's bugzilla which I'd have thought would be the proper place to make such a report.

Maybe that was too difficult to find, and wouldn't be immediately obvious to other zimbra users. But then there's nothing immediately obvious on the official zimbra forums either.

Re:Responsible disclosure?

[ReedYoung]

The disadvantages are:
* Any black-hat who hadn't noticed the problem now knows about it and can write an exploit.

I would expect black-hats to have scripts already laying around for such a battleship-sized hole, and not need to be told because their existing network of zombie machines would be so likely to catch that, but I don't know, I am not a black-hat. I do see your point that Friday press releases are bad form though. Unless the vulnerability has been exploited and not identified by the authors, my first reaction is that it probably could have waited until Monday.

Then again, vulnerabilities that are ignored or denied are already matters of record, so maybe it's better to keep all proprietary software houses "on their toes" to the maximum degree possible, just based on the evidence that without oversight, they'll do absolutely nothing to protect customers' property rights from theft during online transactions. After all, SSL is not some obscure package in use on only two abandoned workstations that somebody just didn't remember to unplug from a defunct warehouse in the 1970's. It is used a lot, and expected to at least require a few million clock cycles to defeat. No, a lot of users don't know "how difficult" 64-bit or 128-bit encryption is to defeat, in clock cycles, they just expect they're substantially safer with it than without it. Claiming to support SSL but then not encrypting data sent to an https URL seems pretty damned amateurish. That ought to have been caught in house, and if HK believes Zimbra users are already vulnerable, and the main effect of his announcement is to cure users' ignorance of the danger they're in already, then I can understand why he decided not to wait until Monday as a courtesy to Yahoo! The text of his post obviously contains a lot of intentional sarcasm, to a dev team that I agree is clearly not even trying. Or they're employed by a proprietary software house but counting on free QA workers for every aspect of development, not just usability. Either way, I hope HK gets his T-shirt.

Then again, maybe the Yahoo! Zimbra team made that behavior intentionally, only for 127.0.0.1 and/or localhost.localdomain, just to phish for aggressive testers and first thing tomorrow morning, the joke's on HK. But Ockham and I suspect they just screwed up.

Re:Responsible disclosure?

[Cow Jones]

I pretty much agree with what you wrote. Just as an addendum, here's a very recent example of a successful cooperation between a person who discovered a security vulnerability (John Resig) and the software vendor (Apple):

Clickjacking iPhone Attack

Re:man in the middle

[Gnavpot]

As aussie_a said, what you describe is in no way similar to a man-in-the-middle attack. 'MITM' refers to be the ability to eavesdrop on and forge network traffic. Fake login pages is part of 'phishing'.

Phishing does not exclude MITM attacks.

If the phishing site acts as a proxy to the real site - as described by the GP - it IS a MITM attack.

Re:man in the middle

[aussie_a]

Merlin comments on the validity of your description, but regardless how would HTTPS change that?

Local http proxy?

[kasperd]

I have been wondering if it is possible to catch this with a local http proxy. If you run an http proxy on your own machine, and let all the https traffic go through that, then that proxy would be between your client and any man in the middle. Is it possible to inspect the https traffic and find out early enough, if the certificate is valid, and for the correct domain? (Asking because I don't know https well enough to say for sure myself). I was hoping that could also get rid of the annoying certificate warnings I always get when connecting to public access points, since they tend to hijack all traffic, including https, until you are logged in.

Re:Local http proxy?

[gomoX]

Most proxies just forward HTTPS traffic because they can't do anything else (they can't read the contents of the messages!).

Technically you could verify the authenticity of the public key proposed by the host (or MitM) because IIRC at that point the communication isn't encrypted yet, but I don't know if there's personal proxying software that can do this.

Re:Firefox error messages

[Anonymous Coward]

Firefox gets criticised for its new warnings because:

1. The old mis-match warnings were just fine unless the user doesn't read warnings, in which case the new ones won't help anyway.

If you want to work around the certificate error, you more or less have to read the text. Arbitrarily clicking the "go away" button does not do what you would expect. Even once you choose to add an exception, you have to manually press a button to choose to download the certificate, and THEN enable the exception.

2. They look like errors. They're not errors, they're warnings.

A bad SSL certificate is an error. These types of rationalization are simply born of outright laziness coupled with gross ineptitude.

3. Why can't it just present the page as insecure (no padlock) by default?

It would still say 'https'. Why can't administrators just use non-broken certificates?

Re:man in the middle

[flosofl]

SSL connections are only valid as long as the user pays attention messages regarding a mismatch between the site and certificate and does not continue with the connection. Other SSL connections you cannot trust are self-signed certificates --it bypasses the whole authentication portion of SSL and only supplies an encrypted link-- and certificates signed by a CA that is not in your chain.

If all you need is an encrypted end-to-end connection over SSL (say for a management front-end), the self-signed is fine. But if you're using it for a connection to serve a population of users, you're better off getting it signed by a valid CA. I know I won't use any 3rd party sites that have self-signed certificates, or a certificate with an IP address for the CN instead of the actual hostname. I've found I haven't really been missing out on anything and I'm not left wondering. It should be noted due to my profession (Info Sec) I'm a little more paranoid than most.

Re:Firefox error messages

[iammani]

2. They look like errors. They're not errors, they're warnings.

A bad SSL certificate is an error. These types of rationalization are simply born of outright laziness coupled with gross ineptitude.

Especially since you can even get free ssl certificates from people like http://www.startssl.com/?app=1

Re:Firefox error messages

[Anonymous Coward]

Firefox gets criticised for its new warnings because:

1. The old mis-match warnings were just fine unless the user doesn't read warnings, in which case the new ones won't help anyway.
2. They look like errors. They're not errors, they're warnings.

You can't have it both ways - those two points are contradictory. If they look like an error, then someone who doesn't read them will think they're an error and stop - they'll hit the Home button or whatever. That saved the non-warning-reader from being phished.

3. Why can't it just present the page as insecure (no padlock) by default?

Because it's not a big enough clue that you're being attacked by an active man-in-the-middle (e.g. Kaminsky DNS attack). People will miss it - after all, they went to their bank via their bookmark as usual, they're expecting it to be secure. You want a big full-screen "you are being hacked!" warning.

Re:man in the middle

[jimicus]

I am pretty sure my workplace is trying to pull this off but it includes providing their own versions of certificate providers certs by controlling the client binaries.

It'd be easier to present a self-signed certificate for every HTTPS connection and simply install your own root certificate on every client PC. Easy enough when you control the client PCs.

Any SSL-protected connection assumes that you either control or have complete trust in the client PC you're sitting at and the system(s) at the other end. If either of these are not true, then you must assume that the security is compromised.

(Of course, in these days of spyware and keyloggers, you can't necessarily be certain you have control over the client PC and with the number of high-profile data security breaches, I'm not sure you can have much faith in the other end either. One time pads and their modern electronic equivalents - those things that some banks supply that look a bit like a pocket calculator and generate a number when you put your card in a slot -help alleviate the spyware issue by ensuring that your credentials can't be stolen, but they don't prevent an attacker from being able to transmit the contents of your session to a third party who may well glean enough information from that to telephone your bank and transfer money out.

Re:In Soviet Russia

[Enter the Shoggoth]

Soviet Russia? Sounds more like Confucius or Yoda.

man in the middle vulnerable attack you!

Re:Just curious

[jimicus]

While 'Man in the Middle' attacks are certainly theoretically possible, but, has there ever actually ever been a verified MitM attack? Links appreciated if they exist.

That's an extremely good question. My instinctive guess is "probably not involving a mainstream use of the Internet, eg. online banking or shopping" - mainly because MitM attacks require quite a bit of effort and would be quite difficult to set up without leaving a dirty great trail. Far easier to get keylogging spyware and grep for "www.majorbank.com" or run a phishing scam.

Once you get into things like online espionage (being carried out by governments with lots of money and the will to ensure that the attacker is allowed to do their work), I wouldn't like to say.

Name the fix

[jav1231]

If a fix gets written it should be named the Tom Shane fix because he eliminates the middle man.

What do you expect?

[Ralph Spoilsport]

From software with a name derived from Dadaist nonsense poetry by Hugo Ball?

At Least...

[Mitchell Bogues]

At least Microsoft didn't buy them out in the spring, or we'd be seeing this vulnerability built right into the next Windows kernel!