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}\.
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 LOC
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/c
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_HID
>> 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_H
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
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://";
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.
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
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.el
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 hre
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
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 w
> 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 un
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 *ve
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*
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 pos
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 o
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 pro
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
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 believ
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-
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
--
--
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
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 misse
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:
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.
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 directo
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?
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
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 m
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 losin
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 wo
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 amou
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 i
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 w
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:
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
sol
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 S
mouss wrote:
Is phishing really a problem for banks? I don't think so.
You're kidding right?
> > 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 dedica
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
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
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 compili
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
expressi
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 compi
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.
Do
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
48 matches
Mail list logo