GitHub Pages로 호스팅하던 커스텀 도메인이 어떻게 공격자에게 점유됐는지, 그리고 verified domains 설정으로 어떻게 복구했는지에 대한 사례와 교훈.
2025년 10월 13일 16:22(UTC+2)에 제 웹사이트 중 하나인 dev.chris-besch.com을 열어봤는데, 해킹되어 있는 것을 발견했습니다(아래 스크린샷 참조).
무슨 일이 있었는지, 그리고 어떻게 해결했는지 설명해보겠습니다. 우선 저는 해당 웹사이트를 호스팅하는 데 GitHub Pages를 사용하고 있습니다. GitHub Pages를 쓰면 웹사이트를 어떤 도메인에서 호스팅할지 지정할 수 있습니다.
이게 어떻게 가능한 걸까요? 어쨌든 GitHub이 제 도메인을 통제하는 게 아니라, 도메인을 통제하는 건 저뿐입니다. GitHub은 dev.chris-besch.com을(를) 자신들이 통제하는 christopher-besch.github.io로 포워딩해 달라고 요구합니다. 저는 원하는 도메인 등록기관(레지스트라)을 통해 DNS 레코드로 이를 설정합니다. 이 과정을 우회할 방법은 없고, 저는 그동안 이를 크게 의식하지 않았습니다. 그러다 “누군가가 제 도메인에 대한 통제권을 가진 것처럼 보이는” 그날이 오기 전까지는요.
며칠 전 실수로 GitHub Pages가 참조하는 git 브랜치를 삭제해버렸습니다. 저는 얼마 지나지 않아 브랜치를 다시 만들었지만, 제가 모르는 사이에 그 사건으로 인해 GitHub Pages 배포가 영구적으로 비활성화되었습니다. 그 결과 제 도메인은 GitHub의 인프라로 계속 포워딩되고 있었지만, 더 이상 어떤 GitHub Pages 사이트에서도 그 도메인을 사용하지 않는 상태가 되었습니다. 누군가가 이를 알아차리고 제 도메인을 자신의 악성 웹사이트에 선택한 것입니다.
다행히 저는 그 악성 웹사이트를 비교적 빨리 발견했습니다. 게다가 해당 도메인은 원래 디버깅 용도로만 쓰고 있었기도 합니다. 그럼에도 이는, GitHub 인프라를 가리키고 있지만 어떤 GitHub Pages 사이트에서도 사용되지 않는 도메인을 찾기 위해 사람들이 지속적으로 스캔하고 있다는 뜻입니다. 무섭죠.
또 다른 무서운 점은 공격자가 제 도메인에 대해 유효한 SSL 인증서를 발급받았다는 것입니다. 공격자는 GitHub의 Let’s Encrypt 인증서 도메인 검증을 이용했습니다. 일단 제 도메인을 통제할 수 있게 되면 그런 인증서는 쉽게 발급받을 수 있습니다. 조직 검증(OV)이나 확장 검증(EV) 같은 방식은 여기서는 불가능했을 겁니다. 그런 종류의 검증은 웹사이트가 해당 위치에 존재할 “권리”가 있음을 증명해 주는데, 이번 상황이 그 필요성을 보여줍니다. 하지만 브라우저의 UI에서는 검증 타입을 실질적으로 크게 구분해주지 않기도 합니다.
저는 일반적인 GitHub 도메인으로 포워딩한 게 아니라, christopher-besch.github.io로 포워딩하고 있었습니다. 그래서 GitHub은 제 DNS 레코드를 확인하고, 저(christopher-besch)가 제 도메인에서 다른 사람이 GitHub Pages를 호스팅하길 원하지 않는다는 점을 알아챌 수도 있었을 겁니다. 저는 GitHub이 그렇게 해줄 거라고 기대했고, 또 그렇게 해줄 것이라고 신뢰했습니다.
하지만 GitHub은 그렇게 하지 않습니다. 대신, 그 도메인이 제 것임을 이해하려면 특정 TXT DNS 레코드가 필요합니다. GitHub은 이 기능을 "verified domains"라고 부릅니다. 저는 이를 활성화했고, 도메인을 되찾았습니다.
이번 일은 제게 교훈이었습니다. 제 도메인을 다른 사람의 인프라로 가리키는 순간, 저는 그 “다른 사람”을 신뢰하게 됩니다. 그리고 이번 상황에서 GitHub은 그 신뢰를 저버렸습니다.
여러분도 직접 통제하지 않는 인프라로 포워딩하는 순간 그들을 신뢰하는 것입니다. 모든 DNS 포워딩, 모든 웹 링크, 외부 IP 주소는 외부 인프라에 대한 신뢰의 표현입니다. 그 점을 인지하고 있어야 합니다.
