Mailing List Archive: Stealth HREF= (missed by SA)

Stealth HREF= (missed by SA)

Sep 14, 2023, 1:37 AM

Post #1 of 9 (406 views)

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

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.

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).

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

Re: Stealth HREF= (missed by SA) [ In reply to ]

me at junc

Sep 14, 2023, 4:17 AM

Post #2 of 9 (406 views)

Permalink

Joe Wein via users skrev den 2023-09-14 10:37:

> This means even if the bad site is listed on domain RBLs (SURBL,
> Spamhaus or URIBL), the mail is not tagged for that.

should sa maybe begin using HtmlTidi
https://metacpan.org/dist/Perl-Tidy/view/lib/Perl/Tidy.pod

i have samples with src="" and href="", is this same error you see ?

cli tools https://www.html-tidy.org/ can this be added to sa, so sa
always see valid html, or possible check if there is lots of invalid
code or just non-sense html refs

thanks for the bugzilla, it hopefully can be fixed

Re: Stealth HREF= (missed by SA) [ In reply to ]

sausers-20150205 at billmail

Sep 14, 2023, 7:24 AM

Post #3 of 9 (406 views)

Permalink

On 2023-09-14 at 04:37:03 UTC-0400 (Thu, 14 Sep 2023 17:37:03 +0900)
Joe Wein via users <joewein@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.

--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Re: Stealth HREF= (missed by SA) [ In reply to ]

giovanni at paclan

Sep 14, 2023, 7:36 AM

Post #4 of 9 (406 views)

Permalink

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 <joewein@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

Re: Stealth HREF= (missed by SA) [ In reply to ]

users at spamassassin

Sep 14, 2023, 8:01 AM

Post #5 of 9 (406 views)

Permalink

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.

On Thursday, September 14, 2023 at 04:37:15 PM GMT+2, <giovanni@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 <joewein@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

Re: Stealth HREF= (missed by SA) [ In reply to ]

giovanni at paclan

Sep 14, 2023, 11:34 PM

Post #6 of 9 (400 views)

Permalink

On 9/14/23 17:01, Pedro David Marco wrote:
> The same happens with other HTML tags...
>
> <img src= can be replaced with <img xyz/src=
>
> virtually any char but >
>
do you have a spample to share (public or privately) ?
Thanks
Giovanni

>
> 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.
>
>
>
> On Thursday, September 14, 2023 at 04:37:15 PM GMT+2, <giovanni@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 <joewein@surbl.org <mailto:joewein@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 <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 <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
>
>

Re: Stealth HREF= (missed by SA) [ In reply to ]

sausers-20150205 at billmail

Sep 15, 2023, 6:10 AM

Post #7 of 9 (399 views)

Permalink

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_marco@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,
> <giovanni@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 <joewein@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
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Re: Stealth HREF= (missed by SA) [ In reply to ]

jhardin at impsec

Sep 17, 2023, 11:35 AM

Post #8 of 9 (399 views)

Permalink

On Fri, 15 Sep 2023, Bill Cole wrote:

> 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_marco@yahoo.com>
> is rumored to have said:
>
>> The same happens with other HTML tags...
>> <=
> DEFANGED_IMG? src=? can be replaced with <=
> DEFANGED_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)\=/

Probably should loosen that a tiny bit to allow for whitespace between the
attr and the equals sign, and a whitespace after the tag name will keep
the two variable-length REs from competing:

/<[a-z]{1,10}\s[^>]{1,80}\/(src|href)\s*\=/

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Microsoft is not a standards body.
-----------------------------------------------------------------------
Today: the 236th anniversary of the signing of the U.S. Constitution

Re: Stealth HREF= (missed by SA) [ In reply to ]

users at spamassassin

Sep 20, 2023, 8:54 PM

Post #9 of 9 (380 views)

Permalink

On Friday, September 15, 2023 15:34, Giovanni wrote:
> On 9/14/23 17:01, Pedro David Marco wrote:
>> The same happens with other HTML tags...
>>
>> <img src= can be replaced with <img xyz/src=
>>
>> virtually any char but >
>>
> do you have a spample to share (public or privately) ?

I am happy to confirm that revision 1912414 is working great and fixes the
problem.

Grazie mille!

Joe
SURBL

> Thanks
> Giovanni

Mailing List Archive

Attached Files:

Attached Files: