Decades-Old Email Flaws Could Let Attackers Mask Their Identities (wired.com) 46
At the Black Hat security conference on Thursday, researchers will present "darn subtle" flaws in industry-wide protections used to ensure that emails come from the address they claim to. From a report: The study looked at the big three protocols used in email sender authentication -- Sender Policy Framework (SPF), Domain Keys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting and Conformance (DMARC) -- and found 18 instances of what the researchers call "evasion exploits." The vulnerabilities don't stem from the protocols themselves, but from how different email services and client applications implement them. Attackers could use these loopholes to make spearphishing attacks even harder to detect. "I think I'm a savvy, educated user and the reality is, no, that's actually not enough," says Vern Paxson, cofounder of the network traffic analysis firm Corelight and a researcher at the University of California, Berkeley, who worked on the study along with Jianjun Chen, a postdoctoral researcher at the International Computer Science Institute, and Jian Jiang, senior director of engineering at Shape Security.
"Even users who are pretty savvy are going to look at the indicators that Gmail or Hotmail or others provide and be fooled," Paxson says. Think about when you hand a friend a birthday card at their party. You probably only write their first name on the outside of the envelope, and maybe underline it or draw a heart. If you mail that letter instead, though, you need the recipient's full name and detailed address, a stamp, and ultimately a postmark with a date on it. Sending email across the internet works similarly. Though email services only require you to fill out the "To" and "Subject" fields, there's a whole list of more detailed information getting filled out behind the scenes. Those industry-standard "headers," as they're known, include date and time sent and received, language, a unique identifier called a Message-ID, and routing information.
"Even users who are pretty savvy are going to look at the indicators that Gmail or Hotmail or others provide and be fooled," Paxson says. Think about when you hand a friend a birthday card at their party. You probably only write their first name on the outside of the envelope, and maybe underline it or draw a heart. If you mail that letter instead, though, you need the recipient's full name and detailed address, a stamp, and ultimately a postmark with a date on it. Sending email across the internet works similarly. Though email services only require you to fill out the "To" and "Subject" fields, there's a whole list of more detailed information getting filled out behind the scenes. Those industry-standard "headers," as they're known, include date and time sent and received, language, a unique identifier called a Message-ID, and routing information.
Free (Score:2)
Re: Free (Score:2)
Re: (Score:3)
My version of a similar idea allowed for credit with periodic accounting between email providers. It didn't even have to be real money at that time, but delivery-time penalties could kill email providers who permitted spammers.
However I eventually concluded that SMTP doesn't really permit it. Therefore my later solution approach was for a separate email system with a CMTP (Complex Mail transfer Protocol) that included the features spammers hate. There would be gateways between the two email systems, with th
Re: (Score:2)
Have you submitted an RFC for this? I would be interested in reading the technical details.
Re: (Score:2)
No, but it was a long time ago and I was pretty busy in those years. Closest I can recall to an RFC was some stuff about extended characters sets. The name that comes to mind was a fellow in a localization team?
What I can recall about that early email idea at this late date was that it basically involved keeping count of email exchanges, which could be used for billing, but which I suggested simply be used for delay times. If any server is sending too much email, its email would start to get more and more d
Re: Free (Score:2)
Because I'd say I get an average of 2 or 3 a day, and the cost is far lower (about half) to send them.
Re: (Score:2)
You can opt out of bulk mail, though.
Re: (Score:2)
Re:Free [to Live and Let Spam] (Score:2)
I think you deserve a mod up and extra if you deliberately avoided the troll FP. However, your concision suggests you were merely too slow. *sigh*
I'll try to extend your argument in the other direction. Your short comment seems to address the marginal cost problem. Another million or billion spams have essentially no cost because SMTP ignores the costs.
My focus is on the benefit side of cost-benefit analysis. The spammers are getting money or they would stop. Proof of concept is the cessation of the pump-an
Re: (Score:2)
Just target the corporation paying for the ad. Really quite simply, start tossing out prison sentences for harassment (it is illegal) and as they paid for the ad and did not properly audit or control their advertising agents, they are liable for the penalty.
Spammers must advertise something, no problem target that, what is being advertised and who is paying for the advertisement. When they start going to jail, spamming will stop and you all know it. The spammer does not make one cent of you they make if of
Re: (Score:2)
I think this is a misdirected reply. At least I'm not seeing how it relates to what I wrote. I can go as far as agreeing that the spammers are advertising something (though it's usually nothing when you check), but I don't see where there's a legitimate company that can be sued in that loop. Maybe you can clarify your reasoning if it is actually a reply to my comment?
However, I can try to clarify a different aspect of my solution approach. I think the spammers' supply of suckers is quite limited. They are a
Re: (Score:2)
With bulk mail prices you still get a lot of spam in the (physical) mailbox. And yet even after despairing of all the dead trees delivered to you weekly, it is still LESS than if mail were free. We get the useless penny-saver once a week, but not every day. Now imagine with email, you can send the same spam to a million people, over and over, and spend less than the cost of parking in front of the internet cafe the spammer is sitting in.
Hash ID? (Score:2)
Re:Hash ID? (Score:4, Insightful)
I think it'd end up being a fairly effective way to DDoS an organization's mail servers just by sending out a few million messages. The recipients of all those messages will all be trying to verify the hash against the spoofed domain at the same time.
Re: (Score:3)
We already have something better (Score:2)
We have something similar to that, it uses hashing. It just doesn't need to contact the purported sender because we have cool tricks to check a signature without having to go ask someone if they signed it.
The probably is inconsistency in how different email software handles invalid or unusual syntax. Here's an example:
From:
From:
To:
Who is the email from? The filter might see it as from ray@morris.com and check the signature, which confirms that it really is from ray@morris.com. Your mail client UI, Ou
Slashdot ate the headers (Score:2)
That should be:
From: updates@microsoft.com
From: ray@morris.com
To: you@slazzy.com
Another example is that email addresses in headers are almost always enclosed in brackets - but they don't have to be. It CAN be as above, just a bare email address. If software processing brackets in the from line, it should use the email address in the brackets; otherwise whatever comes after "from:" is the from email address. But what if there is an EMPTY set of brackets? Different software will handle that case different
Emeil does not assure sender identity (Score:4)
It has always been like that. Nobody with a clue is surprised by that. Anybody with a clue wants a cryptographic signature they can verify on an email before they trust a sender identity.
Re: (Score:3)
Re: (Score:2)
PKI is the obvious solution, and has been for decades, but the major mail providers don't want to implement it.
Yes. I really do not get why. It probably would not even be expensive.
Re: (Score:2)
Agreed. I've been signing my mail for 20 years, and got people at work to start doing it when I started there 14 years ago...but that all died after 1 year when they had jump through the hoops to renew certificates. If we had letsencrypt support built into webmail and imap clients, we could solve this very quickly.
Re: (Score:3)
Well, my last employer just did PGP (you created your own cert and handed the public one in, they signed it with the corporate cert and uploaded to the key-servers), long lifetimes no problem. My current one hands new x.509 certs (one for Email) with 4 years lifetime to each new IT employee and they hand out new ones before the old ones expire. It is really not hard to do this right.
Re: (Score:3)
Yes. I really do not get why. It probably would not even be expensive.
I would imagine the answer is obvious: if you're encrypting your email sent and received, then the "free" mail providers cannot read it and monitize it. It's then a case of "if the big players don't do it, then there's not mileage in us doing it" for the other providers.
Re: (Score:2)
It has always been like that. Nobody with a clue is surprised by that. Anybody with a clue wants a cryptographic signature they can verify on an email before they trust a sender identity.
Thank you. If you look at an email and assume the sender is real... Well I can't help you.
Email Is Not Secure (Score:3)
It's always been way too easy to impersonate someone else via email. Even with all of the "security" in place, I can route a message through our internal relay server and have it appear to come from anyone. And everyone's mail program is "smart" enough to look at the from address of "jsmith@mycompany.com" and replace it with the person's full name "John Smith, CEO" making it very difficult for even an educated user to determine that this message came through our internal relay rather than from the actual person.
Re:Email Is Not Secure (Score:4, Informative)
So you are saying that because you don't have per-user sender authentication enabled on your own server, your own company is insecure. Well that sounds like a personal problem to me. With SPF, DKIM, and DMARC, it is now both somewhat complicated to run an outgoing mail server and very hard to impersonate an organization's email addresses from outside if they have set it up properly. Scams these days don't even try this anymore. They just send an email that comes from "John Smith CEO (johnsmithceo23232@gmail.com)" with something "urgent" and hope the person will click before they notice that the email address is obviously bogus. Bonus points for lifting the signature block out of the bottom of an actual email sent by Mr. CEO, which makes it even less likely that the victim will look at the email address.
The story seems to be about how SPF, DKIM and DMARC provide the appropriate infrastructure, but inconsistent usage among different email vendors make this less effective. SSL suffers from many similar problems. For the longest time Macs put the lock icon in the titlebar, but one could just put a similar-looking one in the web page title and it looked almost the same. Duh. Even now some browsers want to do away with the address bar, but SSL requires that the hostname be visible to the end user for the human to verify that they are communicating with the website they intend to.
I think the biggest problem for email is that the email client needs to ensure that emails from unknown senders are clearly marked as such, so that a user will think twice about an email that they think is coming from someone they know but isn't. My own organization just started marking all external email with "[EXTERNAL]" in the subject. While super annoying this does effectively curtail third-party phishing. If someone gets an email from Mr. CEO that has a big [EXTERNAL] in the subject, even the non-tech-savvy are going to look at the from email address and see that it is bogus. Really we should go to a fully whitelist-only system based on S/MIME signatures with obvious markings for known vs. unknown contacts, not just secure vs. not-secure. (communicating securely with a phisher impersonating your boss, priceless). But big companies don't want to make email work better, they want to lock you into their proprietary communications platform!
Re: (Score:1)
Nice try though.
Nothing new (Score:2)
This is nothing new. I posted about some of these concerns 8 years ago.
http://lists.dmarc.org/pipermail/dmarc-discuss/2012-February/000216.html
Really? (Score:3)
"Those industry-standard "headers," as they're known, include date and time sent and received, language, a unique identifier called a Message-ID, and routing information."
What's this? Some young whippersnapper nerdsplaining eMail to us 40 years after the fact?
Signing (Score:2)
Emails need to be signed, all of the major email clients support S/MIME out of the box and will display if an incoming mail has a valid signature.
We just need user education, and for organisations to start promoting this - "All our emails are signed, if it's not signed by us then it's not from us."
Mail does not assure sender identity. (Score:2)
If you don't assume you know who sent every piece of paper mail in your mail box without consideration of the actual context of the message, why would you assume that about electronic mail. Besides that there is real value in anonymous communications that should not be engineered out of the systems we build.
Re: (Score:2)
Re:Office 365 ATP with anti-impersonation policy (Score:4, Interesting)
Really? Must not be enabled by default, given the number of times I tell O365 people their accounts have been compromised and they're now being used to send phishing messages.
While giving in to phishing is partially on the people who allowed themselves to be fooled, at least some of it is on the programs they select to use for email. Like Outlook, including its web version on O365.
O365 does a LOT of checks for email validity, assuming you read the message headers. SPF failures, DKIM failures, policy violations, all spelled out in the headers, but hidden by Outlook.
Early this year, a local college sent out a notification for some security training to be done online. Given that we were expecting a "phishing test", I checked the training message... and found numerous places where O365 was saying the message was probably forged, AND where the links for the training were obfuscated the same way phishing messages do. It even had a note to "use your campus login" on the non-campus training site.
And none of the warning flags were visible to Outlook users or the online Outlook viewer... I only caught them so easily because I was using a different program, accessing the O365 server via IMAP.
Their response? They changed IMAP access to exclude use of non-Microsoft-approved clients.
One of the college directors was successfully phished. Their response? Add two-factor authentication, making it even harder to access with a more-secure client.
I chose the safe route - I no longer access their O365 instance.
Re: (Score:2)
The while thing is utterly stupid. Also, Outlook is a pretty bad email reader anyways. Wherever I can, I still use Mutt. All these BS features they keep adding is making the house of cards they have build less and less stable. When I was younger, I thought these fictional super-hackers that can get in anywhere were pretty tacky and completely unrealistic. From what I see now, this may well be the future. Not because these hackers are so great, but because commonly used services and software keeps getting wo
Re: (Score:2)
Re: (Score:2)
When your email identity is also your identity for all other parts of a system (like Office365), a lot more than the ability to read/forward email is at stake. In the case of the college director that was phished, the attacker had access to their Sharepoint server, all O365 documents the user had access to, etc.
In the case of the college, they also used the O365 authentication for access to their financial system, course administration, off-site training, etc. In other words, everything that user had access
Re: (Score:2)
Yet another reason for digital crypto identity! (Score:2)
Are we like nine years old? (Score:1)
Think about when you hand a friend a birthday card at their party. You probably only write their first name on the outside of the envelope, and maybe underline it or draw a heart. If you mail that letter instead, though, you need the recipient's full name and detailed address, a stamp, and ultimately a postmark with a date on it. Sending email across the internet works similarly. Though email services only require you to fill out the "To" and "Subject" fields, there's a whole list of more detailed information getting filled out behind the scenes. Those industry-standard "headers," as they're known, include date and time sent and received, language, a unique identifier called a Message-ID, and routing information.
We're all dead. Just bury us already.
Re: (Score:2)
We're all dead. Just bury us already.
I'll go start up the STEM shovel.