NTP reflection attacks continue

Published: 2014-02-17
Last Updated: 2014-02-17 22:23:39 UTC
by Chris Mohan (Version: 1)
5 comment(s)
 
As we discussed here back in January, there has been a significant rise in large Network Time Protocol (NTP) reflection DDoS attacks. In such an attack, an attacker sends a crafted packet that requests a large amount of data that is ultimately sent to the spoofed host. 
 
In our previous post[1], we discussed in detail the “monlist” command but it’s not just “monlist” that can be abused but many level-6 and level-7 commands such as “showpeer”, “sysstats”, “peers”, “listpeers”.
 
To lock down your NTP server, please follow our previous post and upgrade your NTP version as outlined by US-Cert here[2].
 
Additionally, as a FYI, a recent US Cert alert [3] identified other possible sources of UDP amplification attacks and it is recommended to review.
 
For those that think, well that won't happen to me or "Who cares, DDoS attacks have been happening since 1999" this year has already shown an excessive number of public attacks using NTP, creating a devastating flood of traffic to anyone without top notch mitigation* measures lined up. And we're only in February.
 
Brian Krebs's web site, a reporter that write about cyber security stories,  was hit by a 200Gbps of NTP traffic over the last week [4]. Brian reports how and by whom launched the attack in a detail story that's well worth a read. It's not just small targets; since the start of 2014, as reported here, many online gaming websites have been targeted through these reflection-type attacks with the attackers taking to Twitter to announce the upcoming attack and later bask in the glory. The latest Arbor report [5] talks about this in further detail, mentions attacks of up to 309Gbps and names the relevant Twitter IDs tweeting about DDOS. Cloudflare indicated that the attack they saw earlier this week was 400Gbps. The sheer size of these attacks mean that they just don’t break the target but significant areas of the Internet, i.e. large collateral damage.
 
If you see NTP reflection attacks being targeted towards you, the standard best practice follows – 
 
• Apply ACLs to your perimeter network and as far possible upstream 
 
• Work with your ISP(s) to do the same [6]
 
• Lock down your own NTP servers and other UDP-listening servers 
 
• If you detect open ntp servers, report them to the Open NTP project [7]
 
For those that are looking for a handy DDoS quick reference guide explaining the different DDoS attack http://www.us-cert.gov/sites/default/files/publications/DDoS%20Quick%20Guide.pdf
 
* For the majority of businesses DDoS mitigation has a financial cost associated with it that increases upward for increased protection
 
[1] https://isc.sans.edu/diary/NTP+reflection+attack/17300
[2] https://www.us-cert.gov/ncas/alerts/TA14-013A
[3] https://www.us-cert.gov/ncas/alerts/TA14-017A 
[4] http://krebsonsecurity.com/2014/02/the-new-normal-200-400-gbps-ddos-attacks/
[5] http://www.arbornetworks.com/asert/2014/02/ntp-attacks-welcome-to-the-hockey-stick-era/
[6] http://www.ietf.org/rfc/rfc3704.txt 
[7] http://openntpproject.org/
 

Chris Mohan --- Internet Storm Center Handler on Duty

5 comment(s)

Scanning for Symantec Endpoint Manager

Published: 2014-02-17
Last Updated: 2014-02-17 18:06:51 UTC
by Johannes Ullrich (Version: 1)
2 comment(s)

Last week, we mentioned a new vulnerability in Symantec Endpoint Protection Management [1]. According to Symantec's advisory, this product listens on port 9090 and 8443/TCP. Both ports are scanned regularly for various vulnerabilities, in particular 8443, being that it is frequently used by web servers as an alternative to 443. However, on February 7th, we detected a notable increase in scans for both ports. 

(click on image for larger version)

Interestingly, it looks like two different IP addresses caused this increase, scanning for one port only each.

217.174.250.228 is the "heavy hitter" for port 8443, and 125.217.252.183 for port 9090. There is no organizational connection between the two IPs based on Whois. 

125.217.252.183 is assigned to a University in China (the whois record contains a bit a weird looking "description": ~{;*DO@m9$4sQ'~} ). 
217.174.250.228 is assigned to a british hosting company. 

My assumption is that both hosts were compromised at the time. 

Today, we are also seeing a large increase in scanning for port 9090, pointing to someone building a target list of vulnerable systems. Pretty much the only source scanning today is 113.010.155.079. This address is interesting in that it is not assigned according to APNIC (the RIR in charge of this address), but it does respond to pings. It runs a phpmyadmin website as default host, which pretty much guarantees that it is a compromised system (could actually also be a honeypot).

[1] http://www.symantec.com/docs/TECH214866

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

Keywords:
2 comment(s)
ISC StormCast for Monday, February 17th 2014 http://isc.sans.edu/podcastdetail.html?id=3848

Comments


Diary Archives