컴퓨터는 시간 여행을 할 수 있다: NTP 공격 입문

컴퓨터를 재부팅한 후에도 시스템 시계가 어떻게 정확하게 유지되는지 궁금했던 적이 있는가? 그 정답은 바로 네트워크 시간 프로토콜인 NTP(Network Time Protocol)다.

NTP의 문제는 기본적으로 인증 메커니즘을 제공하지 않는다는 점이다. 즉, 컴퓨터는 전달받은 시간이 정당한 시간 서버에서 온 것인지 검증할 방법이 없다.

아래에서는 공격자가 조작된 시계로 무엇을 할 수 있는지, 시간 클라이언트가 이를 막기 위해 어떻게 방어하며, 여전히 남아 있는 치명적인 보안 허점이 무엇인지 살펴본다.

모든 것은 시계에 의존한다

시스템 시계의 정확성에 의존하는 핵심 기술의 몇 가지 예시는 다음과 같다.

• TLS 인증서: notBefore(유효 기간 시작일)와 notAfter(유효 기간 만료일) 사이의 기간 동안에만 유효하다.
• DNSSEC 서명: (RRSIG 레코드) 명시적인 시작 및 만료 타임스탬프를 지정한다.
• TOTP 코드: 인증 앱에서 생성되는 6자리 토큰이다.
• 커베로스(Kerberos) 티켓 및 서명된 API 요청: 수 분 이내의 엄격한 유효 시간 범위 내에서만 허용된다.

무방비 상태의 NTP

표준 NTP는 123번 포트에서 인증되지 않은 UDP를 사용하므로, 클라이언트는 정당한 응답과 위조된 응답을 구분할 수 없다.

네트워크 대역폭을 노리는 NTP 반사 DDoS 공격과 달리, 이 공격 벡터는 클라이언트의 내부 시계를 직접 노린다.

공격자는 주로 다음 세 가지 기법을 사용하여 시스템 시간을 변경할 수 있다.

• 경로 상 공격자(On-path attacker): 전송 중인 NTP 응답을 가로채서 변조한다.
• DNS 포이즈닝 공격자: 부팅 중 발생한 pool.ntp.org 쿼리를 악성 서버로 리다이렉트한다. Jeitner, Shulman, Waidner(DSN 2020)는 "모든 NTP 구현체가 부팅 시점 공격(boot-time attack)에 취약하다"는 것을 증명했다.
• 불량 NTP 풀 서버(Rogue NTP Pool server): 잘못된 타임스탬프를 직접 전송한다. Perry, Rozen-Schiff, Schapira(NDSS 2021)는 악의적인 풀 운영자가 대규모로 클라이언트 시계를 조작할 수 있음을 입증했다.

또한 Malhotra 외 연구진(NDSS 2016)은 IP 단편화(fragmentation)를 활용한 경로 외(off-path) 공격을 선보였다. 이 기법은 "무시할 수 없지만 비교적 작은" 공격 표면을 보여주는 반면, 위 세 가지 방식은 복잡한 패킷 조작조차 필요하지 않다.

시간 여행

클라이언트의 시계를 과거로 되돌리면 만료된 인증서가 다시 살아난다. 공격자가 만료된 인증서의 유출된 개인키를 가지고 있다면, 만료 경고를 발생시키지 않고 대상 사이트를 사칭할 수 있다.

2016년 NDSS 연구에 따르면 클라이언트 시계를 "하트블리드(Heartbleed)로 인해 10만 개 이상의 인증서가 철회되었던" 2014년 중반으로 되돌릴 수 있음이 지적되었다. 시계가 과거로 되돌려지면 "정상(good)" 상태를 주장하는 오래된 OCSP 응답이 다시 수용된다.

반대로 검증을 수행하는 DNS 리졸버(Validating DNS resolver)의 시계를 미래로 되돌리면 활성화된 모든 DNSSEC 서명이 무효화된다. 그 결과 리졸버는 서명된 쿼리를 거부하고 모든 서명된 도메인에 대해 SERVFAIL을 반환한다.

한국의 경우, APNIC Labs 보고서에 따르면 인터넷 사용자의 3.15%가 검증 리졸버에 의존하고 있다(당사의 DNSSEC 포스트 참조). 이러한 사용자들에게 시간이 미래로 이동하는 현상은 모든 서명된 도메인으로의 접속을 완전히 불가능하게 만든다.

기존 방어책과 실제 위험

표준 NTP 클라이언트는 잘못된 시간 업데이트를 완화하기 위해 안전 제한을 구현하고 있다.

• ntpd 문서는 1,000초의 패닉 임계값(panic threshold)을 정의한다. 오차가 이 제한을 초과하면 ntpd는 즉시 종료된다. 오차가 더 작은 경우, 오차가 300초 동안 지속되지 않는 한 갑작스러운 시간 도약을 무시한다. Malhotra 외 연구진의 계산에 따르면, 이러한 제약 조건 하에서 시계를 1년 뒤로 되돌리려면 최소 114일이 걸린다.
• Debian, Ubuntu, Fedora는 chrony를 makestep 1 3으로 설정하여, 초기 3회의 업데이트 동안에만 큰 폭의 시간 조정을 허용한다.
• Windows Time Service는 단독(standalone) 시스템의 경우 15시간, 도메인 컨트롤러의 경우 48시간을 초과하는 보정을 거부한다.
• Google Chrome은 호스트 OS를 무조건 신뢰하는 대신 구글의 네트워크 시간 서버를 기준으로 인증서 유효성을 검증한다.

이러한 보호 조치에도 불구하고, 특히 시스템 부팅 시점에 치명적인 보안 허점이 여전히 존재한다.

• Windows AD 환경에서는 장악된 도메인 컨트롤러가 기본적으로 도메인에 가입된 모든 기기에 영향을 미친다.
• Chrome은 예외 상황 시 로컬 시스템 시계로 폴백(fallback)한다.
• systemd-timesyncd는 패닉 임계값이 아예 없다. 설정된 단일 서버로부터 전달받은 모든 오차를 그대로 적용한다.
• chrony는 부팅 후 첫 3회 업데이트 동안 제한 없는 시간 조정을 허용한다. 이 부팅 허점을 통해 속도 제한이 적용되기 전에 DNS 포이즈닝 공격이 성공할 수 있다.
• -g 옵션으로 설정된 ntpd는 크기 제한 없는 초기 보정을 허용한다. Malhotra 외 연구진은 ntpd -g가 "재부팅 시 과거 또는 미래로 10년을 단번에 이동하는 조정을 수용함"을 확인했다. 해당 논문은 또한 "Linux를 포함한 많은 OS가 기본적으로 ntpd를 -g 옵션과 함께 실행한다"고 지적한다.

인증서 유효 기간이 짧아지면 유출된 키의 노출 기간은 줄어들지만, 취약한 시스템 시계는 이에 반작용한다. 인증서 유효 기간이 짧을수록 시간 공격(time-attack)에 더 취약해지는 법이다.

시간에 대한 신원 검증

RFC 8915(2020년 9월)에 규정된 Network Time Security(NTS)는 NTP에 암호화된 인증 방식의 시간 동기화를 도입한다.

NTS 클라이언트는 TCP 4460 포트를 통해 TLS 1.3 키 교환을 수행하여 키를 협상하고, 이후 전송되는 모든 NTP 패킷에 첨부된 인증 태그를 검증한다.

이 메커니즘은 불량 NTP 서버를 제외한 대부분의 공격을 효과적으로 차단한다.

chrony는 4.0 버전(2020년 10월)부터 NTS를 지원해 왔다. chrony.conf에서 다음과 같이 설정한다.

server time.cloudflare.com iburst nts
server nts.netnod.se iburst nts
server ptbtime1.ptb.de iburst nts
ntsdumpdir /var/lib/chrony

다음 명령어로 인증 상태를 확인한다.

chronyc -N authdata

인증된 세션은 Mode 컬럼에 NTS가 표시되며 쿠키 수(Cook)가 0이 아닌 값으로 설정된다.

12개의 활성 서버가 등록되어 있는 한국 NTP 풀(kr.pool.ntp.org)은 NTS를 제공하지 않는다.

인프라를 보호하려면 다음 세 가지 서버 설정을 적용하는 것이 좋다.

• (가능한 경우) NTS를 사용한다.
• 최소 3개 이상의 서로 다른 NTS 서버를 설정한다. 독립적인 다수의 출처를 지정하면 chrony가 잘못된 타임스탬프를 보낸 단일 불량 서버를 감지하고 표결에서 배제할 수 있다.
• Windows 도메인 멤버에서는 최대 시간 보정치를 제한한다. 무제한의 시간 오차를 허용하기보다 MaxPosPhaseCorrection 및 MaxNegPhaseCorrection을 유한한 값으로 명시적으로 설정한다.

원인을 파악해 보니 잘못된 시계 때문이었던 인증서 오류를 겪어본 적이 있는가?

참고 자료

1. Aanchal Malhotra, Isaac E. Cohen, Erik Brakke, Sharon Goldberg — Attacking the Network Time Protocol (NDSS 2016)
2. Philipp Jeitner, Haya Shulman, Michael Waidner — The Impact of DNS Insecurity on Time (DSN 2020)
3. Yarin Perry, Neta Rozen-Schiff, Michael Schapira — A Devil of a Time: How Vulnerable is NTP to Malicious Timeservers? (NDSS 2021)
4. Network Time Foundation — ntpd - Network Time Protocol (NTP) Daemon
5. Network Time Foundation — Clock State Machine
6. Microsoft — Windows Time service tools and settings
7. IETF — RFC 8915: Network Time Security for the Network Time Protocol (2020년 9월)
8. APNIC Labs — DNSSEC validation rate, Republic of Korea
9. NTP Pool Project — South Korea — kr.pool.ntp.org (2026-10-02 확인)