와일드카드 DNS의 위험: GitHub Pages 사이트가 탈취된 사례

여행에서 돌아와서 자신의 비즈니스 도메인이 여러 인도네시아 온라인 도박 사이트와 슬롯 머신 사기 사이트를 호스팅하고 있는 것을 발견한다고 상상해 보세요. 바로 이것이 개발자 rmeertens에게 일어난 일이며, 그는 자신의 도메인 immersivepoints.com이 GitHub Pages를 이용하는 제3자에 의해 악용된 것을 발견했습니다.

이 사건은 DNS 설정과 플랫폼 수준 도메인 검증이 교차하는 지점을 보여주는 중요한 사례 연구로, 단순한 편리함—와일드카드 DNS 레코드—가 어떻게 거대한 보안 구멍을 만들 수 있는지를 보여줍니다.

공격 구조

작성자는 3D 및 VR 포인트 클라우드 시각화 도구를 GitHub Pages에 호스팅했습니다. 설정을 쉽게 하기 위해 DNS 레코드를 와일드카드(*.immersivepoints.com)로 지정해 GitHub 서버를 가리키도록 했습니다. 이는 www와 같은 모든 서브도메인이 자동으로 자신의 GitHub Pages 사이트로 해석되도록 하기 위함이었습니다.

하지만 작성자는 GitHub Pages가 사용자 정의 도메인을 처리하는 방식에 근본적인 결함이 있음을 발견했습니다: GitHub은 해당 도메인을 가리키는 서버에 레포지토리 내에 일치하는 CNAME 파일이 존재하기만 하면 어떤 도메인이라도 해결합니다.

와일드카드 DNS 레코드가 있었기 때문에 immersivepoints.com의 어떤 서브도메인에 대한 요청도 GitHub으로 라우팅되었습니다. 공격자는 단순히 개인 GitHub 레포지토리를 만들고 kafka.immersivepoints.com이나 hd.immersivepoints.com과 같은 서브도메인에 대한 CNAME 파일을 추가하기만 하면 되었습니다. GitHub의 로드 밸런서는 요청을 감지하고 이를 공격자의 레포지토리와 매핑해, 작성자의 도메인 아래에서 공격자의 콘텐츠를 제공했습니다.

영향: SEO 중독 및 사기

남용은 Google Search Console 알림을 통해 발견되었습니다. 알림은 여러 서브도메인에 대해 새로운 소유자가 검증되었다고 알려주었습니다. 조사 결과, 이러한 서브도메인들이 검색 결과에 노출되어 때로는 정식 사이트보다 더 높은 순위를 차지하고 있었습니다.

작성자는 다음과 같이 언급했습니다:

I hope nobody fell victim to the undoubtedly shitty slot machine scam sites which were hosted on my domain.

이는 "서브도메인 탈취"의 전형적인 사례로, 공격자가 남은 DNS 레코드나 관대한 설정을 이용해 악성 콘텐츠를 호스팅함으로써 도메인 평판을 손상시키고 사용자를 피싱이나 사기 사이트로 유인할 수 있습니다.

논쟁: 누가 책임이 있나?

이 사건은 Hacker News에서 큰 논의를 일으켰으며, 의견은 사용자 설정 오류와 플랫폼의 방어 부재 사이에서 갈렸습니다.

"사용자 오류" 관점

여러 댓글 작성자는 책임이 전적으로 도메인 소유자에게 있다고 주장했습니다. 와일드카드 레코드를 제3자 플랫폼에 지정하는 것은, 정의상 할당되지 않은 모든 서브도메인에 대한 제어권을 해당 플랫폼에 넘기는 행위이기 때문입니다.

You told your NS to forward any request to GitHub, a platform you don't own. I think this is the expected outcome.

"플랫폼 책임" 관점

다른 사람들은 GitHub이 더 엄격한 검증을 도입해야 한다고 주장했습니다. 이미 다른 GitHub 사용자가 사용 중인 도메인을 사용자가 주장하려 하거나, 도메인이 검증된 소유권 레코드 없이 GitHub IP로 지정된 경우, 플랫폼이 연관을 차단해야 한다는 입장입니다.

한 해결책으로 제안된 것은 도메인 검증을 위한 TXT 레코드의 의무화였습니다. 이는 Google Search Console 및 주요 클라우드 제공업체가 요청자가 실제로 DNS 설정을 제어하고 있음을 확인하기 위해 일반적으로 사용하는 방법입니다.

도메인 탈취 방지 방법

이러한 남용을 피하려면 개발자와 사이트 소유자는 다음 모범 사례를 따라야 합니다:

1. 제3자 호스팅에 와일드카드 DNS 사용 금지

GitHub Pages, Netlify, Vercel 등과 같은 서비스에 도메인을 가리키기 위해 와일드카드(*) 레코드를 절대 사용하지 마세요. 특정 이유가 있고 위험을 충분히 이해하는 경우를 제외하고는, 사용하려는 각 서브도메인(www, blog, app 등)을 명시적으로 정의해야 합니다.

2. 도메인 검증 활용

GitHub은 이제 사용자 정의 도메인 검증 기능을 제공합니다. 이는 DNS TXT 레코드를 통해 도메인 소유권을 증명하도록 하여, 다른 GitHub 사용자가 해당 도메인이나 서브도메인을 주장하는 것을 방지합니다. 이 설정은 개별 레포지토리 설정이 아니라 계정 설정에 위치해 있어 간과하기 쉽습니다.

3. 도메인 모니터링

Google Search Console과 같은 도구를 사용하면 무단 변경이나 새로운 "소유자"가 서브도메인을 주장하는 초기 경고를 받을 수 있습니다. 정기적으로 DNS 레코드와 검색 엔진 색인을 감사하면 탈취가 큰 피해를 주기 전에 식별할 수 있습니다.

마무리 생각

이 사건은 현대 웹 인프라에서 "사용 편의성"과 "기본 보안" 사이의 격차를 강조합니다. 와일드카드 DNS는 편리하지만, GitHub 계정만 있으면 누구나 악용할 수 있는 취약점을 만들게 됩니다. 명시적인 검증을 도입하고 관대한 DNS 레코드를 피함으로써 개발자는 디지털 정체성을 다음 슬롯 머신 사기 파동의 호스트가 되는 위험으로부터 보호할 수 있습니다.