Compromising a Mail Client

Your entire work life is in your work mail client.
All the people you communicate with – co-workers, friends, family, vendors, customers, colleagues.
Every email you send. Every email you receive. Any files you attach or receive.
If someone can compromise your mail client, they can see all that.
They can save copies of all your emails, data-mine them and use them for whatever purpose they like. They can build a view of your social network, based on who you exchange emails with, and a model of who you are, based on what you talk about.
That companies like Google do this for “free”, advertising supported webmail shouldn’t be much of a surprise by now – but your corporate email system and your work email is secure, right?
What if an attacker were to set up a man-in-the-middle attack on your employees? Install malware on their iPhone, such that all traffic were transparently routed through a proxy server controlled by the attacker?
Or they could use a more email-centric approach, configuring the compromised mail client to fetch mail from an IMAP server controlled by the attacker that took the employees credentials and passed them through to their real corporate IMAP server – that would let the attacker completely control what the compromised user saw in their inbox. As well as being able to read all mail sent to that user, they could silently filter mail, they could deliver new mail to the users inbox directly, bypassing any mail filters or security. They could even modify the contents of email on-the-fly – adding tracking links, redirection URLs or injecting entirely new content into the message.
Similarly, the attacker could route all outbound mail through a man-in-the-middle smarthost that copied the users credentials and used them to send mail on to their real corporate smarthost. As well as being able to read and modify all mail sent the attacker could also use that access to send mail that masqueraded as coming from the user.
Sounds like the sort of thing you’d expect from criminal malware? Not quite. What I’ve just described is Intro, a new product from LinkedIn.
LinkedIn will be asking your users to click on a link to install a “security profile” to their iPhones. If they do, then LinkedIn will have total control over the phone, and will use that to inject their SMTP and IMAP proxies into your users mailstreams. The potential for abuse by LinkedIn themselves is bad enough – I’ve no doubt that they’ll be injecting adverts for themselves into the mailstream, and their whole business is based on monetizing information they acquire about employees and their employers. But LinkedIn have also been compromised in the past, with attackers stealing millions of LinkedIn user credentials – if they can’t protect their own users credentials, I wouldn’t trust them with your employees credentials.
You might want to monitor where your employees are logging in to your servers from – and suspend any accounts that log in from LinkedIn network space.
Edit: Bishop Fox has looked at Intro too, and come to similar conclusions. TechCrunch too.

Related Posts

Clicktracking 2: Electric Boogaloo

A week or so back I talked about clicktracking links, and how to put them together to avoid abuse and blocking issues.
Since then I’ve come across another issue with click tracking links that’s not terribly obvious, and that you’re not that likely to come across, but if you do get hit by it could be very painful – phishing and malware filters in web browsers.
Visting this site may harm your computer
First, some background about how a lot of malware is distributed, what’s known as “drive-by malware”. This is where the hostile code infects the victims machine without them taking any action to download and run it, rather they just visit a hostile website and that website silently infects their computer.
The malware authors get people to visit the hostile website in quite a few different ways – email spam, blog comment spam, web forum spam, banner ads purchased on legitimate websites and compromised legitimate websites, amongst others.
That last one, compromised legitimate websites, is the type we’re interested in. The sites compromised aren’t usually a single, high-profile website. Rather, they tend to be a whole bunch of websites that are running some vulnerable web application – if there’s a security flaw in, for example, WordPress blog software then a malware author can compromise thousands of little blog sites, and embed malware code in each of them. Anyone visiting any of those sites risks being infected, and becoming part of a botnet.
Because the vulnerable websites are all compromised mechanically in the same way, the URLs of the infected pages tend to look much the same, just with different hostnames – http://example.com/foo/bar/baz.html, http://www.somewhereelse.invalid/foo/bar/baz.html and http://a.net/foo/bar/baz.html – and they serve up just the same malware (or, just as often, redirect the user to a site in russia or china that serves up the malware that infects their machine).
A malware filter operator might receive a report about http://example.com/foo/bar/baz.html and decide that it was infected with malware, adding example.com to a blacklist. A smart filter operator might decide that this might be just one example of a widespread compromise, and go looking for the same malware elsewhere. If it goes to http//a.net/foo/bar/baz.html and finds the exact same content, it’ll know that that’s another instance of the infection, and add a.net to the blacklist.
What does this have to do with clickthrough links?
Well, an obvious way to implement clickthrough links is to use a custom hostname for each customer (“click.customer.com“), and have all those pointing at a single clickthrough webserver. It’s tedious to setup the webserver to respond to each hostname as you add a new customer, though, so you decide to have the webserver ignore the hostname. That’ll work fine – if you have customer1 using a clickthrough link like http://click.customer1.com/123/456/789.html you’d have the webserver ignore “click.customer1.com” and just read the information it needs from “123/456/789.html” and send the redirect.
But that means that if you also have customer2, using the hostname click.customer2.com, then the URL http://click.customer2.com/123/456/789.html it will redirect to customer1’s content.
If a malware filter decides that http://click.customer1.com/123/456/789.html redirects to a phishing site or a malware download – either due to a false report, or due to the customers page actually being infected – then they’ll add click.customer1.com to their blacklist, meaning no http://click.customer1.com/ URLs will work. So far, this isn’t a big problem.
But if they then go and check http://click.customer2.com/123/456/789.html and find the same redirect, they’ll blacklist click.customer2.com, and so on for all the clickthrough hostnames of yours they know about. That’ll cause any click on any URL in any email a lot of your customers send out to go to a “This site may harm your computer!” warning – which will end up a nightmare even if you spot the problem and get the filter operators to remove all those hostnames from the blacklist within a few hours or a day.
Don’t let this happen to you. Make sure your clickthrough webserver pays attention to the hostname as well as the path of the URL.
Use different hostnames for different customers clickthrough links. And if you pick a link from mail sent by Customer A, and change the hostname of that link to the clickthrough hostname of Customer B, then that link should fail with an error rather than displaying Customer A’s content.

Read More

Flush your DNS cache (again)

This time it appears that DNS for major websites, including the NY Times, has been compromised. Attackers put in DNS entries that redirected visitors to a malware site. The compromise has been fixed and the fake DNS entries corrected.
However, people may still have the old data in their DNS caches and security experts are suggesting everyone flush their DNS cache to make sure the fake data is gone.
The Washington Post has an article explaining DNS hijacking.

Read More

Cloudflare and Spamhaus

Spamhaus has been the subject of a lot of discussion the last few weeks. I touched on this a little in June when I blogged that a number of large brands were getting SBL listings.
But big brands are not the only companies with publicly discussed SBL listings.
Cloudflare, the content delivery network that grew out of project honeypot, has a number of SBL listings, covering at least 2 /18s and a /20. Representatives and customers of Cloudflare have been discussing the listings on twitter.
As a content provider, Cloudflare isn’t actually sending mail nor are they actually hosting the content. What they are doing is providing consistent name service and traffic routing to malicious websites. In fact, they’ve been providing services to a malware botnet controller (SBL138291) since May, 2012. They’re also providing services to a number of SEO spammers. Both of these actions are justification for a SBL listing, and Spamhaus has a history of listing providers protecting spammers.
Cloudflare claims they take action on all “properly filed complaints” and they may actually do that. But their reports require quite a bit of information and require consent for releasing information to 3rd parties. Looking at the website, it appears to me to be a site designed to discourage abuse reports and stop people from reporting problems to Cloudflare.
When you look at the Cloudflare business model it’s clearly one that will be abused. Cloudflare acts as a reverse proxy / pass through network that caches data from their customers. This protects the abusers webhosting setup and prevents people tracking the abuser from being able to determine the true host of a website. As a responsible internet citizen, Cloudflare should be disconnecting the customers hiding behind Cloudflare’s services.
Unfortunately, Cloudflare seems unwilling to actually police their customers. They’ve taken a totally hands off approach.
Let’s be frank. Cloudflare has been providing service to Botnet C&C servers for at least two months. It doesn’t matter that the abuser has the malware on a machine elsewhere, Cloudflare’s IP is the one that serves the data. I don’t care what you think about spam, providing service to malware providers is totally unacceptable. It’s even more unacceptable when you claim to be a security company. Nothing about malware is legitimate and the fact that Cloudflare is continuing to host a malware network command and control node is concerning at the very least.
Cloudflare (.pdf) is listed on Spamhaus for providing spam support services. The most obvious of these is providing service to a malware controller. And Spamhaus escalated the listings because they are allowing other abusers to hide behind their reverse proxy.

Read More