Tag: SPF

Posted on
by

Interesting spam/phish technique: Look for subdomains with CNAMEs or SPF records that point to abandoned domains that you can then register…and effectively take control of the subdomain or SPF.

They haven’t seen any cases where it’s been used to host a phishing site at, say, an msn.com subdomain, but they’ve seen thousands of cases where it’s been used to pass email verification checks.

The article describing “SubdoMailing” gives a detailed example of a spam that made use of an msn.com subdomain that was used for a sweepstakes way back in in 2001, with a CNAME pointing to the long-abandoned domain name for the contest, but the subdomain was never actually deleted.

Lesson: check your DNS for any dangling references to outside domains that might not exist anymore!

Posted on
by

I recently noticed that the mail server was experiencing 4 times the typical number of SMTP connections. It didn’t seem to be under any stress, though, not as far as server load went. So I watched the log file trail, and saw a bunch of messages coming in to nonexistent users with the pattern, FirstnameLastname@alternativebrowseralliance.com.

My first thought was that someone was running a dictionary attack against the domain, trying many different addresses to see which might be valid. Then I noticed that they seemed to be coming from <> — in other words, they were bounce notices.

Great. A Joe Job.

I enabled a catch-all temporarily. That did cause the server to slow down, as it was now actually processing the quadruple load instead of kicking back 3/4 of it with a “User unknown” error. (I hadn’t thought to disable spam scanning on the domain first.) In the 30 seconds before I turned it off again, it picked up 25 non-delivery notices. And those are just the ones that got past the spam filter.

As it turned out, they were just random junk. Some spammer had picked the domain and was using it to forge random From: addresses, and we were getting the bounces. In the old days they made up the whole address, but it’s easy to check whether a domain exists. So now they pick some real domain and make up a fake address. That’s harder to detect unless the domain in question uses some sort of verification system like SPF or DKIM.

So it wasn’t a Joe Job: no one was trying to besmirch the site’s reputation. It still meant extra traffic to the mail server, though.

This problem is called backscatter, and it exists for two reasons:

  1. The sender address on an email message is easy to forge, like writing a fake address on an envelope.
  2. Many mail systems will accept a message first, then process it. If it then decides to reject it, it can’t respond to the actual sender, only to the one listed in the message—and in the case of spam, it’s usually forged (see #1).

I don’t send any mail using the domain. The only reason it even has mail pointed anywhere is so that I can receive mail sent to the webmaster for the Alternative Browser Alliance. I suppose I could set up a -all (no servers are authorized) SPF record, and hope some recipients decide not to send bounces. But I’m not sure how much it would actually accomplish.

Anyway, the two lessons to take away from this are:

  • Reject messages to bad recipients in the initial SMTP transaction. It’ll protect your server from backscatter (and dictionary attacks), because you won’t have to queue and process all the extra junk.
  • Don’t generate bounce messages after the fact based on something as easily forged as the supposed sender. Otherwise, you’ll be contributing to backscatter.

Posted on
by

A brief history:

  1. Spammers send mail directly to victims.
  2. Server admins block by source, victims complain and try to get spammers kicked off their networks.
  3. Spammers relay through third-party servers to disguise their origin.
  4. Server admins shut close relays, and block mail from open relays.
  5. Spammers relay through trojaned zombies straight to victims.
  6. Network admins block outgoing mail traffic except through their servers.
  7. Spammers relay through zombies’ ISPs’ mail servers.
  8. ????

We’re in the early stages of step 6, with broadband ISPs starting to block outgoing direct-to-MX mail traffic. The obvious response by spammers is, of course, Continue reading →