[ntp:security] Amplification DDoS vulnerabilities in Cisco's NTP server implementation(s)
Christian Rossow
christian.rossow at gmail.com
Fri Aug 16 09:38:23 UTC 2013
Dear Cisco PSIRT,
I am a researcher and currently explore amplification DDoS attacks. In
such an attack, adversaries send requests to public servers and spoof
the IP address of a victim. These servers, in turn, flood the victim
with valid responses and – unknowingly – exhaust its bandwidth. The most
commonly known amplification attack abuse open DNS resolvers.
I found amplification vectors in many NTP server implementations, among
others in Cisco software. The vulnerability allows attackers to amplify
their attack traffic by factor 25x-54x. Once this vulnerability is
abused, it may affect the connectivity of the Cisco devices, but for
granted it allows to launch severe DDoS attacks.
After a complete IPv4 scan, I estimate that more than 4,000,000 Cisco
devices are affected. Find attached a small test case that illustrates
how attackers can abuse one NTP server.
Unfortunately, I cannot tell exactly what type of Cisco systems are
affected. It may be consumer and business systems. I could at least
confirm one Cisco ASA device. In most cases, the devices identify
themselves as 'cisco' in the NTP requests, which gives me little chance
for further fingerprinting.
I am also in contact with the Network Time Foundation, the developers of
the popular ntpd implementation (see CC), who face similar issues in
their implementation. I'd appreciate if we could launch a joint effort
to get the amplification vectors fixed in future releases.
Note that I plan to file CVEs for this kind of vulnerability (also for
other protocols and their implementations), so do expect this kind of
attack to become public eventually.
Best,
Christian
PS: CC'ing Stewart and Ralph (who I was told are NTP experts at Cisco)
and the security group of the ntpd developers.
-------------- next part --------------
$ ntpq -n -c rv 85.13.250.57
assID=0 status=0600 leap_none, sync_ntp, no events, event_unspec,
system="cisco", leap=00, stratum=4, rootdelay=11.860,
rootdispersion=51.450, peer=16783, refid=193.26.222.150,
reftime=d5b86820.8e566ea9 Fri, Aug 16 2013 10:58:08.556, poll=7,
clock=d5b8682d.f06081cb Fri, Aug 16 2013 10:58:21.938, phase=-0.706,
freq=-21.68, error=0.26
# 12B request ('160200010000000000000000' in hex) lead to ~300B responses
# amplification: 25x in UDP payload bytes; varies per system (due to differing configs)
# likewise for `lv` and `readlist` commands
$ ntpq -n -c lassociations 85.13.250.57
ind assID status conf reach auth condition last_event cnt
===========================================================
1 16782 8000 yes yes none reject
2 16783 9600 yes yes none sys.peer
$ ntpq -n -c peers 85.13.250.57
# 12B request ('160200020000418e00000000' in hex, 418e is association) lead to 652B response(s)
# amplification: 54x in UDP payload bytes
# likewise for `lpeers` and `opeers` commands
# handshake to find associations can be done once; the association IDs do not change
# NOTE: even worse are attacks that abuse the `monlist` command, but
# these were not supported on the few Cisco devices I tested.
# Please double-check thoroughly! `monlist` allows for >4000x
# amplification (including a packet amplification of up to 100x)
$ ntpdc -c monlist 85.13.250.57
***Warning changing to older implementation
***Warning changing the request packet size from 160 to 48
***Server doesn't implement this request
More information about the security
mailing list