보안
국가 코드 레지스트리 세 곳이 장악당하고 유효한 Google 인증서가 발급됐다. 체인에서 고장 난 곳은 없었다
공격자들은 .gh, .sl, .as를 운영하는 외부 사업자를 침해해 권한 DNS 레코드를 바꾸고, 그 통제력으로 Google과 YouTube 도메인용 공개 신뢰 HTTPS 인증서를 발급받았다. Google은 자사 시스템도, 인증서를 발급한 인증기관도 잘못한 것이 없다고 말한다. 문제는 바로 그 점이다.
MAI
Google의 Chrome Secure Web and Networking 팀은 10월 6일, 공격자들이 국가 코드 최상위 도메인 세 곳 — .gh(가나), .sl(시에라리온), .as(미국령 사모아) — 을 각각 운영하는 외부 사업자를 침해해 장악했다고 공개했다. 해당 존의 권한 DNS 레코드를 손에 넣은 공격자들은 자신이 소유하지 않은 도메인에 대해 공개적으로 신뢰되는 유효한 HTTPS 인증서를 발급받았고, 그중 여러 개가 Google의 도메인이었다.
눈에 띄는 대목은 인증서가 잘못 발급됐다는 사실 자체가 아니다. 지금까지 드러난 증거로 보면 체인의 어느 부분도 고장 나지 않았다는 점이다.
이번 사건에 Google 시스템의 침해는 포함되지 않았다. [...] 공격의 성격상, 해당 인증서를 발급한 인증기관(CA)이 부적절하게 행동했다고 볼 이유는 없다.
Google의 시스템은 건드려지지 않았다. 인증기관은 요구되는 검증을 수행했고, 그 검증은 통과됐다. 공격자는 그 검증이 조회하는 자리를 차지했을 뿐이다.
무엇이 발급됐나
Google은 인증서를 한 건도 특정하지 않았다. The Hacker News는 10월 7일 Certificate Transparency 로그를 조사해, 9월 하순 6일 동안 발급된 최소 12건을 찾아냈다. 대상은 7개 도메인이었다.
| ccTLD | 인증서 수 | 발급일 |
|---|---|---|
| .gh(가나) | 2 | 9월 22일 |
| .sl(시에라리온) | 6 | 9월 25일 |
| .as(미국령 사모아) | 4 | 9월 27일 |
11건은 Let's Encrypt가, 1건은 ZeroSSL이 발급했다. .gh의 두 건과 ZeroSSL 발급 건은 9월 26일에, 남은 아홉 건은 10월 1일에 폐기(revoke)됐다. 포함된 이름에는 google.com.gh, google.sl, google.as와 YouTube 관련 도메인이 있다. 검색한 이름이 한정적이었던 만큼 실제 총수는 더 많을 가능성이 크다. Let's Encrypt는 자체 커뮤니티 포럼에서 발급 사실을 확인했고, 스태프 엔지니어 Matthew McPherrin은 이렇게 썼다.
그렇습니다, Google과 YouTube용 인증서가 발급됐고, 이미 폐기됐습니다.
도메인 검증은 DNS에 던지는 질문, 그 이상이 아니다
공개 웹의 거의 모든 인증서는 단 하나를 묻는 도메인 제어 검증을 거쳐 발급된다. 신청자가 해당 이름을 통제하고 있음을 — 보통 CA가 지정한 값을 DNS에 공개하는 방식으로 — 보여줄 수 있는지다. 이 검증은 의도적으로 값싸고 완전히 자동화돼 있다. HTTPS가 10년 만에 소수 트래픽에서 거의 전체로 확산된 이유이며, 설계 결함이 아니다.
다만 그 구조는 이름에 대한 권한이 DNS에 대한 권한이 있는 곳에 정확히 놓인다는 뜻이기도 하다. 개별 도메인이 아니라 레지스트리를 침해하면, 검증의 관점에서는 그 아래 모든 것의 소유자가 된다. 국가 단위 네임스페이스 전체가 한꺼번에, 소유자가 수년간 로그인하지 않은 방어용 등록까지 포함해서다. 영향 범위가 Google을 한참 넘어서는 이유가 여기 있다. Google은 CT 데이터를 검토한 결과 "널리 알려진 글로벌 브랜드와 폭넓게 쓰이는 온라인 서비스"를 포함한 다른 피해 조직들을 확인하고 그들의 인증서도 Chrome에서 차단했다고 밝혔다.
Chrome이 한 일, 그리고 스스로 인정한 한계
Chrome은 승인되지 않은 인증서를 긴급 차단 목록인 CRLSets에 올렸고, Chrome 이외의 클라이언트도 보호받도록 발급 CA들과 폐기 작업을 진행했으며, 추가 발급 여부를 확인하기 위해 CT 로그를 훑었다. Google은 Chrome 사용자가 따로 할 일은 없다고 분명히 말한다.
두 가지 빈틈에 대해서도 그만큼 분명하다. "우리 분석이 영향을 받은 모든 도메인을 찾아냈다고 보장할 수 없다"는 점, 그리고 CRLSets가 지키는 것은 Chrome뿐이라는 점이다.
브라우저 측의 개입을 사용자 보호 수단으로 의존해서는 안 된다
도메인 소유자가 실제로 할 수 있는 일
Google의 권고는 주차된 이름과 지역별 이름까지 포함한 전체 포트폴리오에 대한 CT 모니터링, 그리고 특정 ACME 계정과 검증 방식에 묶인 제한적 CAA 레코드 공개다. 둘 다 할 가치가 있다. 둘 다 예방은 아니다. Google 스스로 공격자가 DNS를 쥐고 있는 동안에는 CAA가 발급을 막을 수 없다고 인정한다. 그 가치는 사후에 나타난다. 정당한 통제가 회복된 뒤 캐시된 검증의 재사용을 거부할 수 있다는 점이다.
여기서 불편한 결론이 나온다. 레지스트리 수준의 장악이 진행되는 동안 도메인 소유자에게는 어떤 예방 수단도 없다. 막을 수 있는 유일한 주체는 레지스트리 운영자이며, 피해를 본 브랜드 대부분은 그 사업자의 보안 수준을 평가해본 적도, 영향을 줄 방법도 없다. 그래서 Google이 가리키는 구조적 처방 — Chrome Root Program을 통한 인증서 유효기간 단축과 캐시된 도메인 검증 재사용 축소 — 은 장악 자체에 대한 해법이 아니다. DNS가 되돌아온 뒤에도 그 장악이 얼마나 오래 수익을 내는지, 그 기간에 대한 해법이다.
아직 모르는 것들
누가 했는지, 세 사업자가 어떻게 침해됐는지, 레지스트리들이 지금은 안전한지. 세 곳 모두 입장을 내지 않았다. 어떤 인증서가 실제로 트래픽 가로채기에 쓰였다는 증거도 공개되지 않았다. 다만 대부분 Google 주요 서비스로 리다이렉트되는 이름들이라면, 악용이 관측되지 않았다는 사실의 의미는 다른 경우보다 작다. Google은 가능한 범위에서 다른 피해 조직들에 연락했다고 했지만 이름은 하나도 밝히지 않았다.
실무적 교훈은 좁지만 행동할 만하다. .gh, .sl, .as 아래에 이름을 보유하고 있다면 — 방어용으로 등록해두고 잊은 것까지 포함해 — 자신의 CT 로그에서 9월 하순 기록을 읽어보라.
Sources: Chrome's Response to Recent ccTLD Registry Hijacks — Google Security Blog · Attackers Hijack .gh, .sl, and .as Registries to Obtain Certificates for Google Domains — The Hacker News · Attackers hijacked top-level domains, minted fake security certs for Google and other orgs — The Register · Hackers hijack Google domains after breaching ccTLD registries — BleepingComputer · Hackers hijack three country-code domain registries — Help Net Security · Chrome's Response to Recent ccTLD Registry Hijacks — Let's Encrypt Community