Category Archives: Security

Security

TA14-017A: UDP-based Amplification Attacks

Original release date: January 17, 2014 | Last revised: March 07, 2014

Systems Affected

Certain UDP protocols have been identified as potential attack vectors:

  • DNS
  • NTP
  • SNMPv2
  • NetBIOS
  • SSDP
  • CharGEN
  • QOTD
  • BitTorrent
  • Kad
  • Quake Network Protocol
  • Steam Protocol

Overview

A Distributed Reflective Denial of Service (DRDoS) attack is an emerging form of Distributed Denial of Service (DDoS) that relies on the use of publicly accessible UDP servers, as well as bandwidth amplification factors, to overwhelm a victim system with UDP traffic.

Description

UDP, by design, is a connection-less protocol that does not validate source IP addresses.  Unless the application-layer protocol uses countermeasures such as session initiation, it is very easy to forge the IP packet datagram to include an arbitrary source IP address [7].  When many UDP packets have their source IP address forged to a single address, the server responds to that victim, creating a reflected Denial of Service (DoS) Attack.

Recently, certain UDP protocols have been found to have particular responses to certain commands that are much larger than the initial request.  Where before, attackers were limited linearly by the number of packets directly sent to the target to conduct a DoS attack, now a single packet can generate tens or hundreds of times the bandwidth in its response.  This is called an amplification attack, and when combined with a reflective DoS attack on a large scale it makes it relatively easy to conduct DDoS attacks.  

To measure the potential effect of an amplification attack, we use a metric called the bandwidth amplification factor (BAF).  BAF can be calculated as the number of UDP payload bytes that an amplifier sends to answer a request, compared to the number of UDP payload bytes of the request [9] [10].

The list of known protocols, and their associated bandwidth amplification factors, is listed below.  US-CERT would like to offer thanks to Christian Rossow for providing this information to us.  For more information on bandwith amplificatication factors, please see Christian’s blog and associated research paper.

Protocol Bandwidth Amplification Factor Vulnerable Command
DNS 28 to 54 see: TA13-088A [1]
NTP 556.9 see: TA14-013A [2]
SNMPv2 6.3 GetBulk request
NetBIOS 3.8 Name resolution
SSDP 30.8 SEARCH request
CharGEN 358.8 Character generation request
QOTD 140.3 Quote request
BitTorrent 3.8 File search
Kad 16.3 Peer list exchange
Quake Network Protocol 63.9 Server info exchange
Steam Protocol 5.5 Server info exchange

 

Impact

Attackers can utilize the bandwidth and relative trust of large servers that provide the above UDP protocols to flood victims with unwanted traffic, a DDoS attack.

Solution

DETECTION

Detection of DRDoS attacks is not easy, due to their use of large, trusted servers that provide UDP services.  As a victim, traditional DoS mitigation techniques may apply.

As a network operator of one of these exploitable services, look for abnormally large responses to a particular IP address.  This may indicate that an attacker is using your service to conduct a DRDoS attack.

MITIGATION

Source IP Verification

Because the UDP requests being sent by the attacker-controlled clients must have a source IP address spoofed to appear as the victim’s IP, the first step to reducing the effectiveness of UDP amplification is for Internet Service Providers to reject any UDP traffic with spoofed addresses. The Network Working Group of the Internet Engineering Task Force (IETF) released Best Current Practice 38 document in May 2000 and Best Current Practice 84 in March 2004 that describes how an Internet Service Provider can filter network traffic on their network to reject packets with source addresses not reachable via the actual packet’s path [3][4].  The changes recommended in these documents would cause a routing device to evaluate whether it is possible to reach the source IP address of the packet via the interface that transmitted the packet. If it is not possible, then the packet most likely has a spoofed source IP address. This configuration change would substantially reduce the potential for most popular types of DDoS attacks. As such, we highly recommend to all network operators to perform network ingress filtering if possible.  Note that it will not explicitly protect a UDP service provider from being exploited in a DRDoS (all network providers must use ingress filtering in order to completely eliminate the threat).

To verify your network has implemented ingress filtering, download the open source tools from the Spoofer Project [5].

Traffic Shaping

Limiting responses to UDP requests is another potential mitigation to this issue.  This may require testing to discover the optimal limit that does not interfere with legitimate traffic.  The IETF released Request for Comment 2475 and Request for Comment 3260 that describes some methods to shape and control traffic [6] [8].  Most network devices today provide these functions in their software. 

References

Revision History

  • February 09, 2014 – Initial Release
  • March 07, 2014 – Updated page to include research links

This product is provided subject to this Notification and this Privacy & Use policy.

CVE-2014-0418 (enterprise_linux_desktop_supplementary, enterprise_linux_hpc_node_supplementary, enterprise_linux_server_supplementary, enterprise_linux_server_supplementary_aus, enterprise_linux_server_supplementary_eus, enterprise_linux_workstation_supplementary, jdk, jre)

Unspecified vulnerability in Oracle Java SE 6u65 and 7u45 allows remote attackers to affect confidentiality, integrity, and availability via unknown vectors related to Deployment, a different vulnerability than CVE-2013-5889, CVE-2013-5902, CVE-2014-0410, CVE-2014-0415, and CVE-2014-0424.

CVE-2013-5906 (enterprise_linux_desktop_supplementary, enterprise_linux_hpc_node_supplementary, enterprise_linux_server_supplementary, enterprise_linux_server_supplementary_aus, enterprise_linux_server_supplementary_eus, enterprise_linux_workstation_supplementary, jdk, jre)

Unspecified vulnerability in Oracle Java SE 5.0u55, 6u65, and 7u45 allows remote attackers to affect confidentiality, integrity, and availability via unknown vectors related to Install, a different vulnerability than CVE-2013-5905.

SA-CORE-2014-001 – Drupal core – Multiple vulnerabilities

  • Advisory ID: DRUPAL-SA-CORE-2014-001
  • Project: Drupal core
  • Version: 6.x, 7.x
  • Date: 2014-January-15
  • Security risk: Highly critical
  • Exploitable from: Remote
  • Vulnerability: Multiple vulnerabilities

Description

Multiple vulnerabilities were fixed in the supported Drupal core versions 6 and 7.

Impersonation (OpenID module – Drupal 6 and 7 – Highly critical)

A vulnerability was found in the OpenID module that allows a malicious user to log in as other users on the site, including administrators, and hijack their accounts.

This vulnerability is mitigated by the fact that the malicious user must have an account on the site (or be able to create one), and the victim must have an account with one or more associated OpenID identities.

Access bypass (Taxonomy module – Drupal 7 – Moderately critical)

The Taxonomy module provides various listing pages which display content tagged with a particular taxonomy term. Custom or contributed modules may also provide similar lists. Under certain circumstances, unpublished content can appear on these pages and will be visible to users who should not have permission to see it.

This vulnerability is mitigated by the fact that it only occurs on Drupal 7 sites which upgraded from Drupal 6 or earlier.

Security hardening (Form API – Drupal 7 – Not critical)

The form API provides a method for developers to submit forms programmatically using the function drupal_form_submit(). During programmatic form submissions, all access checks are deliberately bypassed, and any form element may be submitted regardless of the current user’s access level.

This is normal and expected behavior for most uses of programmatic form submissions; however, there are cases where custom or contributed code may need to send data provided by the current (untrusted) user to drupal_form_submit() and therefore need to respect access control on the form.

To facilitate this, a new, optional $form_state[‘programmed_bypass_access_check’] element has been added to the Drupal 7 form API. If this is provided and set to FALSE, drupal_form_submit() will perform the normal form access checks against the current user while submitting the form, rather than bypassing them.

This change does not fix a security issue in Drupal core itself, but rather provides a method for custom or contributed code to fix security issues that would be difficult or impossible to fix otherwise.

CVE identifier(s) issued

  • Impersonation (OpenID module – Drupal 6 and 7 – Highly critical): CVE-2014-1475
  • Access bypass (Taxonomy module – Drupal 7 – Moderately critical): CVE-2014-1476
  • Security hardening (Form API – Drupal 7 – Not critical): No CVE necessary.

Versions affected

  • Drupal core 6.x versions prior to 6.30.
  • Drupal core 7.x versions prior to 7.26.

Solution

Install the latest version:

Also see the Drupal core project page.

Reported by

  • The OpenID module impersonation issue was reported by Christian Mainka and Vladislav Mladenov.
  • The Taxonomy module access bypass issue was reported by Matt Vance, and by Damien Tournoud of the Drupal Security Team.
  • The form API access bypass issue was reported by David Rothstein of the Drupal Security Team.

Fixed by

Coordinated by

Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at http://drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

Drupal version: 

CVE-2013-7108

Multiple off-by-one errors in Nagios Core 3.5.1, 4.0.2, and earlier, and Icinga before 1.8.5, 1.9 before 1.9.4, and 1.10 before 1.10.2 allow remote authenticated users to obtain sensitive information from process memory or cause a denial of service (crash) via a long string in the last key value in the variable list to the process_cgivars function in (1) avail.c, (2) cmd.c, (3) config.c, (4) extinfo.c, (5) histogram.c, (6) notifications.c, (7) outages.c, (8) status.c, (9) statusmap.c, (10) summary.c, and (11) trends.c in cgi/, which triggers a heap-based buffer over-read. (CVSS:5.5) (Last Update:2014-03-05)