Apologies if this is covered elsewhere and thanks in advance. After posting this, I’m getting offline for the night, so won’t be able to reply till the morning.
I sent an email to a friend from my Hotmail account (web client). He replied. The visible header info in his reply was like this:
From: my friend [my friend’s email @mac.com]
To: my name [(not my email address @comcast.net)]
My friend saw the unfamiliar email address in my original message to him, but just assumed I’d gotten a new one. Neither one of us has ever heard of it.
The header info in my original sent email appears, to me, as it should appear, with my true email address.
Any ideas what’s going on? Is it possible this is my friend’s problem and not mine? (Hoping, but only faintly, with a slow sinking feeling.)
SMTP is not secure, not sure what is going on there but unless you resort to external cryptographic signed messages the TO and FROM are easily spoof-able.
There are very very limited controls related to IP addresses and a dated concept called “privileged ports” which do help a tiny bit but all it takes is one open relay to spoof.
But there are dozens of layers where this could happen.
The important take away is that SMTP is in no way secure, and no matter how it happened that should be the primary takeaway.
I use to test SMTP servers and entered “FROM: billg@microsoft.com” with a simple telnet client out of habit until I had a bounce go out. I am sure that they just dumped my bounce but this protocol is insecure, and most efforts have been targeted at reducing spam and not improving security.
Note, even if your ISP encrypts your “mail user agent” session, the intra-provider communication is almost universally in plain text and the only encryption, which still does not prevent this spoofing just makes the contents harder to read. Note that this is optional and opportunistic.
I work email and security for a living, and I’ve never seen this particular situation before. It’s a weird problem, and I’m off for a few days, so I’m intrigued.
What you see in this area of the email client is controlled by the From: header. Specifically the “friendly name” portion of this header. It’s possible that the one in this message is constructed like this:
There could be even more addresses in the header, since that is valid. But I’m just guessing at this point, and there’s no substitute for actually seeing the headers. I’m not sure how to pull the headers out of Hotmail’s email client, if you can send them to me in a PM, I’ll let you know what I can see. Or, PM me for an email address for you to send a message to, and I’ll let you know what I get in the initial message headers. In fact, I’d prefer the latter, since we’ll be isolating one part of the chain, and I know how to get the headers from the client I use.
rat avatar, I don’t mean to gainsay you, but if the connection to your SMTP servers are TLS encrypted, and your connections to their MX servers are encrypted, the SMTP session is encrypted as far as transit is concerned, and preferring/allowing TLS is pretty common among large providers now. The From: header (and the rest of the headers) are encrypted in these cases, and only the EHLO exchange is done in plain text. That does effectively stop a third party from modifying a message in transit (both endpoints can do all kinds of stuff, though). It’s far more common for this kind of forging to be done by a phisher/spammer with a message they’re sending themselves - that’s why this seems like an interesting problem.
Thanks for the replies. scabpicker, I PM’d you just now.
It does seem like an unusual problem. What I have seen, and not been too surprised by, is a mass mailing goes out apparently from my actual email address to people I know, and it’s obvious spam selling Viagra or whatever. The recipients are not fooled, and after I change my password, I am not too worried. The thing about that is, it makes sense. They want to sell something, and they spoof my email address to get people who trust me to read their sales pitch.
This situation I’m having right now, though, why would anyone do that, what are they gaining by it?
I doubt there’s anything malicious going on here. Some email clients allow you to set your From address; perhaps the OP accidentally set his From address to something else? The fact that the reply email actually reached him indicates that the Reply-To and/or Return-Path in his original email is correct. I agree, it would be very interesting to see the email headers, not only in the reply email that the OP received, but also the original email that his friend received from him.
I agree that there’s probably nothing malicious going on. Mostly because, yeah, I don’t see any point or profit in it at the moment. If one of the earlier incidents where people were apparently receiving spam from masonite’s email address was from their account actually being compromised, maybe the From: address was changed in their Hotmail settings by a bug in the bot that compromised the account? Weird corruption in the replier’s address book? I dunno, I’m still just speculating at this point.
This is 100% opportunistic encryption, and in fact the RFC currently requires that this must allow for fallback to non-encrypted connections. This plus a lack of certificate verification means it is open to trivial man in the middle attacks.
Opportunistic encryption will deter only passive attackers. Most email transferred between MTAs is transmitted in the clear and trivially interceptable. Yes encryption of SMTP traffic is possible using the STARTTLS mechanism but is vulnerable to trivial downgrade attacks and suffers from a lack of adoption of DNSEC/DANE or other methods that would change this.
While my dig options may be wrong, I am not seeing DNS entries for several major providers like hotmail.com right now, and the MUST NOT in the above RFC will need to change and SECDNS/DANE will need to be adopted before this very large attack vector is reduced.
If you do work in security I would highly encourage you to look into the MTA behavior, and there have been a few large cases in the past and simply deleting the “250 STARTTLS” line
SMTP is insecure as email contents are not guaranteed to be end-to-end encrypted during transit. And even if they are encrypted, without some method of verifying the certificate is valid through DNSSEC a simple self signed cert would allow an attacker to still launch a MiM attack, especially seeing as DNS cache poisoning or route hijacking is the main way that government actors have been performing this attack recently.
As a consumer has no ability to ensure that this opportunistic encryption and verification takes place between providers, even if DANE/DNSSEC is finally adopted, it is important that individuals do not assume that SMTP traffic is trustworthy.
Notice, I specified the endpoints. RFC or not, I’ve seen plenty of places that require TLS for delivery to start. I’ve also seen mail servers that don’t require a HELO/EHLO exchange, and others that will promptly close the connection without it. Loony mail servers abound out there.
Yep, and even none of that prevents your email provider from reading the info while they handle it, or at rest. PGP could possibly cure that, and adoption of that is still glacial. Mail providers adopt stuff slowly, in practice. Hell, most of my customers don’t want to change a log level for debugging purposes, much less adopt a new technology that might break or slow down mail delivery.
For the purposes of this problem, I think we can ignore this for the time being. I don’t think this is the action of a nation state or anyone who’s using DNS cache poisoning.
To be clear, IMHO the best option is to be skeptical of any email, and expect anything you email to be publicly available.
I am running into a bit of a restriction on disclosure here, but this attack vector is utilized more than most people know. But to try and provide hints, non-transnational email services tend to be provided by particular vendors who actually pay the large vendors I mentioned above for not being dropped, and this dramatically impacts the ability to use tools like SPF records to help mitigate this issue.
Several of the providers that provide this type of service have very lax protections and also allow easy access, and I have personally seen this leveraged to (anonymized a bit) impersonate internal email addresses for socially engineering, or to abuse email based password resets. This was in an industry that is pretty bad about disclosure, and is not just related to bulk email services but also some providers that provide SaaS sales, customer service, marketing solutions.
To be 100% honest, the income from white-lists for the large mail providers is significant enough that I doubt that this will change. If you work in the field, and have dealt with these same requests for payment even with customer directed transactional emails I am sure you are quite aware as it is often a yearly email to explain why you shouldn’t be paying to be on their whitelist.
The only reason I responded is that people tend to place way too much confidence in many services like SMTP which should be distrusted by default.
Oh, you’ll get no argument from me here. Using every protection possible, it’s rare that you should be confident that what you write can’t be read by someone else. No matter what protocol they’re being shipped over, there’s been a fairly recent known method of breaking it.
If you’re saying you see a lot of instances where the content of email is changed by a malicious actor in transit, I can’t corroborate seeing that. I’m not denying it happens, I know I’ve read articles about them, but I’ve never been called in on an incident like that.
On the other hand, if you mean that you’ve seen forged From: (and other) headers to get the receiving mail server and/or the recipient to trust the message: oh yeah. I’ve seen that on the side of the (usually compromised) server running the script making/sending the messages - and I’ve worked on the email gateway that’s trying to stop it. It’s a pretty bad problem, and I’ve seen enough messages get by the best detection system for it. The worst are ones that break the RFC to do it, and you’re left with the choice of either writing a decent AI or doing something nasty to every message that violates the RFC. I’m not confident either will necessarily be a viable option.
I appreciate the info you are giving here and above, but of course don’t understand it at all myself. That’s OK. I would ask you, though, do you think using web-based Hotmail is just foolishness and I need to cut it out immediately?
Yes. Since the field you quoted is only decorative (It’s at the top of the letter he sent you, not on the outside of the envelope), mail clients can and do re-write it to be helpful, informative, and polite. That’s not always as helpful, informative and polite as you would hope…
Since it appears that his mail client has associated your name with a different mail address, he may have trouble sending mail to you (he may have multiple entries associated with the same name)…
The /reason/ his mail client has made this mistake may be that you are sending out bad information. If that is true, some people will have trouble sending/replying to you, and other people won’t. Most people are never given “the envelope” to look at, and can only go on what’s at the top of the letter. If you have conflicting information there, some mail clients will guess correct, and some will guess wrong.
It is, as mentioned above, also possible that someone in the middle is messing with your mail. That is much less likely. At present, the number of people who have virus infections spoofing the hotmail site, or rewriting mail from hotmail, is much, much, much smaller than the number of people with mis-configured mail clients.