headers
Laurelai | 1 Sep 2011 03:32

A bit shocked nobody has posted this yet - Security breach at kernel.org

https://pastebin.com/BKcmMd47 see also https://www.kernel.org/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Permalink | Reply | 1 comment |
headers
GloW - XD | 1 Sep 2011 04:12
Picon

Re: A bit shocked nobody has posted this yet - Security breach at kernel.org

haha.
xd


On 1 September 2011 11:32, Laurelai <laurelai <at> oneechan.org> wrote:
https://pastebin.com/BKcmMd47 see also https://www.kernel.org/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Permalink | Reply | 0 comments |
headers
Patrick Webster | 1 Sep 2011 04:47
Gravatar

Re: INSECT Pro - Free tool for pentest - New version release 2.7

Ahem, http://mail.metasploit.com/pipermail/framework/2010-September/006889.html

A bit of msf licensing history is mentioned here (and abuses):
http://blog.metasploit.com/2008/10/metasploit-32-bsd-licensing.html

"The new license will lead to commercial abuse, but I believe that the
project is now strong enough to succeed even with competition from
commercial entities that are using our source code. The key to our
success is the Metasploit community and our dedication to sharing
security information (and code) in a timely fashion. Metasploit is
great at destroying FUD, whether the source is an incompetent product
vendor or a media-happy security company. "

-Patrick

On Thu, Sep 1, 2011 at 3:51 AM,  <Valdis.Kletnieks <at> vt.edu> wrote:
> On Wed, 31 Aug 2011 14:34:58 -0300, root said:
>
>> That file is under the msf3 tree, if Insect pro is violating GPL,
>> Metasploit is also doing it (and everything including it, like 80% of
>> security frameworks out there), remember MSF is BSD licensed.
>
> And even the top-level Metasploit HACKING says:
>
>   By submitting code contributions to the Metasploit Project it is
>   assumed that you are offering your code under a BSD or similar
>   license.  MIT and Ruby Licenses are also fine.  We specifically cannot
>   include GPL code. LGPL code is accepted on a case by case basis for
>   libraries only and is never accepted for modules.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Permalink | Reply | 0 comments |
headers
Fernando Gont | 1 Sep 2011 10:51
Favicon

More on IPv6 RA-Guard evasion (IPv6 security)

Folks,

We have posted on the SI6 Networks blog more information about IPv6
RA-Guard evasion, including pointers to the recent presentations at IETF 81.

The post is available at:
http://blog.si6networks.com/2011/09/router-advertisement-guard-ra-guard.html

P.S.: In case you haven't, you may want to join the IPv6 Hackers
mailing-list: http://www.si6networks.com/community/mailing-lists.html

Thanks!

Best regards,
--

-- 
Fernando Gont
SI6 Networks
e-mail: fgont <at> si6networks.com
web: http://www.si6networks.com

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Permalink | Reply | 0 comments |
headers
Dan Luedtke | 1 Sep 2011 11:34

Re: HP A-series switches are affected, too. [WAS: More on IPv6 RA-Guard evasion (IPv6 security)]

Hello Fernando, hello list,

you addressed a problem that many vendors suffer from at the moment.
Marc Heuse discovered this vulnerability, i guess, and he has
published a nice collection of tools to generate the packets mentioned
in your article.
More on that: http://thc.org/thc-ipv6/

Based on Marc's ideas I tested the mentioned attack on Hewlett
Packard's A-series switches, and I have to say that these attacks were
successful. That stopped us from implementing IPv6 for a while in our
network.

If you are interested, you can obtain my thesis as PDF-document here
https://www.danrl.de/dl/bachelor-thesis-luedtke.pdf
(Chapter Edge-Level might be the one of your interest)

By the way, I don't think it is a good idea to disallow any Extension
Headers in ND-Messages, I'd like switches to discard ND-Messages with
more that e.g. 3 chained headers. But that is another conversation...
I subscribed to the IPv6 Hackers mailing list, maybe we will have some
discussion about that over there.

regards,
  danrl

--
danrl / Dan Luedtke
http://www.danrl.de

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Permalink | Reply | 0 comments |
headers
Fernando Gont | 1 Sep 2011 12:10
Favicon

Re: HP A-series switches are affected, too. [WAS: More on IPv6 RA-Guard evasion (IPv6 security)]

Hi, Dan,

On 09/01/2011 06:32 AM, Dan Luedtke wrote:
> you addressed a problem that many vendors suffer from at the moment.
> Marc Heuse discovered this vulnerability, i guess, 

FWIW, "publicly-released first" != "discovered" (ask Cisco's PSIRT if in
doubt) -- anyway, I'm just trying to trigger discussion and get feedback...

> Based on Marc's ideas I tested the mentioned attack on Hewlett
> Packard's A-series switches, and I have to say that these attacks were
> successful. That stopped us from implementing IPv6 for a while in our
> network.

Do they ship with "RA-Guard"? -- Note that "hosts being vulnerable to
RA-based attacks" does not imply a vulnerable RA-Guard implementation.
The layer-2 might simply not ship with RA-Guard, it could ship with it
but not be enabled, etc.

Anyway... I'd bet that every implementation that "followed" the spec is
vulnerable....

> If you are interested, you can obtain my thesis as PDF-document here
> https://www.danrl.de/dl/bachelor-thesis-luedtke.pdf
> (Chapter Edge-Level might be the one of your interest)

Will certainly take a look. Thanks!

> By the way, I don't think it is a good idea to disallow any Extension
> Headers in ND-Messages, 

Consensus at the relevant IETF working-group (6man) seems to be to only
ban the Fragment Header (when SEND is not employed).

A more conservative approach would be to simply require that the
upper-layer header be present in the first fragment. (i.e., that the
first fragment contains all the information that you need to apply an ACL).

> I'd like switches to discard ND-Messages with
> more that e.g. 3 chained headers. 

The point was that this could be expensive (if at all possible) for the
RA-Guard implementation to do.

> But that is another conversation...
> I subscribed to the IPv6 Hackers mailing list, maybe we will have some
> discussion about that over there.

Yep... will post something right now, and see if that triggers discussion.

Thanks!

Best regards,
--

-- 
Fernando Gont
SI6 Networks
e-mail: fgont <at> si6networks.com
web: http://www.si6networks.com

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Permalink | Reply | 3 comments |
headers
Dan Luedtke | 1 Sep 2011 12:44

Re: HP A-series switches are affected, too. [WAS: More on IPv6 RA-Guard evasion (IPv6 security)]

Hello Fernando,

On Thu, Sep 1, 2011 at 12:10 PM, Fernando Gont <fgont <at> si6networks.com> wrote:
>> Based on Marc's ideas I tested the mentioned attack on Hewlett
>> Packard's A-series switches, and I have to say that these attacks were
>> successful. That stopped us from implementing IPv6 for a while in our
>> network.
>
> Do they ship with "RA-Guard"? -- Note that "hosts being vulnerable to
> RA-based attacks" does not imply a vulnerable RA-Guard implementation.
> The layer-2 might simply not ship with RA-Guard, it could ship with it
> but not be enabled, etc.
I have to admit, I was a little bit sloppy about the term RA-Guard.
Every vendors has another name for the feature that *should* provide
protection from faked Router Advertisements, technically it is
sometimes like RA-Guard, in reality it is often a simple ACL wrapped
in a shiny new command. HP tried to implement it in their "Neighbor
Discovery Detection" feature of Comware, and they succeeded partly.
One has to craft some nasty packets to circumvent their protection,
but one still is able to do so.

> Anyway... I'd bet that every implementation that "followed" the spec is
> vulnerable....
Unfortunately :(

>> By the way, I don't think it is a good idea to disallow any Extension
>> Headers in ND-Messages,
>
> Consensus at the relevant IETF working-group (6man) seems to be to only
> ban the Fragment Header (when SEND is not employed).
I'd like to discuss this further, there are many options and I really
like to read other's opinions on that. Disallowing Fragmentation
Headers might break some stack implementations (but hopefully only in
some situations). On the other hand, (virtually) reassembling IPv6
packets on a layer2 device is expensive.

I'll have a look on ipv6-hackers as soon as I am back from vacation.

> Yep... will post something right now, and see if that triggers discussion.
Thanks!

regards,
   danrl
--

-- 
danrl / Dan Luedtke
http://www.danrl.de

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Permalink | Reply | 0 comments |
headers
Marc Heuse | 1 Sep 2011 12:59
Picon
Favicon

Re: HP A-series switches are affected, too. [WAS: More on IPv6 RA-Guard evasion (IPv6 security)]


Am 01.09.2011 12:10, schrieb Fernando Gont:
> On 09/01/2011 06:32 AM, Dan Luedtke wrote:
>> you addressed a problem that many vendors suffer from at the moment.
>> Marc Heuse discovered this vulnerability, i guess, 
> 
> FWIW, "publicly-released first" != "discovered" (ask Cisco's PSIRT if in
> doubt) -- anyway, I'm just trying to trigger discussion and get feedback...

when I reported to PSIRT they were not aware of the issue - so who
called them first is unsettled :-) - however I published first ;-)

> Anyway... I'd bet that every implementation that "followed" the spec is
> vulnerable....

it is not mentioned in the RFC that an interface does have to support
unlimited autoconfigurated addresses on its interfaces, nor does it
state an upper limit. so its undefined and up to the implementor. And
those who thought about it and saw the DOS coming (Solaris, OpenBSD) put
limits, others didnt (everybody else).

>> If you are interested, you can obtain my thesis as PDF-document here
>> https://www.danrl.de/dl/bachelor-thesis-luedtke.pdf
>> (Chapter Edge-Level might be the one of your interest)

 <at> dan: nice paper.
ScreenOS has several DOS issues in their IPv6 implementation btw

>> By the way, I don't think it is a good idea to disallow any Extension
>> Headers in ND-Messages, 
> 
> Consensus at the relevant IETF working-group (6man) seems to be to only
> ban the Fragment Header (when SEND is not employed).

not allowing ANY extension headers for NDP and RA is the way to go. But
of course, doing this might break future features. Thats the reason that
only the fragment header is planned to be banned. Networking people
usually win over security people.

> A more conservative approach would be to simply require that the
> upper-layer header be present in the first fragment. (i.e., that the
> first fragment contains all the information that you need to apply an ACL).

and this is easily bypassed by overlapping fragments.
All current operating systems allow overlapping fragments, Windows,
OpenBSD, ... all.
I know there is an RFC which forbids overlapping fragments, but nobody
is implementing it.

>> I'd like switches to discard ND-Messages with
>> more that e.g. 3 chained headers. 
> 
> The point was that this could be expensive (if at all possible) for the
> RA-Guard implementation to do.

the main problem for RA guard is that it *requires the clients to change
their behaviour to be effective*:
 - drop overlapping fragments
 - drop RAs and NDPs which have extension headers / are fragmented

and this will not be happening soon, if ever.
so until then, RA guard is reliability feature (prevent accidential RAs,
e.g. by connection sharing of a Laptop) and no security feature.
But of course a good way for Cisco et.al. to make money.

Greets,
Marc

--
Marc Heuse
Mobil: +49 177 9611560
Fax: +49 30 37309726
www.mh-sec.de

Marc Heuse - IT-Security Consulting
Winsstr. 68
10405 Berlin

Ust.-Ident.-Nr.: DE244222388
PGP: FEDD 5B50 C087 F8DF 5CB9  876F 7FDD E533 BF4F 891A

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Permalink | Reply | 1 comment |
headers
Fernando Gont | 1 Sep 2011 13:27
Favicon

Re: HP A-series switches are affected, too. [WAS: More on IPv6 RA-Guard evasion (IPv6 security)]

Hi, Marc,

On 09/01/2011 07:59 AM, Marc Heuse wrote:
>> FWIW, "publicly-released first" != "discovered" (ask Cisco's PSIRT if in
>> doubt) -- anyway, I'm just trying to trigger discussion and get feedback...
> 
> when I reported to PSIRT they were not aware of the issue - so who
> called them first is unsettled :-) - however I published first ;-)

Again, please ask PSIRT. :-)

In any case, the world doesn't (or "shouldn't", at least) care about the
"who", but rather should care about the "what".

>> Anyway... I'd bet that every implementation that "followed" the spec is
>> vulnerable....
> 
> it is not mentioned in the RFC that an interface does have to support
> unlimited autoconfigurated addresses on its interfaces, nor does it
> state an upper limit. 

I was referring to the RA-Guard spec (RFC6105), and not the SLAAC spec.

> so its undefined and up to the implementor. And
> those who thought about it and saw the DOS coming (Solaris, OpenBSD) put
> limits, others didnt (everybody else).

One could argue that good programming practice means that you enforce
limits on everything. That said, I agree that implementation advice is
strongly needed.

>>> By the way, I don't think it is a good idea to disallow any Extension
>>> Headers in ND-Messages, 
>>
>> Consensus at the relevant IETF working-group (6man) seems to be to only
>> ban the Fragment Header (when SEND is not employed).
> 
> not allowing ANY extension headers for NDP and RA is the way to go. But
> of course, doing this might break future features. Thats the reason that
> only the fragment header is planned to be banned. Networking people
> usually win over security people.

mmm... not really so. Bob Hinden himself seemed to be in favor of baning
all of them..

>> A more conservative approach would be to simply require that the
>> upper-layer header be present in the first fragment. (i.e., that the
>> first fragment contains all the information that you need to apply an ACL).
> 
> and this is easily bypassed by overlapping fragments.

Agreed.

> All current operating systems allow overlapping fragments, Windows,
> OpenBSD, ... all.
> I know there is an RFC which forbids overlapping fragments, but nobody
> is implementing it.

IIRC, both Linux and Windows 7 do.

>>> I'd like switches to discard ND-Messages with
>>> more that e.g. 3 chained headers. 
>>
>> The point was that this could be expensive (if at all possible) for the
>> RA-Guard implementation to do.
> 
> the main problem for RA guard is that it *requires the clients to change
> their behaviour to be effective*:
>  - drop overlapping fragments
>  - drop RAs and NDPs which have extension headers / are fragmented
> 
> and this will not be happening soon, if ever.

Please see:
http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-01.txt

It doesn't require any modifications at the client (assuming it
completely bans fragmented RAs).

> so until then, RA guard is reliability feature (prevent accidential RAs,
> e.g. by connection sharing of a Laptop) and no security feature.

As noted in my blog post, curiously enough the problem statement
(RFC6104) is about accidental RAs, while the RA-Guard "spec" itself aims
to be a "security device".

Thanks,
--

-- 
Fernando Gont
SI6 Networks
e-mail: fgont <at> si6networks.com
web: http://www.si6networks.com

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Permalink | Reply | 0 comments |
headers
Mr. Hinky Dink | 1 Sep 2011 16:11
Favicon
Gravatar

China - the land of open proxies


In July, hundreds of Chinese proxies on port 8909 started showing up
every day on public proxy lists.  In August the daily numbers were in
the thousands.

Here is the list I collected during that period.  There are >135K
proxies in this file (text, tab delimited, ~8 megs).

http://www.mrhinkydink.com/utmods/135k.txt

You may want to right-click and "save as".  This is offered as data you
may be able to use for forensic purposes or router block lists.  Most of
these proxies are currently offline.  When they are online, they're very
good proxies.

I believe this is similar to the PPLiveVA issue with TCP port 9415 that
I noted back in April.

http://mrhinkydink.blogspot.com/2011/04/insecure-defaults-in-ppliveav-client.html

New port 9415 proxies stopped showing up on proxy lists when 8909 began
to take over, which leads me to believe this is the hot new media client
(either Youku or QQ) in Chinese-speaking countries.

--Mr. Hinky Dink

walk like a mannequin
roll like a tyre
act on reaction
dodge the Big Spud Fryer

http://mrhinkydink.blogspot.com

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Permalink | Reply | 6 comments |

Gmane