서브도메인 탈취(Dangling DNS) 진단

Problem

status.example.com이나 docs.example.com 같은 서브도메인에 DNS 레코드는 아직 있는데, 그게 가리키던 대상은 사라졌습니다 — 폐기한 클라우드 앱, 만료된 SaaS 체험판, 철거한 CDN 배포본. 레코드 정리가 안 됐습니다. 이제 그 레코드는 누구나 점유할 수 있는 이름을 가리키고, 점유한 사람이 당신의 도메인으로, 주소창에 당신 이름을 띄운 채 콘텐츠를 서빙합니다.

Symptoms

• CNAME이나 ALIAS가 서드파티 플랫폼(*.github.io, *.s3.amazonaws.com, *.herokudns.com, *.azurewebsites.net, *.cloudfront.net)을 가리키는데, 페이지에 “There isn’t a GitHub Pages site here” 또는 “NoSuchBucket” 같은 플랫폼 오류가 뜹니다.
• 접은 프로젝트, 마케팅 캠페인, 벤더에서 쓰던 옛 서브도메인이 아직 풀립니다.
• 보안 스캐너나 버그 바운티 리포트가 “dangling” 또는 “claimable” 레코드를 지적했습니다.
• 서브도메인이 내 서버가 아니라 플랫폼에서 404를 반환합니다.

Dangling DNS 레코드가 실제로 뭔지

DNS 레코드는 자기가 가리키던 대상보다 오래 살아남습니다. 호스팅 플랫폼에 문서 사이트를 띄우고 docs.example.com CNAME your-project.platform.io를 추가하면 잘 됩니다. 몇 달 뒤 프로젝트를 닫고 호스팅 계정을 지워도 — 존의 CNAME은 여전히 거기, your-project.platform.io를 충실히 가리킵니다. 그 타깃 이름은 이제 누구의 것도 아닙니다.

이 정리 문제를 보안 구멍으로 바꾸는 부분이 여기 있습니다: 대부분의 클라우드 플랫폼은 리소스 이름을 선착순으로 점유하게 둡니다. 공격자가 같은 플랫폼에 your-project를 등록하면, 당신의 CNAME이 여전히 거기를 가리키니 docs.example.com이 이제 그들의 콘텐츠를 서빙합니다 — 당신의 도메인으로, 흔히 서브도메인 통제권을 증명해 무료로 발급받은 TLS 인증서까지 달고요. 브라우저엔 유효한 자물쇠와 당신의 호스트명이 뜹니다. 방문자 관점에선 진짜 사이트와 구별이 안 됩니다.

이론도, 새로운 것도 아닙니다. 이 기법은 보안 연구자 Frans Rosén이 문서화하고 Detectify가 2014년에 널리 알렸습니다; 커뮤니티가 관리하는 can-i-take-over-xyz 프로젝트가 이제 100개 넘는 서비스의 “미점유” 지문을 목록화합니다. 사라지지 않는 이유는 시시합니다: 리소스 폐기와 그 DNS 정리는 별개의 티켓이고, 두 번째 티켓이 잊힙니다.

Top 3 Causes

1. 폐기된 클라우드 리소스, 살아남은 CNAME — 전형적 케이스. 정적 사이트, 앱, 버킷은 삭제됐는데 DNS 레코드가 남습니다. 지문은 그 플랫폼을 CNAME으로 가리키는 서브도메인에서 (내 404가 아니라) 플랫폼이 생성한 오류 페이지가 뜨는 것. 플랫폼이 그 리소스 이름을 새 계정이 점유하게 허용하면, 서브도메인은 탈취 가능합니다.
2. 만료된 SaaS·벤더 연동 — 헬프데스크, 상태 페이지, 이메일 마케팅, 랜딩 페이지 벤더가 설정하라고 준 CNAME. 결제를 끊었고, 그들이 리소스를 해제했고, 당신의 레코드는 여전히 거기를 가리킵니다. 서브도메인이 흔히 기억하기 좋은 마케팅 이름(help., careers., go.)이라 캠페인이 끝난 뒤엔 아무도 주인이 아니어서 놓치기 쉽습니다.
3. dangling NS 위임 — 더 드물지만 더 위험합니다: 서브도메인을 관리형 DNS 존으로 위임(NS 레코드)했는데 나중에 공급자에서 그 존이 삭제된 경우. 공격자가 같은 공급자에 그 존을 재생성할 수 있으면, 서브도메인 아래 모든 레코드를 통제합니다 — 이름 하나가 아니라요.

DechoNet으로 진단

• DNS 검사는 서브도메인의 정확한 CNAME/ALIAS/NS 타깃을 보여줍니다. 서드파티 플랫폼 호스트명을 가리키면 그 플랫폼을 적어두세요 — 점유 가능한 리소스가 있는지 확인할 서비스입니다. 풀리긴 하는데 당신 것이 아닌 타깃이 경고 신호입니다.
• HTTP 검사는 서브도메인을 가져와 응답을 보여줍니다. 서드파티 호스트를 거쳐 돌아오는 플랫폼 오류 본문(“NoSuchBucket”, “There isn’t a GitHub Pages site here”, “404 Not Found · Fastly”)이 — 당신 서버의 404가 아니라 — dangling, 잠재적으로 점유 가능한 레코드의 지문입니다.

Resolution Checklist

• 서드파티를 CNAME/ALIAS/NS로 가리키는 모든 서브도메인을 목록화하세요. dangling될 수 있는 건 이것들뿐입니다 — 당신 인프라를 가리키는 A/AAAA 레코드는 외부인이 점유 못 합니다.
• 각각에 대해 서브도메인을 가져와 본문을 읽으세요. 플랫폼의 “미점유/그런 리소스 없음” 메시지가 적신호; 당신 애플리케이션의 404는 괜찮습니다.
• 지문을 can-i-take-over-xyz 데이터베이스와 대조해 그 플랫폼이 실제로 해제된 이름의 재점유를 허용하는지 확인하세요(일부는 이제 이름을 계정에 묶어 탈취 불가).
• DNS 레코드를 지우거나 다시 연결해 고치세요 — 그게 구멍을 즉시 닫습니다. DNS는 안 건드리고 상위 리소스만 지우면 정반대; dangling을 만듭니다.
• 아직 쓰고 싶은 리소스라면 지금 직접 재점유하세요(공격자보다 먼저) 그리고 프로비저닝을 유지하세요.
• 앞으로 올바른 철거 순서를 정하세요: DNS 레코드를 먼저 다시 연결하거나 삭제, 클라우드 리소스를 그다음 폐기. 절대 반대로 하지 마세요.

When to Escalate

• 서브도메인이 이미 당신이 안 올린 콘텐츠를 서빙 중이면 실시간 인시던트로 다루세요: DNS 레코드를 즉시 내리고, 그 서브도메인이 무엇에 접근할 수 있었는지 확인하세요 — 공유된 부모 도메인 쿠키, OAuth 리다이렉트 허용목록, CSP/CORS 신뢰, 그것을 허용한 내부 도구들.
• dangling NS 위임은 이름 하나가 아니라 존 전체의 탈취입니다. 일반 정리 티켓 위로 에스컬레이트하세요 — 폭발 반경이 공격자가 그 서브도메인 아래 만들 수 있는 모든 레코드입니다.
• 서드파티 CNAME 타깃의 주인이 누구인지 모르겠다면, 그게 진짜 문제입니다. 추적 안 되는 벤더 레코드가 탈취가 사는 곳입니다; 서브도메인을 누군가 검토하는 인벤토리에 올리세요.