the impact of ntp security weaknesses on dns(sec)

The impact of NTP security weaknesses on DNS(SEC)

Aanchal Malhotra1

Willem Toorop2 (presenter)Benno Overeinder2

Sharon Goldberg1

NLnet LabsRoN++ 15 December 2017

1 Boston University2 NLnet Labs

The impact of NTP security weaknesses on DNS(SEC) 2/22Willem Toorop (NLnet Labs)

Networ

k Work

ing Gr

oup

D.L.

Mills

Reques

t for

Commen

ts: 95

8

M/A-

COM Li

nkabit

Se

ptembe

r 1985

Ne

twork

Time P

rotoco

l (NTP

)

Status

of th

is Mem

o

Thi

s RFC

sugges

ts a p

ropose

d prot

ocol f

or the

ARPA-

Intern

et

com

munity

, and

reques

ts dis

cussio

n and

sugges

tions

for im

provem

ents.

Dis

tribut

ion of

this

memo i

s unli

mited.

Table

of Con

tents

1.

I

ntrodu

ction

2.

S

ervice

Model

3.

P

rotoco

l Over

view

4.

S

tate V

ariabl

es and

Forma

ts

5.

P

rotoco

l Oper

ation

5.1

. P

rotoco

l Mode

s

5.2

. M

essage

Proce

ssing

5.3

. N

etwork

Consi

derati

ons

5.4

. L

eap Se

conds

6.

R

eferen

ces

App

endix

A. UDP

Heade

r Form

at

App

endix

B. NTP

Data

Format

1. In

troduc

tion

Thi

s docu

ment d

escrib

es the

Netwo

rk Tim

e Prot

ocol (

NTP),

a prot

ocol

for

synch

ronizi

ng a s

et of

networ

k cloc

ks usi

ng a s

et of

distri

buted

cli

ents a

nd ser

vers.

NTP i

s buil

t on t

he Use

r Data

gram P

rotoco

l

(UD

P) [13

], whi

ch pro

vides

a conn

ection

less t

ranspo

rt mec

hanism

. It

is

evolve

d from

the T

ime Pr

otocol

[7] a

nd the

ICMP

Timest

amp me

ssage

[6]

and i

s a su

itable

repla

cement

for b

oth.

Network Time Protocol


Domain Name System

Root

COM nlfr

SURFNET.nl Nlnetlabs.nl

Network Working Group P. Mockapetris

Request for Comments: 1034 ISI

Obsoletes: RFCs 882, 883, 973 November 1987

DOMAIN NAMES - CONCEPTS AND FACILITIES

1. STATUS OF THIS MEMO

This RFC is an introduction to the Domain Name System (DNS), and omits

many details which can be found in a companion RFC, "Domain Names -

Implementation and Specification" [RFC-1035]. That RFC assumes that the

reader is familiar with the concepts discussed in this memo.

A subset of DNS functions and data types constitute an official

protocol. The official protocol includes standard queries and their

responses and most of the Internet class data formats (e.g., host

addresses).However, the domain system is intentionally extensible. Researchers are

continuously proposing, implementing and experimenting with new data

types, query types, classes, functions, etc. Thus while the components

of the official protocol are expected to stay essentially unchanged and

operate as a production service, experimental behavior should always be

expected in extensions beyond the official protocol. Experimental or

obsolete features are clearly marked in these RFCs, and such information

should be used with caution.


Networ

k Work

ing Gr

oup

D.L.

Mills

Reques

t for

Commen

ts: 95

8

M/A-

COM Li

nkabit

Se

ptembe

r 1985

Ne

twork

Time P

rotoco

l (NTP

)

Status

of th

is Mem

o

Thi

s RFC

sugges

ts a p

ropose

d prot

ocol f

or the

ARPA-

Intern

et

com

munity

, and

reques

ts dis

cussio

n and

sugges

tions

for im

provem

ents.

Dis

tribut

ion of

this

memo i

s unli

mited.

Table

of Con

tents

1.

I

ntrodu

ction

2.

S

ervice

Model

3.

P

rotoco

l Over

view

4.

S

tate V

ariabl

es and

Forma

ts

5.

P

rotoco

l Oper

ation

5.1

. P

rotoco

l Mode

s

5.2

. M

essage

Proce

ssing

5.3

. N

etwork

Consi

derati

ons

5.4

. L

eap Se

conds

6.

R

eferen

ces

App

endix

A. UDP

Heade

r Form

at

App

endix

B. NTP

Data

Format

1. In

troduc

tion

Thi

s docu

ment d

escrib

es the

Netwo

rk Tim

e Prot

ocol (

NTP),

a prot

ocol

for

synch

ronizi

ng a s

et of

networ

k cloc

ks usi

ng a s

et of

distri

buted

cli

ents a

nd ser

vers.

NTP i

s buil

t on t

he Use

r Data

gram P

rotoco

l

(UD

P) [13

], whi

ch pro

vides

a conn

ection

less t

ranspo

rt mec

hanism

. It

is

evolve

d from

the T

ime Pr

otocol

[7] a

nd the

ICMP

Timest

amp me

ssage

[6]

and i

s a su

itable

repla

cement

for b

oth.

NTP Weaknesses


Networ

k Work

ing Gr

oup

D.L.

Mills

Reques

t for

Commen

ts: 95

8

M/A-

COM Li

nkabit

Se

ptembe

r 1985

Ne

twork

Time P

rotoco

l (NTP

)

Status

of th

is Mem

o

Thi

s RFC

sugges

ts a p

ropose

d prot

ocol f

or the

ARPA-

Intern

et

com

munity

, and

reques

ts dis

cussio

n and

sugges

tions

for im

provem

ents.

Dis

tribut

ion of

this

memo i

s unli

mited.

Table

of Con

tents

1.

I

ntrodu

ction

2.

S

ervice

Model

3.

P

rotoco

l Over

view

4.

S

tate V

ariabl

es and

Forma

ts

5.

P

rotoco

l Oper

ation

5.1

. P

rotoco

l Mode

s

5.2

. M

essage

Proce

ssing

5.3

. N

etwork

Consi

derati

ons

5.4

. L

eap Se

conds

6.

R

eferen

ces

App

endix

A. UDP

Heade

r Form

at

App

endix

B. NTP

Data

Format

1. In

troduc

tion

Thi

s docu

ment d

escrib

es the

Netwo

rk Tim

e Prot

ocol (

NTP),

a prot

ocol

for

synch

ronizi

ng a s

et of

networ

k cloc

ks usi

ng a s

et of

distri

buted

cli

ents a

nd ser

vers.

NTP i

s buil

t on t

he Use

r Data

gram P

rotoco

l

(UD

P) [13

], whi

ch pro

vides

a conn

ection

less t

ranspo

rt mec

hanism

. It

is

evolve

d from

the T

ime Pr

otocol

[7] a

nd the

ICMP

Timest

amp me

ssage

[6]

and i

s a su

itable

repla

cement

for b

oth.

NTP Weaknesses

[1] Attacking the Network Time Protocol.

A. Malhotra, I. Cohen, E. Brakke, S. Goldberg. In the proceedings of The Network & Distributed System Security Symposium (NDSS), CA, 2016.

[2] Attacking NTP’s Authenticated Broadcast Mode.

A. Malhotra, S. Goldberg. ACM SIGCOMM, Computer Communication Review, 2016.

[3] The Security of NTP’s Datagram Protocol.

A. Malhotra, M.V. Gundy, M. Varia, H. Kennedy, J. Gardner, S. Goldberg. In the proceedings of 21st International Conference on Financial Cryptography and Data Security (FC), 2017.

http://www.cs.bu.edu/~goldbe/papers/NTPattack.pdf

https://eprint.iacr.org/2016/055.pdf

https://eprint.iacr.org/2016/1006.pdf


How does DNSdepend on time?

TTL (Time to Live) = Time Span


How do software implementations deal with time spans?

BINDstruct RRset_t { uint8_t dname; uint16_t rrtype; uint16_t rrclass; struct timeval expiry; void *rdata[];};

if (gettimeofday(&rrset->expiry, NULL)) perror("Could not get time of day");else rrset->expiry.tv_sec += ttl;


How do software implementations deal with time spans?

BINDstruct RRset_t { uint8_t dname; uint16_t rrtype; uint16_t rrclass; struct timeval expiry; void *rdata[];};

if (gettimeofday(&rrset->expiry, NULL)) perror("Could not get time of day\n");else rrset->expiry.tv_sec += ttl;

Time Span translated to TIME stampFrom system time updated by NTP


Why is this bad?

BIND

Time Span translated to TIME stampFrom system time updated by NTP

● NTP vulnerabilities [1, 2, 3] can be leveraged for off-path attacks on DNS cache:

– Cache-expiration attack (Time shifted forward)

– Cache-sticking attack (Time shifted backwards)


struct RRset_t { uint8_t dname; uint16_t rrtype; uint16_t rrclass; struct timespec expiry; void *rdata[];};

if (clock_gettime(CLOCK_MONOTONIC_RAW, &rrset->expiry)) perror("Could not get time of day");else rrset->expiry.tv_sec += ttl;

Recommendation

● Not a protocol problem ● Deal with implementations ONLY!

draft-aanchal-time-implementation-guidance

• Unspecified starting point• Monotonically increasing• not subject to NTP adjustments• or by adjustments from adjtime

https://tools.ietf.org/html/draft-aanchal-time-implementation-guidance


struct RRset_t { uint8_t dname; uint16_t rrtype; uint16_t rrclass; struct timespec expiry; void *rdata[];};

if (clock_gettime(CLOCK_MONOTONIC_RAW, &rrset->expiry)) perror("Could not get time of day\n");else rrset->expiry.tv_sec += ttl;

Recommendation

● Not a protocol problem ● Deal with implementations ONLY!


• Unspecified starting point• Monotonically increasing• not subject to NTP adjustments• or by adjustments from adjtime

Terminology

A clock is a function that maps time to a clock time value

Use raw clock time stampInstead of real clock time stamp



DNSSEC


How does DNSSEC depend on time?

Expiration & InceptionAs WALL CLOCKtime stamps


How do software implementations deal with wall clock time stamps?

BIND

struct timeval now;

if (gettimeofday(&now, NULL)) perror("Could not get time of day");

else if (now < rrset->rrsig.inception) verify_error("Not yet valid");

else if (now > rrset->rrsig.expiration) verify_error("Not valid anymore");


Recommendation

● Fundamental problem with the protocol● Have to use real clock time (i.e. system time)

The only solution● Fix Network Time Protocols




Recommendation

● Fundamental problem with the protocol● Have to use real clock time (i.e. system time)

The only solution● Fix Network Time Protocols


Impact?● Denial of Service attacks● Disable DNSSEC by shifting before 15 July 2010



Measure the attack surfaceRIPE ATLAS

● Which resolvers run NTP?Target probe’sresolvers (DHCP?)




● Target resolverswith public IPs +

● Try to discover IPs

dig whoami.akamai.net Adig o-o.myaddr.l.google.com. TXT



# resolvers

Total +- 18500 on 10320 probes

With public IP resolvers 8244 on 4594probes

Answering NTP time queries 2021 (24.5%)

Answering NTP control queriesfrom public internet

75

Answering NTP control queriesfrom NLNOG RING node from same ASN

26

Total answering NTP control queries 101 (1.23%)

Measurements don from 21 till 27 October 2017


Measure the attack surfaceOpen Resolvers

From August 2017 list of the Open Resolver Project

# resolvers

Total 16.5M

Targeted 6.5M

Still answering DNS queries (Nov 2017) 2.3M

Answered REFUSED (authoritatives) 1.7M

Open resolvers 600K

Answering NTP queries 3.7% 24.5% on ATLAS

Answering NTP control queries 0.93% 1.23% on ATLAS


De impact of NTP security weaknesses on DNS(SEC)

● Sophisticated attacks possible● Script-kiddie attacks less so

(DOS of DNSSEC resolvers)● Attack surface around 1% of resolvers

● Software takes a common approach towards (wall/real) clock time stamps and time spans

● Not just RRset TTLs (also network timeouts etc.)



the impact of ntp security weaknesses on dns(sec)

Documents