DDOS Attacks Using NTP

This is new:

The NTP method first began to appear late last year. To bring down a server such as one running “League of Legends,” the attackers trick NTP servers into thinking they’ve been queried by the “League of Legends” server.

The NTP servers, thinking they’re responding to a legitimate query, message the “League of Legends” server, overloading it with as many as 100 gigabits per second (Gbps). That’s large even for a DDoS attack.

In this way, one small request to an NTP server can generate an enormous response capable of taking down even high-capacity websites.

Tags:

Posted on January 20, 2014 at 6:18 AM • 32 Comments

Comments

Paul Renault • January 20, 2014 6:54 AM

I realize that some NTP servers are old and/or not easily patchable. As well as providing the means of a DDOS attack, this also hobbles the NTP server.

Isn’t this something that could be stopped by a firewall between the NTP server and the ‘Net – given a set of rules that can stop the incoming request?

M@ • January 20, 2014 7:14 AM

Not much different than the smurf attacks of yore, sending small ICMP packets to one network’s broadcast address but addressed from your target’s IP address (or broadcast address, if you wanted to take out two network’s at once). Ah the days before firewalls.

Bas • January 20, 2014 8:37 AM

@M@

Same idea, but very different, this works across networks. It’s a lot more difficult to solve on a large scale and you need to do that to really solve this.
With smurf attacks you could only attack (part of) your own network. The problem with no smurf protection on your network (within your control) would only be a problem to yourself.
With the NTP-DDOS you’re vulnerable to servers not in your control.

Secret Police • January 20, 2014 8:39 AM

This was fixed by OpenBSD years ago when they wrote OpenNTPD after seeing the nightmarish cluster of code inside the official ntp release and instead wanted something that could be audited.

Christian • January 20, 2014 9:42 AM

“Who uses NTP nowadays anyway?”

Basically everyone? Of how do you get the time to pc/smartphone.

TimeKeeper • January 20, 2014 9:51 AM

“Basically everyone? Of how do you get the time to pc/smartphone”

From the satellites obviously. NTP is being decomissioned.

feelyat • January 20, 2014 9:55 AM

@chuck
That Wisconsin event was similar only because it involved an NTP server, but in that case, it was a flaw in a commercial product that effectively DDoS’d the University NTP server by distributing thousands of poorly behaving NTP clients. Although the linked article doesn’t contain much in the way of details, it sounds like in this case, NTP servers are being used to launch DDoS attacks on other systems.

Roland Dobbins • January 20, 2014 9:57 AM

Actually, it isn’t new. We’ve observed ntp reflection/amplification DDoS attacks in the wild for 6-7 years, now. It’s just that the more mainstream tech media have picked up on it due to the broad consumer base affected by the attacks in December and early January against online gaming networks.

NobodySpecial • January 20, 2014 10:40 AM

@Alladdin – not now we have siri
They now pick a random number in a timezone in the middle of the night, ring it and parse the resposnse of the person screaming “don’t you know it’s 4:00am”

nakker • January 20, 2014 12:53 PM

Our datacenter – a major western tier 3 datacenter, providing colo for several hundred major companies suffered a connectivity outage for over an hour this weekend as a result of this attack bringing down one of the DC’s border routers. This is serious business, it’s not theoretical and not just going after games. I have some additional details I can provide if anyone takes interest.

/dev/badsuperblock • January 20, 2014 2:47 PM

Shouldn’t NTP servers throttle the number of replies they send to a given IP? I don’t know why on earth someone would request 1000 NTP updates a second, for hours…

garf • January 20, 2014 8:55 PM

sshdoor: Doing that to http (and some other types of requests) screws over tons of end users – or to put it another way, consequently doing that would make adsl an obsolete form of technology, and I’m not sure if there’s adequate replacement available.

Harry Johnston • January 20, 2014 9:04 PM

Surely at some point these malicious packets have to cross at least one router that knows (or ought to know) that the sender address in the packet isn’t valid for the interface that the packet came in on. Why aren’t they filtered?

Does IPv6 do any better in this respect?

65535 • January 21, 2014 2:36 AM

Oddly, my router doesn’t allow NTP connections. All boxes use the world clock manually. Now, DNS jacking is a different story but solvable.

dazzzer • January 21, 2014 5:53 AM

nakker, I’d relay appreciate further info if you are willing to share. Was impact caused by high CPU on the boarder router, or exhaustion of uplink bandwidth making the router unreachable? Were any mitigations effective, or did you have to ride it out?

arielb1 • January 21, 2014 12:08 PM

@garf:

schneier.com apparently removes angle brackets rather then escaping them – I’m reposting with 〈brackets〉 (U+2329/U+232A)

This is usually only done on pre-cookie packets – after you get a cookie you can get whatever you want.

Basically:

Simple “RPC” requests:
C -> S: Request 〈params〉 〈padding〉
S -> C: Response 〈result〉
(|result| ≤ |params| + |padding|)

Session Requests (both real (say SSH) sessions and long TCP-ey transfers):
C → S: Hello 〈params〉 〈client-cookie〉 〈hello-padding〉
S → C: Ready 〈server-cookie〉 〈client-cookie〉 〈ready-response〉

C → S: Request 〈cookie〉 〈req〉
C → S: Acknowledge 〈cookie〉 〈ack-to〉
S → C: Response 〈resp〉

With the cookie bound to the IP address (and typically also the incoming port – which is sometimes used as 〈client-cookie〉) – if 〈cookie〉 is calculable from just 〈ret-cookie〉 this prevents anyone who can’t sniff a connection from sending stuff to it – and in some protocols (I heard that HTTP 2.0 does it) 〈cookie〉 is actually generated from a DH of 〈client-cookie〉 and 〈server-cookie〉 – 〈init-cookie〉||〈client-cookie〉 is signed in 〈ready-response〉 – of course there’s a KDF with the sequence number in-between.

Harry Johnston • January 21, 2014 5:02 PM

That last comment from arielb1 (“Here are some further notes on the subject”) looks potentially malicious. Or has the comment system just done something odd?

sshdoor • January 22, 2014 4:18 AM

@garf: “Doing that to http (and some other types of requests) screws over tons of end users”

My suggestion is only for protocol that will be designed in the future. A future without such powerful DOS is better than a future without asymetric ADSL.

You would be surprised at the size of the http requests, loaded by cookies.

@Harry Johnston: “at some point these malicious packets have to cross at least one router that knows (or ought to know) that the sender address in the packet isn’t valid”

Try traceroute between two clients you own in two different contries: the forward and backwards route will differ.

This is because the dynamic routing protocols would be too complicated if the set of hops (routers) had to be the same for a legitimate request and for its answer. Except if the list of encoutered routers were added to request packets, like it done currently to emails.

sshdoor • January 22, 2014 4:26 AM

@Harry Johnston, please forget about my (wrong) answer to your question.

The right answer is that deep packet inspection is a task with too much complexity (defragmentation of packets, …) for a router.

Future protocols could enforce the sender address to be in a fixed format in the first 1024 bytes of the first packet.

sshdoor • January 22, 2014 4:40 AM

@arielb1: “This is usually only done on pre-cookie packets [… specifications]”

Very nice answer, thank you.

arielb1 • January 22, 2014 5:45 AM

@sshdoor:

I will note that the specification I posted is actually the basics of many network protocols rather then something I invented (TCP,DNS,HTTP/2,actually even TLS – which has a handshake [Hello/Ready] exchange independent of TCP’s) – of course they typically don’t call it `cookies’ – TCP calls 〈client-cookie〉 client port and 〈server-cookie〉 sequence number – but same same. DNS uses the RPC protocol – It actually has a 〈client-cookie〉 too (Again the client port – I forgot to add it in that specification, but it is actually needed in these kinds of protocols to distinguish multiple requests from the same IP)

So they actually go like this:
C → S: Request 〈client-cookie〉 〈params〉 〈padding〉
S → C: Response 〈client-cookie〉 〈result〉

Harry Johnston • January 22, 2014 1:50 PM

@sshdoor: looking at the IP header is hardly “deep packet inspection” and it is already in the first 1024 bytes of the packet.

I’m guessing the problem is that it would be too much work for the typical ISP / carrier to figure out and keep track of all the legitimate exceptions.

TimeToolsGlobal • November 11, 2014 5:24 AM

The latest version of NTP – 4.2.7 fixes this DDOS security issue. NTP.org recommends all users to update to the letest version as soon as possible. For users that have to stick with older versions, disable the monlist function with:

restrict default kod nomodify notrap nopeer noquery

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.