You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Marc Perkel <ma...@perkel.com> on 2009/05/10 15:40:54 UTC
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 - banks
Posted by jp <jp...@saucer.midcoast.com>.
> > 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 Maine http://www.midcoast.com/
*/
Re: FreeMail plugin updated - banks
Posted by "McDonald, Dan" <Da...@austinenergy.com>.
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
Re: FreeMail plugin updated - banks
Posted by mouss <mo...@ml.netoyen.net>.
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
Posted by John Hardin <jh...@impsec.org>.
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 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
-----------------------------------------------------------------------
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
Posted by neil <ne...@supanet.net.uk>.
Hi;
Ned Slider wrote:
<snip>
>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.
</snip>
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. <sigh>
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
Posted by Ned Slider <ne...@unixmail.co.uk>.
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
Posted by John Hardin <jh...@impsec.org>.
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 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
-----------------------------------------------------------------------
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
Posted by Gene Heskett <ge...@verizon.net>.
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
Posted by mouss <mo...@ml.netoyen.net>.
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: <NO...@creditmutuel.fr>
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
Posted by LuKreme <kr...@kreme.com>.
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
Posted by Marc Perkel <ma...@perkel.com>.
mouss wrote:
> Is phishing really a problem for banks? I don't think so.
>
You're kidding right?
Re: FreeMail plugin updated - banks
Posted by mouss <mo...@ml.netoyen.net>.
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
Posted by Ned Slider <ne...@unixmail.co.uk>.
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
Posted by Mike Cardwell <sp...@lists.grepular.com>.
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
Posted by LuKreme <kr...@kreme.com>.
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 - banks
Posted by Ned Slider <ne...@unixmail.co.uk>.
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
Posted by Ned Slider <ne...@unixmail.co.uk>.
John Hardin wrote:
> On Wed, 13 May 2009, Ned Slider wrote:
>
>> uri LOCAL_URI_HIDDEN_DIR m{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.
>
Nice - Thanks John :-)
Re: FreeMail plugin updated - banks
Posted by Ned Slider <ne...@unixmail.co.uk>.
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 <a href="a.bc/.secret"> 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
Posted by Adam Katz <an...@khopis.com>.
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 <a href="a.bc/.secret">
>
> 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
Posted by John Hardin <jh...@impsec.org>.
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 <a href="a.bc/.secret">
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 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
-----------------------------------------------------------------------
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
Posted by John Hardin <jh...@impsec.org>.
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 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
-----------------------------------------------------------------------
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
Posted by John Hardin <jh...@impsec.org>.
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 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
-----------------------------------------------------------------------
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: Hidden Dir in URI (Was: FreeMail plugin updated - banks)
Posted by John Hardin <jh...@impsec.org>.
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.
>> >
>> > uri LOCAL_URI_HIDDEN_DIR /(?!.{6}\.\.\/\..).{8}\/\../
>>
>> How about:
>>
>> uri LOCAL_URI_HIDDEN_DIR m;.{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 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
-----------------------------------------------------------------------
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
Posted by Ned Slider <ne...@unixmail.co.uk>.
John Hardin wrote:
> 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.
>>> > > uri LOCAL_URI_HIDDEN_DIR /(?!.{6}\.\.\/\..).{8}\/\../
>>>
>>> How about:
>>>
>>> uri LOCAL_URI_HIDDEN_DIR m;.{8}/\..(?!/);
>>
>> Yes, that works too on my examples and is probably a more elegant
>> solution than mine :-)
>>
Having done a little more testing, I can confirm this variant is more
accurate than my revision above.
>
> It took a little more work to generate a clean rule and it's somewhat
> more complex than the above.
>
> uri URI_HIDDEN_2 m;.{8}(?:[/\\]|%(?i:5c|2f))(?!\.\.?[/%\\])\..;
>
> Winders generates (and accepts) URIs with backslashes as directory
> separators (in violation of the URI RFC? I'll have to look) and URIs can
> have encoded directory separators (e.g. %2F).
>
and your latest revision (above) performs as expected on my small
collection of hidden_dir ham/spam, hitting on all the spam and missing
the potential FPs (containing relative paths etc). I'm currently running
both rules for further comparative testing.
> A comparison between the older version that hits on /../ and the version
> that does not shows the somewhat counterintuituve result that hitting on
> /../ gives marginally better results (at least, as far as ruleqa is
> concerned). Sure, it's not _really_ a hidden directory, but it has false
> hits on spam to a greater degree than it does on ham, so the S/O ratio
> is better and the overall hits are higher...
>
> http://ruleqa.spamassassin.org/?rule=%2FURI_HIDDEN
>
Interesting and indeed not what one might expect.
Re: Hidden Dir in URI
Posted by John Hardin <jh...@impsec.org>.
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.
>> >
>> > uri LOCAL_URI_HIDDEN_DIR /(?!.{6}\.\.\/\..).{8}\/\../
>>
>> How about:
>>
>> uri LOCAL_URI_HIDDEN_DIR m;.{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.
It took a little more work to generate a clean rule and it's somewhat more
complex than the above.
uri URI_HIDDEN_2 m;.{8}(?:[/\\]|%(?i:5c|2f))(?!\.\.?[/%\\])\..;
Winders generates (and accepts) URIs with backslashes as directory
separators (in violation of the URI RFC? I'll have to look) and URIs can
have encoded directory separators (e.g. %2F).
A comparison between the older version that hits on /../ and the version
that does not shows the somewhat counterintuituve result that hitting on
/../ gives marginally better results (at least, as far as ruleqa is
concerned). Sure, it's not _really_ a hidden directory, but it has false
hits on spam to a greater degree than it does on ham, so the S/O ratio is
better and the overall hits are higher...
http://ruleqa.spamassassin.org/?rule=%2FURI_HIDDEN
--
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
-----------------------------------------------------------------------
Failure to plan ahead on someone else's part does not constitute
an emergency on my part. -- David W. Barts in a.s.r
-----------------------------------------------------------------------
Tomorrow: Daylight Saving Time begins in U.S. - Spring Forward
Re: Hidden Dir in URI (Was: FreeMail plugin updated - banks)
Posted by Ned Slider <ne...@unixmail.co.uk>.
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.
>>
>> uri LOCAL_URI_HIDDEN_DIR /(?!.{6}\.\.\/\..).{8}\/\../
>
> How about:
>
> uri LOCAL_URI_HIDDEN_DIR m;.{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)
Posted by John Hardin <jh...@impsec.org>.
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_DIR m;.{8}/\..(?!/);
--
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
-----------------------------------------------------------------------
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)
Posted by Ned Slider <ne...@unixmail.co.uk>.
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
Posted by Adam Katz <an...@khopis.com>.
>> 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
Posted by LuKreme <kr...@kreme.com>.
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
Posted by LuKreme <kr...@kreme.com>.
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
Posted by Adam Katz <an...@khopis.com>.
> 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 <a href="a.bc/.secret"> and of course it will have to be undone
when SA patches that bug.
Re: FreeMail plugin updated - banks
Posted by Ned Slider <ne...@unixmail.co.uk>.
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:
>
>> <a href=3D=22=2E=
>> =2E/cd=2Easp?i=3D572550545=26UserID=3D4DFEDDHIIBCFBH55=22>
>
> And thus:
>
>> <a href="../cd.asp?i=572550545&UserID=4DFEDDHIIBCFBH55">
>
> 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
Posted by Adam Katz <an...@khopis.com>.
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:
> <a href=3D=22=2E=
> =2E/cd=2Easp?i=3D572550545=26UserID=3D4DFEDDHIIBCFBH55=22>
And thus:
> <a href="../cd.asp?i=572550545&UserID=4DFEDDHIIBCFBH55">
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
Posted by John Hardin <jh...@impsec.org>.
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 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
-----------------------------------------------------------------------
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
Posted by Ned Slider <ne...@unixmail.co.uk>.
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
Posted by John Hardin <jh...@impsec.org>.
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 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
-----------------------------------------------------------------------
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
Posted by Ned Slider <ne...@unixmail.co.uk>.
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
Posted by John Hardin <jh...@impsec.org>.
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 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
-----------------------------------------------------------------------
6 days until the 5th anniversary of SpaceshipOne winning the X-prize
Re: FreeMail plugin updated - banks
Posted by Ned Slider <ne...@unixmail.co.uk>.
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
Posted by LuKreme <kr...@kreme.com>.
On May 15, 2009, at 5:44, Adam Stephens <ad...@bristol.ac.uk>
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
Posted by Adam Stephens <ad...@bristol.ac.uk>.
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.stephens@bristol.ac.uk
Re: FreeMail plugin updated - banks
Posted by LuKreme <kr...@kreme.com>.
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 - banks
Posted by John Hardin <jh...@impsec.org>.
On Wed, 13 May 2009, Ned Slider wrote:
> uri LOCAL_URI_HIDDEN_DIR m{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 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
-----------------------------------------------------------------------
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
Posted by Ned Slider <ne...@unixmail.co.uk>.
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_0 eval: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_1 nice net
>
> header __LOCAL_BANK_2 eval:check_rbl_sub('dnswl-firsttrusted',
> '127.0.4.\d+')
> describe __LOCAL_BANK_2 Organisations
> tflags __LOCAL_BANK_2 nice 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_3 nice net
>
> header LOCAL_FROM_BANK From: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
> describe LOCAL_FROM_BANK From a bank
>
> meta LOCAL_BANK_OK (LOCAL_FROM_BANK && (LOCAL_BANK_0 ||
> LOCAL_BANK_1 || LOCAL_BANK_2 || LOCAL_BANK_3))
> score LOCAL_BANK_OK -0.1
>
> meta LOCAL_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
Posted by neil <ne...@supanet.net.uk>.
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_0 eval: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_1 nice net
header __LOCAL_BANK_2 eval:check_rbl_sub('dnswl-firsttrusted',
'127.0.4.\d+')
describe __LOCAL_BANK_2 Organisations
tflags __LOCAL_BANK_2 nice 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_3 nice net
header LOCAL_FROM_BANK From: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
describe LOCAL_FROM_BANK From a bank
meta LOCAL_BANK_OK (LOCAL_FROM_BANK && (LOCAL_BANK_0 ||
LOCAL_BANK_1 || LOCAL_BANK_2 || LOCAL_BANK_3))
score LOCAL_BANK_OK -0.1
meta LOCAL_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:
>
> 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
>
> describe LOCAL_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
>
> describe LOCAL_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
>
> describe LOCAL_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_DIR m{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
Posted by Ned Slider <ne...@unixmail.co.uk>.
Ned Slider wrote:
>
> 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
>
Ah, this rule hits on unsubscribe links etc, which wasn't what was
intended. For example:
example.com/unsubscribe.php?email=user@example.co.uk
Re: FreeMail plugin updated - banks
Posted by Ned Slider <ne...@unixmail.co.uk>.
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
describe LOCAL_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
describe LOCAL_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
describe LOCAL_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_DIR m{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
Posted by Mike Cardwell <sp...@lists.grepular.com>.
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/)