ISC BIND 9에서 TKEY 쿼리가 named 데몬을 종료시키며 서비스 거부(DoS)까지 유발하는 이유는, 원격 공격자가 보낸 TKEY 쿼리가 처리 경로 안에서 REQUIRE 어설션 실패를 일으켜 데몬을 강제로 종료시키기 때문입니다.
CVE-2015-5477 취약점 개요 및 영향
CVE-2015-5477은 ISC BIND 9의 TKEY 쿼리 처리 경로에서 발생하는 원격 서비스 거부(Remote Denial of Service) 취약점입니다. DNS 서버의 핵심 프로세스인 named 데몬이 특정 조건의 TKEY 쿼리를 처리하는 과정에서 내부적인 REQUIRE 어설션(assertion) 실패가 일어나면 데몬은 곧바로 종료됩니다.
이 취약점의 핵심은 원격 공격자가 특수하게 조작된 TKEY 쿼리를 전송하면 서버의 가용성을 완전히 상실하게 만든다는 점입니다. DNS 서비스는 네트워크 인프라의 근간이라 named 데몬이 종료되면 단순한 서비스 중단을 넘어 전체 네트워크의 도메인 이름 해석 불능 상태까지 초래하는 심각한 보안 위협이 됩니다.
취약 버전 및 수정 버전 경계
해당 취약점은 ISC BIND 9의 여러 릴리스 버전에서 발견되었습니다. 관리자는 현재 운영 중인 named 데몬의 버전이 아래 취약 범위에 들어 있는지 즉시 확인합니다.
| BIND 9 계열 | 취약 버전 범위 | 상태 |
|---|---|---|
| BIND 9.x | 9.9.7-P2 이전 버전 | 취약 |
| BIND 9.10.x | 9.10.2-P3 이전 버전 | 취약 |
위 표에 명시된 버전 경계 이전의 소프트웨어를 사용하는 환경은 TKEY 쿼리를 이용한 서비스 거부 공격에 그대로 노출되어 있어, 최신 보안 패치가 적용된 버전으로 업데이트가 시급합니다.
기술적 분석 및 PoC 공개 상태
이 취약점은 기술적으로 TKEY 처리 로직의 변수 관리 미흡에서 비롯됩니다. 공개된 분석을 보면, 이 취약점의 패치는 두 번째 lookup(조회) 단계가 수행되기 전에 관련 변수를 NULL로 설정해 어설션 실패를 막는 방식으로 이뤄졌습니다.
이 취약점의 위험성을 입증하는 개념 증명(PoC) 코드도 이미 공개되어 있어 공격 진입 장벽이 매우 낮습니다. Exploit-DB의 exploit 37721 자료에 CVE-2015-5477의 BIND9 TKEY assert DoS 공격 방법이 상세히 정리되어 있습니다. 공격자가 PoC를 활용해 조작된 패킷을 전송하면 서버 관리자의 개입 없이도 즉각적인 서비스 중단이 일어납니다.
CISA KEV 등재 및 최신 위협 동향
CVE-2015-5477은 발견된 지 오래된 취약점임에도 실제 환경에서 지속적으로 악용될 가능성이 높다고 판단되어 최신 보안 관리 목록에 올랐습니다. 미국 사이버보안 및 인프라 보안국(CISA)은 2026년 10월 8일 CVE-2015-5477을 KEV(Known Exploited Vulnerabilities, 알려진 악용 취약점) 목록에 공식적으로 추가했습니다.
KEV 목록에 등재되었다는 것은 이론적인 취약성이 아니라 실제로 야생(in-the-wild)에서 공격에 활용되고 있다는 뜻입니다. 구버전 BIND 9를 여전히 운영 중인 서버 관리자에게는 즉각적인 조치가 필요하다는 강력한 경고로 읽힙니다.
대응 방안: 업데이트 및 임시 조치
가장 근본적이고 권장되는 해결책은 ISC BIND 9를 취약점이 해결된 최신 버전으로 업데이트하는 것입니다. 앞서 언급한 버전 경계(9.9.7-P2 및 9.10.2-P3 이후) 이상의 버전을 설치하면 TKEY 쿼리 처리 시 발생하는 어설션 실패 문제가 해결됩니다.
즉각적인 업데이트가 불가능한 환경에서는 네트워크 레벨에서 공격 패킷을 차단하는 임시 조치를 고려할 수 있습니다. iptables로 TKEY Type 패킷(00F900FF)을 식별한 뒤 DROP 처리하는 식으로 공격 시도를 차단하는 방법이 제시되었습니다.
iptables 임시 차단 설정 예시:
# iptables -A INPUT -p udp --dport 53 -m string --algo bm --hex-string '|00F900FF|' -j DROP
다만 이 방화벽 설정은 임시 방편에 불과합니다. TKEY 기능을 정상적으로 사용해야 하는 환경이라면 서비스 영향도를 함께 평가한 뒤 적용하는 것이 좋습니다. 장기적으로는 소프트웨어 패치로 취약점을 근본적으로 제거하는 것이 필수입니다.