My next class:

SNMP: The next big thing in DDoS Attacks?

Published: 2014-05-08. Last Updated: 2014-05-08 13:47:08 UTC
by Johannes Ullrich (Version: 1)
8 comment(s)

It started with DNS: Simple short DNS queries are easily spoofed and the replies can be much larger then the request, leading to an amplification of the attack by orders of magnitude. Next came NTP. Same game, different actors: NTP's "monlist" feature allows for small requests (again: UDP, so trivially spoofed) and large responses. 

Today, we received a packet capture from a reader showing yet another reflective DDoS mode: SNMP. The "reflector" in this case stands nicely in line for our "Internet of Things" theme. It was a video conferencing system. Firewalling these systems is often not practical as video conferencing systems do use a variety of UDP ports for video and audio streams which are dynamically negotiated. As a result, they are often left "wide open" . And of course, these systems not only let attackers spy on your meeting rooms, but the also make great SNMP reflectors as it turns out.

Here is an anonymized traffic capture (target anonymized with 192.0.2.1):

117.27.239.158 -> 192.0.2.1 SNMP 87 getBulkRequest 1.3.6.1.2.1.4.21.1.1
192.0.2.1 -> 117.27.239.158 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=1f48)
192.0.2.1 -> 117.27.239.158 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=1480, ID=1f48)
... [ additional fragments omitted ] ...
192.0.2.1 -> 117.27.239.158 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=54760, ID=1f48)
192.0.2.1 -> 117.27.239.158 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=56240, ID=1f48)
192.0.2.1 -> 117.27.239.158 SNMP 664 get-response    [... large response payload ...]

That is right! A simple 87 byte "getBulkRequest" leads to about 60k Bytes of fragmented data being sent back. We can only assume that poor 117.27.229.158 is the victim of this DoS attack. The user reporting this saw about 5 MBit/sec of traffic. 

Similar to what we have seen with other reflective attacks like this, the fragmentation of the traffic is likely going to make filtering even harder. Prolexic posted a white paper about some of the different DrDOS attacks, including SNMP attacks [1]

So what to do:

- SNMP should probably not traverse your perimeter. Stop it at the firewall. (and I don't think video conferencing systems need it)
- proper egress/ingress control is a good idea.  But you already knew that.

[1] http://www.prolexic.com/kcresources/white-paper/white-paper-snmp-ntp-chargen-reflection-attacks-drdos/An_Analysis_of_DrDoS_SNMP-NTP-CHARGEN_Reflection_Attacks_White_Paper_A4_042913.pdf

 

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords:
8 comment(s)
My next class:

Comments

I beg to disagree that NTP came second.
The SNMP reflection DDoSes have been going on for longer. Saw them 4 to 5 months before the first NTP MONLIST reflections.

My impression was the SNMP reflections disappeared or became less predominant after NTP MONLIST came out.
Perhaps bad guys concentrating their efforts on the more abusable issue.

Now when people start patching their NTP servers; a bunch of bad guys revert back to SNMP and DNS reflection, perhaps.

Anonymous

May 8th 2014
1 decade ago

True. These different attack modes appear to be coming in waves. I think DNS was so dominant because it was so easy (and there are so many DNS servers out there). NTP kept "flaring up" from time to time. Haven't seen a ton of SNMP myself, but I am certain there are lots of amplifiers out there, and unlike NTP, you are not limited to "active" systems (monlist) is most effective if many clients use the NTP server).

Anonymous

May 8th 2014
1 decade ago

SNMP is used by video conferencing systems when you manage them with something like Cisco TMS. That being said, having a router filter at the border for SNMP is trivial to do, and won't interfere with the rest of the ports needed for H.323 and SIP video conferencing.

Anonymous

May 9th 2014
1 decade ago

The first reflection/amplification attacks were TCP-based - induced SYN-ACK floods and the like, which made their debut in the mid-1990s.

In the late 1990s, the Smurf attack was a quite popular reflection/amplification vector, until Cisco and other router manufacturers made 'no ip unreachables' a configuration default.

DNS reflection/amplification attacks were first posited around 2000 or 2001, and started to show up in the wild in late 2004/early 2005.

SNMP reflection/amplification attacks began showing up in the wild in the 2006 - 2007 timeframe.

ntp reflection/amplification attacks began showing up in the wild around 2008 - 2009.

chargen reflection/amplification attacks began showing up in the wild around 2009 - 2010.

tftp reflection/amplification attacks began showing up in the wild around 2009 - 2010.

None of this stuff is new.

Anonymous

May 9th 2014
1 decade ago

Attackers launching ntp reflection/amplification attacks typically 'prime' the monlist cache on the abusable ntpds by sending them a bunch of pseudo-randomly-spoofed ntp time queries before leveraging them in an attack.

Anonymous

May 9th 2014
1 decade ago

No, these various reflection/amplification attack methodologies have all been around for years, and they don't 'disappear'.

The public brouhaha over ntp reflection/amplification attacks began when some gamer script-kiddies (there's always been a strong correlation between online gaming and DDoS attacks) got hold of some simple scripts which had filtered downwards from more sophisticated attackers, along with access to compromised servers on IDC hosting networks which didn't enforce anti-spoofing.

They attacked online game services with very large ntp reflection/amplification attacks; these services typically have tens of millions of simultaneous users, and that's what brought this attack methodology into the view of non-specialists.

But there are DDoS attacks using all these various reflection/amplification methodologies taking place every second of every minute of every our of every day of every year. Attackers add new methodologies to their individual arsenals, but we don't see DNS reflection/amplification attacks being *discarded* in favor of ntp reflection/amplification attacks, for example.

Anonymous

May 9th 2014
1 decade ago

Also, the population of abusable ntpds has declined from ~1.7M to ~110K, due in large part to concerted remediation efforts over the last 6 months or so.

The one thing which would make all forms of reflection/amplification attacks impossible is anti-spoofing at all network edges. BCP38/84 is the answer.

Anonymous

May 9th 2014
1 decade ago

I very much agree! This isn't so much a problem with these specific applications, but a problem with the ability to spoof traffic.

Anonymous

May 9th 2014
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives