Mailsploit: It's 2017, and you can spoof the 'from' in email to fool filters Penetration tester Sabri Haddouche has reintroduced the world to email source spoofing, bypassing spam filters and protections like Domain-based Message Authentication, Reporting and Conformance (DMARC), thereby posing a risk to anyone running a vulnerable and unpatched mail client. What he's found is that more than 30 mail …
Presumably that's (mostly) large companies sending out marketing garbage as hosted content or images. Surely that's no loss to you?
Nah, I've got a good set up (based around DEA) that means I don't see that kind of junk. It was bills from a couple of companies (Pulse8 possibly one of them) and some kind of customer alert from another.
>I have my clients configured to only show text
Like living dangerously!
My default is to display both, thus aiding spam identification:
Lloyds Bank [secure@lloydsconfidential.com]
Sage Invoice [secure@sage-invoices.com]
PayPal [support@bt.com]
All of the above are spam.
Worse still there's an increasing number of companies whose outgoing mail doesn't include any text. I have my clients configured to only show text and to pull it out of the HTML and sometimes the result is nothing at all :(
Even worse, I get this from a company I use:
Hello Client,
Unfortunately your email client is outdated and does not support HTML emails, our system uses HTML emails as standard. You will NOT be able to read thiis email.
HOW DO I READ THIS EMAIL
...
"non-ASCII Text" is somehow still considered the exception.
Well, seeing as the protocol relies on UUCP I don't really see anyway round this and, although I work with non-ASCII everyday I don't really see this as a problem.
SMTP has far bigger problems, such as no support for content encryption.
Email should have had mutual whitelisting since the start.
By design you can set the from email address to be anything
Often the first server outgoing is whatever ISP you are using even if you have your own custom from <name>@<mydomain>
I appreciate this is about more subtle aspects of "from".
Almost all spam I get is from real companies. The EU ones are breaking EU law.
Almost all malware I get the "From" is irrelevant. I know the attachment shouldn't be opened.
Almost all phishing I get the "From" is irrelevant, hovering on a link shows it doesn't go to the bank / paypal etc, or it's relating to a bank or company I have no contact with.
By default I have remote content off.
Really this vulnerability doesn't sound like a big extra problem. I never use any aspect of "from" to verify source. If in doubt I contact person by phone, or a known different email account.
It's not simple and involves the person that wants to send proving who they are and why they want to communicate.
You need private / public key asymmetric encryption.
It's not possible on the SMTP / POP or IMAP model.
Some systems do have embryonic versions of such a system.
Disadvandage is the sender would know you really exist. Advantage is that done properly with a micropayment to establish trust, spam would be gone. Troublesome senders can be revoked.
You don't expect me to publish a complete description with working code? Unfortunately the present system is hardly different to 1980s (email became established before web sites) or posts and telegraphs. "Spam" started when Telegraphic terminals moved outside post offices in the UK.
""Spam" started when Telegraphic terminals moved outside post offices in the UK."
"spam"[0] started a lot earlier than that. Consider the ancient Egyptian pharaohs plastering their faces all over everything, in a vain attempt at convincing the proles that they were gods on earth. Strangely enough, it worked. Just like today. I guess sheeple haven't changed much in 4,000 years, regardless of technology.
[0] Note CaSe ... "Spam" is a product of the Hormel corporation.
You need private / public key asymmetric encryption.
Which will immediately come up against several things:
1. No central key repository or generation point (or at least, not one trusted one).
2. Most end-users will find it too difficult to use - it's taken 20 years for https to catch on significantly and that's almost entirely server-based.
3. How do you validate that the end-user is who they say they are and that they are a valid user of that certificate? Look at the omnishambles in the SSL certificate space..
Sure, you can do PGP but even experts have increasingly come to find that not fit for purpose (for all of the reasons above and more). Some countires do have the ability to generate (sort-of) secure certificates for their citizens but they are few and far between and (in general) smaller counties with a smaller population.
Can you imagine the US or UK putting in place something to generate secure personal certificates? I can't - and even if they tried, it would end up being outsourced to some scum like Capita or Expedia and all you details would end up being extracted by some cracker and sold for pennies on the dark web. At which point you have to generate new certificates - for everyone involved. And if you outsource the end-user task to ISPs - how are they going to validate that you are who you say you are?
The servers should do MX header analyze lookups and then put a little globe icon to geolocate the IP that sent that garbage to you. This email from bad spam area > trash.
Had good friends visitng that area recently. How'd we share emails in that case?
Ok, I'm tech savy (almost, kinda, if you look at me sideways and don't turn the lights on) - how would his non-savy friends stay in touch?
"Really this vulnerability doesn't sound like a big extra problem. I never use any aspect of "from" to verify source. If in doubt I contact person by phone, or a known different email account."
You sir are a one-percenter. For everyone else who just uses email as a convenient and ubiquitous method of communication it (and the broader SMTP security issues described throughout this forum) is a problem. I'm thinking of my friends, family and colleagues who don't have your insight and guile but who could be one-percenters in other fields such as landing planes, fixing cars, or removing tumours.
In the early days you more or less had to. And that was the whole point of doing it. There were so many useful things you wanted to do that required it. Ideally smtp should have been ditched years ago in favour of something that actually copes with the inherent problems that weren't really problems in the early days, but somehow its never happened.
It's disappointing to see a Register reporter getting things so badly round his neck.
DMARC is a reporting system, not a spam filter. It reports to me, for example, about mail claiming to come from my domains but not sent by my servers. Mailling list servers are the most common culprits.
SPF is an anti-forgery system, not a spam filter. It's used so that recipients of mail can (if they can be ar$ed) check if the mail comes from a legitimate source. It works very well once you can get past all the misconceptions such as those demonstrated by the author of this article.
SPF, by design, and precisely because the 'From:' header is so easily forged, operates only on the SMTP envelope information.
SPF IGNORES the 'From:' header.
> DMARC only reports if your policy is set to "none", it can quarantine and reject mails if you like. or am I missing your point?
DMARC lets you broadcast a policy, that tells the world what *should* be done about messages coming from your domain and that are not authenticated a certain way. DKIM is one of those authentication methods and it can actually protect the domain used "from:" (the one in the message, not the smtp envelope). There are a lot of problems still however:
- Adoption rate is very low at the sender level (only a tiny % of domains have proper spf, dkim and dmarc policies in place)
- Adoption rate is still so-so at the received level. It's a much higher %, but there are still stupid situations like Microsoft still not doing shit about DKIM, and *lots* of self-managed smtp servers don't handle these things properly
And of course none of those policies, and use of those policies in email filtering, will do anything about the fact that most email agents are complete garbage. Take Yahoo for instance, you can mangle the subject line so much that it can alter their webmail GUI, still to this day.
Does anyone use DMARC and/or SPF for anything other than spam (and phishing) filtering?
We use it's presence on incoming mail for spam filtering, and make sure it's present on outgoing mail in order for our mail not to be flagged as spam by other companies. I'm pretty sure this isn't an unusual use case.
SPF is an anti-forgery system
Which the large 'free email' ISPs routinely ignore. Which is why I periodically get deluged with spam rejection bounces because someone on BTInternet thinks they can use my domain in their spam headers and BTInternet thinks that SPF checks are only for professionals..
(Yes - my SPF records are up to date and define exactly which email servers are allowed to send emails that use my domain names. Some ISPs check but a lot of them don't bother..)
...then your email is broken.
Use SPF to suggest where your mail comes from, but not definitive.
Otherwise, imagine this situation:
You send email to an important potential client. Their email address is their own domain that is forwarded onto their 'real' mailbox. Their ISP who they use for mail honours SPF. Your SPF records say mail will only come from your servers, yet the mail has just come from mx.bigdaddy.com (or whatever) . Email is rejected (and silly ISP drops rather than bounces in the mistaken belief that bounce messages are just spam). Potential client never gets your email. You are none the wiser.
This is nothing new and I'm not sure how it can be fixed. SMTP is fundamentally broken - at least from a security point of view. At its root there is a disconnect between how the mail is actually delivered and the message itself. SMTP is not much more than 'FTP with mailboxes' where the difference is that the two servers agree between themselves where to put the data. The format of an email message is defined but nothing in a basic SMTP implementation requires that it be read - it's just a chunk of data that one server uploads and the another copies to one or more storage locations. The 'routing' is handled through the SMTP protocol itself.
There are various frameworks such as SPF that allow a server to perform protocol level checking by at least verifying that the sender's claimed domain has authorised that particular server to send mail on their behalf but they are all opt-in. Receiving servers don't have to check and sending domains don't have to be configured. And making any of this compulsory or improving SMTP is a problem because the system is too widely used and still too important to break.
The evidence is that it's already broken. Is it too important to fix?
Good question. I think one of the issues at present is that because it's all receiver-side it can be a nightmare to set up strictly. Your users will start complaining about not getting emails and it can first-off take ages for anyone to realise where the problem is. Then resolving it is difficult because the error exists on a third party domain.
I only run a personal server but imagine if Tesco screwed up their SPF. it might take a couple of days before I realise what's going on. Then imagine the conversation if I call Tesco's customer support line to complain about it. It's not going to be as smooth and straightforward as it is to complain about a problem with a delivery :-/
Possibly could have a blockchain type system.
Email effectively becomes encrypted and decrypted only by your private email wallet. Your email address is entered as a transaction which includes your public key.
The blockchain holds the encrypted email.
Could cost a token to send a mail and get that token to receive. Works as an offset and Spammers would have to pay. miners get paid a portion of the token.
Spammers would have to pay
And when they crack your credentials (which is going to happen sooner or later) then they can send spam as you and, adding insult to injury, make you pay for it..
There are lots of reasons why 'pay to email' schemes have failed historically.
SMTP is too broken to be properly fixed. We need a new protocol.
>SMTP is too broken to be properly fixed. We need a new protocol.
X.400 ?
Suspect it might need to be dusted down and refreshed in light of experience both with X.400 implementations in the 1990's and with SMTP.
But given where we are in networking compared to 1990, perhaps the real problem is that it is time for the current IPv4 Internet to be replaced; just as it is time for copper to be replaced by fibre.
"By design you can set the from email address to be anything".
So to me, a complete ignoramus when it comes to email systems, all that intricate stuff is trivial compared to that simple fact; an email can arrive appearing to come from a spoofed address, which is commonplace.
And no one is able to fix that.
And no one is able to fix that.
Fixing it, as you put it, would break a lot of things. It's there by design, it's not a bug.
Removing the ability to spoof the from address would stop third party companies handling mail on someone else's behalf; a very common thing in business nowadays.
Removing the ability to spoof the from address would stop third party companies handling mail on someone else's behalf; a very common thing in business nowadays.
If that stops the practice of outsourcing marketing emails to spam houses that play fast and loose with all datasec and ITsec just to send me garbage that I didn't ask to be sent, then bring it on.
@Alister: "...third party companies handling mail on someone else's behalf; a very common thing in business nowadays."
It's been a very common thing in business since forever. The original use case was not about companies though - it was about a secretary or PA handling mail on behalf of her (ues, normally her) boss. That's also why there is a From and a Sender and a Reply-To.
it was about a secretary or PA handling mail on behalf of her
Interesting fact that may interest only me:
In centuries before the 20th, secretaries were almost almost always male. For many reasons - women were expected to work in the home and if they did work it was largely manual work. And secretaries (as the name suggests) were people privy to their employers secrets and the view was that only a man had the intestinal fortitude to cope with that..
All complete rubbish of course. But it was the case for a long, long time.
Really - no. You would just need a mechanism - something like DMARC - which can be interrogated to ask if a sending server is authorized to send messages for that sender - and obviously performing checks on both the SMTP MAIL FROM and what is inside the RFC (2)822 message, and ensure they match.
Nothing would forbid to allow more than one server.
SMTP was designed for very low bandwidth situations and slow links, but the situation is very different today, some more roundtrips won't kill the Internet.
You would just need a mechanism - something like DMARC - which can be interrogated to ask if a sending server is authorized to send messages for that sender
And what's to stop the server from just forging those permissions? After all, how can you prove that you are not a dog on the internet?
(The point I'm trying to make is that it's a little more complicated and identity validation is at the heart of it all..)
Really - no. You would just need a mechanism - something like DMARC - which can be interrogated to ask if a sending server is authorized to send messages for that sender - and obviously performing checks on both the SMTP MAIL FROM and what is inside the RFC (2)822 message, and ensure they match.
I've wondered something about that.
Lets say I send you a message from mike@welltec.edu.nz (using an actual email address) claiming to be that person and perhaps offering you a job position or any number of other things that could seem reasonable out-of-the-blue. What is there that checks any SPF information to see if the chain I've put in there is actually relevant to you, ie how can you check that I haven't spoofed the SPF or other such data, especially if you've never had anything in the chain before.
(not spent a lot of time looking at SPF yet)
an email can arrive appearing to come from a spoofed address, which is commonplace.
And no one is able to fix that.
Pretty much. The various bolt-ons put in place can mitigate some of the risk but, since they are not universally implemented, only some.
The SMTP protocol is broken, but worse than that, the means to have a fully-authenticated validated and unforgable identity does not exist. Until it does, protocols that rely on you being who you say that you are (like SMTP) will fail.
Of course, when that ability does exist, governments will use it as a tool of oppression.
I'm cheerful today eh?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
