Interesting paper by Steve Bellovin - Worm propagation in a v6 internet

Mailman List Mirror (Read Only)
1

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

2

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.