[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