어느 날 내 서브도메인이 공격자의 콘텐츠를 내보내기 시작합니다. 그런데 아무도 내 서버를 건드리지 않았습니다. 패치, 인증, 모니터링은 여기서 도움이 되지 않습니다. 원인은 침입이 아니라, 지우는 것을 잊은 무언가입니다.
실제로 일어나는 일 (3단계)
1. 생성
정규화된 도메인 이름(app-xxxx.<제공자 도메인>)을 가진 클라우드 리소스를 만들고,sub.example.com이 그쪽으로 가도록 내 영역에 CNAME 레코드를 추가합니다.2. 폐기(절반만)
필요 없어진 리소스를 삭제합니다. 이때sub.example.com의 CNAME도 지워야 하는데, 지우지 않습니다. 아무 데로도 이어지지 않는데 여전히 활성 도메인으로 공개되어 있는 상태, 즉 매달린(dangling) DNS 레코드입니다.3. 탈취
공격자가 매달린 서브도메인을 발견하고 내가 제어하던 것과 같은 FQDN으로 리소스를 만듭니다. 그때부터sub.example.com으로 가는 트래픽은 공격자의 리소스에 도착하고, 내용은 공격자가 정합니다.
내 DNS 영역(변경 없음)
sub.example.com CNAME→ app-xxxx.provider.example
↓ 대상만 사라졌다
클라우드 리소스: 삭제됨
그 이름은 누구나 차지할 수 있는 상태로 돌아간다
↓ 공격자가 같은 이름으로 리소스를 만든다
공격자의 리소스(공격자의 계정)
sub.example.com이 무엇을 내보낼지 공격자가 정한다. 내 서버는 한 번도 건드려지지 않았다
CNAME이 약한 이유는 이름을 가리키기 때문이다
주소를 가리키는 A 레코드와 달리 CNAME은 이름을 가리키고, 많은 클라우드 서비스에서 그 이름은 먼저 차지하는 사람이 쓸 수 있습니다. 내가 놓는 순간 다른 사람이 가져갈 수 있습니다. 문서는 CNAME 레코드가 "이 위협에 특히 취약하다"고 말합니다. MX 레코드에도 같은 논리가 적용되며, 이 경우 그 서브도메인으로 오는 메일을 다른 사람이 받을 수 있게 됩니다.
피해는 가짜처럼 보이는 페이지에 그치지 않는다
- 서브도메인 통제권 상실
- 내가 관리하지 않는 콘텐츠가 내 도메인에서 나갑니다. 브랜드 손상과 신뢰 상실로 이어집니다
- 쿠키 수집
- 웹 앱은 흔히 와일드카드(
*.example.com)로 세션 쿠키를 서브도메인에 공개하며, 이 경우 어느 서브도메인이든 쿠키에 접근할 수 있습니다. 탈취된 서브도메인의 그럴듯한 페이지가 방문자에게서 쿠키를 수집할 수 있고, Secure 속성이 붙은 쿠키도 포함됩니다 - 피싱에 이용
- 도메인이 정상으로 확인되므로, 그곳에서 보내는 피싱은 훨씬 설득력이 있습니다
가장 큰 오해: "HTTPS고, 인증서도 있다"
문서는 이것을 흔한 오해로 지목하고 부정합니다. 탈취된 서브도메인을 가진 공격자는 그 이름으로 정상 인증서를 신청해 받을 수 있습니다. 도메인 검증 인증서는 신청자가 그 순간 이름을 제어하는지를 확인하므로, 제어권이 넘어간 것은 감지하지 못합니다.
결과적으로 정상 인증서는 공격자에게 유리하게 작용합니다. 자물쇠 표시가 나타나고, Secure 속성의 쿠키도 그대로 전송되고, 가짜 사이트는 덜이 아니라 더 정상처럼 보입니다. 인증서는 "이 이름을 누가 갖고 있는가"로 읽고, 결코 "내가 누구와 통신하고 있는가"로 읽지 마세요.
막는 법: DNS 레코드를 먼저 지우는 것을 절차로 만든다
원인은 기술적인 어려움이 아니라 폐기 작업의 순서입니다. 리소스를 먼저 지우고 DNS를 나중에 지우면, 그 사이에 서브도메인이 탈취될 수 있습니다.
사고를 만드는 순서
리소스 삭제 → DNS는 나중에 → 잊어버림
그동안 DNS는 계속 살아 있는 정상 서브도메인을 공개합니다. 모니터링은 서버가 다운되었다고 알려 주지 않습니다. 다운된 것이 아무것도 없기 때문입니다.
안전한 순서
DNS 레코드를 먼저 삭제 → 그다음 리소스 삭제
문서는 사용자 지정 DNS 항목이 있는 리소스에 삭제 잠금을 걸라고 권합니다. 잠금 자체가 리소스를 폐기하기 전에 매핑을 지워야 한다는 신호가 되기 때문입니다. 다만 이런 조치는 내부 교육과 함께해야 효과가 있다고 덧붙입니다.
폐기 체크리스트에 "DNS 항목 삭제"를 넣는다
문서가 드는 첫 번째 예방 단계입니다. 서비스를 폐기할 때의 필수 점검 목록에 넣고, 리소스를 지울 때마다 DNS 레코드도 지우도록 개발자에게 알려 둡니다. 핵심은 순서를 누군가의 기억에 맡기지 않는 것입니다.
레코드의 수명을 리소스와 묶는다
일부 제공자는 리소스 자체에 묶인 레코드 유형(별칭 레코드 등)을 제공합니다. 리소스를 지우면 레코드가 빈 집합이 되므로, 아무것도 가리키지 않는 레코드가 남을 수 없습니다. 지원 서비스는 한정되지만, 적용할 수 있는 곳에서는 쓰세요. 절차가 아니라 설계로 잊힌 레코드를 막습니다.
소유 증명을 요구한다
일부 서비스에서는 사용자 지정 도메인에 소유 확인용 TXT 레코드를 공개할 수 있습니다. 이것이 있으면 다른 구독은 그 사용자 지정 도메인을 검증하거나 탈취할 수 없습니다. 같은 이름으로 리소스를 만드는 것 자체를 막지는 못하지만, 소유를 증명할 수 없으면 내 트래픽을 받을 수 없습니다. 먼저 차지한 사람이 아니라 소유를 증명할 수 있는 사람만 그 이름을 쓸 수 있습니다.
DNS 영역을 정기적으로 점검한다: 존재하는가, 내 것인가?
문서는 두 가지 확인을 듭니다. 대상이 존재하는가, 그리고 내가 소유하는가. 중요한 것은 두 번째입니다. "응답하니까 괜찮다"는 확인이 아닙니다. 다른 사람의 리소스에서 오는 응답이 바로 이 공격입니다. FQDN 엔드포인트와 담당자를 연결한 서비스 목록을 두고, 자산 목록 점검의 일부로 정기적으로 내보내세요.
발견했다면 레코드 삭제로 끝내지 않는다
복구 단계는 더 나아갑니다. 애플리케이션 코드에 남은 오래된 서브도메인 참조를 고치고, 침해가 있었는지 조사하고, 폐기 시 왜 레코드가 지워지지 않았는지 밝혀 재발을 막습니다. 특히 애플리케이션이 OAuth 자격 증명 같은 비밀이나 개인 정보를 그 매달린 서브도메인으로 보내고 있었다면, 그 데이터가 제3자에게 노출되었을 수 있습니다.
본 사이트의 견해: 노출은 만든 것보다 쓰지 않게 된 것에서 더 많이 생긴다
보안 논의는 지금 만들고 있는 것에 쏠리지만, 침입은 은퇴시키고 방치한 것에서 시작되는 경우가 많습니다. 아무도 쓰지 않는 서브도메인, 퇴사자의 계정, 실험 한 번을 위해 만든 스테이징 환경, 해지 후에도 남아 있는 회원 기록. 모두 "이제 안 쓴다"는 이유로 조용히 감시와 점검에서 빠진다는 공통점이 있습니다. 쓰지 않게 된 것도 삭제될 때까지는 자산입니다. 그래서 본 사이트는 자산 목록의 범위를 지금 운영 중인 것이 아니라 지금까지 만든 모든 것으로 잡으라고 권합니다. 서비스를 해지한 뒤에 제공자 침해의 영향 범위에 들어간 사람들도 같은 문제의 예입니다(호스팅 업체가 침해되었을 때 할 일).
출처(공식)
- Microsoft, "Prevent dangling DNS entries and avoid subdomain takeover" (Microsoft Learn / Azure security fundamentals) — learn.microsoft.com (3단계, CNAME이 특히 취약한 이유, 쿠키 수집과 MX 레코드, 인증서에 대한 오해의 부정, 삭제 잠금·별칭 레코드·소유 확인·정기 점검 등의 예방 및 복구 단계는 모두 이 문서에서 나왔습니다)
다음으로 읽기
- 자산 목록: 자산 목록 점검 체크리스트 (지금까지 만든 모든 것으로 넓히기)
- 배치: 공개 버킷 (같은 "설정 때문에 새는" 형태)
- 용어: 피싱이란 / XSS란 / CSRF란
FAQ
Q서브도메인 탈취는 내 서버가 침해되었다는 뜻인가요?
아닙니다. 그래서 까다롭습니다. 탈취되는 것은 서버가 아니라 DNS가 가리키는 곳입니다. 클라우드 리소스를 삭제하고 DNS 영역에 CNAME 레코드를 남겨 두면, 제3자는 자기 구독에서 같은 정규화된 도메인 이름(FQDN)으로 리소스를 만들기만 하면 되고, 내 서브도메인으로 향하는 트래픽이 그쪽에 도착합니다. 패치, 인증, 모니터링은 여기서 도움이 되지 않습니다. 어느 것도 관여하지 않기 때문입니다.
QHTTPS면 막을 수 있지 않나요? 인증서가 있으면 안전하지 않나요?
막을 수 없습니다. Microsoft 문서는 이것을 흔한 오해로 직접 지목합니다. 탈취된 서브도메인을 가진 쪽은 그 이름으로 정상 인증서를 신청해 받을 수 있습니다. 도메인 검증 인증서는 그것을 가진 쪽이 지금 그 이름을 제어하고 있다는 것만 증명할 뿐, 그 쪽이 누구인지는 말해 주지 않고, 제어권이 넘어간 것도 감지하지 않습니다. 정상 인증서는 오히려 가짜 사이트를 더 정상처럼 보이게 해 공격자에게 유리하게 작용합니다.
Q겉모습에만 영향을 준다면 피해는 제한적이지 않나요?
세션이 유출됩니다. 웹 앱은 흔히 와일드카드(*.example.com)로 세션 쿠키를 서브도메인에 공개하고, 그런 경우 어느 서브도메인이든 쿠키를 읽을 수 있습니다. 사용자를 탈취된 서브도메인으로 유도할 수 있다면 Secure 속성이 붙은 쿠키도 공격자 손에 들어갈 수 있습니다. 또 매달린 MX 레코드가 있으면 그 서브도메인으로 오는 메일을 다른 사람이 받을 수 있습니다.
Q실제로 어떻게 막나요?
삭제 순서를 사람의 기억이 아니라 절차와 장치로 만드세요. 문서는 서비스 폐기 시 필수 점검 목록에 'DNS 항목 삭제'를 넣고, 사용자 지정 DNS 항목이 있는 리소스에 삭제 잠금을 걸어 그 잠금 자체가 DNS를 먼저 지워야 한다는 신호가 되게 하고, 가능하면 리소스와 수명이 연동되는 레코드 유형을 쓰고, DNS 영역을 정기적으로 점검해 각 대상이 존재하는지와 내가 소유하는지를 확인하라고 권합니다.