back to article 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 …

Silver badge

More depressingly...

... it's 2017 and "non-ASCII Text" is somehow still considered the exception.

33
0
Silver badge

Re: More depressingly...

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 :(

31
0
Silver badge

Re: More depressingly...

Worse still there's an increasing number of companies whose outgoing mail doesn't include any text.

Presumably that's (mostly) large companies sending out marketing garbage as hosted content or images. Surely that's no loss to you?

21
0
Silver badge

Re: More depressingly...

"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.

9
3
Silver badge
Thumb Up

Re: More depressingly...

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.

4
0
Silver badge

Re: More depressingly...

>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.

1
7
Silver badge
WTF?

Re: More depressingly...

That some mail client makers consider it a "server issue". WTF does that mean? Both sides of any network communication should be vetting everything as much as possible. All of the time. Regardless of the application.

12
1
Silver badge
Pint

Re: More depressingly...

Scratched my head about the down votes, then realised AndrueC was referring to Messagebody text and not Displayname text.

2
0

Re: More depressingly...

"Presumably that's (mostly) large companies sending out marketing garbage as hosted content or images. Surely that's no loss to you?"

Or maybe just a lazy way to workaround potential font/code page/rendering engine issues?

1
0
Silver badge

Re: More depressingly...

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

...

4
0
Silver badge

Elephant in room

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.

9
4
Silver badge

Re: Elephant in room

Email should have had mutual whitelisting since the start.

And how would that work exactly?

8
2
Anonymous Coward

Re: Elephant in room

"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.

20
0
Silver badge

Re: By design you can set the from email address to be anything

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.

11
0
Silver badge

Re: how would that work exactly?

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.

2
0
Silver badge

Re: how would that work exactly?

""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.

3
2
Silver badge

Re: how would that work exactly?

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?

1
0

Re: how would that work exactly?

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.

0
0
Silver badge

Re: how would that work exactly?

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?

0
0
Bronze badge

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.

30
1
Anonymous Coward

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?

2
2
Silver badge

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.

2
2

> 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.

2
0
Silver badge

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..)

2
0
Silver badge

...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.

0
1
Silver badge

I describe a real-world situation where using SPF strict mode will cause you to lose mail, and get voted down for it with no explaination.

Ah well, your loss!

1
0
Silver badge
Unhappy

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.

12
1
Silver badge

"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?

7
0
Silver badge
Meh

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 :-/

6
1

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.

1
5
Silver badge

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.

1
0
Silver badge

>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.

0
1
Anonymous Coward

So that email I got from crownprinceofnigeria@royalpalacenigeria.com might be fake? I sent with my bank details to the other address as instructed and I'm still waiting for the money.

9
1
Silver badge

Send me your bank details and I'd be happy to check if they did reach your friends in Nigeria.

4
0
Anonymous Coward

Shall I post them here? is it safe?

1
0

You can also send your El Reg password too. It is totally safe. Mine is *********.

2
0
Bronze badge

You can also send your El Reg password too. It is totally safe. Mine is *********.

Still using hunter1 as password?

1
0
Silver badge

I dunno

"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.

10
1
Silver badge

Re: I dunno

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.

7
4
Anonymous Coward

Re: I dunno

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.

16
2
Silver badge

Re: I dunno

"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."

And that is more important than stopping the mechanism for all sorts of common, serious criminal behaviour?

8
2
Silver badge

Re: I dunno

It's analogous to writing your address on a (snail mail) envelope before you pop it in the letter box for the post office. That is trivial to spoof and impossible to enforce.

6
0

Re: I dunno

@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.

4
0
Anonymous Coward

"Removing the ability to spoof the from address would stop third party"...

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.

1
0
Silver badge

Re: I dunno

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?

0
0
Silver badge

Re: I dunno

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.

1
0
Silver badge

Re: "Removing the ability to spoof the from address would stop third party"...

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..)

1
1
Silver badge

Re: I dunno

Precisely, Dr Syntax

It's an argument akin to saying that not installing locks on your door makes it easier for the ParcelForce/Amazon/etc deliveries.

1
0
Silver badge

Re: I dunno

Many folks in this thread keep saying "the SMTP protocol is broken" or similar ... I respectfully submit that this is incorrect. In actual fact, SMTP does exactly what it was designed to do. No more, no less. It''s not SMTP that is broken, rather it is the expectation of the user that is broken.

One doesn't use a ceramic tea pot as a hammer, now does one?

4
0
Silver badge

Re: "Removing the ability to spoof the from address would stop third party"...

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)

0
0

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Forums

Biting the hand that feeds IT © 1998–2017