Spear Phishing Attack Against the Financial Times
Interesting story with a lot of details.
Comments
Brandioch Conner • June 24, 2013 5:00 PM
@John Thurston
Use email clients which, by default, render in plain text.
I will 2nd that. And more than that. In the first example image, the sender appears to be at an FT.com address. Why not change that behaviour so that only authenticated accounts to your servers can claim to be from your domain?
From the article:
Switching to Google accounts (a move which the FT completed last year) gives us access to a well designed two-factor authentication system and automated security checks that offer a much more robust defense.
Yeah, that’s a problem when you move a system outside of your control. Fortunately, the crackers weren’t very good. It would be very simple to use one cracked account to send replies to recent emails from other FT.com and include a link to a site hosting more “mal-ware” that could install itself.
Unfortunately, on Friday, we discovered that we had left it ajar.
That will ALWAYS be a problem. There is no way for you to micro-manage every user each time they login to one of your systems.
It’s been suggested to me that I might have left the tab open and inadvertently logged in later when switching tabs without looking at the URL, and I guess that must be what happened in my case.
Dirk Praet • June 24, 2013 6:43 PM
Did they use SPF ?
Andrew H. • June 24, 2013 7:47 PM
Use email clients which, by default, render in plain text.
Come on, really? You cannot possibly expect a whole company of journalists (or pretty much anybody else in the world) is going to do this. They will just get used to clicking the “display as HTML” button for every incoming e-mail. And are you going to stop people from using tablets and smartphones, too?
Note: this is coming from someone who still reads his personal e-mail primarily in Pine on FreeBSD. But I don’t imagine that you can get any appreciable percentage of normal people to do this!
Alastair • June 24, 2013 8:05 PM
Disagree HTML formatting should be disabled.
However email clients should black-list/filter/modify tags which can be used for mischief. Most email clients treat img tags with care. Anchor tags should be similarly treated with suspicion by the client.
Scott "SFITCS" Ferguson • June 24, 2013 8:57 PM
Once I was a purist that only used plain text for email. Now I use HTML extensively in email and I’ll no more go back to plain text only than I will give up mobile phones and return to POTS only. I still agree that HTML introduces risk to email – but the main problem is not HTML (and Javascript does not work in email) but that many/most people do not understand basic HTML. Couple a lack of basic HTML skill with an inability to judge the trustworthiness of email, and an industry that flogs the concept of “you don’t need to know” and you have a problem. The problem doesn’t get solved by banning HTML.
These are constant “IT” problems that result from making the complex simple for marketing purposes. Simple is also dumb, and dumb makes problems. (simple really).
Rob • June 25, 2013 2:46 AM
It surely wouldn’t be hard for browsers and email clients (maybe via a 3rd party plug-in?) to inspect linked text and render it to be a warning if the text and the link are different, especially if the text looks like a URL or email address. But would it be useful? Even as a small measure?
Scott "SFITCS" Ferguson • June 25, 2013 4:56 AM
@rob
It surely wouldn’t be hard for browsers and email clients (maybe via a 3rd party plug-in?) to inspect linked text and render it to be a warning if the text and the link are different, especially if the text looks like a URL or email address.
Actually it’s simple – getting people to use it, not so much (PEBCAK).
Icedove/Thunderbird is one MUA does something similar – in that it asks user permission before loading offsite components of a HTML email. “To protect your privacy, Icedove has blocked remote content in this message”
It also has some phishing detection:-
Search in about:config for rules with safebrowsing or phish in them.
The actual code is in phishingDetector.js
Icedove flags the following:-
- Links that only use an IP address, including dotted decimal, octal, hex, dword, or some mixed encoding.
- Links that claim to go to one site, but actually go to another. (Mailing lists sometimes do this and news gateways).
- Forms embedded in the email.
Training Icedove/Thunderbird to treat some emails as “not scams” is too hard for many (it’s a simple one click process) so you’ll find numerous posts on the intertubes that guide people through the process of shooting themselves in the foot (sigh).
Note to potential whistle blowers: Do not contact the Financial Times! Their use of Google Apps will mean that the wrong people will know about you faster than the ones you thought you contacted and those people won’t notice that you tried to contact them….
Brandioch Conner • June 25, 2013 12:19 PM
@Scott “SFITCS” Ferguson
Icedove flags the following:
Links that only use an IP address, including dotted decimal, octal, hex, dword, or some mixed encoding.
Links that claim to go to one site, but actually go to another. (Mailing lists sometimes do this and news gateways).
Forms embedded in the email.
(sorry about the re-formatting but blockquote didn’t work otherwise)
The problem that I have with that approach is that it is too much of the “everything is safe EXCEPT for these” when the approach should be “everything is suspicious BUT these are less suspicious”.
It is difficult to think of every possible way that things considered “safe” can be combined in order to get malicious content past a filter.
I’d like to see an MUA that colour-codes email based upon x-headers added by the trusted MTA/mail-server. But that would not be feasible for a company that is using gmail or such.
Scott "SFITCS" Ferguson • June 25, 2013 9:31 PM
@Brandioch Conner
The problem that I have with that approach is that it is too much of the “everything is safe EXCEPT for these” when the approach should be “everything is suspicious BUT these are less suspicious”.(using cite tag, I’d use pre if I wanted to preserve blocks)
That’s a common interpretation based on the expectation that it’s possible to write a set of rules that can accurately flag only a large percentage of suspect emails. I could propose the same rules continue to be used but the warning be replaced with “Danger – this email appears to have been composed by a brain dead script kiddie”. Most of the time the warning would be accurate – but the problem remains. There is no way to make the complex simple – only to make it ‘appear’ simple. I guess I’m alone in viewing the documented spearphish as lame and unsophisticated. Sophisticated would be domain hijacking.
It is difficult to think of every possible way that things considered “safe” can be combined in order to get malicious content past a filter.
Agreed. I’d even suggest it’s impossible (more legislation against sharp corners on furniture just makes people less cautious). How many people realise au.com is not a 2TLD?
NOTE: the Icedove phish filter does detect most phishing scams – but users won’t tolerate any false positives as if forces them to make a decision most don’t want to, or, are incapable of making (for reasons too complicated for me to theorise on here).
Part of the problem is the “mediacy” (I just made that up) – the ability to do “things” instantly puts pressure on users to do just that – even when it’s not necessary. “Click -> Doh!/Don’t think/worry” is the knee jerk reaction to most internet/email “opportunities” rather than “Think -> Click”. Another part of the problem is the perception of loss (loss looms larger than gains). The hooks in phishs cause the (apparent) potential loss (don’t want to miss out on an “opportunity”) to outweigh the possible gains (security). It’s been my observation that deciding to open or ignore an email takes most people less than a second – and few would know how to examine the code even if they wanted to.
I’d like to see an MUA that colour-codes email based upon x-headers added by the trusted MTA/mail-server.
Easily implemented. Writing the rules for ranking not so easy.
But that would not be feasible for a company that is using gmail or such.
Actually… no, that is incorrect. It’s an MUA. I use both gmail accounts hosted at my domain, and on gmail’s domain. Additionally I use my own email hosting. All three types of email account are simple to setup with Thunderbird/Icedove, or Mail.app/Outlook, indeed any “Mail User Agent”. But you may have highlighted part of the problem – it’s easier to conceive of the negative than the positive.
Most of these problems could be solved if people understood:-
- the internet (dns, domains, http)
- HTML (specifically that weird subset used in email)
- encryption
I’m not going to hold my breath waiting for those things to happen, and until they do people will be conned because it’s possible (easy) and profitable to do so.
How many people use PGP to sign their email?
How many people understand how trust and PGP signatures work?
How many companies use PGP signatures?
How many MUAs support PGP signatures?
Does cloud based computing do away with MUAs? Not in my opinion – I use X forwarding in those situations.
TvF • June 26, 2013 6:17 AM
@Scott
Javascript does not work in email
Oh, but it does: Most “normal” people nowadays exclusively use web-based mail clients (GMail, Yahoo, Hotmail, or the countless others) which means their mails are rendered within a fully functional web browser, and in an environment (surrounding page/app) that relies on having scripting enabled.
Scott "SFITCS" Ferguson • June 26, 2013 10:53 AM
@TvF
Oh, but it (sic) javascript does (sic) work in email
Um, I’ll continue to stand by what I said. 😉
Here’s some javascript that does work in HTML[*1].
[script type=”text/javascript”>
alert(“if you can’t prove it, you’re probably wrong”);
[/script>
Knock yourself out.
Please email me your proof of concept (seriously).
[*1] not interpreted in Icedove/Thunderbird, and gmail strips out the [script> tags and everything between them. Yahoo doesn’t interpret it either.
Brandioch Conner • June 26, 2013 12:55 PM
@Scott “SFITCS” Ferguson
I guess I’m alone in viewing the documented spearphish as lame and unsophisticated.
You’re not alone. The problem is that even lame and unsophisticated attacks keep succeeding. I think that is because of 2 reasons:
- Anyone can make a mistake. And eventually will. With enough people being targeted and enough attempts one will, eventually, get through.
- Today, all the effort is put into identifying the “bad”. Here’s a site that explains it better than I can.
http://www.ranum.com/security/computer_security/editorials/dumb/
We need to re-focus on how to reduce the problem set. Something like “These messages are not suspicious enough to be flagged as spam but they are suspicious because too many factors cannot be confirmed. Exercise additional caution.”
Actually… no, that is incorrect. It’s an MUA. I use both gmail accounts hosted at my domain, and on gmail’s domain.
My post probably was not clear enough. You’d need to configure the MTA/mail-server to add additional x-headers (and remove existing ones) for the MUA to use for colour-coding the email messages. If you run your own server, adding x-headers is easy. If you use gmail then you cannot add x-headers specifically for your use.
Most of these problems could be solved if people understood:
Probably. But that is not going to happen. It’s difficult enough to find “IT people” who understand even a majority of those items. So we (people who do understand those) need to find better ways to communicate the risk level to the end users.
Scott "SFITCS" Ferguson • June 26, 2013 3:21 PM
@Brandioch Conner
I’d like to see an MUA that colour-codes email based upon x-headers added by the trusted MTA/mail-server. But that would not be feasible for a company that is using gmail or such.
But that would not be feasible for a company that is using the gmail web interface or such.
FTFY 🙂
So, use a fully featured MUA instead of a limited feature set web interface. Convenience almost always comes at a price.
Eventually I hope that people will learn to use PGP signatures and sites will implement DNSSEC. It still won’t protect people from the same old cons they’ve been falling for since the dawn of time (cheap horses, Spanish Prisoners, lottery wins, lucky finds, their own gullibility – which includes their ability to intuit trustworthiness based on appearance).
If it can be “assessed” at the MTA, it can be assessed at the client. Maybe Melissa Shearin will snatch you and your idea up and it’ll be the new, killer, feature in the free gmail. It’s not a scam prevention measure I’ve heard suggested before (for what that’s worth).
Brandioch Conner • June 26, 2013 5:25 PM
@Scott “SFITCS” Ferguson
But that would not be feasible for a company that is using the gmail web interface or such.
FTFY 🙂
Not until Google allows users to make changes to the Gmail MTA servers to add/remove x-headers. And that is too big of a security risk.
If it can be “assessed” at the MTA, it can be assessed at the client.
Two possible problems with that:
- If you are talking about Gmail – all of the messages received by the MUA will show a Gmail MTA as the last hop. Possibly the last two hops. Maybe more. So you cannot perform a lot of the checks against suspicious MTA’s.
- For any MTA server – the difference is that doing it once at the server where people with more expertise can handle it for all the users versus doing it at 100 or more client installations where the users may not know what an SMTP envelope is, what an rDNS lookup is, etc.
Maybe Melissa Shearin will snatch you and your idea up and it’ll be the new, killer, feature in the free gmail.
It cannot be done on gmail because one gmail account sending email to another gmail account would have to be “less suspicious” or else it defeats the purpose of identifying “more suspicious” traffic.
At least that’s the moral I get from article. Once you move a service “to the cloud” you lose a lot of the control you had when it was “in house”. So you need to take additional precautions. Such as using 2 factor authentication when you want to check your email.
And there is also education/training. If the USER clicks on a link in a “more suspicious” email and is cracked, that USER needs more education/training.
If the admin configures the server such that “more suspicious” emails are not flagged as such then that admin needs more education/training.
Subscribe to comments on this entry
Leave a comment
Sidebar photo of Bruce Schneier by Joe MacInnis.
John Thurston • June 24, 2013 3:49 PM
“Because the email was HTML formatted, it could link to one URL while displaying another, so the link didn’t look like the URL it actually linked to:”
The foot in the door was not, so much, the HTML formatting of the original message, as it was the HTML rendering of the receiving email client.
The post-event analysis mentions several things done to improve their security. I wonder why the simple one wasn’t mentioned:
Use email clients which, by default, render in plain text.