Schneier on Security
A blog covering security and security technology.
« Friday Squid Blogging: Camouflage in Squid Eyes |
| CTX4000: NSA Exploit of the Day »
January 20, 2014
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.
Posted on January 20, 2014 at 6:18 AM
• 31 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
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?
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.
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.
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.
Who uses NTP nowadays anyway?
"Who uses NTP nowadays anyway?"
Basically everyone? Of how do you get the time to pc/smartphone.
"Basically everyone? Of how do you get the time to pc/smartphone"
From the satellites obviously. NTP is being decomissioned.
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.
NTP = Network Time Protocol
NNTP = Network News Transfer Protocol
The first is the subject of this post, the second is not.
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.
I thought computers dial + 44 123 to get the time
@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"
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.
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...
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.
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?
Oddly, my router doesn't allow NTP connections. All boxes use the world clock manually. Now, DNS jacking is a different story but solvable.
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?
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.
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.
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?
@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.
@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.
@arielb1: "This is usually only done on pre-cookie packets [... specifications]"
Very nice answer, thank you.
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〉
@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.
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc.