Interesting paper by Steve Bellovin - Worm propagation in a v6 internet
http://www.cs.columbia.edu/~smb/papers/v6worms.pdf - courtesy Schneier on Security and then the ITU newslog.
Internet Worms and IPv6
Bruce Schneier's Schneier on Security points to a paper dismissing the myth that worms won't be able to propagate under IPv6.
In message <bb0e440a0602140422k6200a9d2v7561e6233cec919e@mail.gmail.com>, Sures h Ramasubramanian writes:
Internet Worms and IPv6>> Bruce Schneier's Schneier on Security points to a
http://www.cs.columbia.edu/~smb/papers/v6worms.pdf - courtesy Schneieron Secur ity and then the ITU newslog. paper dismissing the> myth that worms won't be able to propagate under IPv6.
It's joint work with Angelos Keromytis and Bill Cheswick. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
On Wed, 15 Feb 2006, Mark Andrews wrote:
One of method missing is doing top down random walks of ip6.arpa.
That's only easy if delegation were on a per-nybble basis, which is commonly not the case. Because there are not typically NS's at every nybble level, you have to do more than one hex digit's worth of randomness in the scan in order to find a next-level delegation, increasing the cost of scanning that namespace quite a bit. (Having delegations at every nybble level would be ... alarming at best, given the amount of PTR redirection that implies. :) -- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>
On Wed, 15 Feb 2006, Mark Andrews wrote:
One of method missing is doing top down random walks of ip6.arpa.
That's only easy if delegation were on a per-nybble basis, which is commonly not the case. Because there are not typically NS's at every nybble level, you have to do more than one hex digit's worth of randomness in the scan in order to find a next-level delegation, increasing the cost of scanning that namespace quite a bit.
(Having delegations at every nybble level would be ... alarming at best, given the amount of PTR redirection that implies. :)
-- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>
I suggest that you re-read RFC 1034 and RFC 1035. A empty node returns NOERROR. A non-existant node returns NXDOMAIN (Name Error). e.a.e.e.f.9.e.f.f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa PTR drugs.dv.isc.org causes all of the following to exist. a.e.e.f.9.e.f.f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa e.e.f.9.e.f.f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa e.f.9.e.f.f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa f.9.e.f.f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 9.e.f.f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa e.f.f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa f.f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 0.f.1.0.7.4.0.1.0.0.2.ip6.arpa f.1.0.7.4.0.1.0.0.2.ip6.arpa 1.0.7.4.0.1.0.0.2.ip6.arpa 0.7.4.0.1.0.0.2.ip6.arpa 7.4.0.1.0.0.2.ip6.arpa 4.0.1.0.0.2.ip6.arpa 0.1.0.0.2.ip6.arpa 1.0.0.2.ip6.arpa 0.0.2.ip6.arpa 0.2.ip6.arpa 2.ip6.arpa ip6.arpa arpa . A query for any of them regardless of type should return something other than NXDOMAIN. Also wildcards won't save you as it is possible to detect them. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
On Wed, 15 Feb 2006, Mark Andrews wrote:
I suggest that you re-read RFC 1034 and RFC 1035. A empty node returns NOERROR. A non-existant node returns NXDOMAIN (Name Error).
Right. This means depth-first walk, which will reduce the *possible* address space to probe, but that is the antithesis of traditional scanning (which is often at least partly stochastic). To a worm, the benefit of stochastic scanning is that no collaboration between infected hosts is needed; but with a walking traversal, you have to have some kind of statekeeping if the walk search is not intended to take ~forever. I can see this vector as being useful for scanning within some specific organization's subnet, but even then, you'll need some kind of collaboration with NDP solicitations for most internal setups. Stateless autoconfig, for instance, is unscannable without listening for NDP at the same time -- and from a remote network, you can basically forget it. You're also assuming that there will be PTR records for the most commonly infectable OS ([vendor product elided]) in the most commonly used configuration (desktop). It's highly likely that such systems will use some sort of autoconfiguration, and stateless form as above presents a fairly large address space to scan. If there are PTRs assigned for such hosts at all, the attack vector is actually somewhat simple to minimize: have the DNS product in use return empty NOERROR, rather than NXDOMAIN, for any unassigned addresses in the /64. Don't get me wrong, I'm not one for security through obscurity in the primary case. But attack vector minimization is still useful for this particular angle. -- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>
On Wed, 15 Feb 2006, Mark Andrews wrote:
I suggest that you re-read RFC 1034 and RFC 1035. A empty node returns NOERROR. A non-existant node returns NXDOMAIN (Name Error).
Right. This means depth-first walk, which will reduce the *possible* address space to probe, but that is the antithesis of traditional scanning (which is often at least partly stochastic). To a worm, the benefit of stochastic scanning is that no collaboration between infected hosts is needed; but with a walking traversal, you have to have some kind of statekeeping if the walk search is not intended to take ~forever.
I can see this vector as being useful for scanning within some specific organization's subnet, but even then, you'll need some kind of collaboration with NDP solicitations for most internal setups. Stateless autoconfig, for instance, is unscannable without listening for NDP at the same time -- and from a remote network, you can basically forget it.
And I expect that machines using stateless autoconfig will update their forward and reverse records in the DNS. The reasons for doing this are independent of the mechanism of address assignment. Too many services will not work unless there is a valid PTR / address combination.
You're also assuming that there will be PTR records for the most commonly infectable OS ([vendor product elided]) in the most commonly used configuration (desktop). It's highly likely that such systems will use some sort of autoconfiguration, and stateless form as above presents a fairly large address space to scan. If there are PTRs assigned for such hosts at all, the attack vector is actually somewhat simple to minimize: have the DNS product in use return empty NOERROR, rather than NXDOMAIN, for any unassigned addresses in the /64.
Don't get me wrong, I'm not one for security through obscurity in the primary case. But attack vector minimization is still useful for this particular angle.
-- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
On Wed, 15 Feb 2006, Mark Andrews wrote:
One of method missing is doing top down random walks of ip6.arpa.
That's only easy if delegation were on a per-nybble basis, which is commonly not the case. Because there are not typically NS's at every nybble level, you have to do more than one hex digit's worth of randomness in the scan in order to find a next-level delegation, increasing the cost of scanning that namespace quite a bit.
(Having delegations at every nybble level would be ... alarming at best, given the amount of PTR redirection that implies. :)
-- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>
A simple demonstation program. Don't run it for too long as we don't really want to beat on WIDE's servers. Mark #!/bin/sh qname=1.0.0.2.ip6.arpa depth=4 try() { local newqname local oldqname local l oldqname=$qname for l in 0 1 2 3 4 5 6 7 8 9 a b c d e f do newqname=$l.$oldqname echo trying $newqname dig +noques ptr $newqname > /tmp/$$xxx grep PTR /tmp/$$xxx if grep NOERROR /tmp/$$xxx > /dev/null then qname=$newqname if test $depth -lt 31 then depth=`expr $depth + 1` try depth=`expr $depth - 1` fi fi done qname=$oldqname } try -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
One of method missing is doing top down random walks of ip6.arpa.
Given the difficulty of finding IP addresses for free, perhaps the commercial people will take over the whole botnet business. Then it is simple to find IPv6 addresses to attack. Simply buy webserver logs on the open market similar to the way the bad guys now buy lists of credit card numbers. People are always the weak link in any security scenario, no matter how bulletproof the technologists may claim it is. IPv6 may have less impact on the fact of botnet activity and more impact on the sociology of the participants. --Michael Dillon
participants (5)
-
Mark Andrews -
Michael.Dillonļ¼ btradianz.com -
Steven M. Bellovin -
Suresh Ramasubramanian -
Todd Vierling