Reddit

Hackers obtain counterfeit TLS certificates for Google and other large services | Compromise of 3 domain registries allows hackers to walk off with unauthorized certs.

해커들이 Google 등 대형 서비스의 위조 TLS 인증서를 발급받았습니다

공격자들이 .gh, .sl, .as 국가 코드 최상위 도메인(ccTLD)을 장악하고 권한 DNS 레코드를 바꿔 Google과 여러 서비스의 위조 TLS 인증서를 발급받았습니다. Google은 확인된 인증서를 Chrome에서 차단하고 폐기했으며, 도메인 운영자에게 Certificate Transparency 로그 감시와 CAA 레코드 설정을 권고했습니다.

AI 요약

공격자들이 .gh(가나), .sl(시에라리온), .as(아메리칸사모아) 국가 코드 최상위 도메인(ccTLD)을 공격한 뒤, 해당 영역에 속한 일부 도메인의 권한 DNS 레코드를 바꿨습니다. 이 DNS 통제권으로 자동화된 도메인 소유권 확인 절차를 통과해 Google 도메인 여러 개와 다른 대형 서비스의 인증서를 무단 발급받았습니다. Google은 확인된 인증서를 Chrome에서 차단하고 발급 인증기관(CA)과 협력해 Google 도메인의 인증서를 폐기했다고 밝혔습니다.

인증서 발급 과정의 취약 지점

TLS 인증서는 웹사이트나 메일 서버의 도메인 이름과 공개 키를 전자 서명으로 연결하는 X.509 자격 증명입니다. 브라우저는 인증서와 키를 확인해 접속 대상이 진짜 사이트인지 판단합니다. 공격자가 도메인에 유효한 인증서를 얻으면 해당 인프라를 암호학적으로 사칭할 수 있습니다.

이번 사례에서 공격자는 도메인 소유권 확인에 쓰이는 권한 DNS 레코드를 조작했습니다. 기사에 따르면 Google은 영향을 받은 자사 도메인과 다른 조직의 이름을 공개하지 않았습니다. Chrome 사용자는 별도로 조치하지 않아도 보호된다고 안내했지만, Google은 도메인 운영자가 브라우저의 대응에만 의존하지 말라고 당부했습니다. 예상치 못한 인증서가 발급되지 않았는지 Certificate Transparency 로그를 확인하고, 허용할 CA를 제한하는 CAA DNS 레코드를 설정하라고 권고했습니다. 다만 DNS 자체가 공격자에게 넘어간 상황에서는 CAA 레코드도 바꿀 수 있다는 점이 토론에서 지적됐습니다.

Reddit 반응

  • @u/Chopper3 — 정말, 정말 심각합니다.
    • @u/SirkutBored — 콘텐츠를 둘러싼 신뢰도 이미 문제가 되고 있습니다. 접속한 사이트가 실제 사이트인지에 대한 신뢰까지 무너지면 금융 사이트나 거래를 해커가 직접 통제하는 상황을 떠올려야 합니다.
    • @u/ledow — 네, 하지만 매우 간단히 해결할 수 있고 관련 CA에도 제재가 따릅니다. 과거에도 잘못된 인증서를 발급한 CA가 브라우저에서 퇴출됐습니다. 인증서를 폐기하고 일상으로 돌아가면 됩니다. Google 같은 곳은 HSTS, 인증서 고정, 공개 인증서 발급 목록 감시를 해야 하므로 애초에 이런 일이 가능해서는 안 됩니다.
    • @u/dack42 — 기사를 읽어보세요. 여기서는 CA가 잘못한 게 아닙니다. 공격자가 세 ccTLD의 DNS를 장악했고, 그 통제권을 이용해 DNS 검증 방식의 인증서를 발급받았습니다. 평소에는 CAA 레코드로 이용하는 CA만 허용하는 게 좋습니다. 하지만 DNS를 장악한 공격자는 CAA 레코드도 바꿀 수 있으니 이 경우에는 효과가 없습니다. HSTS는 TLS 사용을 강제할 뿐이라 이번 공격을 막지 못합니다. 인증서 고정은 막을 수 있지만 적용이 늘 실용적인 것은 아니며 널리 쓰이지도 않습니다.
    • @u/Ok-Eggplant-7569 — DNSSEC가 이 공격을 막았을까요? 공격자가 장악한 영역은 DNSSEC 서명이 되어 있었나요? DNSSEC 설정 오류 때문에 .de 도메인이 몇 시간 동안 해석되지 않았던 일이 반년쯤 전에 있었던 것으로 기억합니다.
    • @u/dack42 — 그럴 수도 있습니다. 기사에는 DNS 침해가 어떤 방식으로 일어났는지 자세한 설명이 없습니다.
  • @u/SimpleFile — 공격자들이 .gh, .sl, .as ccTLD를 공격한 다음 해당 영역 일부 도메인의 권한 DNS 레코드를 바꿨다고 합니다. 이 TLD를 사용하지 않았다면 데이터가 침해될 위험은 없는 건가요?
    • @u/theatreddit — 그럴 겁니다.
    • @u/laplongejr — 사용하는 모든 웹사이트가 불러오는 제3자 리소스도 확인하시나요? 광고 제공업체가 이런 도메인을 쓰고 있다면, 침해된 도메인을 통해 웹페이지에서 스크립트를 실행할 수 있습니다.
  • @u/Justin_Passing_7465 — Root CA를 특정 TLD에만 신뢰하도록 제한하는 기능을 추가해야 합니다. 예를 들어 국방부 Root CA는 .mil 도메인만, 국가별 등록기관의 Root CA는 자국 도메인만 인증하도록 하면 이런 공격의 피해 범위를 줄일 수 있습니다.
    • @u/laplongejr — .home.arpa에만 적용되는 자체 서명 Root CA를 쓰고 싶습니다. 그러면 그 허점을 이용해 은행이나 Amazon을 사칭할 수 없다는 확신이 생깁니다.
    • @u/z3roTO60 — Step CA를 확인해 보세요. 집에서 내부 SSL 용도로 사용하고 있습니다.
  • @u/CurrencyCapital8053 — 다들 당황하기 전에, 기사에는 Google이 확인한 무단 인증서를 차단하도록 Chrome 업데이트를 이미 배포했다고 나옵니다. CRL(Certificate Revocation List)을 적극적으로 갱신하거나 정적 핀을 미리 설정한 최신 브라우저를 쓴다면 적어도 이번 인증서로 인한 피해는 대부분 막을 수 있습니다.
    • @u/PeechCore — 그래도 큰 문제입니다. 허용 목록 방식으로 바꿔야 합니다. 이 분야의 보안을 진지하게 다루는 곳은 이미 그렇게 합니다. CRL만으로는 부족합니다.
  • @u/michaelpaoli — Google의 블로그 글이 대체로 더 유익하고 기술적으로도 훨씬 정확합니다. 지난주 .gh(가나), .sl(시에라리온), .as(아메리칸사모아) ccTLD에서 일련의 도메인 하이재킹을 확인했습니다. Google 시스템 침해가 아니라 제3자 ccTLD가 침해됐으며, .gh, .sl, .as로 끝나는 모든 도메인이 위험에 놓였습니다.
  • @u/danekan — 인증서 검증을 무시하는 방식으로 스크립트나 코드를 작성하면 안 된다는 점을 다시 확인해 줍니다.

원문: Ars Technica / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗