[conspire] Case study in modern forgery of SMTP headers, revisited

[Rick Moen]

Continues the same thing posted here in November 2015.

----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Mon, 8 Aug 2016 15:51:37 -0700
From: Rick Moen <rick at linuxmafia.com>
To: Michael Siladi [address at netcom.com]
Subject: Re: More spam from Michael -- Spoofing?
Organization: If you lived here, you'd be $HOME already.

Quoting Michael Siladi:

> Rick:
> 
> Looks like I got spoofed again. Several hundred email sent from
> "From: parties14 [RM: Michael's real address, here]".

Yes, and the targets were all Mailman *-owner aliases, which can always
be expected to get a great deal of spam.

And yes, of course it's spoofing.

The injection point to Bluehost's servers was IP address 193.9.21.100,
which identified itself to Bluehost as 'newhope.afektnet.net' -- and
indeed that is the reverse DNS for that IP address.  That IP netblock
(93.9.21.0 - 193.9.21.255) is allocated to 'Optimus IT d.o.o.', of
Ljubljana, Slovenia.  The published 'abuse' contact for Optimus IT is
abuse at optimus.si .

There are manipulable companies with SMTP presence on the Internet all
over the world.  This just happens to be one of them being abused, I
would guess as part of a big organised effort by a crime group.


> I find it interesting that the target malware URL is different in
> the two messages.

{shrug}  It's probably like an advertising company.  They serve multiple
clients.


> What's your take on this?

There are two halves to addressing the problem of mail forgery.  One is
that legitimate senders (i.e., their ISPs) need to provide information
in mails and in the DNS sufficient to permit receiving SMTP servers to
authenticate received mail.  A couple of competing protocols for
authentication exist.  One is a Yahoo-originated family of protocols:
DomainKeys, DKIM (DomainKeys Identified Mail), DMARC (Domain-based
Message Authentication, Reporting and Conformance)

https://en.wikipedia.org/wiki/DomainKeys  (now deprecated)
https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail:  authenticates
   mail contents, but not the sending domain
https://en.wikipedia.org/wiki/DMARC:  authenticates both mail contents
   and sending domain.

All of those are rather byzantine, and DMARC is by a country mile the
most byzantine of the lot.  DMARC also poses huge problems for mailing
lists, which it causes to appear to be forged senders.  To my annoyance
and dismay, several large firms have lately been attempting to
strong-arm the rest of the world into using DMARC.  (Long story.)

The other protocol is SPF (Sender Policy Framework).  My domains
linuxmafia.com and unixmercenary.net publish clear, categorical SPF
records in their DNS stating that if the mail doesn't come from my IP,
then it's not genuine.  SPF authenticates the sending domain, but not
the contents.  (I.e., there's no crypto hash checkable to verify that 
contents haven't been altered en-route.)

As a domain owner/operator, I found that SPF ideally satisfied my
use-case:  I care about the reputation of my domain.  From my
perspective, if mail senders want to ensure that their mail can be
verified to not have been altered en-route, they can bloody well
PGP-sign their mail, and it's really not my problem.


Here is a guide for the layman (omits DomainKeys as deprecated):
http://blog.endpoint.com/2014/04/spf-dkim-and-dmarc-brief-explanation.html


The other half of addressing mail forgery is that receiving SMTP servers
must vet arriving mail against the claimed sender domain's published
authentication information.


We went through this subject before back in November 2015, according to
my records, when you worked through six different Earthlink support 
people during two telephone calls without getting any meaningful
information let alone help.  At that time (my mail to you of Fri, 6 Nov
2015 18:33:58), I determined that Netcom publishes (obsolete,
deprecated) DomainKeys data, e.g., this bit from one of your mail's
headers:

DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=dk20050327; d=ix.netcom.com;
b=oLbGKWWw3ykemWcqQifzUoMnhSTQGr+dFk+wHLhLhqNS99UmamopQ9GZQSO1Xv5;
h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;


In a better world, BlueHost would check DomainKeys headers and the
corresponding records in DNS, to vet all incoming mail.  Evidently,
BlueHost does not do so.

Netcom does not publish SPF records.  

The standards picture is a bit of a horror show.




If you have any question, please follow up and ask, because if it's not
covered by the above, I'm not sure what you're curious about.


----- End forwarded message -----