You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Alex <my...@gmail.com> on 2015/12/17 19:34:28 UTC
Google redirects
Hi,
Can someone explain why spamassassin is allowing apparent google
redirects? Cryptolocker :-( This one's blocked now.
<td align="left" style="font-family: 'merriweather sans', tahoma,
arial, sans-serif; color: rgb(54, 54, 54); font-size: 14px;"><a
href="https://www.google.com/url?q=http://www.mediafire.com/download/izdqjzml6dz68t3/1Z4566W50325036.ups.doc_.wsf08137322366IlRiZxJtpLvPq78WySF33Y&sa=D&usg=AFQjCNG6PWyLVrbpnrMhn12glB2txWOUgA"
style="color: rgb(89, 143, 222);
outline: 0px;" target="_blank">1Z4566W50378875...</a></td>
# href="https://www.google.com/url?q=http://www.mediafire.com/download/izdqjzml6
rawbody GOOG_VIEW1
m;https?://www\.google\.com/url\?(q=http(s)?|sa=t\&\;url=http);
describe GOOG_VIEW1 Using google url
score GOOG_VIEW1 6.0
Ideas for improving the rule or making it more flexible would be appreciated.
http://pastebin.com/MY7mZkjs
Re: Google redirects
Posted by Joe Quinn <jq...@pccc.com>.
On 12/17/2015 1:34 PM, Alex wrote:
> Hi,
>
> Can someone explain why spamassassin is allowing apparent google
> redirects? Cryptolocker :-( This one's blocked now.
>
> <td align="left" style="font-family: 'merriweather sans', tahoma,
> arial, sans-serif; color: rgb(54, 54, 54); font-size: 14px;"><a
> href="https://www.google.com/url?q=http://www.mediafire.com/download/izdqjzml6dz68t3/1Z4566W50325036.ups.doc_.wsf08137322366IlRiZxJtpLvPq78WySF33Y&sa=D&usg=AFQjCNG6PWyLVrbpnrMhn12glB2txWOUgA"
> style="color: rgb(89, 143, 222);
> outline: 0px;" target="_blank">1Z4566W50378875...</a></td>
>
> # href="https://www.google.com/url?q=http://www.mediafire.com/download/izdqjzml6
> rawbody GOOG_VIEW1
> m;https?://www\.google\.com/url\?(q=http(s)?|sa=t\&\;url=http);
> describe GOOG_VIEW1 Using google url
> score GOOG_VIEW1 6.0
>
> Ideas for improving the rule or making it more flexible would be appreciated.
>
> http://pastebin.com/MY7mZkjs
It goes without saying, but if your mail client automatically highlights
URLs be very careful about clicking in this email.
I think your rawbody rule should probably be a URI rule, especially
since it's looking for a protocol anyway. Then you can probably get a
bit more aggressive in using (.*) and such to handle URLs like
"https://www.google.com/url?asdhlf=laskjdhflkjasdhf&lakjsdf=laskjfhlasdf&...&q={payload}".
I'm not sure about scoring it 6.0 for myself, but it's fine if it works
for you. I'd also be interested to see what RuleQA thinks of it.
Re: Google redirects
Posted by Reindl Harald <h....@thelounge.net>.
Am 17.12.2015 um 22:41 schrieb Axb:
> On 12/17/2015 10:38 PM, John Hardin wrote:
>> On Thu, 17 Dec 2015, Axb wrote:
>>
>>> On 12/17/2015 09:15 PM, John Hardin wrote:
>>>> On Thu, 17 Dec 2015, Alex wrote:
>>>>
>>>> > Hi,
>>>> > > Can someone explain why spamassassin is allowing apparent google
>>>> > redirects? Cryptolocker :-( This one's blocked now.
>>>> > > <td align="left" style="font-family: 'merriweather sans', tahoma,
>>>> > arial, sans-serif; color: rgb(54, 54, 54); font-size: 14px;"><a
>>>> >
>>>> href="https://www.google.com/url?q=http://www.mediafire.com/download/{snip}"
>>>>
>>>>
>>>> > > style="color: rgb(89, 143, 222);
>>>> > outline: 0px;" target="_blank">1Z4566W50378875...</a></td>
>>>> > > #
>>>> >
>>>> href="https://www.google.com/url?q=http://www.mediafire.com/download/izdqjzml6
>>>>
>>>>
>>>> > > rawbody GOOG_VIEW1
>>>> > m;https?://www\.google\.com/url\?(q=http(s)?|sa=t\&\;url=http);
>>>> > describe GOOG_VIEW1 Using google url
>>>> > score GOOG_VIEW1 6.0
>>>> > > Ideas for improving the rule or making it more flexible would be
>>>> > appreciated.
>>>>
>>>> There are google rules. I'll take a look at why this wasn't scored
>>>> when
>>>> I get a chance later today or tomorrow.
>>>
>>> there's a bunch of Henry Stern's google redirector_pattern rules but
>>> they're all made for http only.
>>> Adding and commiting s? now
>>
>> And this in my sandbox, with a different pattern:
>>
>> uri __GOOG_MALWARE_DNLD
>> m;^https?://[^/]*\.google\.com/[^?]*url\?.*[\?&]download=1;i
>>
>> I will broaden that a bit.
>
> could you make a version using redirector_pattern so the redirected
> target can be looked up via URIBL plugin?
sounds promising
ClamAV with SaneSecurity would have blocked that thread without
whitelisting the list with "Sanesecurity.Spam.ldb.2.UNOFFICIAL"
current topic and ClamAV:
http://sanesecurity.com/usage/signatures/
Sanesecurity_sigtest.yara Yara format: Signature test Low
Sanesecurity_spam.yara Yara format: Detects Spam emails Low
http://blog.clamav.net/2015/06/clamav-099b-meets-yara.html
______________________________________________
Sanesecurity_spam.yara:
rule Sanesecurity_Spam_Google_Redir_001 //Match Google Redirects without
Email client headers
{
strings:
$match1 = "http://www.google.com/url?q=%"
$match2 = "http://www.google.com/url?q=http"
$ignore1 = "X-Mailer:"
$ignore2 = "User-Agent:"
$ignore3 = "List-Unsubscribe:"
condition:
($match1 or $match2) and not ($ignore1 or $ignore2 or
$ignore3)
}
rule Sanesecurity_Spam_Google_Redir_002 //Match Google Redirects without
Email client headers
{
strings:
$match1 = "https://www.google.com/url?q=%"
$match2 = "https://www.google.com/url?q=http"
$ignore1 = "X-Mailer:"
$ignore2 = "User-Agent:"
$ignore3 = "List-Unsubscribe:"
condition:
($match1 or $match2) and not ($ignore1 or $ignore2 or
$ignore3)
______________________________________________
BTW:
[root@mail-gw:~]$ cat sa-update.log
02-Dez-2015 01:02:53: SpamAssassin: Update processed successfully
03-Dez-2015 00:37:51: SpamAssassin: Update processed successfully
04-Dez-2015 00:56:46: SpamAssassin: Update processed successfully
05-Dez-2015 00:00:16: SpamAssassin: Update processed successfully
06-Dez-2015 00:45:06: SpamAssassin: No update available
07-Dez-2015 00:19:04: SpamAssassin: No update available
08-Dez-2015 00:14:33: SpamAssassin: No update available
09-Dez-2015 00:15:58: SpamAssassin: No update available
10-Dez-2015 01:09:43: SpamAssassin: No update available
11-Dez-2015 01:20:40: SpamAssassin: No update available
12-Dez-2015 01:13:00: SpamAssassin: No update available
13-Dez-2015 00:49:06: SpamAssassin: No update available
14-Dez-2015 01:04:57: SpamAssassin: No update available
15-Dez-2015 01:09:07: SpamAssassin: No update available
16-Dez-2015 00:37:36: SpamAssassin: No update available
17-Dez-2015 00:27:17: SpamAssassin: No update available
Re: Google redirects
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 12/20/2015 1:01 PM, John Hardin wrote:
> On Sun, 20 Dec 2015, Axb wrote:
>
>> On 12/20/2015 10:36 AM, Reindl Harald wrote:
>>> 20-Dez-2015 00:21:46: SpamAssassin: No update available
>>
>> You probably run sa-update too early -
>
> That wouldn't explain it, as running off-schedule would apply updates
> late, not skip them entirely.
>
> Reindl:
>
> The corpus may have been starved for a couple of weeks, it has
> happened before and will happen again unless more people participate
> in masscheck.
It's more about the weekly vs. daily cycle. If a daily cycle is
starved, we can catch back up the next night and all is good. However,
if a weekly is starved, it's a week until the starvation is overcome.
We can't produce dailies without the weekly.
We've had ASF maintenance and masschecker maintenance both interfere
with the weekly. And masscheckers can't typically dedicate an out of
band weekly check.
So, in this case, we were starved two weekly cycles and just published
on the 19th and 20th. Tonight's will be in about 11 hours if all looks
good.
Regards,
KAM
Re: Google redirects
Posted by Axb <ax...@gmail.com>.
On 12/20/2015 07:01 PM, John Hardin wrote:
> On Sun, 20 Dec 2015, Axb wrote:
>
>> On 12/20/2015 10:36 AM, Reindl Harald wrote:
>>> 20-Dez-2015 00:21:46: SpamAssassin: No update available
>>
>> You probably run sa-update too early -
>
> That wouldn't explain it, as running off-schedule would apply updates
> late, not skip them entirely.
My comment applied to the last one, according to his log:
20-Dez-2015 00:21:46: SpamAssassin: No update available
(assuming 00:21:46 was CET)
Re: Google redirects
Posted by John Hardin <jh...@impsec.org>.
On Sun, 20 Dec 2015, Axb wrote:
> On 12/20/2015 10:36 AM, Reindl Harald wrote:
>> 20-Dez-2015 00:21:46: SpamAssassin: No update available
>
> You probably run sa-update too early -
That wouldn't explain it, as running off-schedule would apply updates
late, not skip them entirely.
Reindl:
The corpus may have been starved for a couple of weeks, it has happened
before and will happen again unless more people participate in masscheck.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
"Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
does quite what I want. I wish Christopher Robin was here."
-- Peter da Silva in a.s.r
-----------------------------------------------------------------------
5 days until Christmas
Re: Google redirects
Posted by Axb <ax...@gmail.com>.
On 12/20/2015 12:22 PM, Reindl Harald wrote:
>
>
> Am 20.12.2015 um 12:13 schrieb Axb:
>> On 12/20/2015 10:36 AM, Reindl Harald wrote:
>>> 20-Dez-2015 00:21:46: SpamAssassin: No update available
>>
>> You probably run sa-update too early -
>> As your log lacks last update version it's hard to tell..
>>
>> head /var/lib/spamassassin/4.000000/updates_spamassassin_org.cf
>> # UPDATE version 1720887
>
> but usually there are daily score-updates what didn't happen for more
> than two weeks now!
>
just in case it hasn't sinked in yet:
sa-updates / rules/score promotions depend on masschecks which are run
by volunteers.
If spam/ham corpus aren't large enough, there are no updates.
Volunteers willing to donate a few cpu cycles and a bit of time are
always welcome.
All required info is in Wiki
http://wiki.apache.org/spamassassin/NightlyMassCheck
Re: Google redirects
Posted by Dave Warren <da...@hireahit.com>.
On 2015-12-20 03:22, Reindl Harald wrote:
> but usually there are daily score-updates what didn't happen for more
> than two weeks now!
It happens, life goes on.
--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren
Re: Google redirects
Posted by Reindl Harald <h....@thelounge.net>.
Am 20.12.2015 um 12:13 schrieb Axb:
> On 12/20/2015 10:36 AM, Reindl Harald wrote:
>> 20-Dez-2015 00:21:46: SpamAssassin: No update available
>
> You probably run sa-update too early -
> As your log lacks last update version it's hard to tell..
>
> head /var/lib/spamassassin/4.000000/updates_spamassassin_org.cf
> # UPDATE version 1720887
but usually there are daily score-updates what didn't happen for more
than two weeks now!
Re: Google redirects
Posted by Axb <ax...@gmail.com>.
On 12/20/2015 10:36 AM, Reindl Harald wrote:
> 20-Dez-2015 00:21:46: SpamAssassin: No update available
You probably run sa-update too early -
As your log lacks last update version it's hard to tell..
head /var/lib/spamassassin/4.000000/updates_spamassassin_org.cf
# UPDATE version 1720887
............
Re: Google redirects
Posted by Reindl Harald <h....@thelounge.net>.
Am 20.12.2015 um 05:25 schrieb John Hardin:
> On Fri, 18 Dec 2015, John Hardin wrote:
>
>> I've relaxed my google malware redirect rule (above) to match your
>> sample. It will go out the next time rules pass masscheck. The corpus
>> looks well-fed today so that *should* occur overnight.
>>
>> As soon as masscheck publishes an update, that redirect will get at
>> least one point; possibly more after your spamples are in the corpus
>> and that rule starts getting some fresh spam hits.
>
> Masscheck has published a rules update and the modified google malware
> redirect rule and the updated https google redirector_pattern entries
> are included.
something is wrong with updates
[root@localhost:~]$ cat sa-update.log
02-Dez-2015 01:02:53: SpamAssassin: Update processed successfully
03-Dez-2015 00:37:51: SpamAssassin: Update processed successfully
04-Dez-2015 00:56:46: SpamAssassin: Update processed successfully
05-Dez-2015 00:00:16: SpamAssassin: Update processed successfully
06-Dez-2015 00:45:06: SpamAssassin: No update available
07-Dez-2015 00:19:04: SpamAssassin: No update available
08-Dez-2015 00:14:33: SpamAssassin: No update available
09-Dez-2015 00:15:58: SpamAssassin: No update available
10-Dez-2015 01:09:43: SpamAssassin: No update available
11-Dez-2015 01:20:40: SpamAssassin: No update available
12-Dez-2015 01:13:00: SpamAssassin: No update available
13-Dez-2015 00:49:06: SpamAssassin: No update available
14-Dez-2015 01:04:57: SpamAssassin: No update available
15-Dez-2015 01:09:07: SpamAssassin: No update available
16-Dez-2015 00:37:36: SpamAssassin: No update available
17-Dez-2015 00:27:17: SpamAssassin: No update available
18-Dez-2015 00:38:14: SpamAssassin: No update available
19-Dez-2015 01:12:45: SpamAssassin: No update available
20-Dez-2015 00:21:46: SpamAssassin: No update available
Re: Google redirects
Posted by John Hardin <jh...@impsec.org>.
On Fri, 18 Dec 2015, John Hardin wrote:
> I've relaxed my google malware redirect rule (above) to match your sample. It
> will go out the next time rules pass masscheck. The corpus looks well-fed
> today so that *should* occur overnight.
>
> As soon as masscheck publishes an update, that redirect will get at least one
> point; possibly more after your spamples are in the corpus and that rule
> starts getting some fresh spam hits.
Masscheck has published a rules update and the modified google malware
redirect rule and the updated https google redirector_pattern entries are
included.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
"Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
does quite what I want. I wish Christopher Robin was here."
-- Peter da Silva in a.s.r
-----------------------------------------------------------------------
6 days until Christmas
Re: Google redirects
Posted by John Hardin <jh...@impsec.org>.
On Fri, 18 Dec 2015, Alex wrote:
>>>> I suggested converting the rawbody rule John was working on into a
>>>> redirector_pattern
>>>
>>> Note that the following rule as posted by John:
>>>
>>> uri __GOOG_MALWARE_DNLD
>>> m;^https?://[^/]*\.google\.com/[^?]*url\?.*[\?&]download=1;i
>>>
>>> would not currently work as a redirector_pattern due to the problem
>>> I posted in my today's reply (Re: redirector_pattern question);
>>> i.e. where the redirector target contains "http:", followed
>>> by other URI arguments (like "&download=1" here).
>>
>> Right, and I would take that into account when composing the
>> redirector_pattern. That extra bit is there to avoid treating *all* google
>> redirects as malware downloads.
>>
>> Question: has anyone ever seen a *legit* (non-spam, non-phishing,
>> non-malware) google redirect like that in an email? Maybe this rule is too
>> restrictive and we should be suspicious of *all* google redirects?
>
> I've forwarded you a few samples.
Thanks.
> I'm not entirely sure I've kept up with the pieces of this. Has a rule
> yet been developed?
I've relaxed my google malware redirect rule (above) to match your sample.
It will go out the next time rules pass masscheck. The corpus looks
well-fed today so that *should* occur overnight.
> Is both a rule and Marc's patch required?
I re-ran a test against your original sample after the other Alex edited
the existing google redirect patterns to also match https but before the
pattern order patch was committed and it did pull out the malware download
URL, so that should allow URIBL to see the download hostname (again,
pending rules being published from masscheck) and I don't think the patch
matters in this case.
However, that only helps if the download is being hosted by a site that
hits URIBL et. al. (or some other rule) and I don't think
www.mediafire.com will be listed, so yes, a scored rule that matches that
pattern is necessary in addition to the patch.
As soon as masscheck publishes an update, that redirect will get at least
one point; possibly more after your spamples are in the corpus and that
rule starts getting some fresh spam hits.
> After the patch was posted, there was a comment about the
> redirector_pattern not being necessary...
Yeah, the existing google redirect pattern for "url=" did work when it was
broadened to include https, so my rule doesn't need to be used as the
basis for another new redirect pattern.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
"Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
does quite what I want. I wish Christopher Robin was here."
-- Peter da Silva in a.s.r
-----------------------------------------------------------------------
7 days until Christmas
Re: Google redirects
Posted by Alex <my...@gmail.com>.
Hi,
>>> I suggested converting the rawbody rule John was working on into a
>>> redirector_pattern
>>
>>
>> Note that the following rule as posted by John:
>>
>> uri __GOOG_MALWARE_DNLD
>> m;^https?://[^/]*\.google\.com/[^?]*url\?.*[\?&]download=1;i
>>
>> would not currently work as a redirector_pattern due to the problem
>> I posted in my today's reply (Re: redirector_pattern question);
>> i.e. where the redirector target contains "http:", followed
>> by other URI arguments (like "&download=1" here).
>
> Right, and I would take that into account when composing the
> redirector_pattern. That extra bit is there to avoid treating *all* google
> redirects as malware downloads.
>
> Question: has anyone ever seen a *legit* (non-spam, non-phishing,
> non-malware) google redirect like that in an email? Maybe this rule is too
> restrictive and we should be suspicious of *all* google redirects?
I've forwarded you a few samples.
I'm not entirely sure I've kept up with the pieces of this. Has a rule
yet been developed? Is both a rule and Marc's patch required? After
the patch was posted, there was a comment about the redirector_pattern
not being necessary...
Thanks,
Alex
Re: Google redirects
Posted by John Hardin <jh...@impsec.org>.
On Fri, 18 Dec 2015, Joe Quinn wrote:
> On 12/18/2015 11:32 AM, John Hardin wrote:
>> >
>> > uri __GOOG_MALWARE_DNLD
>> > m;^https?://[^/]*\.google\.com/[^?]*url\?.*[\?&]download=1;i
>>
>> Question: has anyone ever seen a *legit* (non-spam, non-phishing,
>> non-malware) google redirect like that in an email? Maybe this rule is too
>> restrictive and we should be suspicious of *all* google redirects?
>>
> I do it occasionally, if I am sending a link to someone and I right-click ->
> "copy link location" on the search results. I'd be suspicious of those sorts
> of links, but not too suspicious.
It's already there as a subrule for masscheck eval and use in metas:
http://ruleqa.spamassassin.org/20151218-r1720729-n/__GOOG_REDIR/detail
SPAM% HAM% S/O
0.3357 0.0288 0.921
~12% of spam hits are at <5 points.
It's meta'd for score in a couple of rules:
http://ruleqa.spamassassin.org/20151218-r1720729-n/GOOG_REDIR_SHORT/detail
http://ruleqa.spamassassin.org/20151218-r1720729-n/GOOG_REDIR_NORDNS/detail
...and those are hitting the bulk of the spams but they are not hitting
the low-scoring spams.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
"Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
does quite what I want. I wish Christopher Robin was here."
-- Peter da Silva in a.s.r
-----------------------------------------------------------------------
7 days until Christmas
Re: Google redirects
Posted by Joe Quinn <jq...@pccc.com>.
On 12/18/2015 11:32 AM, John Hardin wrote:
> On Fri, 18 Dec 2015, Mark Martinec wrote:
>
>> On 2015-12-18 16:29, Axb wrote:
>>> On 12/18/2015 04:17 PM, Mark Martinec wrote:
>>> > On 2015-12-17 22:41, Axb wrote:
>>> > > could you make a version using redirector_pattern so the
>>> redirected
>>> > > target can be looked up via URIBL plugin?
>>> > > Isn't this already the case? Redirect targets are added
>>> > to a list of URIs and are subject to same rules as
>>> > directly collected URIs.
>>> >
>>> I suggested converting the rawbody rule John was working on into a
>>> redirector_pattern
>>
>> Note that the following rule as posted by John:
>>
>> uri __GOOG_MALWARE_DNLD
>> m;^https?://[^/]*\.google\.com/[^?]*url\?.*[\?&]download=1;i
>>
>> would not currently work as a redirector_pattern due to the problem
>> I posted in my today's reply (Re: redirector_pattern question);
>> i.e. where the redirector target contains "http:", followed
>> by other URI arguments (like "&download=1" here).
>
> Right, and I would take that into account when composing the
> redirector_pattern. That extra bit is there to avoid treating *all*
> google redirects as malware downloads.
>
> Question: has anyone ever seen a *legit* (non-spam, non-phishing,
> non-malware) google redirect like that in an email? Maybe this rule is
> too restrictive and we should be suspicious of *all* google redirects?
>
I do it occasionally, if I am sending a link to someone and I
right-click -> "copy link location" on the search results. I'd be
suspicious of those sorts of links, but not too suspicious.
Re: Google redirects
Posted by John Hardin <jh...@impsec.org>.
On Fri, 18 Dec 2015, Mark Martinec wrote:
> On 2015-12-18 16:29, Axb wrote:
>> On 12/18/2015 04:17 PM, Mark Martinec wrote:
>> > On 2015-12-17 22:41, Axb wrote:
>> > > could you make a version using redirector_pattern so the redirected
>> > > target can be looked up via URIBL plugin?
>> >
>> > Isn't this already the case? Redirect targets are added
>> > to a list of URIs and are subject to same rules as
>> > directly collected URIs.
>> >
>>
>> I suggested converting the rawbody rule John was working on into a
>> redirector_pattern
>
> Note that the following rule as posted by John:
>
> uri __GOOG_MALWARE_DNLD
> m;^https?://[^/]*\.google\.com/[^?]*url\?.*[\?&]download=1;i
>
> would not currently work as a redirector_pattern due to the problem
> I posted in my today's reply (Re: redirector_pattern question);
> i.e. where the redirector target contains "http:", followed
> by other URI arguments (like "&download=1" here).
Right, and I would take that into account when composing the
redirector_pattern. That extra bit is there to avoid treating *all* google
redirects as malware downloads.
Question: has anyone ever seen a *legit* (non-spam,
non-phishing, non-malware) google redirect like that in an email? Maybe
this rule is too restrictive and we should be suspicious of *all* google
redirects?
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
"Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
does quite what I want. I wish Christopher Robin was here."
-- Peter da Silva in a.s.r
-----------------------------------------------------------------------
7 days until Christmas
Re: Google redirects
Posted by Mark Martinec <Ma...@ijs.si>.
On 2015-12-18 16:29, Axb wrote:
> On 12/18/2015 04:17 PM, Mark Martinec wrote:
>> On 2015-12-17 22:41, Axb wrote:
>>> could you make a version using redirector_pattern so the redirected
>>> target can be looked up via URIBL plugin?
>>
>> Isn't this already the case? Redirect targets are added
>> to a list of URIs and are subject to same rules as
>> directly collected URIs.
>>
>
> I suggested converting the rawbody rule John was working on into a
> redirector_pattern
Note that the following rule as posted by John:
uri __GOOG_MALWARE_DNLD
m;^https?://[^/]*\.google\.com/[^?]*url\?.*[\?&]download=1;i
would not currently work as a redirector_pattern due to the problem
I posted in my today's reply (Re: redirector_pattern question);
i.e. where the redirector target contains "http:", followed
by other URI arguments (like "&download=1" here).
Mark
Re: Google redirects
Posted by John Hardin <jh...@impsec.org>.
On Fri, 18 Dec 2015, Axb wrote:
> On 12/18/2015 04:17 PM, Mark Martinec wrote:
>> On 2015-12-17 22:41, Axb wrote:
>> > could you make a version using redirector_pattern so the redirected
>> > target can be looked up via URIBL plugin?
>>
>> Isn't this already the case? Redirect targets are added
>> to a list of URIs and are subject to same rules as
>> directly collected URIs.
>
> I suggested converting the rawbody rule John was working on into a
> redirector_pattern
It doesn't appear to be needed. With your changes to the existing google
redirector patterns I now get this in my debug log for Alex's original
message:
ran uri rule __ALL_URI ======> got hit: "http://www.mediafire.com/download/izdq{snip}"
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
"Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
does quite what I want. I wish Christopher Robin was here."
-- Peter da Silva in a.s.r
-----------------------------------------------------------------------
7 days until Christmas
Re: Google redirects
Posted by Axb <ax...@gmail.com>.
On 12/18/2015 04:17 PM, Mark Martinec wrote:
> On 2015-12-17 22:41, Axb wrote:
>> could you make a version using redirector_pattern so the redirected
>> target can be looked up via URIBL plugin?
>
> Isn't this already the case? Redirect targets are added
> to a list of URIs and are subject to same rules as
> directly collected URIs.
>
I suggested converting the rawbody rule John was working on into a
redirector_pattern
Re: Google redirects
Posted by Mark Martinec <Ma...@ijs.si>.
On 2015-12-17 22:41, Axb wrote:
> could you make a version using redirector_pattern so the redirected
> target can be looked up via URIBL plugin?
Isn't this already the case? Redirect targets are added
to a list of URIs and are subject to same rules as
directly collected URIs.
Mark
Re: Google redirects
Posted by John Hardin <jh...@impsec.org>.
On Thu, 17 Dec 2015, Axb wrote:
> On 12/17/2015 10:38 PM, John Hardin wrote:
>> On Thu, 17 Dec 2015, Axb wrote:
>>
>> > On 12/17/2015 09:15 PM, John Hardin wrote:
>> > > On Thu, 17 Dec 2015, Alex wrote:
>> > >
>> > > > Hi,
>> > > > > Can someone explain why spamassassin is allowing apparent google
>> > > > redirects? Cryptolocker :-( This one's blocked now.
>> > > > > <td align="left" style="font-family: 'merriweather sans', tahoma,
>> > > > arial, sans-serif; color: rgb(54, 54, 54); font-size: 14px;"><a
>> > > >
>> > > href="https://www.google.com/url?q=http://www.mediafire.com/download/{snip}"
>> > >
>> > > > > style="color: rgb(89, 143, 222);
>> > > > outline: 0px;" target="_blank">1Z4566W50378875...</a></td>
>> > > > > #
>> > > >
>> > > href="https://www.google.com/url?q=http://www.mediafire.com/download/izdqjzml6
>> > >
>> > > > > rawbody GOOG_VIEW1
>> > > > m;https?://www\.google\.com/url\?(q=http(s)?|sa=t\&\;url=http);
>> > > > describe GOOG_VIEW1 Using google url
>> > > > score GOOG_VIEW1 6.0
>> > > > > Ideas for improving the rule or making it more flexible would be
>> > > > appreciated.
>> > >
>> > > There are google rules. I'll take a look at why this wasn't scored
>> > > when
>> > > I get a chance later today or tomorrow.
>> >
>> > there's a bunch of Henry Stern's google redirector_pattern rules but
>> > they're all made for http only.
>> > Adding and commiting s? now
>>
>> And this in my sandbox, with a different pattern:
>>
>> uri __GOOG_MALWARE_DNLD
>> m;^https?://[^/]*\.google\.com/[^?]*url\?.*[\?&]download=1;i
>>
>> I will broaden that a bit.
>
> could you make a version using redirector_pattern so the redirected target
> can be looked up via URIBL plugin?
Sadly, there's nothing in the corpus that matches that rule. I think it'll
be published, but with a low score.
http://ruleqa.spamassassin.org/20151218-r1720729-n/GOOG_MALWARE_DNLD/detail
Alex, if you still have some of those around, send them to me as RFC822
attachments and I'll add them to my masscheck spam corpora.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
"Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
does quite what I want. I wish Christopher Robin was here."
-- Peter da Silva in a.s.r
-----------------------------------------------------------------------
7 days until Christmas
Re: Google redirects
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 12/17/2015 5:38 PM, John Hardin wrote:
> On Thu, 17 Dec 2015, Axb wrote:
>
>> On 12/17/2015 10:38 PM, John Hardin wrote:
>>> And this in my sandbox, with a different pattern:
>>>
>>> uri __GOOG_MALWARE_DNLD
>>> m;^https?://[^/]*\.google\.com/[^?]*url\?.*[\?&]download=1;i
>>>
>>> I will broaden that a bit.
>>
>> could you make a version using redirector_pattern so the redirected
>> target can be looked up via URIBL plugin?
>
> Whoops! Sure, I will do that.
Great idea...
Re: Google redirects
Posted by John Hardin <jh...@impsec.org>.
On Thu, 17 Dec 2015, Axb wrote:
> On 12/17/2015 10:38 PM, John Hardin wrote:
>> And this in my sandbox, with a different pattern:
>>
>> uri __GOOG_MALWARE_DNLD
>> m;^https?://[^/]*\.google\.com/[^?]*url\?.*[\?&]download=1;i
>>
>> I will broaden that a bit.
>
> could you make a version using redirector_pattern so the redirected target
> can be looked up via URIBL plugin?
Whoops! Sure, I will do that.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
"Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
does quite what I want. I wish Christopher Robin was here."
-- Peter da Silva in a.s.r
-----------------------------------------------------------------------
8 days until Christmas
Re: Google redirects
Posted by Axb <ax...@gmail.com>.
On 12/17/2015 10:38 PM, John Hardin wrote:
> On Thu, 17 Dec 2015, Axb wrote:
>
>> On 12/17/2015 09:15 PM, John Hardin wrote:
>>> On Thu, 17 Dec 2015, Alex wrote:
>>>
>>> > Hi,
>>> > > Can someone explain why spamassassin is allowing apparent google
>>> > redirects? Cryptolocker :-( This one's blocked now.
>>> > > <td align="left" style="font-family: 'merriweather sans', tahoma,
>>> > arial, sans-serif; color: rgb(54, 54, 54); font-size: 14px;"><a
>>> >
>>> href="https://www.google.com/url?q=http://www.mediafire.com/download/{snip}"
>>>
>>> > > style="color: rgb(89, 143, 222);
>>> > outline: 0px;" target="_blank">1Z4566W50378875...</a></td>
>>> > > #
>>> >
>>> href="https://www.google.com/url?q=http://www.mediafire.com/download/izdqjzml6
>>>
>>> > > rawbody GOOG_VIEW1
>>> > m;https?://www\.google\.com/url\?(q=http(s)?|sa=t\&\;url=http);
>>> > describe GOOG_VIEW1 Using google url
>>> > score GOOG_VIEW1 6.0
>>> > > Ideas for improving the rule or making it more flexible would be
>>> > appreciated.
>>>
>>> There are google rules. I'll take a look at why this wasn't scored when
>>> I get a chance later today or tomorrow.
>>
>> there's a bunch of Henry Stern's google redirector_pattern rules but
>> they're all made for http only.
>> Adding and commiting s? now
>
> And this in my sandbox, with a different pattern:
>
> uri __GOOG_MALWARE_DNLD
> m;^https?://[^/]*\.google\.com/[^?]*url\?.*[\?&]download=1;i
>
> I will broaden that a bit.
could you make a version using redirector_pattern so the redirected
target can be looked up via URIBL plugin?
Re: Google redirects
Posted by John Hardin <jh...@impsec.org>.
On Thu, 17 Dec 2015, Axb wrote:
> On 12/17/2015 09:15 PM, John Hardin wrote:
>> On Thu, 17 Dec 2015, Alex wrote:
>>
>> > Hi,
>> >
>> > Can someone explain why spamassassin is allowing apparent google
>> > redirects? Cryptolocker :-( This one's blocked now.
>> >
>> > <td align="left" style="font-family: 'merriweather sans', tahoma,
>> > arial, sans-serif; color: rgb(54, 54, 54); font-size: 14px;"><a
>> > href="https://www.google.com/url?q=http://www.mediafire.com/download/{snip}"
>> >
>> > style="color: rgb(89, 143, 222);
>> > outline: 0px;" target="_blank">1Z4566W50378875...</a></td>
>> >
>> > #
>> > href="https://www.google.com/url?q=http://www.mediafire.com/download/izdqjzml6
>> >
>> > rawbody GOOG_VIEW1
>> > m;https?://www\.google\.com/url\?(q=http(s)?|sa=t\&\;url=http);
>> > describe GOOG_VIEW1 Using google url
>> > score GOOG_VIEW1 6.0
>> >
>> > Ideas for improving the rule or making it more flexible would be
>> > appreciated.
>>
>> There are google rules. I'll take a look at why this wasn't scored when
>> I get a chance later today or tomorrow.
>
> there's a bunch of Henry Stern's google redirector_pattern rules but they're
> all made for http only.
> Adding and commiting s? now
And this in my sandbox, with a different pattern:
uri __GOOG_MALWARE_DNLD m;^https?://[^/]*\.google\.com/[^?]*url\?.*[\?&]download=1;i
I will broaden that a bit.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
"Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
does quite what I want. I wish Christopher Robin was here."
-- Peter da Silva in a.s.r
-----------------------------------------------------------------------
8 days until Christmas
Re: Google redirects
Posted by Axb <ax...@gmail.com>.
On 12/17/2015 09:15 PM, John Hardin wrote:
> On Thu, 17 Dec 2015, Alex wrote:
>
>> Hi,
>>
>> Can someone explain why spamassassin is allowing apparent google
>> redirects? Cryptolocker :-( This one's blocked now.
>>
>> <td align="left" style="font-family: 'merriweather sans', tahoma,
>> arial, sans-serif; color: rgb(54, 54, 54); font-size: 14px;"><a
>> href="https://www.google.com/url?q=http://www.mediafire.com/download/{snip}"
>>
>> style="color: rgb(89, 143, 222);
>> outline: 0px;" target="_blank">1Z4566W50378875...</a></td>
>>
>> #
>> href="https://www.google.com/url?q=http://www.mediafire.com/download/izdqjzml6
>>
>> rawbody GOOG_VIEW1
>> m;https?://www\.google\.com/url\?(q=http(s)?|sa=t\&\;url=http);
>> describe GOOG_VIEW1 Using google url
>> score GOOG_VIEW1 6.0
>>
>> Ideas for improving the rule or making it more flexible would be
>> appreciated.
>
> There are google rules. I'll take a look at why this wasn't scored when
> I get a chance later today or tomorrow.
>
there's a bunch of Henry Stern's google redirector_pattern rules but
they're all made for http only.
Adding and commiting s? now
Re: Google redirects
Posted by John Hardin <jh...@impsec.org>.
On Thu, 17 Dec 2015, Alex wrote:
> Hi,
>
> Can someone explain why spamassassin is allowing apparent google
> redirects? Cryptolocker :-( This one's blocked now.
>
> <td align="left" style="font-family: 'merriweather sans', tahoma,
> arial, sans-serif; color: rgb(54, 54, 54); font-size: 14px;"><a
> href="https://www.google.com/url?q=http://www.mediafire.com/download/{snip}"
> style="color: rgb(89, 143, 222);
> outline: 0px;" target="_blank">1Z4566W50378875...</a></td>
>
> # href="https://www.google.com/url?q=http://www.mediafire.com/download/izdqjzml6
> rawbody GOOG_VIEW1
> m;https?://www\.google\.com/url\?(q=http(s)?|sa=t\&\;url=http);
> describe GOOG_VIEW1 Using google url
> score GOOG_VIEW1 6.0
>
> Ideas for improving the rule or making it more flexible would be appreciated.
There are google rules. I'll take a look at why this wasn't scored when I
get a chance later today or tomorrow.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
"Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
does quite what I want. I wish Christopher Robin was here."
-- Peter da Silva in a.s.r
-----------------------------------------------------------------------
8 days until Christmas