Bug 6577 - IPv6 encapsulated IPv4 sender not detected correctly
Summary: IPv6 encapsulated IPv4 sender not detected correctly
Status: RESOLVED WORKSFORME
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Plugins (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: All All
: P2 major
Target Milestone: 3.4.0
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-25 21:17 UTC by Jeff Chan
Modified: 2011-05-04 16:55 UTC (History)
5 users (show)



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Chan 2011-04-25 21:17:29 UTC
Got a 419 scam spam with an IPv6 encapsulated IPv4 address that was not detected correctly:

Received: from userPC ([::ffff:82.128.107.32])
 (AUTH: LOGIN zzzz@yyyyy.com, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
 by mail.xxxxxxx.com with ESMTPSA; Mon, 25 Apr 2011 16:nn:00 -0500
 id 0000000000aaaaa.00000000bbbbb.00000ccccc

"I believe that this is a new method to obfuscate an IPv4 address from harvesters and DNSbl's by hiding it in a IPv4 over IPv6 tunnel address so that it doesn't get processed." says a friend.

I might call this v4 obfuscation via v6.
Comment 1 Jeff Chan 2011-04-25 23:25:32 UTC
Forgot to add that this may not be a special case of https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6519 in that it's really a v4 address.  A bit kludgey, but perhaps the v4-specific prefix ::ffff: could force treatment of the lower 4 octets of a v6 space as v4.  This bit of obfuscation may or may not warrant such a kludge.  As a practical matter, it would probably be undesirable to miss a clearly v4 address encapsulated in this way.
Comment 2 Darxus 2011-04-26 01:48:06 UTC
That is the entirely valid way to encapsulate an IPv4 address in an IPv6 address: 
http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#Stateless_IP.2FICMP_Translation_.28SIIT.29
Although it wouldn't be the first time spammers took advantage of something entirely valid but poorly supported.  

I agree that it would work well for SA to just handle (blacklist lookups of) such addresses as IPv4 addresses.  Although it would need to handle all the possible abbreviations, from the mentioned ::ffff:82.128.107.32 to the long form 0000:0000:0000:0000:0000:ffff:82.128.107.32

The v4 form of this address is listed by spamhaus and several others.
Comment 3 Darxus 2011-04-26 01:56:21 UTC
Did you actually verify this isn't working with trunk?
Comment 4 Jeff Chan 2011-04-26 02:09:31 UTC
Did not verify whether it works or not.  Was a user report.
Comment 5 D. Stussy 2011-04-26 03:41:18 UTC
This ("::/80" - to accomodate both original forms "::/96" and "::FFFF:0:0/80") and 2002::/16 both have known IPv4 mappings.  A fix to extract the appropriate bits for an IPv4 address to check would require a programming fix, assuming that it's not already handled.  Scanning the text format of the address would not be efficient.  Comparing the converted 128-bit address would be better.


I also note that the sample "Received:" header does not follow the required RFC 5321 ABNF syntax and is thus invalid.  [The "id" clause is in the wrong place.  It should be before the datestamp.]
Comment 6 D. Stussy 2011-04-26 03:43:23 UTC
oops - prior post should have had "::FFFF:0:0/96".
Comment 7 Darxus 2011-04-26 12:17:24 UTC
This is working in trunk, somebody with sufficient access please close it.

I forged a received header with this IPv6 encapsulated IPv4 address:

Received: from mail.apache.org (hermes.apache.org [::ffff:82.128.107.32])
  by panic.chaosreigns.com (Postfix) with SMTP id 3710CAC792
  for <darxus@chaosreigns.com>; Mon, 25 Apr 2011 21:17:54 -0400 (EDT)

Ran it through spamassassin, and got:

 3.6 RCVD_IN_PBL            RBL: Received via a relay in Spamhaus PBL
                            [82.128.107.32 listed in zen.spamhaus.org]

Note the unencapsulated IPv4 address in the report (and I know IPv6 addresses show up differently).  So the magic is already there, in trunk, somewhere.


So we just need Jeff to use valid headers (running Exim?), and a new SA release.
Comment 8 Darxus 2011-04-26 12:37:33 UTC
Jeff, I ran your exact header through SA trunk in debug mode:

Apr 26 12:31:30.134 [25889] dbg: received-header: parsed as [ ip=82.128.107.32 rdns= helo=userPC by=mail.xxxxxxx.com ident= envfrom= intl=0 id=0000000000aaaaa.00000000bbbbb.00000ccccc auth=LOGIN msa=0 ]
Apr 26 12:31:30.134 [25889] dbg: received-header: relay 82.128.107.32 trusted? yes internal? yes msa? no

It's parsing it just fine, but it's noticing that the user is authenticated / logged in, because of the "AUTH: LOGIN" stuff, so it's considering that header / IP internal and skipping it.

So was this a legitimate logged in user, for whom blacklists were appropriately skipped?  Or do you have a spammer managing to log in to your server?
Comment 9 Tom S 2011-04-26 20:28:43 UTC
Actually, I provided this sample to Jeff.  

I don't use SA so I can't comment upon detection but it was the first time I saw IPv6 being used to obfuscate a IPv4 address from and active spam out in the wild and I wanted to make sure that everyone including our friends at SA had a copy of the sample.

As for the question, I was on the receiving side so I can't be sure but it looks like a user's account at mail.xxxxxxx.com (a foreign mailserver that has been informed of this situation) had its password sniffed and that 82.128.107.32 was using the hijacked user/password to access the mailserver using AUTH: LOGIN zzzz@yyyyy.com, TLS: TLSv1/SSLv3,256bits,AES256-SHA to send 419 spam.

The reason to identify this is that IPv6 blacklists are not available and will not be unless we all agree to list /64's and the IPv4 IP would have been detected in current IPv4 lists.

Since SA appears to detect the IPv4 encapsulated in IPv6 per the thread above, I would have to say that the case is closed.  However, one might question the logic to completely exonerate a header when hijacking user logins is so pervasive.

Tom
Comment 10 Karsten Bräckelmann 2011-04-26 23:41:19 UTC
Closing RESOLVED WORKSFORME (a fancy name for not-a-bug) as per comment 7 and comment 9. Thanks Darxus for the investigation, and thanks Jeff and Tom for providing the sample and bringing this to our attention. Please feel free to re-open this bug, if you ever can reproduce it, or if the issue persists.


(In reply to comment #9)
> Since SA appears to detect the IPv4 encapsulated in IPv6 per the thread above,
> I would have to say that the case is closed.  However, one might question the
> logic to completely exonerate a header when hijacking user logins is so
> pervasive.

Which I believe is in response to

(In reply to comment #8)
> It's parsing it just fine, but it's noticing that the user is authenticated /
> logged in, because of the "AUTH: LOGIN" stuff, so it's considering that header
> / IP internal and skipping it.

SA does not blindly trust Received headers with auth, but only those that are directly extending your trusted network. It will not consider it, if it has been added in an untrusted part of the trail. Thus, I assume this to be a red herring and a debugging artifact.
Comment 11 D. Stussy 2011-04-27 15:53:28 UTC
RE: Comment #7.  It may very well be working in "the trunk," but what good does that do us if that's NOT pushed out into a release version (such as 3.3.2)?

Ever since the release of Perl 5.12.0, we've needed 3.3.1 to be updated, yet more than a year later, 3.3.2 has NOT been released?

What exactly is the problem?
Comment 12 Greg Troxel 2011-04-28 10:24:21 UTC
From the header, I don't think it's accurate to characterize the header as obfuscated.  It appears to be the address as recorded by mail.xxxx.com, not something provided by the previous hop.  The basic issue is that there are two ways to deal with IPv6.  One is to have user programs open both v4 and v6 sockets, and the other is to use these mapped addresses so that a listening v6 socket will also get connections that come from v4.   So SA should be treating this address exactly as if it were just the v4 address, and it seems that is indeed what is happening.  So I concur with the resolution, but I don't think calling this "obfuscated" is accurate.

It is odd that the octets in the encapsulated v4 address are in decimal.