Original release date: January 17, 2014 | Last revised: February 11, 2014
Certain UDP protocols have been identified as potential attack vectors:
Quake Network Protocol
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.
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 . 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.
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.
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.
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.
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 . 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 .
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  . Most network devices today provide these functions in their software.
Original release date: January 13, 2014 | Last revised: February 05, 2014
A Network Time Protocol (NTP) Amplification attack is an emerging form of Distributed Denial of Service (DDoS) that relies on the use of publically accessible NTP servers to overwhelm a victim system with UDP traffic.
The NTP service supports a monitoring service that allows administrators to query the server for traffic counts of connected clients. This information is provided via the “monlist” command. The basic attack technique consists of an attacker sending a "get monlist" request to a vulnerable NTP server, with the source address spoofed to be the victim’s address.
The attack relies on the exploitation of the 'monlist' feature of NTP, as described in CVE-2013-5211, which is enabled by default on older NTP-capable devices. This command causes a list of the last 600 IP addresses which connected to the NTP server to be sent to the victim. Due to the spoofed source address, when the NTP server sends the response it is sent instead to the victim. Because the size of the response is typically considerably larger than the request, the attacker is able to amplify the volume of traffic directed at the victim. Additionally, because the responses are legitimate data coming from valid servers, it is especially difficult to block these types of attacks. The solution is to disable “monlist” within the NTP server or to upgrade to the latest version of NTP (4.2.7) which disables the “monlist” functionality.
On a UNIX-platform, the command “ntpdc” will query existing NTP servers for monitoring data. If the system is vulnerable to exploitation, it will respond to the “monlist” command in interactive mode. By default, most modern UNIX and Linux distributions allow this command to be used from localhost, but not from a remote host. To test for monlist support, execute the following command at the command line:
/usr/sbin/ntpdc <remote server>
Additionally, the “ntp-monlist” script is available for NMap, which will automatically display the results of the monlist command. If the system does not support the monitor query, and is therefore not vulnerable to this attack type, NMap will return an error type 4 (No Data Available) or no reply at all.
Recommended Course of Action
As all versions of ntpd prior to 4.2.7 are vulnerable by default, the simplest recommended course of action is to upgrade all versions of ntpd that are publically accessible to at least 4.2.7. However, in cases where it is not possible to upgrade the version of the service, it is possible to disable the monitor functionality in earlier versions of the software.
To disable “monlist” functionality on a public-facing NTP server that cannot be updated to 4.2.7, add the “noquery” directive to the “restrict default” line in the system’s ntp.conf, as shown below:
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
Original release date: January 02, 2014 | Last revised: February 05, 2014
Point of Sale Systems
Point of Sale Systems
When consumers purchase goods or services from a retailer, the transaction is processed through what are commonly referred to as Point of Sale (POS) systems. POS systems consist of the hardware (e.g. the equipment used to swipe a credit or debit card and the computer or mobile device attached to it) as well as the software that tells the hardware what to do with the information it captures.
When consumers use a credit or debit card at a POS system, the information stored on the magnetic stripe of the card is collected and processed by the attached computer or device. The data stored on the magnetic stripe is referred to as Track 1 and Track 2 data. Track 1 data is information associated with the actual account; it includes items such as the cardholder’s name as well as the account number. Track 2 data contains information such as the credit card number and expiration date.
For quite some time, cyber criminals have been targeting consumer data entered in POS systems. In some circumstances, criminals attach a physical device to the POS system to collect card data, which is referred to as skimming. In other cases, cyber criminals deliver malware which acquires card data as it passes through a POS system, eventually exfiltrating the desired data back to the criminal. Once the cybercriminal receives the data, it is often trafficked to other suspects who use the data to create fraudulent credit and debit cards.
As POS systems are connected to computers or devices, they are also often enabled to access the internet and email services. Therefore malicious links or attachments in emails as well as malicious websites can be accessed and malware may subsequently be downloaded by an end user of a POS system. The return on investment is much higher for a criminal to infect one POS system that will yield card data from multiple consumers.
There are several types of POS malware in use, many of which use a memory scraping technique to locate specific card data. Dexter, for example, parses memory dumps of specific POS software related processes looking for Track 1 and Track 2 data. Stardust, a variant of Dexter not only extracts the same track data from system memory, it also extracts the same type of information from internal network traffic. Researchers surmise that Dexter and some of its variants could be delivered to the POS systems via phishing emails or the malicious actors could be taking advantage of default credentials to access the systems remotely, both of which are common infection vectors. Network and host based vulnerabilities, such as weak credentials accessible over Remote Desktop, open wireless networks that include a POS machine and physical access (unauthorized or misuse) are all also candidates for infection.
POS System Owner Best Practices
Owners and operators of POS systems should follow best practices to increase the security of POS systems and prevent unauthorized access.
Use Strong Passwords: During the installation of POS systems, installers often use the default passwords for simplicity on initial setup. Unfortunately, the default passwords can be easily obtained online by cybercriminals. It is highly recommended that business owners change passwords to their POS systems on a regular basis, using unique account names and complex passwords.
Update POS Software Applications: Ensure that POS software applications are using the latest updated software applications and software application patches. POS systems, in the same way as computers, are vulnerable to malware attacks when required updates are not downloaded and installed on a timely basis.
Install a Firewall: Firewalls should be utilized to protect POS systems from outside attacks. A firewall can prevent unauthorized access to, or from, a private network by screening out traffic from hackers, viruses, worms, or other types of malware specifically designed to compromise a POS system.
Use Antivirus: Antivirus programs work to recognize software that fits its current definition of being malicious and attempts to restrict that malware’s access to the systems. It is important to continually update the antivirus programs for them to be effective on a POS network.
Restrict Access to Internet: Restrict access to POS system computers or terminals to prevent users from accidentally exposing the POS system to security threats existing on the internet. POS systems should only be utilized online to conduct POS related activities and not for general internet use.
Disallow Remote Access: Remote access allows a user to log into a system as an authorized user without being physically present. Cyber Criminals can exploit remote access configurations on POS systems to gain access to these networks. To prevent unauthorized access, it is important to disallow remote access to the POS network at all times.
Fraudulent charges to a credit card can often be remediated quickly by the issuing financial institution with little to no impact on the consumer. However, unauthorized withdrawals from a debit card (which is tied to a checking account) could have a cascading impact to include bounced checks and late-payment fees.
Consumers should routinely change debit card PINs. Contact or visit your financial institutions website to learn more about available fraud liability protection programs for your debit and credit card accounts. Some institutions offer debit card protections similar to or the same as credit card protections.
If consumers have a reason to believe their credit or debit card information has been compromised, several cautionary steps to protect funds and prevent identity theft include changing online passwords and PINs used at ATMs and POS systems; requesting a replacement card; monitoring account activity closely; and placing a security freeze on all three national credit reports (Equifax, Experian and TransUnion). A freeze will block access to your credit file by lenders you do not already do business with. Under federal law, consumers are also entitled to one free copy of their credit report every twelve months through AnnualCreditReport.com.
Consumers may also contact the Federal Trade Commission (FTC) at (877) 438-4338 or via their website at www.consumer.gov/idtheft or law enforcement to report incidents of identity theft.
Original release date: November 13, 2013 | Last revised: November 16, 2013
Windows Operating System and Components
Select Microsoft software products contain multiple vulnerabilities. Microsoft has released updates to address these vulnerabilities.
The Microsoft Security Bulletin Summary for November 2013 describes multiple vulnerabilities in Microsoft software. Microsoft has released updates to address these vulnerabilities. The November Security Bulletin includes a patch for the new “watering hole” campaign which utilizes a US-based website that specializes in domestic and international security policy.
These vulnerabilities could allow remote code execution, elevation of privilege, information disclosure or denial of service.
Original release date: November 05, 2013 | Last revised: November 18, 2013
Microsoft Windows systems running Windows 8, Windows 7, Vista, and XP operating systems
US-CERT is aware of a malware campaign that surfaced in 2013 and is associated with an increasing number of ransomware infections. CryptoLocker is a new variant of ransomware that restricts access to infected computers and demands the victim provide a payment to the attackers in order to decrypt and recover their files. As of this time, the primary means of infection appears to be phishing emails containing malicious attachments.
CryptoLocker appears to have been spreading through fake emails designed to mimic the look of legitimate businesses and through phony FedEx and UPS tracking notices. In addition, there have been reports that some victims saw the malware appear following after a previous infection from one of several botnets frequently leveraged in the cyber-criminal underground.
The malware has the ability to find and encrypt files located within shared network drives, USB drives, external hard drives, network file shares and even some cloud storage drives. If one computer on a network becomes infected, mapped network drives could also become infected. CryptoLocker then connects to the attackers’ command and control (C2) server to deposit the asymmetric private encryption key out of the victim’s reach.
Victim files are encrypted using asymmetric encryption. Asymmetric encryption uses two different keys for encrypting and decrypting messages. Asymmetric encryption is a more secure form of encryption as only one party is aware of the private key, while both sides know the public key.
While victims are told they have three days to pay the attacker through a third-party payment method (MoneyPak, Bitcoin), some victims have claimed online that they paid the attackers and did not receive the promised decryption key. US-CERT and DHS encourage users and administrators experiencing a ransomware infection to report the incident to the FBI at the Internet Crime Complaint Center (IC3).
US-CERT recommends users and administrators take the following preventative measures to protect their computer networks from a CryptoLocker infection:
Conduct routine backups of important files, keeping the backups stored offline.
Maintain up-to-date anti-virus software.
Keep your operating system and software up-to-date with the latest patches.