2003년 5월, 위스콘신-매디슨 대학교는 캠퍼스의 공개 NTP(Network Time Protocol) 서버 한 대로 향하는 대규모 인바운드 트래픽 홍수에 직면했다. 유입량은 초당 수십만 개의 패킷, 수백 메가비트에 달했다. 처음 대학 측은 이를 전형적인 분산 서비스 거부(DDoS) 공격으로 판단했다. 실제로 5월 14일 오전 8시경부터 상용 인터넷 서비스 제공사인 WiscNet 회선을 통해 트래픽이 급증했고, 9시 40분경에는 측정 인프라와 일부 구형 교내 라우터에 장애가 발생했다. 대학은 오전 11시경 문제 트래픽을 프로토콜과 포트로 식별해 WiscNet 경계 라우터에서 상단 차단하는, 공격 대응의 정석적 조치를 취했다.
그런데 이 트래픽에는 이상한 특징이 있었다. 겉보기에는 수많은 출처에서 온 76바이트 IP 패킷이 UDP 123번 포트(NTP)로 향하는 정상적인 질의처럼 보였지만, 모든 패킷이 동일한 출발지 포트 번호 23457을 사용하고 있었다. 덕분에 대학은 이 포트에서 나온 트래픽만 선별 차단하고 정상 요청은 계속 처리할 수 있었다. 23456 다음 숫자인 23457이라는 값 자체가 사람이 손으로 고른 흔적으로 보였다. 처음에는 미숙한 공격자가 출발지 주소를 무작위로 위조한 것으로 짐작하고 넘어갔다.
공격이 아니라 설계 결함
한 달 뒤에도 홍수는 잦아들기는커녕 더 거세졌다. 6월 초 라우터의 폐기 패킷 통계는 초당 25만 개, 150메가비트를 넘어섰고 시간이 갈수록 증가했다. 대학은 일부 인터페이스의 차단을 조심스럽게 풀어 소량의 트래픽을 통과시킨 뒤 페이로드까지 캡처했다. 그 결과 이 패킷들은 위조된 공격이 아니라 잘 구성된 SNTP(Simple NTP) 버전 1 질의였다. 다만 각 클라이언트가 초당 한 번꼴로 질의를 보내는, 시계를 맞추려는 목적으로는 터무니없이 잦은 빈도였다. 게다가 다수의 IP가 실제 DNS 이름으로 역해석되었고 해당 인터페이스의 유효한 출발지였다. 위조가 아니라 전 세계에 실재하는 호스트들이 문제였던 것이다.
출처 호스트가 모두 교외에 있었기 때문에 대학은 원격지 기관 네트워크 담당자들에게 조사를 요청했다. 상위 트래픽 발생 IP 중 두 곳의 대학 담당자들이 확인한 결과, 트래픽의 근원은 모두 넷기어(Netgear) 브랜드 라우터였으며 그중 하나는 MR814 모델로 특정되었다. 여기서 모든 조각이 맞아떨어졌다. 수많은 호스트가 같은 출발지 포트를 쓴 것은, 임베디드 SNTP 클라이언트에 프로그래머가 포트 번호 23457을 하드코딩했기 때문이었다.
strings 명령이 드러낸 하드코딩
조사자는 넷기어 여러 제품의 펌웨어를 내려받아 유닉스 strings 명령만으로 코드 안에 23457이라는 포트 번호가 박혀 있음을 확인했다. 같은 방식으로 RP614_4_12.bin 안에서 ASCII 문자열 형태의 IP 주소들도 찾아냈다. 그중 전 세계 라우팅 가능한 3개 주소 가운데 128.105.39.11 하나만 NTP 서버로 실제 사용되고 있었는데, 이는 바로 대학의 ntp1.cs.wisc.edu였다. 나머지 중 하나는 과거 dyndns.org가 쓰던 주소였고, 넷기어는 남은 주소들이 개발자가 디버깅용으로 남긴 죽은 코드라고 해명했다. 결함이 있는 클라이언트는 이 대학 서버 IP를 고정으로 박아두고, 응답을 받기 전까지 1초 간격으로 폭주하듯 질의를 보낸 뒤에야 제품과 펌웨어에 따라 1분·10분·2시간·24시간 간격으로 전환하는 구조였다.
제조사와의 소통은 순탄치 않았다. 6월 16일 넷기어 지원팀과 웹에서 수집한 직원들에게 이메일을 보냈지만 며칠간 응답이 없었고, 본사에 전화해 임원들에게 메시지를 남기고 명명 규칙을 추정해 임원 이메일까지 보낸 끝에야 대화가 시작됐다. 정식 지원 시스템의 자동 회신은 최초 신고로부터 23일이 지나서야 도착했다. 이후 대학·제조사·인터넷 커뮤니티 각 3분의 1씩 약 15명으로 구성된 검토팀이 꾸려져 해결 방향을 논의했다.
하나의 상수가 남긴 교훈
2003년 8월 시점에 대학은 최선을 다해 넷기어의 시간 요청을 계속 처리하기로 했고, 그 덕에 해당 제품 사용자는 대개 문제를 체감하지 못했다. 실제로 로깅·정책 스케줄·이메일 알림 같은 시간 기반 기능을 인지한 고객은 소수에 불과했다. 넷기어는 문제를 일으키지 않는 펌웨어를 내놓았고, RP614v2·RP614·DG814·MR814의 최신 펌웨어는 더 이상 대학 서버를 쓰거나 과도하게 폴링하지 않게 되었다. 다만 하루에만 50만 개 이상의 고유 넷기어 출처가 집계되었고, NAPT로 인한 주소·포트 재작성과 유휴 시 회선을 끊는 광대역 서비스 특성 탓에 실제 규모는 이보다 더 컸을 것으로 추정됐다.
이 사건은 20여 년이 지난 지금의 실무자에게도 유효한 시사점을 준다. 특정 공개 서버의 IP를 펌웨어에 박아두고, 응답 전까지 1초 간격으로 재시도하는 클라이언트가 수십만 대 배포되면 그 자체로 상대 서버에는 상시 DDoS와 다름없는 부하가 된다. 출발지 포트 하드코딩은 역설적이게도 피해자가 트래픽을 식별하고 선별 차단하는 데 결정적 도움을 주었지만, 정작 근본 원인은 임베디드 개발 단계의 상수 하나였다. 대량 배포되는 기기의 백오프 로직, 서버 주소 구성 방식, 그리고 취약점 신고에 대한 제조사의 대응 체계 — 오늘날 사물인터넷 시대의 펌웨어 설계와 vendor 커뮤니케이션에 그대로 적용되는 문제들이다.