You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by John Hardin <jh...@impsec.org> on 2014/09/02 19:37:11 UTC
current destination user in rules
On Tue, 2 Sep 2014, Kevin A. McGrail wrote:
> On 9/2/2014 11:55 AM, John Hardin wrote:
>> On Tue, 2 Sep 2014, Kevin A. McGrail wrote:
>>
>> > On 9/1/2014 9:56 PM, John Hardin wrote:
>> > >
>> > > Is there any way to interpolate the "current destination user
>> > > name" perl variable into a rule?
>> >
>> > Do you mean something to do with the username passed to spamc?
>>
>> Ideally the username the message is destined for;
>
> Spamassassin has no idea who the email is destined to by username.
OK, darn.
The reason I ask is I've started to see spams with my username in body
URIs, for example:
View as a webpage https://jhardin4874.org/policy/?qs=3Db15XXXXXXa89ab007c31d5ac410973dae95fd
Absent having the destination username available in a variable that could
be used in a RE, I suspect this is the best that can be done:
full __RECIP_IN_URL m;^Received:[^:]{1,400}?\sfor\s<(\w+)\@.+?https?://\1\d*\.;ism
...in all its wince-worthy FULLness.
Suggestions for alternatives welcomed.
--
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
-----------------------------------------------------------------------
Maxim II: A Sergeant in motion outranks a Lieutenant who doesn't
know what's going on.
Maxim III: An ordnance technician at a dead run outranks everybody.
-----------------------------------------------------------------------
15 days until the 227th anniversary of the signing of the U.S. Constitution
Re: current destination user in rules
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 9/2/2014 1:56 PM, John Hardin wrote:
> On Tue, 2 Sep 2014, Kevin A. McGrail wrote:
>
>> On 9/2/2014 1:37 PM, John Hardin wrote:
>>> On Tue, 2 Sep 2014, Kevin A. McGrail wrote:
>>> > Spamassassin has no idea who the email is destined to by username.
>>>
>>> OK, darn.
>>
>> How are you calling SA? Procmail to spamc? or a glue?
>
> I personally am using procmail -> spamc, without a user name. I was
> hoping for a generic solution; if it depends on the implementation
> then it would be much less useful.
>
> For the larger question: has anybody written a rule that successfully
> references the value of a perl variable?
Well, you COULD get the username passed by spamc to spamd or from
Spamssassin or the API call to signal_user_changed.
It's in $self->{username} and I think you would need a new eval rule.
regards,
KAM
Re: current destination user in rules
Posted by John Hardin <jh...@impsec.org>.
On Tue, 2 Sep 2014, Kevin A. McGrail wrote:
> On 9/2/2014 1:37 PM, John Hardin wrote:
>> On Tue, 2 Sep 2014, Kevin A. McGrail wrote:
>> > Spamassassin has no idea who the email is destined to by username.
>>
>> OK, darn.
>
> How are you calling SA? Procmail to spamc? or a glue?
I personally am using procmail -> spamc, without a user name. I was hoping
for a generic solution; if it depends on the implementation then it would
be much less useful.
For the larger question: has anybody written a rule that successfully
references the value of a perl variable?
--
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
-----------------------------------------------------------------------
Maxim II: A Sergeant in motion outranks a Lieutenant who doesn't
know what's going on.
Maxim III: An ordnance technician at a dead run outranks everybody.
-----------------------------------------------------------------------
15 days until the 227th anniversary of the signing of the U.S. Constitution
Re: current destination user in rules
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 9/2/2014 1:37 PM, John Hardin wrote:
> On Tue, 2 Sep 2014, Kevin A. McGrail wrote:
>> Spamassassin has no idea who the email is destined to by username.
>
> OK, darn.
How are you calling SA? Procmail to spamc? or a glue?
Regards,
KAM
Re: current destination user in rules
Posted by John Hardin <jh...@impsec.org>.
On Wed, 3 Sep 2014, Karsten Bräckelmann wrote:
> And, well... You saw a pattern worth chasing in a single sample?
> Seriously? :)
Something that obvious caught my eye.
>> You're right about 2ld in URIBL, so maybe my idea that it was a
>> URIBL-avoidance technique doesn't hold water. www foxnews areb.ru does hit
>> URIBL_BLACK...
>
> How exactly did you mangle the domain? Space instead of hyphen? Didn't
> find a URIBL_BLACK listing right now.
Just remove the spaces.
>>> Regarding whether SA can use Perl variables in regex rules: Yes.
>>> Though I'd consider it abuse and would oppose to doing so in
>>> officially hosted rules (stock and sandbox).
>>>
>>> $ echo -e "\n uid=1000(kb)" | ./spamassassin -D -L --cf='body VAR /$</'
>>> dbg: rules: ran body rule VAR ======> got hit: "1000"
>>
>> I didn't try generic language-provided variables like that, I tried
>> some specific variables defined by SA and couldn't get it to work. I
>> got a variable-related error message so I knew it was *trying* to get
>> the variable's value but couldn't. I don't remember exactly what I
>> tried, it was a little while ago and I didn't keep notes.
>
> That was meant as a proof of concept. I was being lazy. ;)
:)
> Without actually trying, referencing SA internal variables should be
> possible, too, I believe. It most likely would require some traversing
> of object hashes -- $self usually doesn't hold what you're after, but a
> $pms or similarly named hash entry, which in turn contains a reference
> to...
Yeah. I didn't try to track all that down.
>> Plus, being able to use an application variable would help address the
>> general desire to have a way to pass a capture from one rule to another.
>
> I'd definitely prefer that to use some special markup, guided by tflags
> enabling interpolation.
You'd obviously need a tflag to mark rules where you wanted to expose the
capture. I suppose having to mark the rules where you'd want to use a
saved capture would make sense from the POV of limiting the scope of extra
processing. Good point.
> Frankly, I'd probably be in favor of M::SA::Conf preventing $variables
> from being expanded.
I can see that being a gaping potential hazard.
> In related context: Do note that spamd's processing speed advantage over
> the plain spamassassin executable is notably due to pre-compiling the
> bulk of the regex rules. Variables might not hold the value you'd expect
> during run-time, in particular WRT scan-specific per-user variables.
Yeah, that's another issue.
--
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
-----------------------------------------------------------------------
...intellectuals have no interest in what _creates_ wealth, and
what _inhibits_ the creation of wealth. They are very concerned
about the _distribution_ of it, but they act as if wealth just
exists somehow. It's like manna from heaven, it's only a
question of how we split it up. -- Thomas Sowell
-----------------------------------------------------------------------
15 days until the 227th anniversary of the signing of the U.S. Constitution
Re: current destination user in rules
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Tue, 2014-09-02 at 17:49 -0700, John Hardin wrote:
> On Wed, 3 Sep 2014, Karsten Bräckelmann wrote:
> > Using "personalized" domain names hardly scales up. No surprise, that
> > domain isn't registered. Probably just a broken template and soon to
> > vanish again?
>
> That's definitely a possibility. I've only gotten one like that and there
> were several URIs with *different* variants in the same email:
>
> Manage My OTCBB Mail
> https://jhardin83.org/policy/?qs=d27c0d440a8XXXXXXXX60ea44d136b6ec0cd0089
> | Unsubscribe
> https://jhardinE0368.org/policy/?qs=a03667e69XXXXXXXXd78280697656530ea7fdae9
>
> OTCBB Privacy Policy
> https://jhardinC7.org/policy/?qs=6eefc188XXXXXXXXe76a4268e1b75ff21431b4a1
>
> That strongly suggests a screw-up.
It does indeed.
And, well... You saw a pattern worth chasing in a single sample?
Seriously? :)
> However, "username in the third-level name part" is a little more likely
> to be a workable tactic (2ld mangled to get past SA on the mailing list):
>
> Flat-rate shipping offer inside | 48 hours ONLY!
> Can't see images? View online.
> http://jhardin.www
> foxnews areb.ru/?14F57=7cb1dbea6802XXXXXXXX1c8aebc91974fea34ef9
>
> That email used "jhardin.www foxnews areb.ru" for all the URIs. And that
> does resolve to an IP address right now.
>
> You're right about 2ld in URIBL, so maybe my idea that it was a
> URIBL-avoidance technique doesn't hold water. www foxnews areb.ru does hit
> URIBL_BLACK...
How exactly did you mangle the domain? Space instead of hyphen? Didn't
find a URIBL_BLACK listing right now.
Anyway, user.example.com is in no way different from www.example.com as
far as URI DNSBL listings are concerned. It *might* make a difference in
parsing and extracting the domain in the first place (affecting not only
SA, but any other URI detecting software), in case there is no leading
protocol. Which in this sample is -- and its absence would affect
software all over the place, including MUAs not linkify-ing them.
> So what's the point other than to tease rule makers? It looks like such a
> clear spam sign that I was captivated by it. :)
>
> > (For completeness, since you mentioned "username in body URIs", which
> > includes non-domain parts: Having the recipient's local address part in
> > the URI path or query string is common with ham, too.)
>
> Yeah, I'm well aware of that. This is purely to detect the username in the
> hostname, which is *very* unusual. Sorry if the short description I used
> was misleading, please substitute "username in body URI hostname".
It wasn't actually misleading, I really just added it for completeness.
I knew you should be well aware of it. Hence the parenthesis.
> > Regarding whether SA can use Perl variables in regex rules: Yes. Though
> > I'd consider it abuse and would oppose to doing so in officially hosted
> > rules (stock and sandbox).
> >
> > $ echo -e "\n uid=1000(kb)" | ./spamassassin -D -L --cf='body VAR /$</'
> > dbg: rules: ran body rule VAR ======> got hit: "1000"
>
> I didn't try generic language-provided variables like that, I tried some
> specific variables defined by SA and couldn't get it to work. I got a
> variable-related error message so I knew it was *trying* to get the
> variable's value but couldn't. I don't remember exactly what I tried, it
> was a little while ago and I didn't keep notes.
That was meant as a proof of concept. I was being lazy. ;)
Without actually trying, referencing SA internal variables should be
possible, too, I believe. It most likely would require some traversing
of object hashes -- $self usually doesn't hold what you're after, but a
$pms or similarly named hash entry, which in turn contains a reference
to...
> Plus, being able to use an application variable would help address the
> general desire to have a way to pass a capture from one rule to another.
I'd definitely prefer that to use some special markup, guided by tflags
enabling interpolation. Frankly, I'd probably be in favor of M::SA::Conf
preventing $variables from being expanded.
In related context: Do note that spamd's processing speed advantage over
the plain spamassassin executable is notably due to pre-compiling the
bulk of the regex rules. Variables might not hold the value you'd expect
during run-time, in particular WRT scan-specific per-user variables.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: current destination user in rules
Posted by John Hardin <jh...@impsec.org>.
On Wed, 3 Sep 2014, Karsten Bräckelmann wrote:
> On Tue, 2014-09-02 at 10:37 -0700, John Hardin wrote:
>> On Tue, 2 Sep 2014, Kevin A. McGrail wrote:
>
>>> Spamassassin has no idea who the email is destined to by username.
>>
>> OK, darn.
>>
>> The reason I ask is I've started to see spams with my username in body
>> URIs, for example:
>>
>> View as a webpage https://jhardin4874.org/policy/?qs=3Db15XXXXXXa89ab007c31d5ac410973dae95fd
>
> I wonder why.
>
> Using "personalized" domain names hardly scales up. No surprise, that
> domain isn't registered. Probably just a broken template and soon to
> vanish again?
That's definitely a possibility. I've only gotten one like that and there
were several URIs with *different* variants in the same email:
Manage My OTCBB Mail
https://jhardin83.org/policy/?qs=d27c0d440a8XXXXXXXX60ea44d136b6ec0cd0089
| Unsubscribe
https://jhardinE0368.org/policy/?qs=a03667e69XXXXXXXXd78280697656530ea7fdae9
OTCBB Privacy Policy
https://jhardinC7.org/policy/?qs=6eefc188XXXXXXXXe76a4268e1b75ff21431b4a1
That strongly suggests a screw-up.
However, "username in the third-level name part" is a little more likely
to be a workable tactic (2ld mangled to get past SA on the mailing list):
Flat-rate shipping offer inside | 48 hours ONLY!
Can't see images? View online.
http://jhardin.www
foxnews areb.ru/?14F57=7cb1dbea6802XXXXXXXX1c8aebc91974fea34ef9
That email used "jhardin.www foxnews areb.ru" for all the URIs. And that
does resolve to an IP address right now.
You're right about 2ld in URIBL, so maybe my idea that it was a
URIBL-avoidance technique doesn't hold water. www foxnews areb.ru does hit
URIBL_BLACK...
So what's the point other than to tease rule makers? It looks like such a
clear spam sign that I was captivated by it. :)
> (For completeness, since you mentioned "username in body URIs", which
> includes non-domain parts: Having the recipient's local address part in
> the URI path or query string is common with ham, too.)
Yeah, I'm well aware of that. This is purely to detect the username in the
hostname, which is *very* unusual. Sorry if the short description I used
was misleading, please substitute "username in body URI hostname".
>> Absent having the destination username available in a variable that could
>> be used in a RE, I suspect this is the best that can be done:
>>
>> full __RECIP_IN_URL m;^Received:[^:]{1,400}?\sfor\s<(\w+)\@.+?https?://\1\d*\.;ism
>>
>> ...in all its wince-worthy FULLness.
>
> I'd suggest a plugin. Well, if it is worth it at all...
>
>
> Regarding whether SA can use Perl variables in regex rules: Yes. Though
> I'd consider it abuse and would oppose to doing so in officially hosted
> rules (stock and sandbox).
>
> $ echo -e "\n uid=1000(kb)" | ./spamassassin -D -L --cf='body VAR /$</'
> dbg: rules: ran body rule VAR ======> got hit: "1000"
I didn't try generic language-provided variables like that, I tried some
specific variables defined by SA and couldn't get it to work. I got a
variable-related error message so I knew it was *trying* to get the
variable's value but couldn't. I don't remember exactly what I tried, it
was a little while ago and I didn't keep notes.
Plus, being able to use an application variable would help address the
general desire to have a way to pass a capture from one rule to another.
--
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
-----------------------------------------------------------------------
Gun Control laws cannot reduce violent crime, because gun control
laws assume a violent criminal will obey the law.
-----------------------------------------------------------------------
15 days until the 227th anniversary of the signing of the U.S. Constitution
Re: current destination user in rules
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Tue, 2014-09-02 at 10:37 -0700, John Hardin wrote:
> On Tue, 2 Sep 2014, Kevin A. McGrail wrote:
> > Spamassassin has no idea who the email is destined to by username.
>
> OK, darn.
>
> The reason I ask is I've started to see spams with my username in body
> URIs, for example:
>
> View as a webpage https://jhardin4874.org/policy/?qs=3Db15XXXXXXa89ab007c31d5ac410973dae95fd
I wonder why.
Using "personalized" domain names hardly scales up. No surprise, that
domain isn't registered. Probably just a broken template and soon to
vanish again?
(For completeness, since you mentioned "username in body URIs", which
includes non-domain parts: Having the recipient's local address part in
the URI path or query string is common with ham, too.)
> Absent having the destination username available in a variable that could
> be used in a RE, I suspect this is the best that can be done:
>
> full __RECIP_IN_URL m;^Received:[^:]{1,400}?\sfor\s<(\w+)\@.+?https?://\1\d*\.;ism
>
> ...in all its wince-worthy FULLness.
I'd suggest a plugin. Well, if it is worth it at all...
Regarding whether SA can use Perl variables in regex rules: Yes. Though
I'd consider it abuse and would oppose to doing so in officially hosted
rules (stock and sandbox).
$ echo -e "\n uid=1000(kb)" | ./spamassassin -D -L --cf='body VAR /$</'
dbg: rules: ran body rule VAR ======> got hit: "1000"
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: current destination user in rules
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Tue, 2014-09-02 at 15:11 -0700, John Hardin wrote:
> I've seen two versions: username(\d+)?.tld and username(\d+)?.2ld.tld
>
> The first would be subject to URIBL blacklisting, except spreading out the
> spamvertised domains across the targeted usernames could potentially
> dilute the reputation hit to the degree no one domain looks evil enough to
> list. It's also more expensive in terms of domain registration effort and
> costs (and I was somewhat surprised to see it based on that alone, but I
> may have an inaccurate appreciation for how much spammers are bothered by
> registering new domains).
>
> The second is less costly to register and is probably less likely to be
> blacklisted because reputation dilution is less expensive, and if the
With the second form, 2ld.tld would be blacklisted, not the full
personalized form.
> subdomains are under a "legit" domain (like perhaps blogspot.com) you
> won't be able to blacklist the entire second-level domain.
That's why there is util_rb_2tld (and util_rb_3tld). Useful with abused
blogspot.com type of mass-hosting, given URI DNSBL providers' support
and listing them, as happened before.
See 20_aux_tlds.cf, it actually contains blogspot.com. ;)
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: current destination user in rules
Posted by John Hardin <jh...@impsec.org>.
On Tue, 2 Sep 2014, Benny Pedersen wrote:
> John Hardin skrev den 2014-09-02 20:59:
>
>> But I was looking for alternatives to a FULL rule to detect "recipient
>> name in URI hostname" spams.
>
> yep got it now, the current plugin does not work with \d nummeric part of
> url, missed that point
>
>> Perhaps time for a plugin (or modification of the existing header
>> parser) to pull the recipient name (if any) out of trusted/internal
>> Received headers and save that into a perl variable, assuming that
>> perl variables that change from message to message can be used in
>> rules...
>
> you would like to strip nummerric part to detect forged domain ?, well for
> https its not forged :=)
No, that's not the point. The point is this is a way to programmatically
construct URLs that is very hard to write a generic rule for (or at least
expensive to check - see the FULL rule) and may be somewhat effective at
avoiding URIBL checks.
I've seen two versions: username(\d+)?.tld and username(\d+)?.2ld.tld
The first would be subject to URIBL blacklisting, except spreading out the
spamvertised domains across the targeted usernames could potentially
dilute the reputation hit to the degree no one domain looks evil enough to
list. It's also more expensive in terms of domain registration effort and
costs (and I was somewhat surprised to see it based on that alone, but I
may have an inaccurate appreciation for how much spammers are bothered by
registering new domains).
The second is less costly to register and is probably less likely to be
blacklisted because reputation dilution is less expensive, and if the
subdomains are under a "legit" domain (like perhaps blogspot.com) you
won't be able to blacklist the entire second-level domain.
It's not *quite* per-spam domains, but I don't think you can get a lot
closer.
Alex, is my assessment of how effective this might be in avoiding URIBL
listing at all realistic?
,lopl[=[]]]]]]]]][=[' ,llp[';/
[[]]]]]]]]'' <= Kali Miao sez "hi!"
--
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
-----------------------------------------------------------------------
End users want eye candy and the "ooo's and aaaahhh's" experience
when reading mail. To them email isn't a tool, but an entertainment
form. -- Steve Lake
-----------------------------------------------------------------------
15 days until the 227th anniversary of the signing of the U.S. Constitution
Re: current destination user in rules
Posted by Benny Pedersen <me...@junc.eu>.
John Hardin skrev den 2014-09-02 20:59:
> But I was looking for alternatives to a FULL rule to detect "recipient
> name in URI hostname" spams.
yep got it now, the current plugin does not work with \d nummeric part
of url, missed that point
> Perhaps time for a plugin (or modification of the existing header
> parser) to pull the recipient name (if any) out of trusted/internal
> Received headers and save that into a perl variable, assuming that
> perl variables that change from message to message can be used in
> rules...
you would like to strip nummerric part to detect forged domain ?, well
for https its not forged :=)
its imho more type of typesqauttering, but baying a ssl cert or make one
self is more work for the typesquatter, lets see
awl also use http urls, dont know if it tracks ips for it ?
Re: current destination user in rules
Posted by John Hardin <jh...@impsec.org>.
On Tue, 2 Sep 2014, Benny Pedersen wrote:
> On 2. sep. 2014 19.37.44 John Hardin <jh...@impsec.org> wrote:
>
>> View as a webpage
>> https://jhardin4874.org/policy/?qs=3Db15XXXXXXa89ab007c31d5ac410973dae95fd
>> Suggestions for alternatives welcomed.
>
> Time for a plugin that fetch ssl key info ?, and possible autolearn spam
> based on it?
Maybe.
But I was looking for alternatives to a FULL rule to detect "recipient
name in URI hostname" spams.
Perhaps time for a plugin (or modification of the existing header parser)
to pull the recipient name (if any) out of trusted/internal Received
headers and save that into a perl variable, assuming that perl variables
that change from message to message can be used in rules...
--
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
-----------------------------------------------------------------------
Vista: because the audio experience is *far* more important than
network throughput.
-----------------------------------------------------------------------
15 days until the 227th anniversary of the signing of the U.S. Constitution
Re: current destination user in rules
Posted by Benny Pedersen <me...@junc.eu>.
On 2. sep. 2014 19.37.44 John Hardin <jh...@impsec.org> wrote:
> View as a webpage
> https://jhardin4874.org/policy/?qs=3Db15XXXXXXa89ab007c31d5ac410973dae95fd
> Suggestions for alternatives welcomed.
Time for a plugin that fetch ssl key info ?, and possible autolearn spam
based on it?