1.1 OVERVIEW - · PDF file3! akamai’s [state of the internet] / Threat Advisory! Any device configured to listen for SNMP v2c requests could potentially become a reflector

1

akamai’s [state of the internet] / Threat Advisory

1.1 OVERVIEW / The Prolexic Security Engineering and Response Team (PLXsert, now part of Akamai) has observed a marked resurgence in the use of Simple Network Management Protocol (SNMP) reflection attacks, beginning on April 11, 2014. The SNMP protocol is commonly used in devices for the home, enterprises and other commercial settings; typical devices include printers, switches, firewalls and routers.

Until approximately three years ago, SNMP devices were manufactured using SNMP version 2 and were commonly delivered with the SNMP protocol openly accessible to the public by default. Devices using SNMP v3 are more secure. To stop these older devices from participating in attacks, network administrators need to check for the presence of this protocol and turn off public access. Devices using SNMP v3 are more secure.

The use of specific types of protocol reflection attacks such as SNMP surge from time to time, becoming suddenly popular with the re-use or new availability of distributed denial of service (DDoS) tools. Newly available SNMP reflection tools in the underground have enabled the current situation.

This threat advisory outlines the indicators, source code, malicious payloads and recommended IDS snort rule for the SNMP Reflector DDoS tool.

1.2 INDICATORS OF SNMP REFLECTOR DDOS ATTACKS / SNMP DDoS attacks from the SNMP Reflector DDoS tool make use of devices on the Internet that allow public SNMP queries. The queries themselves have several identifying characteristics including the following:

§ SNMP GetBulk requests: The GetBulk operation allows the efficient transmission of data from an SNMP device. The request delivers values stored in the device such as IP addresses on a router or the type of toner used in a printer.

§ Use of SNMP Version 2c for SNMP

§ Community string public: The community string regulates access to device information. The default community string for SNMP v2c is usually public.

SNMP REFLECTION DDOS ATTACKS RISK FACTOR - MEDIUM

GSI ID: 1074

2


§ Max-repeaters set to 2250: Attackers are crafting SNMP requests to maximize the response payload by using a high value for max-repetitions. The largest value observed during an attack was 2,250.

§ Source port 80: Port 80 is used as the source port of the attack, which sends the reflected payload to port 80 of the target.

§ Query attempts to begin at OID (Object Identifier) 1.3.6.1: Attackers are directing the query to this high-level OID to ensure they get the largest possible response as the request traverses the OID tree structure. OID 1.3.6.1 does not exist but the GetBulk command will start at the next successive OID value. The object identifier provides a means to query for specific information from a device. For example, 1.3.6.1.2.1.1.1 or sysDesc, contains information about the device being queried. This could be the version of Windows or the model and brand of router for the device.

§ Request-id: 20039: The attack tool uses a static request identifier, which is usually generated randomly at the time an snmpgetbulk request is made. The response will match the id.

RFCs 3416 and 1901 provide more information on the indicators above.

1.3 PAYLOAD GENERATION / Attackers appear to be using a malicious tool to automate their GetBulk requests, possibly using multiple threads. First, an attacker would need to scan the Internet for hosts that are listening on port 161 and using a community string of public. The tool or a paid DDoS service may provide lists of such devices. The list of IP addresses would be placed in a text file, which is input into the attack tool.

Using the IP address of the attacker’s target as a spoofed source from which the requests will appear to originate, the attacker generates snmpbulkget requests to the list of reflectors. These actions lead to a flood of SNMP GetResponse data sent from the reflectors to the target. The target will see this inflow of data as coming from the victim devices queried by the attacker. The IP address of the actual attack source will be hidden.

The initial request payload from the attacker to a reflector device is less than 40 bytes. Figure 1 captures data from a single snmpbulkget request. Identifying information is shown in red.

3


Any device configured to listen for SNMP v2c requests could potentially become a reflector for this SNMP attack. Based on recent attacks, PLXsert has determined that malicious actors have reflected these queries from routers, printers, cable modems, desktops and servers. Figure 2 captures traffic snippets involving some of the observed devices used during attacks.

Figure 1: A 37-‐byte SNMPBulkGet request generated by attack tool against an Akamai customer

Figure 2: Traffic capture samples from various network devices

4


Figure 3 shows tshark output for a GetBulk response received during an attack campaign. The payload was so large that it was split into 44 fragmented packets. This payload, a response from a Windows 2003 server, represents an amplification factor of more than 1,700 times.

Figure 3: A sample response of more than 64,000 bytes

5


Not all SNMP responses will result in such large payloads. Total response size will depend on the available OID data on the reflecting device.

1.4 OBSERVED CAMPAIGNS / Since April 11, 2014 PLXsert has observed 14 DDoS campaigns that have made use of SNMP amplified reflection attacks. The attacks targeted clients in the following industry verticals: consumer goods, gaming, hosting, non-profits and Software-as-a-Service (SaaS). The resurgence of the SNMP reflection attack has been accompanied by a specific pattern in the request and payload response from SNMP reflectors as shown in previous figures. The main source countries have been the United States, China, Brazil, Italy and Turkey.

Figure 4: Observed SNMP source distribution based on a single attack campaign

6


Figure 5 shows the bandwidth consumed by SNMP attacks since April 11. As devices are discovered to be participating in attacks, their IP addresses are blacklisted or null routed by the Internet community, leading to smaller attack sizes. Past experience indicates, however, that malicious actors will continue to identify additional devices vulnerable to SNMP reflection and use them in their lists instead.

1.5 AN EXAMPLE DDOS TOOL: SNMP REFELECTOR DDOS / PLXsert researchers were able to identify a tool used during the recent SNMP reflection attacks and use it to replicate the request and payload in a laboratory setting. This particular tool, which was written by Team Poison in 2011, is available on the Internet. A code snippet from the code of the SNMP Refelector (sic) DDOS tool is shown in Figure 6.

Figure 5: Bandwidth consumed SNMP attacks by day. Bandwidth declined as involved IP addresses were blacklisted by the Internet community

7


1.6 LAB STUDY / Using the snmpbulkget command, PLXsert was able to closely simulate a request made by the SNMP Refelector DDoS tool to a Windows 7 computer and to a Cisco router, as shown in Figures 7 and 8. The following is of special interest:

§ The key parameter is -C r2250. This sets the max-repeaters to 2250. The default is 10.

§ Even though the query is set for .1.3.6.1, the first matching OID would be

sysDescr(1.3.6.1.2.1.1.1).

§ The BulkGet command finds the next OID value after 1.3.6.1. and proceeds to return up to 2,250 subsequent OIDs.

Figure 6: A code snippet from the SNMP Refelector DDOS tool believed to be used in recent attacks. The misspelling Refelector is coded in the tool.

8


As shown in Figures 9 and 10 below, the laboratory setup was able to replicate requests and payloads. The tool produced a request of 37 bytes and an amplified response of 51,722 bytes, effectively replicating the SNMP reflection attack seen in the campaigns.

Figure 7: A laboratory-‐based snmpbuklkget request to a Windows 7 computer

Figure 8: A laboratory-‐based snmpbuklkget request to a Cisco router

Figure 9: Indicators are replicated during attack tool execution in the lab environment

9


Figure 10: A payload produced by the malicious tool in the lab against a Windows 7 computer with SNMP service enabled and the default community string public

10


1.7 RECOMMENDED REMEDIATION FOR SNMP DEVICES / Network administrators with SNMP devices should take the following actions to mitigate and protect against device involvement in SNMP reflection attacks:

§ Scan for devices on your network that are configured with the default public community string and limit public access.

§ Some SNMP devices, such as printers, should not be allowed to be open to the

Internet.

§ Restrict and monitor access to SNMP devices, especially those that perform management oversight of large SNMP device populations.

§ When possible use SNMP v3.

1.8 RECOMMENDED VICTIM MITIGATION Snort rule for intrusion detection systems (IDS) alert udp any 80 -> any 161 \ (msg: "SNMP large GetBulk Request"; \ content: "|302302010104067075626c6963a51602024e47020100020208ca3009300706032b06010500|"; dsize:37<>37;\ sid:20130515; rev:1;) 1.9 CONCLUSION / The SNMP Refelector DDoS tool described here is one of many malicious SNMP reflection DDoS tools. Ongoing IP address blacklisting efforts by the Internet community are resulting in a smaller number of involved SNMP devices, but the remaining vulnerable SNMP servers will continue to make this attack dangerous. It is essential that network administrators engage in takedown of vulnerable devices. SNMP v3 is preferred. SNMP v2c is set to the public community string by default and such devices should be configured to prevent public access where it is not needed. SNMP v3 is preferred. The SNMP Reflector DDoS tool described here is one of many malicious SNMP reflection DDoS tools.

11


The Prolexic Security Engineering and Research Team (PLXsert) monitors malicious cyber threats globally and analyzes these attacks using proprietary techniques and equipment. Through research, digital forensics and post-event analysis, PLXsert is able to build a global view of security threats, vulnerabilities and trends, which is shared with customers and the security community. By identifying the sources and associated attributes of individual attacks, along with best practices to identify and mitigate security threats and vulnerabilities, PLXsert helps organizations make more informed, proactive decisions.

Akamai® is a leading provider of cloud services for delivering, optimizing and securing online content and business applications. At the core of the company’s solutions is the Akamai Intelligent Platform™ providing extensive reach, coupled with unmatched reliability, security, visibility and expertise. Akamai removes the complexities of connecting the increasingly mobile world, supporting 24/7 consumer demand, and enabling enterprises to securely leverage the cloud. To learn more about how Akamai is accelerating the pace of innovation in a hyperconnected world, please visit www.akamai.com or blogs.akamai.com, and follow @Akamai on Twitter.

Akamai is headquartered in Cambridge, Massachusetts in the United States with operations in more than 40 offices around the world. Our services and renowned customer care enable businesses to provide an unparalleled Internet experience for their customers worldwide. Addresses, phone numbers and contact information for all locations are listed on www.akamai.com/locations

©2014 Akamai Technologies, Inc. All Rights Reserved. Reproduction in whole or in part in any form or medium without express written permission is prohibited. Akamai and the Akamai wave logo are registered trademarks. Other trademarks contained herein are the property of their respective owners. Akamai believes that the information in this publication is accurate as of its publication date; such information is subject to change without notice. Published 05/14.

Documents

1.1 OVERVIEW - · PDF file3! akamai’s [state of the internet] / Threat Advisory! Any device configured to listen for SNMP v2c requests could potentially become a reflector