Re: Router worm exploiting poor SNMP security.

[J Edgar Hoover <zorch () TOTALLY RIGHTEOUS NET>]

It seems we all agree on one thing, and that is that SNMP security is
typically pretty weak. Aside from the problems with the protocol itself
(cleartext and UDP), it is often poorly configured (predictable community
names) and sometimes poorly implemented by the vendor.

It is probably safe to assume that 50% of end user routers are open to RO
access, and about half of them are open to RW access.

Now, what does that get us?

Read Only doesn't get us much, just information. This often includes
things like the ID of the admin, contact phone numbers and physical
location, as well as Circuit ID numbers, routing and connection tables.

Enough to call their provider and say "Hi, I'm Heywood Jablome from
ownme.com, we have moved to a new location and would to turn off CID
#31337-90210 as of tomorrow morning. Thanks"

Or, a little perl script on a web site
(seewhatsitesyourbossisviewing.com?) that traceroutes to a user defined
IP, SNMP polls the host or routers, and displays active TCP connections.

Fun stuff, but still no worm... so how about the remaining (25% ?) of the
routers with Read Write set to "public" "private" "cisco" or something
equally lame?

Remote command execution seems to be limited in most implementations.
Remote ping requires that you set numeric values for IP, protocol, size
etc.. Less than 20 protocols are documented, while 65535 are possible. TCP
protocols are not supported. There may be something here, but I don't see
it.

Remote configuration seems to be more promising. You can add interfaces,
specify a remote TFTP server from which to load configs or *new firmware*,
and more.

With remote access to the interface table, you can add interfaces and
sub-interfaces, set up vlans, tunnels etc.. This could probably be
leveraged to avoid what security is provided by supporting TFTP updates
only on specific interfaces. Set up a tunnel to your TFTP server that
loops back on the router's LAN interface...

The problem remains, how do you get the router to execute your code to
find and exploit other routers? In some cases you can load new config
files and a supported script, but these are limited in what they can do.

The only apparent and widely exploitable way to do this is to replace the
firmware. While not trivial, this is doable. Existing firmware already
supports sending SNMP packets, we only need change the data and type.

You'd have to compile a new Operating System for each hardware platform
you want to infect. An snmpget will tell you which platform the target is
running. The new OS would have to discover new routers (CDP, multicast or
just plain scanning), and upload the appropriate OS and configs to the
target.

You'd probably need one or more TFTP servers, depending on how you do it.
To support multiple routers, you need multiple copies of altered firmware.
Some routers may be able to store an extra copy or two, so you could
distribute the different OSes on different routers, or use one large TFTP
server.

Another problem is that you need to keep the infected router operational.
Prior to flashing the nvram, you'll need to retrieve the running configs,
possibly modify and them, and then restore them. That's some high level
parsing to do in opcode.

The worm is doable. Making it independant, where it uses exploited routers
for all functions is a little trickier if you need to support more than a
few types of hardware. Writing new firmware isn't easy either. But it is
all doable.