Vibe Guardian

Vibe Guardian

목록으로
BLOG DETAIL

서브도메인 탈취란 — 삭제한 서비스의 CNAME이 공격자에게 넘어가는 방법

#서브도메인탈취#subdomain takeover#CNAME보안#DNS설정

ARTICLE CONTENT

1. 서브도메인 탈취가 왜 자주 언급될까

1) 삭제한 서비스와 남아 있는 DNS 설정의 문제

서브도메인탈취는 생각보다 단순한 설정 실수에서 시작되는 경우가 많습니다. 서비스를 삭제했는데도 DNS 설정이 그대로 남아 있으면, 그 주소가 계속 외부를 향하게 됩니다. 특히 CNAME이 더 이상 존재하지 않는 서비스 주소를 가리키고 있으면, 공격자가 그 빈틈을 노릴 수 있습니다. 그래서 subdomain takeover는 “복잡한 해킹”보다 “정리되지 않은 설정”에서 출발하는 문제로 많이 다뤄집니다.

2) 왜 검색하는 사람이 많은가

이 주제를 검색하는 사람들은 보통 두 가지 상황에 놓여 있습니다. 하나는 운영 중인 사이트에서 이상 징후가 있을까 걱정하는 경우이고, 다른 하나는 예전에 연결해 둔 서브도메인이 안전한지 확인하려는 경우입니다. 특히 여러 서비스와 외부 도구를 함께 쓰는 팀일수록 DNS설정 관리가 분산되기 쉬워, 서브도메인탈취 가능성을 점검하려는 수요가 생깁니다. 결국 이 키워드는 “지금 내 설정이 안전한가”를 확인하려는 의도와 연결되어 있습니다.

3) 이 글에서 다룰 내용

이 글에서는 서브도메인 탈취가 어떤 원리로 발생하는지, CNAME보안에서 왜 이런 문제가 생기는지, 그리고 어떤 항목을 먼저 확인하면 좋은지 정리해보겠습니다. 또한 실제로 점검할 때 자주 놓치는 부분과, 기본적인 보안 점검을 도와주는 방식이 어떤 상황에서 유용한지도 함께 살펴보겠습니다.

2. 서브도메인 탈취는 어떤 구조에서 발생할까

1) CNAME이 가리키는 대상이 사라질 때

서브도메인탈취의 대표적인 사례는 CNAME이 연결하던 외부 서비스가 삭제되거나 계정이 해지된 경우입니다. DNS는 여전히 “이 주소는 저쪽으로 연결하라”고 안내하지만, 정작 목적지는 더 이상 존재하지 않습니다. 이때 동일한 이름의 리소스를 공격자가 등록할 수 있는 환경이라면, 원래 주소를 대신 차지하는 상황이 생길 수 있습니다.

2) 공격자가 노리는 지점

공격자는 보통 완전히 새로운 취약점을 뚫기보다, 이미 죽어 있는 연결고리를 찾는 방식으로 접근합니다. 예를 들어 서브도메인이 특정 서비스에 연결된 흔적은 남아 있는데 실제 서비스는 비어 있는 경우가 있습니다. 이런 상태는 subdomain takeover의 전형적인 탐색 대상이 됩니다. 즉, 문제의 핵심은 “주소가 살아 있는 것처럼 보이지만 실제 소유권 확인이 느슨한 상태”에 있습니다.

3) 단순 삭제와 안전한 삭제는 다르다

서비스를 없앴다고 해서 자동으로 안전해지는 것은 아닙니다. 도메인 연결을 해제하지 않고 서비스를 먼저 종료하면, DNS설정상 남은 레코드가 오랜 기간 방치될 수 있습니다. 그래서 삭제 순서와 정리 절차가 중요하며, CNAME보안 관점에서는 “서비스 삭제”와 “DNS 정리”를 함께 봐야 합니다.

3. CNAME보안에서 특히 확인해야 할 부분

1) 연결 대상이 실제로 유효한지

CNAME은 편리하지만, 대상 서비스가 계속 살아 있어야만 의미가 있습니다. 점검할 때는 단순히 레코드가 존재하는지만 볼 것이 아니라, 그 대상이 현재도 유효한지 확인해야 합니다. 서브도메인탈취는 바로 이 빈틈에서 발생하는 경우가 많습니다. 따라서 DNS설정 점검 시에는 “기록이 있다”보다 “기록이 가리키는 서비스가 정상인지”가 더 중요합니다.

2) 인증서와 HTTPS 상태

기본적인 보안 점검에서는 HTTPS와 인증서 상태도 함께 보는 편이 좋습니다. 인증서 오류가 있다고 해서 곧바로 subdomain takeover가 되는 것은 아니지만, 운영이 제대로 정리되지 않았다는 신호가 될 수 있습니다. 특히 서브도메인이 오래된 상태로 남아 있다면, HTTPS 연결과 보안 헤더도 함께 확인하는 것이 좋습니다.

3) 쿠키와 권한 범위

서브도메인이 공격자에게 넘어가면, 그 도메인과 연관된 쿠키나 권한 설정이 예상치 못한 영향을 줄 수 있습니다. 물론 모든 경우에 바로 큰 사고로 이어지는 것은 아니지만, 쿠키 범위가 넓거나 API 접근 제어가 느슨한 경우에는 위험도가 커집니다. 그래서 CNAME보안은 단순히 DNS 한 줄을 보는 일이 아니라, 브라우저와 애플리케이션의 권한 구조까지 함께 보는 과정이라고 이해하는 편이 좋습니다.

4. 실제로 어떤 피해로 이어질 수 있을까

1) 신뢰를 이용한 피싱

서브도메인탈취가 무서운 이유는 겉모습이 원래 사이트와 비슷해 보일 수 있다는 점입니다. 정상 도메인의 하위 주소이기 때문에 사용자는 의심을 덜 할 수 있고, 그만큼 피싱이나 유사 페이지 운영에 악용될 가능성이 있습니다. subdomain takeover가 단순 설정 오류처럼 보여도, 실제로는 브랜드 신뢰를 직접 건드릴 수 있습니다.

2) 내부 링크와 외부 공유 자산의 오염

예전에 외부에 공유했던 링크, 문서에 남아 있는 주소, 앱 내 하드코딩된 URL 등이 여전히 살아 있다면 문제는 더 커집니다. 사용자는 해당 주소를 신뢰한 채 접속할 수 있고, 내부 시스템과 연관된 경로라면 혼선을 만들 수 있습니다. 이런 이유로 DNS설정 정리는 “현재 접속 여부”보다 “과거에 어디에 쓰였는지”까지 함께 보는 것이 좋습니다.

3) 자동화된 탐색의 대상이 되기 쉬움

이런 취약한 서브도메인은 사람이 하나하나 찾기보다 자동화된 도구로 빠르게 탐색되는 경우가 많습니다. 즉, 한 번 놓치면 오래 잠복하는 문제가 아니라 비교적 빨리 발견되고 악용될 수 있습니다. 그래서 정기적으로 CNAME보안과 관련 항목을 살피는 습관이 중요합니다.

5. 점검할 때 흔히 놓치는 항목

1) 사용하지 않는 서브도메인의 잔존

서비스를 여러 번 실험하다 보면 테스트용 서브도메인이 많이 생깁니다. 문제는 실험이 끝난 뒤에도 DNS설정이 남아 있는 경우입니다. 이런 주소는 눈에 잘 띄지 않아서 서브도메인탈취의 사각지대가 되기 쉽습니다.

2) 외부 서비스 해지 후 확인 누락

호스팅, 랜딩 페이지, 분석 도구, 파일 서비스 등 외부 플랫폼과 연결해 둔 뒤 계정만 정리하는 경우가 있습니다. 하지만 연결 해제 없이 서비스만 삭제하면 CNAME이 빈 채로 남을 수 있습니다. subdomain takeover 점검에서는 외부 서비스 해지 이력까지 같이 살펴보는 것이 중요합니다.

3) 운영자 변경으로 인한 책임 공백

조직 내 담당자가 바뀌면 DNS설정과 도메인 관리 기록이 분리되는 일이 있습니다. 누가 어떤 서브도메인을 어떤 목적에 썼는지 모호해지면, 오래된 레코드가 그대로 유지될 가능성이 커집니다. 이런 상황에서는 정기 점검 목록을 만들어 두는 편이 도움이 됩니다.

6. 기본 점검 도구가 도움이 되는 상황

1) 복잡한 설정 전, 빠르게 현황을 보고 싶을 때

모든 보안 문제를 대규모 보안 솔루션으로 관리하기는 부담이 큰 경우가 있습니다. 이럴 때는 URL을 입력하면 기본적인 보안 상태를 빠르게 살펴볼 수 있는 도구가 유용할 수 있습니다. 예를 들어 HTTPS, 보안 헤더, CORS, 쿠키, API 접근, 노출 가능성 같은 항목을 함께 확인하면 서브도메인탈취와 관련된 위험 신호를 더 빨리 찾는 데 도움이 됩니다.

2) 개발·운영 단계에서 반복 점검이 필요할 때

기본적인 보안은 한 번 점검하고 끝나는 것이 아니라, 배포와 수정이 반복될 때마다 다시 확인하는 편이 좋습니다. 새 기능을 올리거나 외부 서비스를 교체하면 DNS설정과 CNAME보안 상태도 달라질 수 있기 때문입니다. 이런 점에서 간단한 점검 방식은 “큰 보안 감사 전의 예비 점검”처럼 활용할 수 있습니다.

3) 사고가 아닌 예방 차원에서 확인하고 싶을 때

실제 문제가 터진 뒤 확인하는 것보다, 배포 전이나 서비스 정리 시점에 확인하는 것이 훨씬 효율적입니다. 특히 서브도메인탈취는 눈에 잘 보이지 않는 설정 실수에서 생기므로, 예방 목적의 점검이 잘 맞습니다. Vibe Guardian 같은 도구는 이런 기본 확인을 빠르게 진행하는 데 적합한 편입니다.

7. 서브도메인 탈취를 줄이기 위한 정리 습관

1) 서비스 삭제와 DNS 정리를 함께 하기

가장 기본적이지만 중요한 습관은 서비스를 지울 때 관련 DNS 레코드도 같이 정리하는 것입니다. CNAME이 남아 있으면 subdomain takeover 가능성을 완전히 배제할 수 없기 때문입니다. 삭제 절차를 문서화해 두면 담당자가 바뀌어도 누락을 줄일 수 있습니다.

2) 정기 점검 목록 만들기

서브도메인 목록, 연결된 외부 서비스, 인증서 상태, 보안 헤더, 쿠키 범위 같은 항목을 정기적으로 확인하는 것이 좋습니다. 이를 통해 DNS설정의 오래된 흔적을 빠르게 찾을 수 있습니다. 작은 체크리스트만 있어도 서브도메인탈취 위험을 상당 부분 줄일 수 있습니다.

3) 외부 서비스 의존도 기록하기

어떤 서브도메인이 어떤 플랫폼과 연결되어 있는지 기록해 두면, 서비스 종료 시 헷갈릴 일이 줄어듭니다. 특히 CNAME보안은 “연결했다”보다 “언제, 무엇과, 왜 연결했는지”가 중요합니다. 이런 메모가 남아 있으면 나중에 점검할 때 훨씬 수월합니다.

서브도메인 탈취는 대단히 복잡한 공격처럼 보이지만, 실제로는 삭제된 서비스와 남아 있는 CNAME, 정리되지 않은 DNS설정에서 시작되는 경우가 많습니다. 따라서 서브도메인탈취가 걱정된다면 먼저 연결 대상이 유효한지, HTTPS와 인증서 상태가 정상인지, 오래된 서브도메인이 남아 있지 않은지 확인하는 것이 좋습니다. 이런 점검은 서비스가 많거나 외부 도구를 자주 붙이는 환경에서 특히 유용하며, 직접 하나씩 전화해서 확인하는 방식보다 URL 기준으로 빠르게 상태를 살펴보는 편이 훨씬 효율적입니다. 결국 subdomain takeover 예방은 복잡한 고급 설정보다, CNAME보안과 DNS설정을 꾸준히 정리하는 습관에서 시작된다고 볼 수 있습니다.

다른 콘텐츠도 함께 보세요

같은 주제에서 이어서 읽기 좋은 글들을 랜덤으로 추천합니다.

4 ARTICLES

Cloudflare를 쓰면 보안이 자동으로 해결되나요 — 실제 커버 범위

Cloudflare를 쓰면 보안이 어느 정도 자동으로 보완된다고 생각하는 경우가 많습니다. 실제로 CDN과 보안 기능이 함께 제공되다 보니, 기본적인 보호는 쉽게 시작할 수 있습니다. 하지만 Cloudflare보안이 곧 모든 취약점의 해결을 의미하는…

#Cloudflare보안#CDN보안#Cloudflare한계+1

클라우드 API 키가 노출되면 어떤 일이 일어나는가 — 요금 폭탄 발생 원리

클라우드 환경을 사용하다 보면 AWS키유출, 크리덴셜노출, GCP보안 같은 단어를 한 번쯤 검색하게 됩니다. 개발 초기에는 “내 서비스는 아직 작으니 괜찮겠지”라고 생각하기 쉽지만, 실제로는 작은 실수 하나가 큰 비용과 장애로 이어지는 경우가 많습니다…

#AWS키유출#클라우드요금폭탄#크리덴셜노출+1

Mixed Content 경고가 왜 뜨는지, 왜 위험한지

Mixed Content 경고가 무엇인지 먼저 이해하기 1) 브라우저가 안전하지 않다고 알리는 이유 웹사이트 주소가 로 시작하면, 기본적으로 통신이 암호화된 상태라고 볼 수 있습니다. 그런데 페이지 안에 로 불러오는 이미지, 스크립트, 스타일 파일 등…

#MixedContent#HTTPS보안#브라우저경고+1

깃허브에 코드 올릴 때 절대 포함하면 안 되는 것들

깃허브에 코드를 올릴 때 왜 보안 점검이 필요한가 1) 저장소는 생각보다 쉽게 공개됩니다 깃허브는 협업과 배포에 매우 편리하지만, 한 번 올라간 내용은 예상보다 넓게 퍼질 수 있습니다. 특히 팀 프로젝트나 오픈소스처럼 저장소를 외부와 공유하는 경우,…

#깃허브보안#gitignore#시크릿노출+1