[nsp-sec] SNMP fun, was Re: comcast?

[Rob Thomas]

Hi, team.

My apologies if you see this in multiple places.

My thanks to an assemblage of gurus at Team Cymru for their input,
particularly John, Tim, James, and Steve.  I am *NOT* a SNMP guru; my
last foray into SNMP other than for monitoring was writing MIBs for
UUNET, and smic loathed me with a passion.  Any errors in the SNMP
details below are solely my own.

As some of you likely know, we and others located the top senders.  The
top sender implemented null routes for the victim IP addresses, which
cut the attack down to the level of "what attack?"

The attackers then shifted targets and are now hitting router interfaces
upstream of the server IP addresses.  It's an old tactic, and rendered
less effective with clever null routes and the use of RFC1918 IP space
for peering interfaces.

We have a pretty good sense of how the attack works.

We see the attackers using SNMP v2c and counting on a community string
of "public" (no quotes).  Neither is surprising.

They are using SNMP GETBULK to facilitate the attack.

Handy references include:

<http://www.webnms.com/snmp/help/snmpapi/snmpv3/snmp_operations/snmp_getbulk.html>
<http://docstore.mik.ua/orelly/networking_2ndEd/snmp/ch02_06.htm>
man 1 snmpbulkget

"In other words, the SNMP GETBULK operation does a simple GETNEXT
operation for the first N variable bindings in the request and does M
GETNEXT operation (continuous) for each of the remaining R variable
bindings in the request list..."

And:

"SNMPv2 defines the get-bulk operation, which allows a management
application to retrieve a large section of a table at once. The standard
get operation can attempt to retrieve more than one MIB object at once,
but message sizes are limited by the agent's capabilities. If the agent
can't return all the requested responses, it returns an error message
with no data. The get-bulk operation, on the other hand, tells the agent
to send as much of the response back as it can. This means that
incomplete responses are possible. Two fields must be set when issuing a
get-bulk command: nonrepeaters and max-repetitions. Nonrepeaters tells
the get-bulk command that the first N objects can be retrieved with a
simple get-next operation. Max-repetitions tells the get-bulk command to
attempt up to M get-next operations to retrieve the remaining objects.
Figure 2-7 shows the get-bulk command sequence."

Folks should look for spoofed source SNMP GETBULK requests with the
following settings:

   Version: v2c
   Community string: public
   OID: .1.3.1.6 (can be different or more specific)
   R: 20039 (may be different, see below)
   N: 0
   M: 2250

The packet contents will include something along the lines of:

    { SNMPv2c { GetBulk(22) R=20039  N=0 M=2250 .1.3.6.1 } }

The "R" above isn't the variable bindings; it's the request ID used to
associate requests with responses.  It appears to be hard coded to 20039
in every packet regardless of the source IP address.

The value of "R" as the variable bindings can't be set on the command
line.  The value of "N" and "M" can be set on the command line, and are
perhaps hard-coded in the attack tool.

The packets have a Non-Repeaters (N) value of 0 and a Max-Repetitions
(M) of 2250.

An example of a legitimate command with N and M set is:

   snmpbulkget -Cr2 -Cn0 -v2c -c public localhost

   -Cr2: Set the max-repetitions field to 2.
         Set the max-repetitions field in the GETBULK PDU.
         This specifies the maximum number of iterations
         over the repeating variables.  The default is 10.

   -Cn0: Set the non-repeaters filed to 0.
         Set the non-repeaters field in the GETBULK PDU.
         This specifies the number of supplied variables
         that should not be iterated over.  The default is 0.

It certainly looks like they are hand crafted, perhaps with some custom
code to generate the initial requests because the SNMP session id is the
same across all the packets and no single host is going to generate all
that traffic.  It seems unlikely any of the standard tools are going to
do that.

No single reflector address stands out above the rest.

It looks like fragments frequently total up to about the maximum IP
packet size of 65535.  I'm not certain, but this may simply be a
function of the SNMP data being returned not fitting into a singe
packet.  I'm not likely going to have time to fully investigate that
aspect now, but it might be worth looking into further.  A cursory
analysis and the distribution of packet sizes seem to bear this out
anyway:

# IP total datagram lengths
<=64    	627413
<=1500  	287332
<=1024  	48417
<=128   	32853
<=512   	3985

We've seen sustained and simultaneous attacks of circa 20Gbps over five
hours from this beastie.  We're not yet certain of the amplification ratio.

We've seen evidence of Windows hosts, printers, and CPE gear being used
in the amplification.  We're not yet certain of the number of each.

We will send the attacking/amplification IP addresses to the providers
who own them.

Thanks,
Rob.
-- 
Rob Thomas
Team Cymru
https://www.team-cymru.org/
"Say little and do much." M Avot 1:15