You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2017/02/02 11:00:39 UTC
[Bug 7388] New: Invalid Content-Type and/or Transfer Encodings can
be used to bypass SA while some MUAs will show the message
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7388
Bug ID: 7388
Summary: Invalid Content-Type and/or Transfer Encodings can be
used to bypass SA while some MUAs will show the
message
Product: Spamassassin
Version: 3.4 SVN branch
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P2
Component: Rules
Assignee: dev@spamassassin.apache.org
Reporter: kmcgrail@pccc.com
Target Milestone: Undefined
Pedro David Marco on the users list has pointed out an in the wild phishing
campaign that uses bad Content-Type and Content-Transfer-Encoding that bypasses
SA's engine.
Fix #1 is something like:
#Bad UTF-8 content type and transfer encoding - Thanks to Pedro David Marco for
alerting to issue
header __KAM_BAD_UTF8_1 Content-Type =~ /text\/html;
charset=\"utf-8\"/i
header __KAM_BAD_UTF8_2 Content-Transfer-Encoding =~ /base64/i
meta KAM_BAD_UTF8 (__KAM_BAD_UTF8_1 + __KAM_BAD_UTF8_2 >= 2)
score KAM_BAD_UTF8 4.0
describe KAM_BAD_UTF8 Bad Content Type and Transfer Encoding that attempts to
evade SA scanning
It is unknown at this time if this is only a sign of spam but preliminary
checks look good.
Fix #2 is to identify if there are more variants that can evade the engine,
create more rules as well as change the engine not to have this issue. That
work is pending a spample.
Fix #3 is the MUA's (Outlook and Thunderbird) should likely not show the
content of the message but they are likely just being flexible in the world of
non-rfc compliant content so hard to complain.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7388] Invalid Content-Type and/or Transfer Encodings can be
used to bypass SA while some MUAs will show the message
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7388
Frank Urban <fr...@commerzbank.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |frank.urban@commerzbank.com
--- Comment #3 from Frank Urban <fr...@commerzbank.com> ---
I just run into the same problem here.
I was asked to see if we can find a way if we are receiving emails with
"basestriker" links included.
<html><head><meta http-equiv="Content-Type" content="text/html;
charset=utf-8"></Head><body text="#000000" bgcolor="#FFFFFF"><p><base
href="https://xxxxx.xxx">Split the URL, the <a
href="world/xxxxxx/xxxxxx.html">link </A>gets through. </P></Body></Html>
So I wrote a little rule
body COBA_BASESTRIKER /base href=.http/i
describe COBA_BASESTRIKER baseStriker Link
score COBA_BASESTRIKER 0.1
but this rule doesn't hit my example email.
Now I saw that the header of this example email
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64
I include now the KAM_BAD_UTF8 into my system but I got hits every minute and
not all is SPAM
I'm not sure if this Bug is more important today than one year ago....
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7388] Invalid Content-Type and/or Transfer Encodings can be
used to bypass SA while some MUAs will show the message
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7388
--- Comment #5 from Frank Urban <fr...@commerzbank.com> ---
My rule works in general but it seemed it does not work if we have such a
header
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64
So my idea was that SpamAssassin is not able to scan the body and I found this
Bug here.
But the body in my example is base64 encoded. So it look like that I have
another problem
And this will not work
body COBA_BASESTRIKER /base\ href=\.http/i
because I want to get a hit for
base href="http
.. but this is another thing not relevant in this Bug here
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7388] Invalid Content-Type and/or Transfer Encodings can be
used to bypass SA while some MUAs will show the message
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7388
Benny Pedersen <me...@junc.eu> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |me@junc.eu
--- Comment #4 from Benny Pedersen <me...@junc.eu> ---
try:
body COBA_BASESTRIKER /base\ href=\.http/i
untested but should work
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7388] Invalid Content-Type and/or Transfer Encodings can be
used to bypass SA while some MUAs will show the message
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7388
Kevin A. McGrail <km...@pccc.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kmcgrail@pccc.com
--- Comment #2 from Kevin A. McGrail <km...@pccc.com> ---
(In reply to Philip Prindeville from comment #1)
> I should probably know this by heart, but I don't... what is non-conformant
> about what they're sending? A quick eyeballing says it looks good, but I'm
> not comparing it to the MIME RFC syntax rules.
The actual text isn't base64 encoded.
So the engine is "decoding" plain text at which point it evades some parta of
the engine.
In reality, the example scored something like 17 points from other tests anyway
so I don't consider this too critical. And RW helped with a rule to detect
things better. See KAM.cf for a good test rule.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7388] Invalid Content-Type and/or Transfer Encodings can be
used to bypass SA while some MUAs will show the message
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7388
Philip Prindeville <ph...@redfish-solutions.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |philipp@redfish-solutions.c
| |om
--- Comment #1 from Philip Prindeville <ph...@redfish-solutions.com> ---
(In reply to Kevin A. McGrail from comment #0)
> Pedro David Marco on the users list has pointed out an in the wild phishing
> campaign that uses bad Content-Type and Content-Transfer-Encoding that
> bypasses SA's engine.
I should probably know this by heart, but I don't... what is non-conformant
about what they're sending? A quick eyeballing says it looks good, but I'm not
comparing it to the MIME RFC syntax rules.
--
You are receiving this mail because:
You are the assignee for the bug.