Re: FreeMail plugin updated
On Thursday September 2 2010 01:52:28 Runbox wrote: > Would you please remove Runbox.com from that list as we have not been a > free email provider since 2001. > Kim Thanks, removed! Should propagate with the next sa-update. Mark
Re: FreeMail plugin updated
Hello, Would you please remove Runbox.com from that list as we have not been a free email provider since 2001. Kim -- View this message in context: http://old.nabble.com/FreeMail-plugin-updated-tp23468766p29599495.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Hidden Dir in URI (Was: FreeMail plugin updated - banks)
On Mon, 8 Mar 2010, Ned Slider wrote:
John Hardin wrote:
On Mon, 8 Mar 2010, Ned Slider wrote:
>
> So I've refined the rule to specifically exclude hitting on the sequence
> ../. which stops the rule triggering on multiple relative paths.
>
> uriLOCAL_URI_HIDDEN_DIR/(?!.{6}\.\.\/\..).{8}\/\../
How about:
uri LOCAL_URI_HIDDEN_DIRm;.{8}/\..(?!/);
Yes, that works too on my examples and is probably a more elegant solution
than mine :-)
John - are you able to try this rule in your sandbox and do mass checks? I'd
be interested to see how it scores.
I'll add it.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
---
Failure to plan ahead on someone else's part does not constitute
an emergency on my part. -- David W. Barts in a.s.r
---
6 days until Daylight Saving Time begins in U.S. - Spring Forward
Re: Hidden Dir in URI (Was: FreeMail plugin updated - banks)
John Hardin wrote:
On Mon, 8 Mar 2010, Ned Slider wrote:
So I've refined the rule to specifically exclude hitting on the
sequence ../. which stops the rule triggering on multiple relative paths.
uriLOCAL_URI_HIDDEN_DIR/(?!.{6}\.\.\/\..).{8}\/\../
How about:
uri LOCAL_URI_HIDDEN_DIRm;.{8}/\..(?!/);
Yes, that works too on my examples and is probably a more elegant
solution than mine :-)
John - are you able to try this rule in your sandbox and do mass checks?
I'd be interested to see how it scores.
Re: Hidden Dir in URI (Was: FreeMail plugin updated - banks)
On Mon, 8 Mar 2010, Ned Slider wrote:
Adam Katz wrote:
> > On 15-May-2009, at 12:46, Adam Katz wrote:
> > > uri URI_HIDDEN /.{7}\/\../
LuKreme wrote:
> > That won't catch
> > http://www.spammer.example.com/.../hidden-malware.asf, it will only
> > catch the relative url form "../path/to/content" which SA improperly
> > prefaces with "http://";
> >
> > uri URI_HIDDEN /.{8}\/\../
Works for me:
$ echo http://www.spammer.example.com/.../hidden-malware.asf |perl -ne
'$_ = "http://$_"; unless m{^[a-z]+://}; print "hits\n" if /.{8}\/\../'
hits
$
$ echo 'href="../not/a/hidden/directory"' |perl -ne '$_ = "http://$_";
unless m{^[a-z]+://}; print "hits\n" if /.{8}\/\../'
$
For some time now I've been running
uri LOCAL_URI_HIDDEN_DIR/.{8}\/\../
as discussed above and it works extremely well with few FPs.
However, today I did notice a FP on this type of URI with multiple relative
paths:
../../../../blah
So I've refined the rule to specifically exclude hitting on the sequence ../.
which stops the rule triggering on multiple relative paths.
uri LOCAL_URI_HIDDEN_DIR/(?!.{6}\.\.\/\..).{8}\/\../
How about:
uri LOCAL_URI_HIDDEN_DIRm;.{8}/\..(?!/);
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
---
Failure to plan ahead on someone else's part does not constitute
an emergency on my part. -- David W. Barts in a.s.r
---
6 days until Daylight Saving Time begins in U.S. - Spring Forward
Re: Hidden Dir in URI (Was: FreeMail plugin updated - banks)
Adam Katz wrote:
On 15-May-2009, at 12:46, Adam Katz wrote:
uri URI_HIDDEN /.{7}\/\../
LuKreme wrote:
That won't catch
http://www.spammer.example.com/.../hidden-malware.asf, it will only
catch the relative url form "../path/to/content" which SA improperly
prefaces with "http://";
uri URI_HIDDEN /.{8}\/\../
Works for me:
$ echo http://www.spammer.example.com/.../hidden-malware.asf |perl -ne
'$_ = "http://$_"; unless m{^[a-z]+://}; print "hits\n" if /.{8}\/\../'
hits
$
$ echo 'href="../not/a/hidden/directory"' |perl -ne '$_ = "http://$_";
unless m{^[a-z]+://}; print "hits\n" if /.{8}\/\../'
$
For some time now I've been running
uri LOCAL_URI_HIDDEN_DIR/.{8}\/\../
as discussed above and it works extremely well with few FPs.
However, today I did notice a FP on this type of URI with multiple
relative paths:
../../../../blah
So I've refined the rule to specifically exclude hitting on the sequence
../. which stops the rule triggering on multiple relative paths.
uri LOCAL_URI_HIDDEN_DIR/(?!.{6}\.\.\/\..).{8}\/\../
Tested, and all seems good so feel free to update if you're using this
rule locally.
Note: I'm still on 3.2.5 so I don't know if this rule ever got
officially picked up in 3.3.x
Re: FreeMail plugin updated - banks
>> On 15-May-2009, at 12:46, Adam Katz wrote:
>>> uri URI_HIDDEN /.{7}\/\../
LuKreme wrote:
>> That won't catch
>> http://www.spammer.example.com/.../hidden-malware.asf, it will only
>> catch the relative url form "../path/to/content" which SA improperly
>> prefaces with "http://";
>>
>> uri URI_HIDDEN /.{8}\/\../
Works for me:
$ echo http://www.spammer.example.com/.../hidden-malware.asf |perl -ne
'$_ = "http://$_"; unless m{^[a-z]+://}; print "hits\n" if /.{8}\/\../'
hits
$
$ echo 'href="../not/a/hidden/directory"' |perl -ne '$_ = "http://$_";
unless m{^[a-z]+://}; print "hits\n" if /.{8}\/\../'
$
LuKreme also wrote:
> http://example.com/.hidden/directory/
> scores: 3.0 URI_HIDDEN URI: Contains a link with a hidden ...
>
> href="../not/a/hidden/directory"
> does not match
That is the desired outcome, and it works as intended.
Re: FreeMail plugin updated - banks
On Fri, 15 May 2009, LuKreme wrote: Of course, if SA didn't preface URIs with http:// on its own, this wouldn't be an issue. However, I am not willing to call that a bug as I suspect there is a very good reason for it. It's a bug in the specific case of a URI like "../whatever", as it doesn't provide the base for the relative offset. In _most_ cases it's the right thing to do. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- A superior gunman is one who uses his superior judgment to keep himself out of situations that would require the use of his superior skills. --- 6 days until the 5th anniversary of SpaceshipOne winning the X-prize
Re: FreeMail plugin updated - banks
On 15-May-2009, at 14:35, LuKreme wrote:
On 15-May-2009, at 12:46, Adam Katz wrote:
uri URI_HIDDEN /.{7}\/\../
That won't catch http://www.spammer.example.com/.../hidden-
malware.asf, it will only catch the relative url form "../path/to/
content" which SA improperly prefaces with "http://";
uri URI_HIDDEN /.{8}\/\../
Some tests:
http://example.com/.hidden/directory/
scores:
* 3.0 URI_HIDDEN URI: Contains a link with a hidden directory
href="../not/a/hidden/directory"
does not match
--
<[TN]FBMachine> i got kicked out of Barnes and Noble once for
moving all the bibles into the fiction section
Re: FreeMail plugin updated - banks
On Fri, 15 May 2009, LuKreme wrote:
On 15-May-2009, at 12:46, Adam Katz wrote:
uri URI_HIDDEN /.{7}\/\../
That won't catch http://www.spammer.example.com/.../hidden-malware.asf,
How so? That rule matches "ple.com/.." in that URI.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
---
A superior gunman is one who uses his superior judgment to keep
himself out of situations that would require the use of his
superior skills.
---
6 days until the 5th anniversary of SpaceshipOne winning the X-prize
Re: FreeMail plugin updated - banks
On 15-May-2009, at 12:46, Adam Katz wrote:
uri URI_HIDDEN /.{7}\/\../
That won't catch http://www.spammer.example.com/.../hidden-
malware.asf, it will only catch the relative url form "../path/to/
content" which SA improperly prefaces with "http://";
uri URI_HIDDEN /.{8}\/\../
Will catch anything where the . appears after the very start of the URI
http://../whatever/goes/here# will NOT match
http://anything/.../goes# WILL match
Of course, if SA didn't preface URIs with http:// on its own, this
wouldn't be an issue. However, I am not willing to call that a bug as
I suspect there is a very good reason for it.
--
Heisenberg's only uncertainty was what pub to vomit in next and
Jung fancied Freud's mother too. -- Jared Earle
Re: FreeMail plugin updated - banks
On May 15, 2009, at 5:44, Adam Stephens wrote: LuKreme wrote: On 12-May-2009, at 18:27, John Hardin wrote: uri URI_HIDDEN/\/\../ Ah, that's very very nice. Scoring it at 3.0, too aggressive? I'd say so - I'm seeing lots of FPs on this, most prominently on mail from mail.elsevier-alerts.com Hmm. I will double check when I am at a computer, but I don't think this has flagged on any legit mail for my server. I'll do a mass grep and report back.
Re: FreeMail plugin updated - banks
John Hardin wrote: > What about an explicit "https://.."; URI? I have no problem marking that as spam (you're thinking too hard). >> I should also have noted that while this works around the SA bug, it >> also ignores hidden dirs and files appearing early in relative paths, >> like > > That href would get "http://"; prepended, though, would it not? Ah. My turn for having through too hard. I knew there was a reason I deleted that paragraph before writing it a second time... >> and of course it will have to be undone when SA patches that bug. > > Yup. However, I think that a hostname _that_ short is extremely unlikely > in real world spams/phishes. Some of the URL shorteners let you tack on extra characters. Or at least, I'd like them to.
Re: FreeMail plugin updated - banks
Adam Katz wrote:
Adam Katz wrote:
Relative URIs are only safe when prefacing the URI. Requiring the
protocol beforehand should do the trick. Since "http://"; is the
implied protocol and is 8 chars, we get this:
uri URI_HIDDEN /.{8}\/\../
Ned Slider wrote:
Yep - that works great for me and I understand the logic (I assume you
meant the protocol is a max of 8 chars as in "https://";).
I was initially thinking https, but it appears SA's "uri" always
converts relative URIs into "http://"; links, so we want a "7" there.
uri URI_HIDDEN /.{7}\/\../
I should also have noted that while this works around the SA bug, it
also ignores hidden dirs and files appearing early in relative paths,
like and of course it will have to be undone
when SA patches that bug.
But again wouldn't that be converted to http://a.bc/{dot}secret and
therefore hit the rule?
Please correct me if I'm wrong, but presumably the shortest possible
valid resolvable domain is 5 chars as in http://ab.cd/ so if we are
merely interested hidden subdirectories there must be a minimum of 12
characters before the slash-dot?
Anyway, I think I'm happy sticking with /.{8}\/\../
Re: FreeMail plugin updated - banks
On Fri, 15 May 2009, Adam Katz wrote:
Adam Katz wrote:
Relative URIs are only safe when prefacing the URI. Requiring the
protocol beforehand should do the trick. Since "http://"; is the
implied protocol and is 8 chars, we get this:
uri URI_HIDDEN /.{8}\/\../
Ned Slider wrote:
Yep - that works great for me and I understand the logic (I assume you
meant the protocol is a max of 8 chars as in "https://";).
I was initially thinking https, but it appears SA's "uri" always
converts relative URIs into "http://"; links, so we want a "7" there.
What about an explicit "https://.."; URI?
I should also have noted that while this works around the SA bug, it
also ignores hidden dirs and files appearing early in relative paths,
like
That href would get "http://"; prepended, though, would it not?
and of course it will have to be undone when SA patches that bug.
Yup. However, I think that a hostname _that_ short is extremely unlikely
in real world spams/phishes.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
---
The problem is when people look at Yahoo, slashdot, or groklaw and
jump from obvious and correct observations like "Oh my God, this
place is teeming with utter morons" to incorrect conclusions like
"there's nothing of value here".-- Al Petrofsky, in Y! SCOX
---
6 days until the 5th anniversary of SpaceshipOne winning the X-prize
Re: FreeMail plugin updated - banks
> Adam Katz wrote:
>> Relative URIs are only safe when prefacing the URI. Requiring the
>> protocol beforehand should do the trick. Since "http://"; is the
>> implied protocol and is 8 chars, we get this:
>>
>> uri URI_HIDDEN /.{8}\/\../
Ned Slider wrote:
> Yep - that works great for me and I understand the logic (I assume you
> meant the protocol is a max of 8 chars as in "https://";).
I was initially thinking https, but it appears SA's "uri" always
converts relative URIs into "http://"; links, so we want a "7" there.
uri URI_HIDDEN /.{7}\/\../
I should also have noted that while this works around the SA bug, it
also ignores hidden dirs and files appearing early in relative paths,
like and of course it will have to be undone
when SA patches that bug.
Re: FreeMail plugin updated - banks
Adam Katz wrote:
John Hardin wrote:
http://pastebin.com/m1268fbe6
Thanks. Here's the problematic URI:
http://../cd.asp?i=572550545&UserID=4DFEDDHIIBCFBH55
in the unsunscribe link.
Which was actually:
=2E/cd=2Easp?i=3D572550545=26UserID=3D4DFEDDHIIBCFBH55=22>
And thus:
This is *very* different from prefacing that with "http://"; (which is
apparently what the SA "uri" rule does).
Note to developers: that's a bug.
There should be some rule for noting relative paths in links (even if
it's scored 0.001), just as (IMHO) there should be one for things like
hrefs pointing at Windows paths or the file:/// protocol.
Granted, ".." is not a hidden directory.
I think it's almost as bad, as it obfuscates URLs; let's assume you've
got Microsoft's website whitelisted for some reason, or a spam filter
blacklists http://black-hat.example.com/live-exploits/* ...
http://pastebin.com/http://www.microsoft.com/../../../m1268fbe6
http://black-hat.example.com/cute-bunnies/../live-exploits/foo
This may even suggest that the "right way" to do it is to have SA
resolve the .. for us, handing the regex the corrected path.
Revised rule, to omit current directory and parent directory relative
URIs, while still hitting on "..." (which is pretty common):
uri URI_HIDDEN /\/\.(?!\.\/)[^\/]/i
Relative URIs are only safe when prefacing the URI. Requiring the
protocol beforehand should do the trick. Since "http://"; is the
implied protocol and is 8 chars, we get this:
uri URI_HIDDEN /.{8}\/\../
Yep - that works great for me and I understand the logic (I assume you
meant the protocol is a max of 8 chars as in "https://";).
or alternatively:
rawbody URI_HIDDEN /href=[^ >]{,99}\/\../i
Thank you John and Adam for the insightful discussion.
Re: FreeMail plugin updated - banks
John Hardin wrote:
>> http://pastebin.com/m1268fbe6
>
> Thanks. Here's the problematic URI:
>
>http://../cd.asp?i=572550545&UserID=4DFEDDHIIBCFBH55
>
> in the unsunscribe link.
Which was actually:
> =2E/cd=2Easp?i=3D572550545=26UserID=3D4DFEDDHIIBCFBH55=22>
And thus:
>
This is *very* different from prefacing that with "http://"; (which is
apparently what the SA "uri" rule does).
Note to developers: that's a bug.
There should be some rule for noting relative paths in links (even if
it's scored 0.001), just as (IMHO) there should be one for things like
hrefs pointing at Windows paths or the file:/// protocol.
> Granted, ".." is not a hidden directory.
I think it's almost as bad, as it obfuscates URLs; let's assume you've
got Microsoft's website whitelisted for some reason, or a spam filter
blacklists http://black-hat.example.com/live-exploits/* ...
http://pastebin.com/http://www.microsoft.com/../../../m1268fbe6
http://black-hat.example.com/cute-bunnies/../live-exploits/foo
This may even suggest that the "right way" to do it is to have SA
resolve the .. for us, handing the regex the corrected path.
> Revised rule, to omit current directory and parent directory relative
> URIs, while still hitting on "..." (which is pretty common):
>
>uri URI_HIDDEN /\/\.(?!\.\/)[^\/]/i
Relative URIs are only safe when prefacing the URI. Requiring the
protocol beforehand should do the trick. Since "http://"; is the
implied protocol and is 8 chars, we get this:
uri URI_HIDDEN /.{8}\/\../
or alternatively:
rawbody URI_HIDDEN /href=[^ >]{,99}\/\../i
Re: FreeMail plugin updated - banks
On Fri, 15 May 2009, Ned Slider wrote: John Hardin wrote: On Fri, 15 May 2009, Adam Stephens wrote: > > I'm seeing lots of FPs on this, most prominently on mail > from mail.elsevier-alerts.com Really? Sites are sending out legitimate URLs pointing to hidden directories? Could you post an example, please? This I gotta see... I don't so much think it's a case of them containing hidden dirs, but rather for some reason the rule misfires (maybe??). Anyway, here's an example I saw today where I can't see why the rule fired: http://pastebin.com/m1268fbe6 Thanks. Here's the problematic URI: http://../cd.asp?i=572550545&UserID=4DFEDDHIIBCFBH55 in the unsunscribe link. Granted, ".." is not a hidden directory. Revised rule, to omit current directory and parent directory relative URIs, while still hitting on "..." (which is pretty common): uri URI_HIDDEN /\/\.(?!\.\/)[^\/]/i -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- You cannot bring about prosperity by discouraging thrift. You cannot help small men by tearing down big men. You cannot strengthen the weak by weakening the strong. You cannot lift the wage-earner by pulling down the wage-payer. You cannot help the poor man by destroying the rich. You cannot keep out of trouble by spending more than your income. You cannot further the brotherhood of man by inciting class hatred. You cannot establish security on borrowed money. You cannot build character and courage by taking away men's initiative and independence. You cannot help men permanently by doing for them what they could and should do for themselves. -- William J. H. Boetcker --- 6 days until the 5th anniversary of SpaceshipOne winning the X-prize
Re: FreeMail plugin updated - banks
John Hardin wrote: On Fri, 15 May 2009, Ned Slider wrote: Adam Stephens wrote: LuKreme wrote: > On 12-May-2009, at 18:27, John Hardin wrote: > > uri URI_HIDDEN/\/\../ > > > Ah, that's very very nice. > > Scoring it at 3.0, too aggressive? > I'd say so - I'm seeing lots of FPs on this, most prominently on mail from mail.elsevier-alerts.com I saw a FP on this today also that I don't quite understand. I searched the text of the email and no matches against the string "\." were found (most likely as the encoding was quoted-printable) and manually checking the URIs didn't help much either. I'm not sure what's causing it to FP. Care to post the raw URI? Done, in reply to your last message :)
Re: FreeMail plugin updated - banks
On Fri, 15 May 2009, Ned Slider wrote: Adam Stephens wrote: LuKreme wrote: > On 12-May-2009, at 18:27, John Hardin wrote: > > uri URI_HIDDEN/\/\../ > > > Ah, that's very very nice. > > Scoring it at 3.0, too aggressive? > I'd say so - I'm seeing lots of FPs on this, most prominently on mail from mail.elsevier-alerts.com I saw a FP on this today also that I don't quite understand. I searched the text of the email and no matches against the string "\." were found (most likely as the encoding was quoted-printable) and manually checking the URIs didn't help much either. I'm not sure what's causing it to FP. Care to post the raw URI? -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- 6 days until the 5th anniversary of SpaceshipOne winning the X-prize
Re: FreeMail plugin updated - banks
John Hardin wrote: On Fri, 15 May 2009, Adam Stephens wrote: LuKreme wrote: On 12-May-2009, at 18:27, John Hardin wrote: > uri URI_HIDDEN/\/\../ Ah, that's very very nice. Scoring it at 3.0, too aggressive? I'd say so - I'm seeing lots of FPs on this, most prominently on mail from mail.elsevier-alerts.com Really? Sites are sending out legitimate URLs pointing to hidden directories? Could you post an example, please? This I gotta see... I don't so much think it's a case of them containing hidden dirs, but rather for some reason the rule misfires (maybe??). Anyway, here's an example I saw today where I can't see why the rule fired: http://pastebin.com/m1268fbe6
Re: FreeMail plugin updated - banks
Adam Stephens wrote: LuKreme wrote: On 12-May-2009, at 18:27, John Hardin wrote: uri URI_HIDDEN/\/\../ Ah, that's very very nice. Scoring it at 3.0, too aggressive? I'd say so - I'm seeing lots of FPs on this, most prominently on mail from mail.elsevier-alerts.com I believe if the rule is strict enough such that it doesn't FP, then a score of 3 is not inappropriate. The problem with the rule as it stands above is that it appears to be hitting on something other than /. in a URI I saw a FP on this today also that I don't quite understand. I searched the text of the email and no matches against the string "\." were found (most likely as the encoding was quoted-printable) and manually checking the URIs didn't help much either. I'm not sure what's causing it to FP. In the meantime I' going to revert to something closer to my original implementation which doesn't FP on the examples I have: uri URI_HIDDEN /\w/\.\w/
Re: FreeMail plugin updated - banks
On Fri, 15 May 2009, Adam Stephens wrote: LuKreme wrote: On 12-May-2009, at 18:27, John Hardin wrote: > uri URI_HIDDEN/\/\../ Ah, that's very very nice. Scoring it at 3.0, too aggressive? I'd say so - I'm seeing lots of FPs on this, most prominently on mail from mail.elsevier-alerts.com Really? Sites are sending out legitimate URLs pointing to hidden directories? Could you post an example, please? This I gotta see... -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- It is not the place of government to make right every tragedy and woe that befalls every resident of the nation. --- 6 days until the 5th anniversary of SpaceshipOne winning the X-prize
Re: FreeMail plugin updated - banks
LuKreme wrote: On 12-May-2009, at 18:27, John Hardin wrote: uri URI_HIDDEN/\/\../ Ah, that's very very nice. Scoring it at 3.0, too aggressive? I'd say so - I'm seeing lots of FPs on this, most prominently on mail from mail.elsevier-alerts.com -- Adam Stephens Network Specialist - Email & DNS adam.steph...@bristol.ac.uk
Re: FreeMail plugin updated
On Sun, May 10, 2009 at 01:08:29PM +0300, Henrik K wrote:
>
> http://sa.hege.li/FreeMail.pm (see inside for some documentation)
> http://sa.hege.li/FreeMail.cf (for some examples)
I've added suggestion for this:
header __freemail_reply eval:check_freemail_replyto('reply')
meta FREEMAIL_REPLY (__freemail_reply && !FREEMAIL_REPLYTO)
describe FREEMAIL_REPLY From and body are different freemails
score FREEMAIL_REPLY 1
There is lots of mail that doesn't have Reply-To, only different From+body.
You need to use the new 'reply' option for this, the original rule only
works if Reply-To exists.
Cheers,
Henrik
Re: FreeMail plugin updated - banks
neil wrote:
Hi;
Ned Slider wrote:
>First up, from Mike's inspiration above, I came up with these:
I took your rule and added some meta rules to it. I'm getting hits on
phishes, but I haven't seen any legitimate traffic hit it.
This may be that I have not seen any real bank mail or it could be that
it misses it completely.
I don't have time to test it fully right now, so play at your peril.
header __LOCAL_BANK_0eval:check_rbl_sub('dnswl-firsttrusted',
'127.0.2.\d+')
describe __LOCAL_BANK_0 Banks
tflags __LOCAL_BANK_0 nice net
header __LOCAL_BANK_1 eval:check_rbl_sub('dnswl-firsttrusted',
'127.0.3.\d+')
describe __LOCAL_BANK_1 Email service providers
tflags __LOCAL_BANK_1nice net
header __LOCAL_BANK_2 eval:check_rbl_sub('dnswl-firsttrusted',
'127.0.4.\d+')
describe __LOCAL_BANK_2 Organisations
tflags __LOCAL_BANK_2nice net
header __LOCAL_BANK_3 eval:check_rbl_sub('dnswl-firsttrusted',
'127.0.15.\d+')
describe __LOCAL_BANK_3 Email Marketing Providers
tflags __LOCAL_BANK_3nice net
headerLOCAL_FROM_BANKFrom:addr =~
/\@(abbey|abbeyinternational|abbeynational|abbey-online|alliance-leicester|bankofamerica|barclays|cahoot|cbonline|ci
tibank|co-operativebank|egg|firstdirect|halifax|hbos|hsbc|lloydstsb|llyodstsb|natwest|nationwide|newegg|neweggbank|northernbank|rbs|secure-halifax|woolwich|ybonline)\
.(com|co\.uk)/i
describeLOCAL_FROM_BANKFrom a bank
metaLOCAL_BANK_OK (LOCAL_FROM_BANK && (LOCAL_BANK_0 ||
LOCAL_BANK_1 || LOCAL_BANK_2 || LOCAL_BANK_3))
score LOCAL_BANK_OK -0.1
metaLOCAL_BANK_BAD (LOCAL_FROM_BANK && !(LOCAL_BANK_0 ||
LOCAL_BANK_1 || LOCAL_BANK_2 || LOCAL_BANK_3) )
score LOCAL_BANK_BAD 0.1
Rgds
n
Just did a couple quick lookups for a few legit bank emails, and those
that send directly from their own IP space passed the dnswl lookup, but
those having their mails delivered by third parties failed (not listed).
In the case I tested, as the rule stands above, neither (legitimate)
examples were hit by LOCAL_FROM_BANK (due to From being a subdomain),
and the third party mailer IP didn't hit any of your dnswl rules either.
I was thinking of combining LOCAL_FROM_BANK with meta rules for common
phrases appearing in phishing emails, much like the JM_SOUGHT rules.
Claims to be from a bank, and contains a common phishing phrase should
IMHO provide a pretty reliable indicator. Perhaps we need a
JM_SOUGHT_PHISH subset ;) (I'm happy to submit some samples)
But I still maintain we should be able produce/maintain a list of
legitimate banking (sub)domains that banks use to send mail so that any
others can be scored outright with a good degree of certainty (although
arguably the phishers might use such a list against us).
Re: FreeMail plugin updated - banks
Hi;
Ned Slider wrote:
>First up, from Mike's inspiration above, I came up with these:
I took your rule and added some meta rules to it. I'm getting hits on
phishes, but I haven't seen any legitimate traffic hit it.
This may be that I have not seen any real bank mail or it could be that
it misses it completely.
I don't have time to test it fully right now, so play at your peril.
header __LOCAL_BANK_0eval:check_rbl_sub('dnswl-firsttrusted',
'127.0.2.\d+')
describe __LOCAL_BANK_0 Banks
tflags __LOCAL_BANK_0 nice net
header __LOCAL_BANK_1 eval:check_rbl_sub('dnswl-firsttrusted',
'127.0.3.\d+')
describe __LOCAL_BANK_1 Email service providers
tflags __LOCAL_BANK_1nice net
header __LOCAL_BANK_2 eval:check_rbl_sub('dnswl-firsttrusted',
'127.0.4.\d+')
describe __LOCAL_BANK_2 Organisations
tflags __LOCAL_BANK_2nice net
header __LOCAL_BANK_3 eval:check_rbl_sub('dnswl-firsttrusted',
'127.0.15.\d+')
describe __LOCAL_BANK_3 Email Marketing Providers
tflags __LOCAL_BANK_3nice net
headerLOCAL_FROM_BANKFrom:addr =~
/\@(abbey|abbeyinternational|abbeynational|abbey-online|alliance-leicester|bankofamerica|barclays|cahoot|cbonline|ci
tibank|co-operativebank|egg|firstdirect|halifax|hbos|hsbc|lloydstsb|llyodstsb|natwest|nationwide|newegg|neweggbank|northernbank|rbs|secure-halifax|woolwich|ybonline)\
.(com|co\.uk)/i
describeLOCAL_FROM_BANKFrom a bank
metaLOCAL_BANK_OK (LOCAL_FROM_BANK && (LOCAL_BANK_0 ||
LOCAL_BANK_1 || LOCAL_BANK_2 || LOCAL_BANK_3))
score LOCAL_BANK_OK -0.1
metaLOCAL_BANK_BAD (LOCAL_FROM_BANK && !(LOCAL_BANK_0 ||
LOCAL_BANK_1 || LOCAL_BANK_2 || LOCAL_BANK_3) )
score LOCAL_BANK_BAD 0.1
Rgds
n
Mike Cardwell wrote:
Marc Perkel wrote:
Or maybe I'm trying to reinvent a wheel someone already has up and
running :-)
a bank without SPF or DKIM signing is NOT worth using
Yes - but I think what he's saying is that you have to start with a
list of bank domains, the test those domains with higher scrutiny.
Does such a list exist? One of my users was getting a lot of spam
pretending to be from banks. I ended up just compiling a regular
expression to match against the from header of the emails:
@([-a-zA-Z0-9\.]+[-\.])?(rbs|barclays|halifax|secure-halifax|hsbc|natwest|nationwide|northernbank|cbonline|ybonline|co-operativebank|bank-of-ireland|bankofengland|lloydstsb|bankofscotland|firstdirect|alliance-leicester|abbeynational|egg|new\.egg|woolwich|firsttrustbank|ulsterbank|citibank|icicibank)\.(com|co\.uk)
It's far from comprehensive obviously, but it covers most of what he
was receiving.
If that regular expression matches, and the connecting host is in a
list of what I refer to as "dodgy countries," then I reject the email.
OK, time for some rules to get this thread back on track :)
First up, from Mike's inspiration above, I came up with these:
headerLOCAL_FROM_BANKFrom:addr =~
/\@(abbey|abbeyinternational|abbeynational|abbey-online|alliance-leicester|bankofamerica|barclays|cahoot|cbonline|citibank|co-operativebank|egg|firstdirect|halifax|hbos|hsbc|lloydstsb|llyodstsb|natwest|nationwide|newegg|neweggbank|northernbank|rbs|secure-halifax|woolwich|ybonline)\.(com|co\.uk)/i
describeLOCAL_FROM_BANKFrom a bank
headerLOCAL_FROM_BANK_NETFrom:addr =~
/\@(abbey|abbeyinternational|abbeynational|abbey-online|alliance-leicester|bankofamerica|barclays|cahoot|cbonline|citibank|co-operativebank|egg|firstdirect|halifax|hbos|hsbc|lloydstsb|llyodstsb|natwest|nationwide|newegg|neweggbank|northernbank|rbs|secure-halifax|woolwich|ybonline)\.net/i
describeLOCAL_FROM_BANK_NETBanks don't send from .net
headerLOCAL_FROM_BANK_OBFFrom:addr =~
/\@(abbey|abbeyinternational|abbeynational|abbey-online|alliance-leicester|bankofamerica|barclays|cahoot|cbonline|citibank|co-operativebank|egg|firstdirect|halifax|hbos|hsbc|lloydstsb|llyodstsb|natwest|nationwide|newegg|neweggbank|northernbank|rbs|secure-halifax|woolwich|ybonline)[-a-zA-Z0-9]{1,5}\.(com|co\.uk|net)/i
describeLOCAL_FROM_BANK_OBFFrom an obfuscated bank like domain
Hopefully the last two are self explanatory, and with the first I
chose to only test the primary domain (as opposed to Mike's example
above) as I notice this matches the vast majority of phishing examples
I'm seeing, and most legitimate bank emails appear to be sent From
subdomains (eg, email.bank.com) so shouldn't trigger false positives
on this rule.
Maybe they could be further split into domains known never to send
legitimate mail to allow for higher scoring.
Now for some URI rules I've been experimenting with, again originating
from what I've observed in phishing examples, but maybe more widely
applicable (UK examples given but feel free to adapt to your
country/tld of choice):
uriLOCAL_URI_PHISH_UKm{https?://.{1,4
Re: FreeMail plugin updated
Henrik K wrote: >> When I run "spamassassin --lint" no problems are reported. Any thoughts >> on why this is happening only when updating the sought rules? > > It seems sa-update only lints the directory that it downloaded, thus no > freemail_domains cf is ever seen. I've now reduced the warning when linting, > v1.998 is up. Thanks Henrik, looks good now! Bill
Re: FreeMail plugin updated - banks
Ned Slider wrote:
uriLOCAL_URI_PHISH_UK3
m{https?://.{1,40}/.{1,60}\.(ac|co|gov)\.uk}
describeLOCAL_URI_PHISH_UK3contains obfuscated UK phish link of
form example.com/bank.co.uk
Ah, this rule hits on unsubscribe links etc, which wasn't what was
intended. For example:
example.com/unsubscribe.php?email=u...@example.co.uk
Re: FreeMail plugin updated
On Tue, May 12, 2009 at 07:25:26PM -0700, Bill Landry wrote: > Hi Henrik, > > > I've revamped fully the old code. Works still the same, but has some new > > functions. It's also a bit more careful when parsing body (new parser, > > emails inside <> are ignored, as well ones inside urls etc), so it might > > even reduce FPs and add hits, who knows. > > > > Domains are now separated from the plugin, so you should download the > > default list first: http://sa.hege.li/freemail_domains.cf - don't download > > too often, won't be probably that much updated. Also check out: > > http://www.rulesemporium.com/rules/90_sare_freemail.cf > > > > http://sa.hege.li/FreeMail.pm (see inside for some documentation) > > http://sa.hege.li/FreeMail.cf (for some examples) > > I'm wondering why sa-update has no problem with: > > sa-update --channelfile sare-sa-update-channels.txt > > > However, it complains when I try to update the sought rules: > > sa-update --channel sought.rules.yerp.org --gpgkey 6C6191E3 && echo > "Updated" > no freemail_domains entries defined, disabling plugin at > /etc/mail/spamassassin/FreeMail.pm line 301. > no freemail_domains entries defined, disabling plugin at > /etc/mail/spamassassin/FreeMail.pm line 301. > Updated > > When I run "spamassassin --lint" no problems are reported. Any thoughts > on why this is happening only when updating the sought rules? It seems sa-update only lints the directory that it downloaded, thus no freemail_domains cf is ever seen. I've now reduced the warning when linting, v1.998 is up. Cheers, Henrik
Re: FreeMail plugin updated - banks
On 12-May-2009, at 18:27, John Hardin wrote: uri URI_HIDDEN/\/\../ Ah, that's very very nice. Scoring it at 3.0, too aggressive? -- No matter how fast light travels it finds the darkness has always go there first, and is waiting for it.
Re: FreeMail plugin updated
Bill Landry wrote: > Hi Henrik, > >> I've revamped fully the old code. Works still the same, but has some new >> functions. It's also a bit more careful when parsing body (new parser, >> emails inside <> are ignored, as well ones inside urls etc), so it might >> even reduce FPs and add hits, who knows. >> >> Domains are now separated from the plugin, so you should download the >> default list first: http://sa.hege.li/freemail_domains.cf - don't download >> too often, won't be probably that much updated. Also check out: >> http://www.rulesemporium.com/rules/90_sare_freemail.cf >> >> http://sa.hege.li/FreeMail.pm (see inside for some documentation) >> http://sa.hege.li/FreeMail.cf (for some examples) > > I'm wondering why sa-update has no problem with: > > sa-update --channelfile sare-sa-update-channels.txt > > > However, it complains when I try to update the sought rules: > > sa-update --channel sought.rules.yerp.org --gpgkey 6C6191E3 && echo > "Updated" > no freemail_domains entries defined, disabling plugin at > /etc/mail/spamassassin/FreeMail.pm line 301. > no freemail_domains entries defined, disabling plugin at > /etc/mail/spamassassin/FreeMail.pm line 301. > Updated > > When I run "spamassassin --lint" no problems are reported. Any thoughts > on why this is happening only when updating the sought rules? Oh, and I forgot to mention that the plugin seems to be working just fine: grep -c "FREEMAIL_" /var/log/maillog 348 Bill
Re: FreeMail plugin updated
Hi Henrik, > I've revamped fully the old code. Works still the same, but has some new > functions. It's also a bit more careful when parsing body (new parser, > emails inside <> are ignored, as well ones inside urls etc), so it might > even reduce FPs and add hits, who knows. > > Domains are now separated from the plugin, so you should download the > default list first: http://sa.hege.li/freemail_domains.cf - don't download > too often, won't be probably that much updated. Also check out: > http://www.rulesemporium.com/rules/90_sare_freemail.cf > > http://sa.hege.li/FreeMail.pm (see inside for some documentation) > http://sa.hege.li/FreeMail.cf (for some examples) I'm wondering why sa-update has no problem with: sa-update --channelfile sare-sa-update-channels.txt However, it complains when I try to update the sought rules: sa-update --channel sought.rules.yerp.org --gpgkey 6C6191E3 && echo "Updated" no freemail_domains entries defined, disabling plugin at /etc/mail/spamassassin/FreeMail.pm line 301. no freemail_domains entries defined, disabling plugin at /etc/mail/spamassassin/FreeMail.pm line 301. Updated When I run "spamassassin --lint" no problems are reported. Any thoughts on why this is happening only when updating the sought rules? Thanks, Bill
Re: FreeMail plugin updated - banks
John Hardin wrote:
On Wed, 13 May 2009, Ned Slider wrote:
uriLOCAL_URI_HIDDEN_DIRm{https?://.{1,40}/\.\w}
describeLOCAL_URI_HIDDEN_DIRcontains hidden directory of form
example.com/.something
the fourth might be indicative of a hacked server with a hidden
phishing directory.
Any comments?
I've been running a hidden-dir rule for a long time; it gets pretty
steady hits on phishes and and I can't recall any FPs. Mine's somewhat
simpler:
uri URI_HIDDEN/\/\../
Note that a directory named "..." would not be caught by your rule.
Nice - Thanks John :-)
Re: FreeMail plugin updated - banks
On Wed, 13 May 2009, Ned Slider wrote:
uri LOCAL_URI_HIDDEN_DIRm{https?://.{1,40}/\.\w}
describe LOCAL_URI_HIDDEN_DIR contains hidden directory of form
example.com/.something
the fourth might be indicative of a hacked server with a hidden
phishing directory.
Any comments?
I've been running a hidden-dir rule for a long time; it gets pretty steady
hits on phishes and and I can't recall any FPs. Mine's somewhat simpler:
uri URI_HIDDEN/\/\../
Note that a directory named "..." would not be caught by your rule.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
---
Perfect Security and Absolute Safety are unattainable; beware
those who would try to sell them to you, regardless of the cost,
for they are trying to sell you your own slavery.
---
9 days until the 5th anniversary of SpaceshipOne winning the X-prize
Re: FreeMail plugin updated - banks
Mike Cardwell wrote:
Marc Perkel wrote:
Or maybe I'm trying to reinvent a wheel someone already has up and
running :-)
a bank without SPF or DKIM signing is NOT worth using
Yes - but I think what he's saying is that you have to start with a
list of bank domains, the test those domains with higher scrutiny.
Does such a list exist? One of my users was getting a lot of spam
pretending to be from banks. I ended up just compiling a regular
expression to match against the from header of the emails:
@([-a-zA-Z0-9\.]+[-\.])?(rbs|barclays|halifax|secure-halifax|hsbc|natwest|nationwide|northernbank|cbonline|ybonline|co-operativebank|bank-of-ireland|bankofengland|lloydstsb|bankofscotland|firstdirect|alliance-leicester|abbeynational|egg|new\.egg|woolwich|firsttrustbank|ulsterbank|citibank|icicibank)\.(com|co\.uk)
It's far from comprehensive obviously, but it covers most of what he was
receiving.
If that regular expression matches, and the connecting host is in a list
of what I refer to as "dodgy countries," then I reject the email.
OK, time for some rules to get this thread back on track :)
First up, from Mike's inspiration above, I came up with these:
header LOCAL_FROM_BANK From:addr =~
/\@(abbey|abbeyinternational|abbeynational|abbey-online|alliance-leicester|bankofamerica|barclays|cahoot|cbonline|citibank|co-operativebank|egg|firstdirect|halifax|hbos|hsbc|lloydstsb|llyodstsb|natwest|nationwide|newegg|neweggbank|northernbank|rbs|secure-halifax|woolwich|ybonline)\.(com|co\.uk)/i
describeLOCAL_FROM_BANK From a bank
header LOCAL_FROM_BANK_NET From:addr =~
/\@(abbey|abbeyinternational|abbeynational|abbey-online|alliance-leicester|bankofamerica|barclays|cahoot|cbonline|citibank|co-operativebank|egg|firstdirect|halifax|hbos|hsbc|lloydstsb|llyodstsb|natwest|nationwide|newegg|neweggbank|northernbank|rbs|secure-halifax|woolwich|ybonline)\.net/i
describeLOCAL_FROM_BANK_NET Banks don't send from .net
header LOCAL_FROM_BANK_OBF From:addr =~
/\@(abbey|abbeyinternational|abbeynational|abbey-online|alliance-leicester|bankofamerica|barclays|cahoot|cbonline|citibank|co-operativebank|egg|firstdirect|halifax|hbos|hsbc|lloydstsb|llyodstsb|natwest|nationwide|newegg|neweggbank|northernbank|rbs|secure-halifax|woolwich|ybonline)[-a-zA-Z0-9]{1,5}\.(com|co\.uk|net)/i
describeLOCAL_FROM_BANK_OBF From an obfuscated bank like domain
Hopefully the last two are self explanatory, and with the first I chose
to only test the primary domain (as opposed to Mike's example above) as
I notice this matches the vast majority of phishing examples I'm seeing,
and most legitimate bank emails appear to be sent From subdomains (eg,
email.bank.com) so shouldn't trigger false positives on this rule.
Maybe they could be further split into domains known never to send
legitimate mail to allow for higher scoring.
Now for some URI rules I've been experimenting with, again originating
from what I've observed in phishing examples, but maybe more widely
applicable (UK examples given but feel free to adapt to your country/tld
of choice):
uri LOCAL_URI_PHISH_UK m{https?://.{1,40}\.(ac|co|gov)\.uk\.\w}
describe LOCAL_URI_PHISH_UK contains obfuscated UK phish link of form
example.co.uk.something
uri LOCAL_URI_PHISH_UK2 m{https?://.{1,40}\.(ac|co|gov)-uk\.\w}
describe LOCAL_URI_PHISH_UK2 contains obfuscated UK phish link of form
example.co-uk.something
uri LOCAL_URI_PHISH_UK3
m{https?://.{1,40}/.{1,60}\.(ac|co|gov)\.uk}
describe LOCAL_URI_PHISH_UK3 contains obfuscated UK phish link of form
example.com/bank.co.uk
uri LOCAL_URI_HIDDEN_DIRm{https?://.{1,40}/\.\w}
describe LOCAL_URI_HIDDEN_DIR contains hidden directory of form
example.com/.something
The first two I've been running for a while and they pretty much catch
what they are intended to (I think that SA contains a similar rule for
.com already). The third rule is something I'm just testing and may be
prone to FPs, and the fourth might be indicative of a hacked server with
a hidden phishing directory.
Any comments?
Re: FreeMail plugin updated - banks
John Hardin a écrit : > On Tue, 12 May 2009, Ned Slider wrote: > >> Then you get phish where the From address is a bank domain, and the >> envelope address is from a completely unrelated domain with a valid >> spf record so even a simple From_Bank && spf_pass isn't going to work. > > That might make a useful general rule, though: SPF Pass and the From: > header in a different domain than the envelope From: address... > unfortunately, this doesn't "fix" the problem. you can get a phish with a from header = envelope sender = ... in a "typo squatted" domain, such as pajpal.com (the gangs are creative to find variants that get around filters that you set). while we do need to detect phishing at the email reception stage, we also need to detect the missed ones at the "use" stage (either via browser or via email if user sends his password). and even then, we still need to insist on the education side. one way is to intentionally send phishes (that is, trap your own users), and those users who get caught win a half day lesson...
Re: FreeMail plugin updated - banks
Marc Perkel a écrit :
>
>
> mouss wrote:
>> Is phishing really a problem for banks? I don't think so.
>
(I'll forgive you for snipping the rest of the paragraph, and thus
isolating a single phrase which was part of a context...).
> You're kidding right?
>
No. I never heard of a bank losing money or business because of phishing.
note that they do nothing against the use of stolen credit cards (which
causes a lot of spam and botnet attacks).
and a lot of phishes I get come from ISPs that have no business relaying
for *...@paypal and the like.
oh and worst, my own ISP relays phishes "against" itself (In short, I
get mail claiming to be from {admin|accounts|@free.fr relayed by ...
free.fr. sigh).
and why do I get mail like this:
Return-Path:
Received: from smtp2a.orange.fr (smtp2a.orange.fr [80.12.242.140])
..
orange.fr, the most important French operator, is relaying mail
submitted on its webmail (seen from other headers), on behalf of a
French bank?
once ISP/MSPs do something about phishing, I'll see what banks could do.
Until then, I prefer that my bank doesn't use "our money" in useless
experimentations.
we keep hearing of dkim, spf, and whatsnot. People belive in a lot of
gods (and the fact that the new gods get an RFC changes nothing). do you
really think the miscreants will say "oh, gee, they're using dkim now.
these guys are really good. I'll have to find a honest job now". come on...
Re: FreeMail plugin updated - banks
On Tuesday 12 May 2009, LuKreme wrote: >On 11-May-2009, at 17:20, Marc Perkel wrote: >> mouss wrote: >>> Is phishing really a problem for banks? I don't think so. >> >> You're kidding right? > >No, he has a point. The people with the problem are the customers. The >bank is at best neutral and at worst couldn't care less. > And likely won't care until such time as a customer, whose account was hacked and cleaned out, successfully sues for several millions. That gets their attention cuz it can be seen on the bottom line. I find my bank at least (and thank $DIETY it has no connection to a certain big one being bailed out, they truly haven't got a quarter to call anybody who might care) is very responsive to that which will cost them money. Years ago, when they first started doing the online thing, which I find handier than that famous button on the outhouse door, they supported windows XP and IE5 only and refused to help me with login details because I was running linux and mozilla (yeah, that is old) so I got in the truck and drove down there and offered to move my account across town. It was in the range of 25k at the time. Eyebrows went up, a long ways, and girls in cubicles were suddenly busy on the phones. 10 minutes later one of them came out with a printout that gave me an address that bypassed all their active directory crap & took me straight to the login screen. It worked, and is still working 7 or 8 years later. You just have to know how to talk to them, you do it with the only thing they grok, money. >Also, despite the amount of phishing, I think the vast majority of >data leaks come from the banks themselves, or from some stolen laptop >worth tens of thousands of customers's account info on it and no >encryption. This has been demoed very well, but without near enough ink from the MSM. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) The good (I am convinced, for one) Is but the bad one leaves undone. Once your reputation's done You can live a life of fun. -- Wilhelm Busch
Re: FreeMail plugin updated - banks
On 11-May-2009, at 17:20, Marc Perkel wrote: mouss wrote: Is phishing really a problem for banks? I don't think so. You're kidding right? No, he has a point. The people with the problem are the customers. The bank is at best neutral and at worst couldn't care less. Also, despite the amount of phishing, I think the vast majority of data leaks come from the banks themselves, or from some stolen laptop worth tens of thousands of customers's account info on it and no encryption. -- Nihil est--in vita priore ego imperator Romanus fui.
Re: FreeMail plugin updated - banks
On Mon, 2009-05-11 at 19:36 -0700, John Hardin wrote: > On Tue, 12 May 2009, Ned Slider wrote: > > > Then you get phish where the From address is a bank domain, and the > > envelope address is from a completely unrelated domain with a valid spf > > record so even a simple From_Bank && spf_pass isn't going to work. > > That might make a useful general rule, though: SPF Pass and the From: > header in a different domain than the envelope From: address... No, that's the way things like mail lists are supposed to work. And other useful things like fedex package notifications - you put your address in the message for Fedex to send, and they use fedex.com for the envelope address. Perfectly legal and expected behavior -- Daniel J McDonald, CCIE # 2495, CISSP # 78281, CNX www.austinenergy.com signature.asc Description: This is a digitally signed message part
Re: FreeMail plugin updated - banks
Hi; Ned Slider wrote: >My point is it's really not easy to track down such information even when banks do occasionally try to do the right thing. Maybe there is already a >list out there. If not, maybe we should compile one? It's hard work trying to do it by yourself, but done as a group it would make the task a lot >easier. I did a similar thing for exim. I made a list of popular UK banks that I had seen phished, then checked them against our local whitelist and DNSWL. I've submitted entries to DNSWL where needed. If you wish to continue along those lines then we can implement a more brutal form of SPF or at least give them a decent spam score :-) The false positives I've had have been staff mailing, using non public mail gateways and bulk mailers doing their mail shots. banks.txt: abbey.co.uk abbeynational.co.uk abbey.com alliance-leicester.co.uk ... etc exim snippet: warn log_message = BANK PHISHING sender_domains = +banks !dnslists = list.dnswl.org=127.0.2.0, 127.0.2.1, 127.0.2.2, 127.0.2.3, 127.0.3.2, 127.0.3.3, 127.0.4.2, 127.0.15.1,127.0.15.2 !dnslists = my-whitelist.example.com The admins at the banks seem to be blissfully ignorant of phishing and how to reduce it. You wont get a reply to mail you send so it is up to you to do what you can. Some are listed at rfc-ignorant, so you cant even report phishing without going through a call centre. Rgds N John Hardin wrote: On Mon, 11 May 2009, Marc Perkel wrote: mouss wrote: Is phishing really a problem for banks? I don't think so. You're kidding right? I think mouss' point is that if banks considered phishing "their problem" they would be pursuing effective technological and policy solutions like proper SPF and DKIM signing of their customer communications and not using random third-party mailing services for their email marketing, thus training their customers to accept email from any source as legitimate bank communication. Some do, but even then it's not easy to find. Take a popular UK bank (Barclays, for example) - they send emails from email.barclays.co.uk which does have an spf record and mails are signed. However, many phish claim to be from the primary domain which has no spf record so how would one know that subdomain even exists if one didn't have access to legitimate mails from this particular bank? They may send mails from other (sub)domains too for all I know. Another - natwest.com has an spf record but natwest.co.uk doesn't. So may I safely drop all email claiming to be from natwest.co.uk on the assumption that domain doesn't send mail? If it doesn't send mail, set the spf record to say so. Some banks provide minimal information on phishing, but it's more aimed at consumers and not the type of information that is of much use to email admins. My point is it's really not easy to track down such information even when banks do occasionally try to do the right thing. Maybe there is already a list out there. If not, maybe we should compile one? It's hard work trying to do it by yourself, but done as a group it would make the task a lot easier. I'm just frustrated at bank phish emails slipping through the system - they are so easy for us to spot yet there doesn't seem to be an easy reliable way to catch them. Really I just view them as more unwanted spam that I'd rather not have reach the inbox. I had to laugh earlier today - I saw one slip past virtually everything other than clamav that claimed to be from one bank in the subject, another in the From address, and contained a URL to a third bank! Then you get phish where the From address is a bank domain, and the envelope address is from a completely unrelated domain with a valid spf record so even a simple From_Bank && spf_pass isn't going to work.
Re: FreeMail plugin updated - banks
On Tue, 12 May 2009, Ned Slider wrote: Then you get phish where the From address is a bank domain, and the envelope address is from a completely unrelated domain with a valid spf record so even a simple From_Bank && spf_pass isn't going to work. That might make a useful general rule, though: SPF Pass and the From: header in a different domain than the envelope From: address... -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- If you ask amateurs to act as front-line security personnel, you shouldn't be surprised when you get amateur security. -- Bruce Schneier --- 10 days until the 5th anniversary of SpaceshipOne winning the X-prize
Re: FreeMail plugin updated - banks
John Hardin wrote: On Mon, 11 May 2009, Marc Perkel wrote: mouss wrote: Is phishing really a problem for banks? I don't think so. You're kidding right? I think mouss' point is that if banks considered phishing "their problem" they would be pursuing effective technological and policy solutions like proper SPF and DKIM signing of their customer communications and not using random third-party mailing services for their email marketing, thus training their customers to accept email from any source as legitimate bank communication. Some do, but even then it's not easy to find. Take a popular UK bank (Barclays, for example) - they send emails from email.barclays.co.uk which does have an spf record and mails are signed. However, many phish claim to be from the primary domain which has no spf record so how would one know that subdomain even exists if one didn't have access to legitimate mails from this particular bank? They may send mails from other (sub)domains too for all I know. Another - natwest.com has an spf record but natwest.co.uk doesn't. So may I safely drop all email claiming to be from natwest.co.uk on the assumption that domain doesn't send mail? If it doesn't send mail, set the spf record to say so. Some banks provide minimal information on phishing, but it's more aimed at consumers and not the type of information that is of much use to email admins. My point is it's really not easy to track down such information even when banks do occasionally try to do the right thing. Maybe there is already a list out there. If not, maybe we should compile one? It's hard work trying to do it by yourself, but done as a group it would make the task a lot easier. I'm just frustrated at bank phish emails slipping through the system - they are so easy for us to spot yet there doesn't seem to be an easy reliable way to catch them. Really I just view them as more unwanted spam that I'd rather not have reach the inbox. I had to laugh earlier today - I saw one slip past virtually everything other than clamav that claimed to be from one bank in the subject, another in the From address, and contained a URL to a third bank! Then you get phish where the From address is a bank domain, and the envelope address is from a completely unrelated domain with a valid spf record so even a simple From_Bank && spf_pass isn't going to work.
Re: FreeMail plugin updated - banks
On Mon, 11 May 2009, Marc Perkel wrote: mouss wrote: Is phishing really a problem for banks? I don't think so. You're kidding right? I think mouss' point is that if banks considered phishing "their problem" they would be pursuing effective technological and policy solutions like proper SPF and DKIM signing of their customer communications and not using random third-party mailing services for their email marketing, thus training their customers to accept email from any source as legitimate bank communication. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- A well educated Electorate, being necessary to the liberty of a free State, the Right of the People to Keep and Read Books, shall not be infringed. --- 10 days until the 5th anniversary of SpaceshipOne winning the X-prize
Re: FreeMail plugin updated - banks
mouss wrote: Is phishing really a problem for banks? I don't think so. You're kidding right?
Re: FreeMail plugin updated - banks
> > In the meantime I'm left working on the basis that for the large part, > > banks simply don't send email to my clients so *any* email claiming to > > be from a bank is immediately highly suspicious and could probably be > > scored well on the way to being spam. > > > > I personally use dedicated addresses for banks, amazon, ISPs, ... etc. > if they leak, I detect that (and I complain, disbale the address and > give them a new one). if they don't, their mail gets in. and all > forgeries to other addresses are caught. I setup a dedicated address for a bank once and only checked it from the server (no spyware, etc..) , and it got phished. The bank had a data-leak and lost a bunch of customer information to a malicious international group. I was amongst the first to know because I had a dedicated address for that banking purpose. -- /* Jason Philbrook | Midcoast Internet Solutions - Wireless and DSL KB1IOJ| Broadband Internet Access, Dialup, and Hosting http://f64.nu/ | for Midcoast Mainehttp://www.midcoast.com/ */
Re: FreeMail plugin updated - banks
Ned Slider a écrit :
> [snip]
> I
> would really like to see the creation of a tld along the lines of .bank,
> and make it like .gov or .edu (ac.uk) where only confirmed banks and
> financial institutions can register such domains.
my $devil{"advocate"}->mode = $status->enabled;
and after banks, operators/ISPs (.isp?). then next come amazon, ebay,
(what tld should we use here?). then come software and hardware
vendors (microsoft, cisco, ...), I guess a .vnd should do? then
consulting companies... etc. then at some point, we cover every organization
die $smiley->print;
> That combined with
> mandatory DKIM and/or spf would make it a lot easier to spot and stop
> the phishing but I think we are a long way from anything that
> coordinated actually happening.
>
> It's been said before on this list, but it doesn't help when banks have
> multiple domain names and often mix and match domains/URLs in the same
> email (goes to demonstrate their lack of understanding).
>
Is phishing really a problem for banks? I don't think so. Risk is their
job and they handle it in a way that always worked for them (push as
much losses to customers). As we say in .fr, "on ne change pas une
équipe qui gagne" (literally: "don't replace a winning team").
now, if every email user sends me 1 Euro, I'll open a bank and I promise
to setup DKIM, SPF and a whole lot of funny other things. and I'll make
it green, equitable, future-proof, crisis-resilient, here->map(%buz) ;-p
> In the meantime I'm left working on the basis that for the large part,
> banks simply don't send email to my clients so *any* email claiming to
> be from a bank is immediately highly suspicious and could probably be
> scored well on the way to being spam.
>
I personally use dedicated addresses for banks, amazon, ISPs, ... etc.
if they leak, I detect that (and I complain, disbale the address and
give them a new one). if they don't, their mail gets in. and all
forgeries to other addresses are caught.
Re: FreeMail plugin updated - banks
On 11-May-2009, at 03:11, Ned Slider wrote: My thinking is that combined as a meta with a few simple keywords/ phrases (eg, alert, security, account suspended etc) it might make a very effective rule against bank phish. The only thing that needs to be done to prevent bank phish is to check the sending host against the bank name or check the mail for auth. If they don't match, score 1000. There's no need to get into the body of the message at all. bankofamerica.com is not sending phishing spam. This does require a list of banks, but something like this should work (cribbed from Dave Pooser) whitelist_auth *...@paypal.com whitelist_auth *...@bankamerica.com header FROM_PAYPAL Received =~ /from @paypal\.com/ score FROM_PAYPAL 100 header FROM_BOA Received =~ /from @bankofamerica\.com/ score FROM_BOA 100 etc. -- From deep inside the tears that I'm forced to cry From deep inside the pain I--I chose to hide
Re: FreeMail plugin updated
On Sun, May 10, 2009 at 01:08:29PM +0300, Henrik K wrote: > > Hello, > > I've revamped fully the old code. Works still the same, but has some new > functions. It's also a bit more careful when parsing body (new parser, > emails inside <> are ignored, as well ones inside urls etc), so it might > even reduce FPs and add hits, who knows. > > Domains are now separated from the plugin, so you should download the > default list first: http://sa.hege.li/freemail_domains.cf - don't download > too often, won't be probably that much updated. Also check out: > http://www.rulesemporium.com/rules/90_sare_freemail.cf > > http://sa.hege.li/FreeMail.pm (see inside for some documentation) > http://sa.hege.li/FreeMail.cf (for some examples) Versions before 1.997 didn't skip messages by default when too many emails were found from body. You should download this new version, as the logic of (yet undocumented) freemail_skip_when_over_max setting was buggy also.. Also added a new example in FreeMail.cf to do more whitelisting. Feel free to post improvements to that or if you come up with nice metas to bump up score together with replyto. Cheers, Henrik
Re: FreeMail plugin updated - banks
Mike Cardwell wrote: Ned Slider wrote: Yes - but I think what he's saying is that you have to start with a list of bank domains, the test those domains with higher scrutiny. Does such a list exist? One of my users was getting a lot of spam pretending to be from banks. I ended up just compiling a regular expression to match against the from header of the emails: @([-a-zA-Z0-9\.]+[-\.])?(rbs|barclays|halifax|secure-halifax|hsbc|natwest|nationwide|northernbank|cbonline|ybonline|co-operativebank|bank-of-ireland|bankofengland|lloydstsb|bankofscotland|firstdirect|alliance-leicester|abbeynational|egg|new\.egg|woolwich|firsttrustbank|ulsterbank|citibank|icicibank)\.(com|co\.uk) It's far from comprehensive obviously, but it covers most of what he was receiving. If that regular expression matches, and the connecting host is in a list of what I refer to as "dodgy countries," then I reject the email. Yes, that's the type of thing I was thinking of Mike. I was thinking it might be easier to maintain as a plugin with a separate bank-domains.cf file listing banking type domains as Henrik has done for freemail, and then query a FROM_BANK type rule. That would be good yes. If the banks were serious about combating online fraud, you'd expect them to come together and agree on a standard for sending their email, eg they could all use DKIM. They should also publish a combined directory of their own domain names. Yes, there are loads of things banks /could/ do to make it easier to stop phishing, but for the most part they seem totally disinterested. I would really like to see the creation of a tld along the lines of .bank, and make it like .gov or .edu (ac.uk) where only confirmed banks and financial institutions can register such domains. That combined with mandatory DKIM and/or spf would make it a lot easier to spot and stop the phishing but I think we are a long way from anything that coordinated actually happening. It's been said before on this list, but it doesn't help when banks have multiple domain names and often mix and match domains/URLs in the same email (goes to demonstrate their lack of understanding). In the meantime I'm left working on the basis that for the large part, banks simply don't send email to my clients so *any* email claiming to be from a bank is immediately highly suspicious and could probably be scored well on the way to being spam.
Re: FreeMail plugin updated - banks
Ned Slider wrote: Yes - but I think what he's saying is that you have to start with a list of bank domains, the test those domains with higher scrutiny. Does such a list exist? One of my users was getting a lot of spam pretending to be from banks. I ended up just compiling a regular expression to match against the from header of the emails: @([-a-zA-Z0-9\.]+[-\.])?(rbs|barclays|halifax|secure-halifax|hsbc|natwest|nationwide|northernbank|cbonline|ybonline|co-operativebank|bank-of-ireland|bankofengland|lloydstsb|bankofscotland|firstdirect|alliance-leicester|abbeynational|egg|new\.egg|woolwich|firsttrustbank|ulsterbank|citibank|icicibank)\.(com|co\.uk) It's far from comprehensive obviously, but it covers most of what he was receiving. If that regular expression matches, and the connecting host is in a list of what I refer to as "dodgy countries," then I reject the email. Yes, that's the type of thing I was thinking of Mike. I was thinking it might be easier to maintain as a plugin with a separate bank-domains.cf file listing banking type domains as Henrik has done for freemail, and then query a FROM_BANK type rule. That would be good yes. If the banks were serious about combating online fraud, you'd expect them to come together and agree on a standard for sending their email, eg they could all use DKIM. They should also publish a combined directory of their own domain names. -- Mike Cardwell (https://secure.grepular.com/) (http://perlcv.com/)
Re: FreeMail plugin updated - banks
Mike Cardwell wrote: Marc Perkel wrote: Yes - but I think what he's saying is that you have to start with a list of bank domains, the test those domains with higher scrutiny. Does such a list exist? One of my users was getting a lot of spam pretending to be from banks. I ended up just compiling a regular expression to match against the from header of the emails: @([-a-zA-Z0-9\.]+[-\.])?(rbs|barclays|halifax|secure-halifax|hsbc|natwest|nationwide|northernbank|cbonline|ybonline|co-operativebank|bank-of-ireland|bankofengland|lloydstsb|bankofscotland|firstdirect|alliance-leicester|abbeynational|egg|new\.egg|woolwich|firsttrustbank|ulsterbank|citibank|icicibank)\.(com|co\.uk) It's far from comprehensive obviously, but it covers most of what he was receiving. If that regular expression matches, and the connecting host is in a list of what I refer to as "dodgy countries," then I reject the email. Yes, that's the type of thing I was thinking of Mike. I was thinking it might be easier to maintain as a plugin with a separate bank-domains.cf file listing banking type domains as Henrik has done for freemail, and then query a FROM_BANK type rule. My thinking is that combined as a meta with a few simple keywords/phrases (eg, alert, security, account suspended etc) it might make a very effective rule against bank phish. Heck, I've almost considered automatically quarantining *all* mail claiming to be FROM a bank domain and manually reinjecting those very rare legitimate examples I see on my server.
Re: FreeMail plugin updated - banks
Marc Perkel wrote: Or maybe I'm trying to reinvent a wheel someone already has up and running :-) a bank without SPF or DKIM signing is NOT worth using Yes - but I think what he's saying is that you have to start with a list of bank domains, the test those domains with higher scrutiny. Does such a list exist? One of my users was getting a lot of spam pretending to be from banks. I ended up just compiling a regular expression to match against the from header of the emails: @([-a-zA-Z0-9\.]+[-\.])?(rbs|barclays|halifax|secure-halifax|hsbc|natwest|nationwide|northernbank|cbonline|ybonline|co-operativebank|bank-of-ireland|bankofengland|lloydstsb|bankofscotland|firstdirect|alliance-leicester|abbeynational|egg|new\.egg|woolwich|firsttrustbank|ulsterbank|citibank|icicibank)\.(com|co\.uk) It's far from comprehensive obviously, but it covers most of what he was receiving. If that regular expression matches, and the connecting host is in a list of what I refer to as "dodgy countries," then I reject the email. -- Mike Cardwell (https://secure.grepular.com/) (http://perlcv.com/)
Re: FreeMail plugin updated
Just curious - how did you build that list? Henrik K wrote: Hello, I've revamped fully the old code. Works still the same, but has some new functions. It's also a bit more careful when parsing body (new parser, emails inside <> are ignored, as well ones inside urls etc), so it might even reduce FPs and add hits, who knows. Domains are now separated from the plugin, so you should download the default list first: http://sa.hege.li/freemail_domains.cf - don't download too often, won't be probably that much updated. Also check out: http://www.rulesemporium.com/rules/90_sare_freemail.cf http://sa.hege.li/FreeMail.pm (see inside for some documentation) http://sa.hege.li/FreeMail.cf (for some examples) PS. mail.fairbrass.de, please stop downloading it every 2 hours. It's not that wise to blindly download plugins anyway.. Cheers, Henrik
Re: FreeMail plugin updated - banks
Benny Pedersen wrote: On Sun, May 10, 2009 13:15, Ned Slider wrote: Or maybe I'm trying to reinvent a wheel someone already has up and running :-) a bank without SPF or DKIM signing is NOT worth using Yes - but I think what he's saying is that you have to start with a list of bank domains, the test those domains with higher scrutiny.
Re: FreeMail plugin updated
On Sun, May 10, 2009 13:15, Ned Slider wrote: > Or maybe I'm trying to reinvent a wheel someone already has up and > running :-) a bank without SPF or DKIM signing is NOT worth using -- http://localhost/ 100% uptime and 100% mirrored :)
Re: FreeMail plugin updated
Henrik K wrote: Hello, I've revamped fully the old code. Works still the same, but has some new functions. It's also a bit more careful when parsing body (new parser, emails inside <> are ignored, as well ones inside urls etc), so it might even reduce FPs and add hits, who knows. Domains are now separated from the plugin, so you should download the default list first: http://sa.hege.li/freemail_domains.cf - don't download too often, won't be probably that much updated. Also check out: http://www.rulesemporium.com/rules/90_sare_freemail.cf http://sa.hege.li/FreeMail.pm (see inside for some documentation) http://sa.hege.li/FreeMail.cf (for some examples) PS. mail.fairbrass.de, please stop downloading it every 2 hours. It's not that wise to blindly download plugins anyway.. Cheers, Henrik Nice :-) Sorry to immediately go slightly OT... I'm wondering if this could also be easily adapted for banking domains to use in anti-phishing rules? I see very little legitimate mail (claiming to be) from banking domains and am seriously considering applying a score to any email claiming to be from a bank (combined with some other simple rules as a meta). On smaller mail servers individual clients could be whitelisted on a case by case basis. Or maybe I'm trying to reinvent a wheel someone already has up and running :-)
FreeMail plugin updated
Hello, I've revamped fully the old code. Works still the same, but has some new functions. It's also a bit more careful when parsing body (new parser, emails inside <> are ignored, as well ones inside urls etc), so it might even reduce FPs and add hits, who knows. Domains are now separated from the plugin, so you should download the default list first: http://sa.hege.li/freemail_domains.cf - don't download too often, won't be probably that much updated. Also check out: http://www.rulesemporium.com/rules/90_sare_freemail.cf http://sa.hege.li/FreeMail.pm (see inside for some documentation) http://sa.hege.li/FreeMail.cf (for some examples) PS. mail.fairbrass.de, please stop downloading it every 2 hours. It's not that wise to blindly download plugins anyway.. Cheers, Henrik
