DNS 보호하는 DNSSEC, 문제 있다?
- DNS 조작과 변조 방지하는 DNSSEC
- 하지만 기존 DNSSEC 검사 기능에 허점들 있어
- 새 검사 기법 적용했더니, 여러 가지 충돌 현상 발견돼
DNS 응답의 무결성과 출처를 검증하는 데 사용되는 기술인 DNSSEC을 100% 신뢰하기는 힘들다는 연구 결과가 나왔다. 이는 보안 기업 팔로알토네트웍스(Palo Alto Networks)와 퍼듀대학, 캘리포니아 대학교 어바인, 텍사스대학교 댈러스의 연구원들이 참여한 이번 분석 프로젝트의 충격적인 결과로, “DNSSEC은 모두가 알고 있는 것만큼 안전한 건 아니”라고 한다.
DNSSEC?
이 연구 결과가 왜 충격적인지 이해하려면 제일 먼저 DNSSEC부터 알아야 한다. DNSSEC은 ‘도메인 이름 시스템 보안 확장 프로그램(Domain Name System Security Extensions)’의 준말이다. DNS가 위조 혹은 변조되는 것을 확인하는 방법이라고 할 수 있다. 아, 그러면 DNS가 무엇인지부터 알아야 하는데, 이 ‘도메인 이름 시스템’은 아주 간단히 말해 ‘인터넷의 전화번호부’ 정도라 할 수 있다. 그러므로 DNSSEC은 전화번호부를 사용할 때 그 내용이 잘못되지 않았다는 걸 보장해주는 장치다.
연구원들은 DNS와 DNSSEC에 대해 다음과 같이 표현하기도 한다. “DNS가 일반 엽서라면 DNSSEC은 등기 우편입니다. 일반 엽서는 실제 발송인이 누구인지 확인할 수 없죠. 엽서에 써 있는 정보를 믿어야 할 뿐입니다. 등기 우편은 발신자 서명이 찍히고, 훨씬 정확하게 발신자를 추적할 수도 있습니다.” 그런데 그 DNSSEC을 신뢰하기 어렵다는 건, 등기 우편 시스템 자체를 수정해야 할지도 모른다는 뜻이 된다.
또, 이 설명을 통해 알 수 있는 건, 인터넷을 통해 정보나 요청을 보낼 수 있는 방법이 DNS와 DNSSEC 두 가지나 우리에게 있다는 것이다. 그리고 그 중 DNSSEC은 ‘안전’에 좀 더 초점을 맞춘 방식이라 할 수 있다. “DNS는 속도에 좀 더 비중을 둔 기술입니다. 안전과 관련된 기술을 상대적으로 빈약하며, 그렇기에 공격자들은 이미 오래 전부터 DNS를 공격에 알맞게 조작하곤 했습니다.”
DNS 공격
DNS를 공략하는 방법 중 대표적인 것은 DNS 캐시 포이즈닝(DNS Cache Poisoning)이다. DNS 스푸핑(DNS Spoofing)이라고 부르기도 한다. 해커가 가짜 IP 주소를 리졸버에 심어두는 기법인데, 이렇게 하면 피해자가 정상적인 주소를 자신의 브라우저 주소창에 입력하더라도 해커의 IP 주소로 접속하게 된다. 하지만 DNSSEC이 위변조 방지에 특화된 기술인만큼, 이런 공격은 잘 차단하는 편이다. DNS 통신을 중간에서 가로채 조작하는 공격인 DNS 하이재킹(DNS Hijacking)의 경우도 비슷하게 DNSSEC로 어느 정도는 해결이 된다.
DNS를 조작하는 게 아니라, DNS로 트래픽을 증폭시켜서 효과를 내는 디도스 공격의 경우, DNSSEC으로는 차단이 어렵다. 공격 메커니즘과 방어 메커니즘이 전혀 달라 서로 호환이 되지 않는다고 봐야 한다. 하지만 DNSSEC의 신뢰성에 어느 정도 문제가 있다는 게 진짜라면, DNS 스푸핑이나 하이재킹과 같은 공격도 안정적으로 막을 수 없게 된다.
DNSSECVerifi, 새로운 테스트 기법
여태까지의 내용들이 보안 업계의 일반적 상식이었다. 그런데 위 보안 기업과 대학 연구원들이 여기에 의문을 품고 새로운 테스트 프레임워크를 활용해 실험을 진행했다. 이 프레임워크의 이름은 DNSSECVerifi로, 연구원들이 새롭게 개발한 건 아니다. 암호화 프로토콜 분석에서는 흔히 사용되는 것이다. 다만 DNSSEC에는 거의 적용된 적이 없었다. “DNSSECVerifi는 기존 DNSSEC 검사보다 좀 더 꼼꼼하게 검사를 진행합니다. 컴퓨터를 통해 수많은 경우의 수를 다 대입해 적용하거든요.”
‘기존 검사’는 여러 가지인데, 대표적으로는 퍼징(fuzzing), 수동 코드 점검 및 모의 해킹, 상호 호환성 시험 등이 있다. 퍼징은 프로그램이나 시스템, 플랫폼 등이 어떤 상황에서 비정상 종료되는지를 파악하는 데 강점이 있고, 수동 코드 점검 및 모의 해킹은 소스 코드를 한 줄 한 줄 분석하거나 알려진 공격 기법을 직접 대입하기 때문에 창의적이며, 상호 호환성 시험(interoperability test)은 서로 다른 소프트웨어가 상호작용할 때 데이터가 깨지지 않는지 확인한다. 따라서 퍼징은 프로그램이 버티느냐 못 버티느냐를 찾아내는 데 더 적합하고, 수동 코드 점검은 놓치는 경우의 수가 있으며, 상호 호환성 시험은 ‘기능 정상 작동’을 보는 데 초점을 맞추고 있다.
이런 테스트 기법들과 달리 DNSSECVerifi는 거의 모든 경우의 수를 수학적으로 검증하는 것이라, 학계에서는 ‘정식 방법론(Formal Methods)’이라 부르기도 한다. “DNSSECVerifi는 컴퓨터 안에서 DNS 세계를 통째로 복제합니다. 즉, 모든 구성 요소들이 가상으로 자리를 잡는 겁니다. 요청을 던지는 리졸버, 그에 대한 답을 내는 서버, 답을 기억하는 캐시가 대표적인 구성 요소들이죠. 이들이 DNSSEC 표준 안에서만 작동하도록 합니다. 그런 후에는 이 요소들이 맞닥트릴 수 있는 모든 상황을 시뮬레이션 해서 수학적으로 잘 작동하는지를 확인합니다.”
기존 테스트 기법과 DNSSECVerifi의 차이는 정확히 무엇일까? “기존에는 실제 문제가 발생하면, 그제서야 ‘여기에 구멍이 있었다’는 걸 알리고 조치를 취하는 순서로 일이 진행됐습니다. 즉, 사후 대처 위주였죠. DNSSECVerifi는 건물 설계도를 보고 도둑이 구멍으로 여길 수 있는 모든 지점을 하나하나 다 확인하고, 그 구멍들로 보이는 것들이 어떤 가상의 시나리오 속에서 연계적으로 활용될 수 있는지를 다 수학적으로 계산하는 겁니다.”
그래서 어떤 문제 발견했나?
이번에 연구진들이 발견한 문제점 중 가장 핵심적인 건 NSEC과 NSEC3가 혼용되어 배포된다는 것이라고 한다. NSEC과 NSEC3는 ‘특정 도메인이 존재하지 않는다는 것을 증명하는 방법’이라고 할 수 있다. DNS의 출처를 확인할 때, 출처라고 여겨진 도메인이 존재하느냐, 존재하지 않느냐를 파악하는 건 대단히 중요한 일이라고 할 수 있다. 그런데 이 두 방법이 공존한다는 게 문제가 될 수 있다는 거다.
“NSEC은 도메인 이름을 알파벳 순서대로 줄을 세워 빈 칸이 있나 없나 확인하는 기법입니다. 그래서 예를 들면 ‘A와 C 사이에는 아무 것도 없다’고 증명하는 식이죠. NSEC3는 이름을 암호화 해서 줄을 세운 상태로 증명한다는 차이를 가지고 있습니다.” 이 두 가지는 왜 공존할 수 없을까? “리졸버가 NSEC3 방식의 증명을 받았다고 칩시다. 그런데 그 근처에 NSEC 관련 기록이 같이 있다면 리졸버는 헷갈리기 시작합니다. 그래서 실제로는 존재하는 도메인인데, 없는 것처럼 여깁니다. 그런 상황들이 현재 DNSSEC 상태에서 실제 발생할 수 있습니다.”
이러한 충돌 때문에 생기는 현상은 크게 3가지였다고 한다. 하나는 “인증에 공백이 생긴다는 것”이었다. 공격자가 NSEC3 응답을 조작함으로써 리졸버가 특정 NSEC 응답을 무시하게 만들 수 있는데, 이 때문에 가짜를 진짜로 인증하는 사태가 발생한다는 게 연구진들의 설명이다. 두 번째는 리졸버의 캐시가 오염된다는 건데, “캐시라는 저장소에 모순된 정보가 저장되는 일이 있었다”고 한다. 이것이 쌓이고 쌓이면 서비스 거부 상태에 이를 수 있다고 한다.
마지막은 “자원 고갈 및 증폭”이었다. “전 세계 220만 리졸버를 조사해 보니 NSEC과 NSEC3가 섞여 있을 때 응답 실패나 타임아웃이 발생할 확률이 훨씬 높았습니다. 모순된 상황이 발생하니, 리졸버가 이를 해결하기 위해 여러 계산을 반복하게 돼서 생기는 일이었습니다.” 이런 상황들은 NSEC과 NSEC3을 별도로 검사해서는 발견할 수 없는 것들이었다고 연구진들은 강조한다. “DNSSEC 규정 하나하나만 보면 모를 수밖에 없는 겁니다. 이 규정들을 이리 저리 조합해보니 나오는 문제였어요.”
그래서?
연구팀은 이번 발견을 토대로 “NSEC과 NSEC3을 절대로 한 구역에서 혼합해 사용하면 안 된다”는 결론을 내릴 수 있었다고 한다. “아직 두 가지가 혼용되는 상황에 대해서 국제 표준 기구가 별 다른 언급을 하지는 않고 있습니다. 아직 그러한 상황을 인지하지 못하고 있기 때문인데, 이번 발견을 통해 움직임이 이어질 것으로 예상합니다. 공식 발표가 있기 전이지만, 지금부터라도 NSEC과 NSEC3을 혼용하지 말아야 합니다.”🆃🆃🅔
by 문가용 기자(anotherphase@thetechedge.ai)
Related Materials
- How we measure DNSSEC validation - APNIC Blog, 2023년 (DNSSEC 검증 실패 시 SERVFAIL 응답률 측정으로 실제 신뢰성 평가, 많은 리졸버에서 무효 서명 처리 문제 발견)
- DNSSEC Checker: FREE DNSSEC Validator - PowerDMARC, 2024년 (dnssecverifi 유사 도구로 DS/DNSKEY 불일치, RRSIG 만료 등 실제 DNSSEC 구성 오류 사례 다수 검출)
- Troubleshooting DNSSEC Configurations - DNSimple, 2024년 (Verisign/ICANN DNSSEC Analyzer 결과로 DS 기록 누락·오류 등 검증 실패 원인 상세 분석)
- DNSSEC validation results and troubleshooting tips - Site24x7, 2024년 (실제 테스트에서 NSEC/NSEC3 불완전, 서명 검증 실패 등 DNSSEC 보호 미비 사례 정리)
Donghwi Shin
문가용 기자
![[TE머묾] 이민국에 대항하는 미국 시민들, 한국에도 힌트가 되다](https://images.unsplash.com/photo-1762468046498-461933328de6?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDIyfHxjaXRpemVuc2hpcHxlbnwwfHx8fDE3Njc4ODE0NjR8MA&ixlib=rb-4.1.0&q=80&w=600)
