On 2023-09-14 at 11:01:37 UTC-0400 (Thu, 14 Sep 2023 15:01:37 +0000
(UTC))
Pedro David Marco via users <pedrod_ma...@yahoo.com>
is rumored to have said:
The same happens with other HTML tags...
<img src= can be replaced with <img xyz/src=
virtually any char but >
so, with Giovanni permission, i tighten the nut 1 more turn
(limiting to 100 chars to prevent Regex Self-DOS)
rawbody BADHREF /<(a|img|video)[^>]{0,100}\/(src|href)\=/
Pete.
I've tweaked this a bit and added it to my ruleQA sandbox:
describe HTML_BADATTR Illegal char in HTML attribute name
rawbody HTML_BADATTR /<[a-z]{1,10}[^>]{1,80}\/(src|href)\=/
score HTML_BADATTR 1
tflags HTML_BADATTR publish
On Thursday, September 14, 2023 at 04:37:15 PM GMT+2,
<giova...@paclan.it> wrote:
On 9/14/23 16:24, Bill Cole wrote:
On 2023-09-14 at 04:37:03 UTC-0400 (Thu, 14 Sep 2023 17:37:03 +0900)
Joe Wein via users <joew...@surbl.org>
is rumored to have said:
I filed a bug for this issue on Bugzilla (#8186) but so far no
response from developers.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8186
FWIW, I've thought about it a bit...
We're seeing literally millions of phishing spams from Tencent VMs
in Singapore targeting mostly Amazon Japan that are getting around
SA checks because of this issue.
Wow. I didn't expect that this was that big of a tactic.
I am wondering how many other users are seeing this problem which
allows spammers to circumvent URI checks in links in spam (i.e. hide
the payload sites).
I don't see it, but the systems I manage have no reason to expect
anything but criminal-grade spam from anything on a Tencent network
in Singapore. Everyone gets their own bespoke spamstream I guess.
They do it by prefixing the href= attribute in an HTML <a
href="..."> tag with letters and a slash, for example:
<a h/href="https://some.phishing.site:>https://amazon.co.jp</a>
Both Chrome and mail clients like Mozilla Thunderbird discard that
"h/" prefix (perhaps treating it as a separate unrecognizable
attribute, like "<a h href="...") and display a clickable link to
the payload site while SpamAssassin will not see the URI and
therefore not it through any of the rules for URIs.
This means even if the bad site is listed on domain RBLs (SURBL,
Spamhaus or URIBL), the mail is not tagged for that.
Joe Wein
SURBL
I'm thinking that the best approach may not be in trying to parse the
bogus tag to glean a domain that may or may not be known to be bad,
but rather to detect the general pattern, which is itself a direct
indicator of bad intent.
rawbody BADHREF /\s+.\/href\=/
should be a start to write a rule to catch those spam messages.
Giovanni
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
