Email Spoofing by SMTP Message-ID?

Question

Many of my users today got email from docs#@mydomain.com (where docs# was between docs0 and docs8 or so, and mydomain.com is obviously changed from my real domain name), with the sender name of "Administrator." The message had subject "New Voice message" and message: "You have received a voice mail message. Message length is 00:06:11." It was sent to many different users and distribution groups, a weird mix of different departments that wouldn't normally make sense (email to our customer service group, plus our CFO, plus a random IT member? Weird). There was an attachment: ATT00001..txt, a text file.

Some research online shows this to be a virus attempt possibly from CryptoLocker (yikes!!!), and the remaining text file is what was left after being stripped upon arrival, either by our spam filtering service (I don't think so, based on logs), our SonicWALL gateway (I believe it's this that saved us), or a virus scanner built in to Outlook (nope, Webmail shows the same attachment). We use Postini for our spam filtering service, so our MX records direct all email there and our squid proxy server only accepts mail from Postini, does some filtering, and passes it on to our Exchange server.

Based on the email header, I've figured out this route that the email has allegedly taken (Domain and our public IP have been changed):

docs9718.mydomain.com (10.139.106.94) --> smtp.mydomain.com (10.0.0.18)

docs844.mydomain.com (10.0.0.18) --> mydomain.com (10.0.0.147)

ABTS-KK-dynamic-175.185.172.122.airtelbroadband.in ([122.172.185.175]) --> exprod5mx283.postini.com ([64.18.4.10])

psmtp.com (exprod5mx283.postini.com [64.18.0.107]) --> proxy2.mydomain.com

proxy2.mydomain.com ([127.0.0.1]) --> localhost (proxy2.mydomain.com [127.0.0.1])

localhost (localhost.localdomain [127.0.0.1]) --> proxy2.mydomain.com

proxy2.mydomain.com (12.7.13.46) --> proteus.mydomain.com (192.168.200.3)

Postini was allowing these messages through, even though there were a couple of strange things about them. For example, the SMTP Message-ID is a unique string that is set by the first message server that handles the message, and is normally not messed with by any subsequent servers. Yet this email's Message-ID was [email protected] instead of, for example if I got something from Dell, it would say S[email protected]. It has my domain in its Message-ID.

But that's when I realized, the first servers to handle the message DID have my domain name! That's how the SMTP Message-ID was spoofed, I presume. In fact, that residential address in India (ABTS-KK-dynamic...) is probably a home user with a virus, and that virus made up the first few addresses.

The problem there is those 10.x.x.x addresses are not only in the private ARPA IP range, but they obviously don't really correspond to our domain (altered, but in this example my "real" IP is 12.7.13.46). Another issue is that there is a gap between the fake mydomain.com and the Indian computer.

How do our mail servers not account for a major gap in the headers? And does it not verify anything about the originating server, just takes its word for it? Because not only is it not a valid IP, it doesn't match DNS records for that domain it says, plus the originating domain is the same as the destination domain! That wouldn't normally make sense, as that mail would be internal.

Also, am I right about this SMTP Message-ID spoofing technique? I can't find anything like it online. But the tactic makes sense - If I say it came from some bogus mydomain.com servers and the middle servers never verify that, the final server will believe it really came from my domain. Simple MAIL FROM: spoofing on an open relay won't work on our server, but something like this apparently can. I'm just not sure if that's what's being done here.

Here's the entire faked headers file (renamed public IP, domain, and To: email addresses only): Pastebin link

Answer 1

Everything about an email message can be forged, or can be tampered with in transit. The only headers you can trust are those put there by your server; the only content you can trust is that protected by a verified digital signature. In the case of your pastebin file, if I'm understanding your description of your network setup correctly, lines 1 through 22 are trustworthy, lines 23 through 25 are probably trustworthy, and everything from line 26 on down is forged.

Email servers don't account for gaps in the headers because they don't need to. Most email servers are designed on the Unix philosophy: do one thing, do it well, and provide a standard way to interface with other programs. An email server's job is to move email from Point A to Point B; things like checking for gaps in the headers is the job of a spam filter.

Answer 2

Message ID header cannot be validated as there is nothing it needs to conform to. The message ID is used simply as a unique identifier for a message. If a message is resent without any changes, then the message ID should remain the same so clients know that its the same message. A typical Message ID follows a scheme whereby it will be a few md5s (often of the message body) concatinated followed by the hostname of the mailserver - or something similar. This briefly allows the messageID to convey where the message came from and what the message-body contains... but this is not required at all and is just one of those 'people do it this way' things. '1234567890abcdefghijklmnopqrstuvwxyz' is also a valid Message ID. So no, contrary to the other answers here i'm going to say that Message ID's CANNOT be spoofed, because there is no benefit to modifying anything in the message ID, beyond confusing sysadmins and poor anti-spam filters.