내 도메인이 GitHub Pages에서 악용됐어요: 방치된 CNAME이 부르는 보안 사고

도대체 무슨 일이 벌어진 걸까요

Meertens라는 개발자가 자기 블로그에 올린 사연인데, 읽고 나면 등골이 좀 서늘해져요. 어느 날 보니까 자기 도메인의 서브도메인 하나가 전혀 모르는 사람의 GitHub Pages 사이트로 연결돼서 피싱이나 사기에 가까운 콘텐츠를 띄우고 있었던 거예요. 본인은 아무것도 안 했는데 말이죠. 이게 어떻게 가능한 일일까요?

원인은 "버려진 CNAME 레코드"였어요. CNAME이 뭐냐면, 도메인 설정에서 "이 주소로 들어오면 저쪽 주소로 보내라"라고 알려주는 일종의 우편 전달 지시서예요. 예전에 이분이 myproject.example.com 같은 서브도메인을 만들어서 GitHub Pages에 있는 username.github.io/myproject로 연결해뒀었는데, 시간이 지나 GitHub 저장소는 삭제하고서 도메인 쪽 CNAME 레코드 지우는 걸 깜빡한 거예요. 그러면 어떻게 되냐면, 이 서브도메인은 여전히 "GitHub Pages 어딘가"를 가리키고 있는 상태가 돼요. 빈집인데 우편함에 주소만 살아 있는 셈이죠.

공격자가 이걸 어떻게 이용했을까요

이게 바로 "서브도메인 탈취(subdomain takeover)"라고 부르는 고전적인 공격 패턴이에요. 작동 방식은 무서울 정도로 단순해요. 공격자가 자기 GitHub 계정으로 빈 저장소를 만들고, 그 저장소의 GitHub Pages 설정에서 커스텀 도메인을 피해자의 그 서브도메인으로 지정해버리는 거예요. GitHub은 "아, 이 도메인이 우리한테 CNAME으로 연결돼 있네" 하고 확인한 다음 그냥 연결을 해줘요. 그러면 그 순간부터 피해자의 도메인 이름으로 공격자의 콘텐츠가 서빙되기 시작해요.

문제의 핵심은 GitHub이 도메인 소유권을 제대로 검증하지 않는다는 거예요. CNAME이 자기네를 가리키고만 있으면 "이 사람이 이 도메인의 주인이 맞나?" 같은 확인을 안 해요. 글쓴이는 GitHub에 이 부분을 신고했는데, GitHub 측 답변은 "이건 우리 책임이 아니고 도메인 소유자가 DNS 정리를 잘 해야 하는 문제"라는 식이었다고 해요. 기술적으로 틀린 말은 아니지만, 사용자 입장에서는 좀 답답한 거죠.

왜 위험할까요

탈취된 서브도메인이 위험한 이유는 "신뢰"가 따라오기 때문이에요. login.유명회사.com 같은 주소가 진짜로 그 회사 도메인 아래에 있으면, 사람들도 브라우저도 그걸 의심하지 않아요. 공격자는 거기에 가짜 로그인 페이지를 띄워서 계정을 훔치거나, SEO를 부풀리거나, 멀웨어를 배포하거나, 코인 사기 페이지를 띄울 수 있어요. 게다가 HTTPS 인증서까지 자동으로 발급되니까 자물쇠 아이콘도 멀쩡하게 떠요. 사용자가 진짜 가짜 사이트를 알아채기가 정말 어려워져요.

다른 서비스에서도 같은 문제가 있어요

GitHub Pages만의 문제가 아니에요. Heroku, AWS S3, Azure, Netlify, Vercel, Shopify, Fastly 등 "커스텀 도메인을 연결할 수 있는 호스팅 서비스" 거의 전부가 비슷한 위험을 안고 있어요. 그래서 보안 업계에서는 can-i-take-over-xyz라는 깃허브 저장소까지 만들어서 어떤 서비스가 어떤 조건에서 탈취 가능한지 정리해두고 있어요. 헌트리 그룹이 가진 자산을 점검할 때도 이 목록이 자주 쓰여요.

한국 개발자라면 뭘 해야 할까요

실무적으로 당장 할 수 있는 일이 몇 가지 있어요. 첫째, 회사나 개인 도메인의 DNS 레코드를 한 번 쭉 훑어보세요. 지금 안 쓰는 서브도메인인데 CNAME이 외부 서비스를 가리키고 있다면 위험 신호예요. 둘째, "서비스를 내릴 때 DNS도 같이 내린다"를 운영 체크리스트에 넣으세요. 보통 저장소나 인스턴스를 지우는 건 기억하는데 DNS 정리는 잊기 쉬워요.

셋째, 좀 더 적극적으로는 subjack, subzy, nuclei 같은 오픈소스 도구로 자기 도메인의 서브도메인 탈취 가능성을 정기적으로 스캔하는 걸 추천해요. CI 파이프라인에 넣어서 주기적으로 돌리면 더 좋고요. 큰 회사라면 "DNS 변경 시 승인 워크플로우"를 두는 것도 방법이에요. 넷째, 도메인 소유권 증명이 필요한 서비스(Cloudflare Pages 등 일부)를 선호하는 것도 좋아요.

마무리

한 줄로 정리하면, "안 쓰는 DNS 레코드는 그냥 쓰레기가 아니라 시한폭탄이다"예요. 깔끔한 정리가 곧 보안이에요.

여러분 회사의 DNS 레코드, 마지막으로 점검한 게 언제인가요? 혹시 "이거 누가 만든 거지?" 싶은 서브도메인이 있다면 이번 주에 한 번 정리해보면 어떨까요?