요약
해커들이 국가 최상위 도메인 3곳을 장악해 구글 등 대형 서비스의 위조 TLS 인증서를 발급받았습니다.
구글이 화요일 공개한 사건을 아스테크니카의 댄 구딘 기자가 전했습니다. 공격자는 가나(.gh), 시에라리온(.sl), 아메리칸사모아(.as)의 국가 코드 최상위 도메인(ccTLD)을 뚫고 일부 도메인의 DNS 기록을 바꿨습니다.
왜 중요한가
- 인증 기관(CA)이 규정을 모두 지켰는데도 DNS만 장악하면 정상 절차로 인증서를 받을 수 있다는 점이 드러났습니다.
- Chrome의 차단은 다른 브라우저 이용자를 지키지 못하고 누락이 있을 수 있어, 도메인 소유자가 직접 대비해야 합니다.
핵심 내용
- 공격자는 세 ccTLD에서 특정 도메인의 DNS 기록과 네임서버 위임을 바꿔 자동 도메인 검증을 통과했습니다.
- 구글 도메인 여러 개와 세계적 브랜드 여러 곳의 인증서가 발급됐지만, 구체적 이름은 공개되지 않았습니다.
- 구글은 Chrome을 업데이트해 확인된 위조 인증서를 막고, 발급 기관과 함께 자사 도메인 인증서를 폐기했습니다.
- 구글은 도메인 소유자에게 인증서 투명성(CT, 발급 인증서를 공개 기록하는 로그)을 감시하라고 권했습니다.
- CAA 기록(인증서 발급을 허용할 기관을 적는 DNS 기록)도 엄격하게 두라고 했습니다.
HN 반응
- 일부 이용자는 인증 기관이 뚫린 것이 아니며, DNS를 장악하면 CAA 기록도 지울 수 있어 약한 고리라고 짚었습니다.
- 공개 키 고정(HPKP)이면 막았을 것이라는 의견에는, 고정은 위험해서 폐기됐고 CT 덕에 금세 드러났다는 반론이 맞섰습니다.
이건 HPKP(https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning)였다면 막을 수 있었을 것 같고, CAA 레코드(https://letsencrypt.org/docs/caa/)로는 막을 수 없었을 것 같습니다. 그런데 HPKP는 이제 폐기됐죠.
그 사이트에 이전에 방문한 적이 있는 경우에만 통하는 방법인데, 위험도 말도 안 되게 큽니다. 지켜 내는 사이트보다 망가뜨리는 사이트가 훨씬 많을 겁니다.
발급 사실은 CT 덕분에 거의 즉시 탐지됐습니다. 인증서 수명이 짧아지는 쪽으로 가고 있으니 피해 규모도 계속 줄어들고 있고요.
그래도 DNS의 CAA 레코드는 약한 고리입니다.
"인증서 수명이 짧아지는 쪽으로 가고 있으니 피해 규모도 계속 줄어들고 있다"
고객이 30억 명인 회사라면 인증서 수명을 아무리 줄여도 노출을 실질적으로 줄이는 방법은 없습니다. 5분만 있어도 상당한 피해를 줄 만큼의 트래픽을 가로챌 수 있고, 하루면 사용자 상당수가 영향을 받고, 닷새면 거의 100%입니다.
이 공격 표면을 아예 없애 버리면 CDN에 맡기는 것 자체를 못 하게 되는 것 아닌가요? 제가 잘못 생각하는 건가요?
구글에 접속하는 것 자체가 어차피 이미 해로워요.
+1
그렇다면 저나 여러분, 일반 대중이 입을 위험은 낮다는 뜻이기도 합니다.
다만 이런 점도 있습니다. 이번 일은 가치가 큰 단일 표적(많아야 그 시간 안에 칠 수 있는 소수의 표적)을 노린 조율된 표적 공격이 지나간 뒤의 모습일 가능성이 높다는 겁니다. 공격자는 자신들에게 총알이 한 발뿐인 총이 있다는 걸 알고 있었고, 우리는 지금 그 총성만 들은 셈입니다.
Certificate Transparency 로그는 9월 말 것인데 공개 보도는 10월 6일입니다. 그 사이 시간대가 실제로 얼마나 넓었는지 좁았는지 궁금하네요.
추신: 저보다 호기심이 많은 분이라면 CRLSet이 언제 공개됐는지 보면 답을 찾으실 수 있을 겁니다. https://github.com/agl/crlset-tools
CAA 레코드(ACME 계정 바인딩 포함)라면 이걸 막을 수 있습니다.
HPKP는 실서비스에 적용하기에 너무 위험해서 폐기된 겁니다.
DNS 항목에서 CAA 레코드를 그냥 지워 버리면 못 막죠.
"그냥" 지울 수는 없습니다. 긴 캐시 기간이 CAA를 고정해 주니까요. 물론 그러면 결국 똑같아지고 문제도 똑같이 생깁니다.
제가 보고 싶은 건 같은 세션에서 TLS 인증서와 호스트 키를 여러 개 쓸 수 있는 기능입니다. 그러면 교차 서명이 권위를 보증하는 가운데 모든 키를 대역 내(in-band)에서 교체하고 단계적으로 바꿀 수 있습니다.
서명자가 (이를테면) 30일보다 빠르게 바뀌는 것이 조금이라도 보이면, 브라우저나 클라이언트 스택이 "google.com이 지금 공격받고 있을 수 있으니 기존 인증서에 적힌 이 번호로 전화하세요, 암구호는 banana-alpha-lima-lima-sigma" 같은 경고를 띄워야 합니다. 키를 서로 공개할 필요 없이 교차 서명만 하면 되고, 이전에 본 것을 잊지만 않으면 됩니다.
그러면 브라우저는 서명자가 바뀐 인증서를 무조건 신뢰하지 않는다는 정책을 쓸 수 있습니다(단계적 교체가 가능하니까요). 프라이버시가 새는 공용 오라클(DNS, 인증서 투명성 등)을 더 조회할 필요도 없고요.
webauthn을 TLS 클라이언트 인증서에 다시 연결하는 것도 보고 싶습니다. 패스키 대신 1997년으로 돌아가 있었다면 그것도 이 일을 막았을 겁니다.
이건 서명자의 키가 침해될 수 없다고 가정하는 데다, 웹 PKI 커뮤니티가 의존 대상들에서 없애려고 아주 열심히 밀어붙여 온 키 고정의 문제를 다시 끌어들입니다. 현실적인 해법은 아니라고 봅니다.
키를 실제로 잃어버렸다면 같은 서명자를 쓸 가능성이 매우 높다고 봐요. 그래서 어설픈 시스템 관리자가 호스트 고정을 말아먹는 식으로 이것까지 말아먹을 것 같지는 않아요.
서명자의 키를 잃어버렸는데 어떻게 같은 서명자를 쓰나요?
아니면 서명자의 키가 침해됐다면, 경보가 울리지 않게 하면서 침해되지 않은 서명자로 어떻게 갈아탑니까?
문제는 위임된 CA와 거의 똑같습니다. CA 키가 침해되면 모든 인증서를 재발급해야 하죠. 클라이언트가 CA 키를 고정해 두면 신뢰 사슬은 영구히 끊어집니다.
Letsencrypt가 갑자기 제 요청에 새로 서명할 능력을 잃는다는 가정 말씀이신가요?
그러면 저한테 그걸 알아채고 새 서명자를 고를 시간이 30일쯤 있습니다.
다시 분명히 하자면, 이 경우는 Letsencrypt 자신의 서명 키가 침해되고 게다가 그들이 그 키에 접근하지 못하게 되는 상황입니다. 두 가지 실패가 동시에 일어날 가능성은 극히 낮아 보이지만, 그래도 저는 새 서명자를 찾을 시간이 30일 있습니다.
아닙니다! Letsencrypt가 서명 권한을 제3자에게 재허가하더라도 그 인증서는 별개로 취급될 테니 바꿔치기가 탐지될 겁니다!
그래서 TLS를 확장해 키 쌍과 인증서를 여러 개 써서 세션 키를 상호 인증할 수 있게 하는 게 중요한 겁니다. 그러면 이전에 고정된 키 아무거나로 고정 값을 갱신할 수 있습니다. 아무 이유 없이 이걸 원한다고 한 게 아닙니다!
지금 google.as의 CAA 레코드는 24시간짜리인데, 이전에도 있었다고 봐야겠죠.
그렇다면 이 중 하나입니다.
Letsencrypt가 CAA 레코드를 무시했다(가능성 낮음)
DNS 하이재커들이 공격 12시간 이상 전에 CAA 레코드를 지웠는데 구글이 눈치채지 못했다(설마 그랬을까 싶지만요)
Letsencrypt의 리졸버가 그 레코드를 요청받은 적이 없어서 캐시된 CAA 레코드가 조회되지 않았고, 그래서 몇 분 전에 CAA 레코드를 지워 둔 것이 통했다.
설마 이게 이레네 이모한테 보여 줄 만한 메시지라고 진지하게 생각하세요?
좋은 지적이네요.
문제는 다른 기기들처럼 대역 외(out-of-band)로 업데이트할 수단이 없다는 겁니다.
모바일 앱의 CA 인증서에 문제가 생기면 기기의 앱 스토어로 대역 외 업데이트를 내보낼 수 있습니다.
그런데 브라우저로 접속하는 웹사이트의 CA 인증서에 문제가 생기면 그걸 갱신할 수단은... 브라우저입니다. 애초에 신뢰하고 싶지 않았던 TLS 연결을 쓰지 않고는 새 인증서를 받을 수 없습니다.
정리하면 이런 흐름으로 보입니다.
최상위 국가 코드 도메인의 DNS 항목이 해킹당했다
CAA 항목이 삭제됐다(구글이 갖고 있었다고 가정합니다. 지금은 CAA 0 issue "pki.goog"가 있으니까요)
그 상태에서 주요 CA(letsencrypt 등)에 인증서 발급을 요청할 때 도메인 검증에 이용했다. 예를 들어 DNS 검증용으로 새 CNAME 레코드를 만드는 식이다
특히 google.as를 보면 2026-09-27에 Let's Encrypt가 인증서를 발급한 기록이 있습니다.
https://ctlogs.dev/search?q=google.as
구글은 보통 "Google Trust Services"로 인증서를 발급받습니다. 모든 브라우저가 신뢰하는 자체 CA일 텐데, 발급을 구글로 제한하는 유일한 방법이 CAA 레코드입니다.
DNS를 장악하면 인증서 발급도 장악하는 겁니다. 인증서를 요청하는 실제 당사자를 확인할 업무 관계가 없는 CA가 여럿 있으니 익명으로도 가능합니다. (CA가 검증을 요구한다 해도 그 CA를 쓰는 사람의 탈취한 자격 증명을 엮으면 되니 큰 장애물은 아닙니다.)
제가 보기에는(기사는 이걸 diginoir 사건과 뒤섞어서 그렇게 읽히게 만들었지만) 이번 일은 인증 기관(CA)이 침해된 사건이 아닙니다.
영향을 받은 국가 코드 최상위 도메인은 다음과 같습니다.
AS: 아메리칸사모아
GH: 그린란드
SL: 시에라리온
.gh는 그린란드가 아니라 가나입니다.
앗, 이런 :)
제가 잘못 봤네요.
바로잡아 주셔서 고맙습니다.
.GL이 그린란드입니다.
https://en.wikipedia.org/wiki/.gl
AI 방어 봇은 다 어디 간 거죠?
도메인 인증서 발급은 컴퓨터에만 맡겨 두기엔 점점 너무 중요해지는 것 같아요. 대체할 방법이 없다는 게 아쉽네요.
"웹 PKI"는 DNS, 구체적으로는 "도메인 이름"에 의존합니다.
구글 블로그의 "Chrome's Response to Recent ccTLD Registry Hijacks"에는 이렇게 나와 있습니다.
"이번 사건은 구글 시스템이 침해된 것이 아니라, 공격자들이 제3자가 운영하는 ccTLD를 장악해 .gh, .sl, .as로 끝나는 모든 도메인을 위험에 빠뜨린 것입니다. 이 하이재킹 동안 공격자들은 권한 있는 DNS 레코드를 수정해, 여러 구글 도메인과 다른 조직 소유 도메인에 대한 승인되지 않은 HTTPS 인증서를 발급받았습니다."
그러니까 최상위 도메인 레지스트리 전체가 침해됐다는 얘기입니다. 흥미로운 시대네요. 이것에 대한 1차 자료는 정말 없는 겁니까?
최근 올라온 다른 글 중에 구글 블로그 링크 https://blog.google/security/chromes-response-to-recent-cctld-registry-hijacks/ 를 건 글도 있습니다.
https://news.ycombinator.com/item?id=49988253
https://news.ycombinator.com/item?id=49981886
새로울 게 전혀 없는 일입니다. 사실 구글이 몇 년 전에 자사 웹사이트를 ccTLD로 서비스하는 걸 그만둔 이유가 바로 이거였죠.
https://google.co.ck 에 술 한 잔 따라 줍시다. (그래도 아직 리디렉션은 되네요.)