Re: 0day Windows Network Interception Configuration Vulnerability
On 4/4/11 11:46 AM, andrew.wallace wrote: > Someone has recently post to a mailing list: > http://lists.grok.org.uk/pipermail/full-disclosure/2011-April/080096.html > > Andrew > And users of that list certainly have it. Why is it being reposted here? request for admin action
Re: 0day Windows Network Interception Configuration Vulnerability
On Mon, 04 Apr 2011 08:46:22 PDT, "andrew.wallace" said: > Someone has recently post to a mailing list: > http://lists.grok.org.uk/pipermail/full-disclosure/2011-April/080096.html *yawn* No news, move along, nothing to see. RFC4862, section 6: The use of stateless address autoconfiguration and Duplicate Address Detection opens up the possibility of several denial-of-service attacks. For example, any node can respond to Neighbor Solicitations for a tentative address, causing the other node to reject the address as a duplicate. A separate document [RFC3756] discusses details about these attacks, which can be addressed with the Secure Neighbor Discovery protocol [RFC3971]. It should also be noted that [RFC3756] points out that the use of IP security is not always feasible depending on network environments. Note that similar text was present in RFC2462, all the way back in Dec 1998. So somebody's 13 years late to the party. pgpp2bCzYxEQ2.pgp Description: PGP signature
Re: 0day Windows Network Interception Configuration Vulnerability
On 04/04/11 12:14 -0400, valdis.kletni...@vt.edu wrote: On Mon, 04 Apr 2011 08:46:22 PDT, "andrew.wallace" said: Someone has recently post to a mailing list: http://lists.grok.org.uk/pipermail/full-disclosure/2011-April/080096.html *yawn* No news, move along, nothing to see. RFC4862, section 6: The use of stateless address autoconfiguration and Duplicate Address Detection opens up the possibility of several denial-of-service attacks. For example, any node can respond to Neighbor Solicitations for a tentative address, causing the other node to reject the address as a duplicate. A separate document [RFC3756] discusses details about these attacks, which can be addressed with the Secure Neighbor Discovery protocol [RFC3971]. It should also be noted that [RFC3756] points out that the use of IP security is not always feasible depending on network environments. Note that similar text was present in RFC2462, all the way back in Dec 1998. So somebody's 13 years late to the party. For more information, see RFC 6104 for a comprehensive problem statement (rogue routers), and RFC 6105 for a proposed solution. -- Dan White
Re: 0day Windows Network Interception Configuration Vulnerability
On Mon, 2011-04-04 at 12:14 -0400, valdis.kletni...@vt.edu wrote: > On Mon, 04 Apr 2011 08:46:22 PDT, "andrew.wallace" said: > > Someone has recently post to a mailing list: > > http://lists.grok.org.uk/pipermail/full-disclosure/2011-April/080096.html > > *yawn* No news, move along, nothing to see. RFC4862, section 6: I think the article is important: since a lot of systems and network admins still bury their heads in the sand when it comes to IPv6, they don't realize that it can be an attack vector in several ways... All recent operating systems have IPv6 enabled by default and prefer it over IPv4; this article clearly shows how easy it is to set up a MITM for IPv4 traffic when IPv6 hasn't been configured or properly secured on a network yet. I believe this attack will work on most networks out there, simply because IPv6 is enabled on hosts and rogue RA filtering hasn't been implemented on most switches yet. Regards, Jeroen van Ingen ICT Service Centre University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands
Re: 0day Windows Network Interception Configuration Vulnerability
On Mon, 4 Apr 2011, Jeroen van Ingen wrote: a network yet. I believe this attack will work on most networks out there, simply because IPv6 is enabled on hosts and rogue RA filtering hasn't been implemented on most switches yet. Any responsible ISP will block this kind of L2 "unknown" traffic between customers. We see this happening unwittingly in the wild as of several years ago with Windows ICS announcing RA to both WAN and LAN because it (or thinks it) has 6to4 connectivity and wants to share it. Nothing new here, but the wider it's known the better. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: 0day Windows Network Interception Configuration Vulnerability
On 04/04/2011 16:46, andrew.wallace wrote: Someone has recently post to a mailing list: http://lists.grok.org.uk/pipermail/full-disclosure/2011-April/080096.html There's a serious vulnerability in the default ipv4 configuration too: Windows will accept a reply from any DHCP server which replies. The fix right now is for Microsoft to disable IPv4 by default. I think I'm the first person in the world to notice this, so can you cross-post this to full-disclosure as a critical 0day? kthx, Nick
Re: 0day Windows Network Interception Configuration Vulnerability
Nick Hilliard wrote: > The fix right now is for Microsoft to disable IPv4 by default. Yes, please. That would put a serious dent in most botnets... > Nick --Johnny
Re: 0day Windows Network Interception Configuration Vulnerability
On Mon, 2011-04-04 at 19:46 +0200, Mikael Abrahamsson wrote: > > I believe this attack will work on most networks out > > there, simply because IPv6 is enabled on hosts and rogue RA filtering > > hasn't been implemented on most switches yet. > > Any responsible ISP will block this kind of L2 "unknown" traffic between > customers. I fully agree, but not all networks are run by ISPs (let alone by "responsible" persons/entities). Perhaps not the main audience for Nanog, but there will be enough enterprises, small ISPs or colo facilities, schools / edu networks etc where this attack is currently possible. > We see this happening unwittingly in the wild as of several years ago with > Windows ICS announcing RA to both WAN and LAN because it (or thinks it) > has 6to4 connectivity and wants to share it. It's almost the same, but not quite: the same in the sense that it might result in MITM for traffic and rogue RAs are involved; different because with the attack described, *virtually all* traffic can be intercepted with the addition of NAT-PT including modified DNS responses (eg returning quad-A RRs for (originally) IPv4-only services. That's not the same as some ICS box which usually doesn't even properly forward the v6 traffic, and if it does, only sees the traffic for the small percentage of v6-enabled services with both an A and quad-A resource record in DNS. > Nothing new here, but the wider it's known the better. To me the NAT-PT part was new, but I don't work for an ISP and perhaps you wouldn't consider me to be a responsible network admin... even though our University has been running RA monitors on all segments for a long time (and will continue to do so until we can properly filter rogue RA on all edge ports etc). I don't know *everything* there is to know in networking, nor will I believe anyone who claims he/she does. The main reason I responded was the "blah blah old news" attitude in one of the reactions, while I doubt that the possibilities with the combination of methods as described are that widely known. But if I'm the only (security) ignorant person on this list, please forgive me ;) Regards, Jeroen van Ingen ICT Service Centre University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands
