News

We would like to thank the Open Net Initiative for their news feeds.

Security Alerts

Make sure these updates are installed!

TA14-098A: OpenSSL 'Heartbleed' vulnerability (CVE-2014-0160)

Original release date: April 08, 2014

Systems Affected

  • OpenSSL 1.0.1 through 1.0.1f
  • OpenSSL 1.0.2-beta

Overview

A vulnerability in OpenSSL could allow a remote attacker to expose sensitive data, possibly including user authentication credentials and secret keys, through incorrect memory handling in the TLS heartbeat extension.

Description

OpenSSL versions 1.0.1 through 1.0.1f contain a flaw in its implementation of the TLS/DTLS heartbeat functionality. This flaw allows an attacker to retrieve private memory of an application that uses the vulnerable OpenSSL library in chunks of 64k at a time. Note that an attacker can repeatedly leverage the vulnerability to retrieve as many 64k chunks of memory as are necessary to retrieve the intended secrets. The sensitive information that may be retrieved using this vulnerability include:

  • Primary key material (secret keys)
  • Secondary key material (user names and passwords used by vulnerable services)
  • Protected content (sensitive data used by vulnerable services)
  • Collateral (memory addresses and content that can be leveraged to bypass exploit mitigations)

Exploit code is publicly available for this vulnerability.  Additional details may be found in CERT/CC Vulnerability Note VU#720951.

Impact

This flaw allows a remote attacker to retrieve private memory of an application that uses the vulnerable OpenSSL library in chunks of 64k at a time.

Solution

OpenSSL 1.0.1g has been released to address this vulnerability.  Any keys generated with a vulnerable version of OpenSSL should be considered compromised and regenerated and deployed after the patch has been applied.

US-CERT recommends system administrators consider implementing Perfect Forward Secrecy to mitigate the damage that may be caused by future private key disclosures.

References

Revision History

  • Initial Publication

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


TA14-069A: Microsoft Ending Support for Windows XP and Office 2003

Original release date: March 10, 2014 | Last revised: March 11, 2014

Systems Affected

  • Microsoft Windows XP with Service Pack 3 (SP3) Operating System
  • Microsoft Office 2003 Products

Overview

Microsoft is ending support for the Windows XP operating system and Office 2003 product line on April 8, 2014. [1] After this date, these products will no longer receive:

  • Security patches which help protect PCs from harmful viruses, spyware, and other malicious software
  • Assisted technical support from Microsoft
  • Software and content updates

Description

All software products have a lifecycle. End of support refers to the date when Microsoft no longer provides automatic fixes, updates, or online technical assistance. [2] As of February 2014, nearly 30 percent of Internet-connected PCs still run Windows XP. [3]

Microsoft will send “End of Support” notifications to users of Windows XP who have elected to receive updates via Windows Update. Users in organizations using Windows Server Update Services (WSUS), System Center Configuration manager, or Windows Intune will not receive the notification. [4]

Impact

Computer systems running unsupported software are exposed to an elevated risk to cybersecurity dangers, such as malicious attacks or electronic data loss.

Users may also encounter problems with software and hardware compatibility since new software applications and hardware devices may not be built for Windows XP or Office 2003.

Organizations that are governed by regulatory obligations may find they are no longer able to satisfy compliance requirements. [4]

Solution

Computers operating Windows XP with SP3 or running Office 2003 products will continue to work after support ends. However, using unsupported software may increase the risk of viruses and other security threats.

Users have the option to upgrade to a currently supported operating system or office productivity suite. The Microsoft “End of Support” pages for Windows XP and Office 2003 offer additional details.

There are software vendors and service providers in the marketplace who offer assistance in migrating from Windows XP or Office 2003 to a currently supported operating system or office productivity suite. US-CERT does not endorse or support any particular product or vendor.

Users who choose to continue using Windows XP after the end of support may mitigate some risks by using a web browser other than Internet Explorer. The Windows XP versions of some alternative browsers will continue to recieve support temporarily. Users should consult the support pages of their chosen alternative browser for more details.

References

Revision History

  • March 10, 2014 - Initial Release

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


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.

ProtocolBandwidth Amplification FactorVulnerable Command
DNS28 to 54see: TA13-088A [1]
NTP556.9see: TA14-013A [2]
SNMPv26.3GetBulk request
NetBIOS3.8Name resolution
SSDP30.8SEARCH request
CharGEN358.8Character generation request
QOTD140.3Quote request
BitTorrent3.8File search
Kad16.3Peer list exchange
Quake Network Protocol63.9Server info exchange
Steam Protocol5.5Server 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.


More alerts...