요약
이무드라 중간 인증기관 8곳의 개인 키를 누구나 공개 인증서에서 알아낼 수 있었습니다.
데니스 잭슨이 정리한 사고 안내 페이지가 2026년 10월 20일 공개됐습니다. 웨인이라는 제보자가 각 키로 시험 메시지에 서명한 증거를 10월 17일 브라우저·운영체제 업체의 루트 인증서 관리팀에 보냈습니다.
왜 중요한가
- 이 키가 하나라도 있으면 어떤 웹사이트나 서비스로도 위장할 수 있습니다.
- 인증서가 만들어진 2025년 4월부터 이런 상태였지만, 실제로 악용됐는지는 아직 모릅니다.
- 인증서 투명성(CT, 발급된 인증서를 공개 로그에 남기는 제도)을 확인하지 않는 브라우저 밖 프로그램은 피해를 가려내기 어렵습니다.
핵심 내용
- 이무드라가 키를 잘못 생성해서 공개된 인증서만으로 개인 키를 복구할 수 있었습니다.
- 영향받은 중간 인증기관(루트 아래에서 실제 인증서를 발급하는 기관)은 모질라·마이크로소프트·애플·구글이 신뢰하는 루트에 연결돼 있습니다.
- Firefox와 Chrome은 10월 17일, 애플은 19일, 마이크로소프트는 20일부터 해당 인증서를 차단했습니다.
- CT 로그에 이 인증기관이 발급한 인증서가 없어서 CT를 강제하는 브라우저는 공격받지 않았을 것으로 봤습니다.
- 인증서 폐기 정보를 쓰지 않는 프로그램은 업데이트가 필요하며, 페이지에 Ubuntu·Debian·Go·Node.js 등의 패치 버전이 정리돼 있습니다.
HN 반응
- 일부 이용자는 8개 개인 키가 모두 1바이트짜리 숫자였다며, 키 생성 스크립트 결함으로 만든 약한 키를 실수로 썼다는 이무드라의 해명을 옮겼습니다.
- CT 로그가 비어 있으니 악용 여부를 확인할 수 있다는 주장과, pip처럼 CT를 확인하지 않는 프로그램을 노린 공격은 드러나지 않는다는 반론이 맞섰습니다.
아직 이 얘기가 충분히 나오지 않은 것 같아서 씁니다.
"침해된" CA 8개의 개인 키가 전부 1바이트짜리입니다: https://mastodon.catgirl.cloud/@49016/117474217042191790
그중 하나는 말 그대로 "4"예요.
'침해'라는 말에 따옴표를 붙인 건, 민망하고 욕이 나와서 따옴표 없이는 못 쓰겠기 때문입니다.
[참고: https://news.ycombinator.com/item?id=50169109 ]
장담하는데 이건 오류 코드예요. 뭔가로 키를 생성하려다 오류가 났고, 오류 코드 4가 그대로 키로 들어간 거죠. 암호는 멍청하고 사람은 사람이라서 아무도 키 값을 안 들여다본 거고요.
수정: 보고된 개인 스칼라 값은 인증서 8개에 걸쳐 4, 56, 66, 115, 155, 156, 230, 237이래요. 내기에서 이기기는 글렀네요 :'D
꼭 로또 번호 같네요. 지하 세계 누군가는 이걸로 한몫 챙겼을 겁니다.
0~255 사이의 난수입니다.
그뿐만이 아니라, 키가 HSM 안에 있었다고 하니 들여다볼 수도 없었을 가능성이 높습니다.
'emudhra에 대한 질문'에 답하던 사람이, 이 키들은 미국과 EU 데이터 센터로 내보낼 목적이었다고도 말했습니다. 그게 내용 확인을 막았을지는 모르겠습니다(어떤 식으로든 암호화되어 있기를 바라지만, 왜 목적지 HSM이 직접 CSR을 생성하게 하지 않았을까요?).
수정: 아래에 이 단락이 길게 인용되어 있네요. 그 댓글들을 아직 못 봤습니다. 뭐, 어쩔 수 없죠.
출처: https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c11
내용:
저희가 예비 평가를 진행했고, 해당 날짜에 이 ECC 발급 CA들을 만드는 데 쓰인 KGC 스크립트에 결함이 있었던 것으로 보입니다. 이 ECC 키들에 대해 KGC 검토, 코드 평가, 지금까지의 HSM 키 확인 결과는 다음과 같습니다. a) 원래의 ECC 키 한 쌍은 예정대로 HSM 내부에서 생성되었습니다. b) 이번 건은 키를 내보낼 용도였기 때문에, 래핑/언래핑을 시험하려고 평소의 KGC에서 벗어나는 변경이 승인되어 도입되었습니다. c) 코드 결함으로 인해 두 번째 키 쌍이 HSM 내부에서 생성되었고, 이 키는 더 약했습니다. d) 키 레이블이 비슷해서, 이 두 번째의 약한 키 쌍이 실수로 CSR 생성에 쓰였고 저희 루트가 서명했습니다. e) 이 약한 키의 CSR은 교차 서명을 위해 Sectigo에도 전달되었습니다(Sectigo에 보낸 파일은 저희가 확인했습니다).
RSA 발급 CA는 저희 평가상 다른 경로를 거쳤으므로 영향을 받지 않았습니다. 추가로 말씀드리면, 이 발급 CA들은 일부 고객의 데이터 주권 문제를 해결하려고 미국과 유럽 데이터 센터로 내보낼 목적으로 만든 것이며, 하나를 제외하면 실제 운영 환경에는 투입된 적이 없습니다.
래핑/언래핑이란 HSM이 개인 키를 생성한 다음, 다른 HSM들만 아는 키로 암호화하는 것입니다. 그러면 다른 HSM들이 가져오기 때 복호화하고요. 그래도 개인 키는 HSM 밖에서 들여다볼 수 없어야 정상입니다.
그 사람들은 키가 몇 바이트인 줄 알았을지 궁금하네요. 한 바이트씩 읽어 가면서 '이 HSM 최고네, 우리 키를 전부 넣을 수 있겠어!' 이랬을 거 아니에요 xD
그리고 맥락 알려 줘서 고마워요. 이제 어떻게 된 일인지 진짜 궁금해지네요 ㅋㅋ
정말 터지는 키 생성 의식이었네요.
공정한 주사위 굴림으로 선택됨.
이거 진짜예요? 너무 어이없는 얘기라서, 이 CA가 얼마나 오래 시스템에 깔려 있었는지, 그동안 누가 먼저 발견해서 악용하지는 않았는지(국가 차원의 공격자든 아니든) 궁금해지네요. 적어도 안드로이드 6을 쓰는 제 오래된 폰에는 EMudhra 인증서가 없습니다.
국가 차원의 공격자가 알아채고 조용히 악용했을 가능성이 거의 확실합니다.
웹 PKI는 인증서 투명성(CT)을 쓰니까, 이게 악용됐는지 아닌지는 곧 확실히 알게 될 겁니다.
(어쨌든 CT 덕분에 '조용히' 악용하는 건 불가능합니다.)
침해된 중간 CA에서 나온 인증서는, 브라우저 쪽에서 조치하기 전까지 CT에 하나도 기록되지 않았습니다.
다행이네요. CT 로그에 없는 인증서는 무효이거나 신뢰할 수 없는 것으로 취급되니까요.
CT는 브라우저에는 훌륭합니다. 하지만 브라우저 밖에서 가져오는 것들에는 대체로 의미가 없습니다.
그래서 저는 순전히 사고 대응과 포렌식 맥락에서 말하는 겁니다.
CT로 악용 여부를 "확실히" 증명할 수 있다고 하셨는데, 그건 틀렸습니다.
CT 기록이 없다는 건 (아마도) 브라우저가 중간자 공격을 당하지 않았다는 것만 증명합니다.
그래도 인증서가 발급됐는지는 알 수 있잖아요. 우리가 확인하고 싶은 게 바로 그거고요.
어떻게 알아요? CA가 침해됐다면 공격자가 왜 가짜 인증서를 CT에 올리겠어요?
사실상 주요 브라우저 말고는 아무도 CT 로그를 검증하지 않으니까, 올리지 않아도 많은 사람을 공격할 수 있습니다.
나쁜 놈들은 CT 로그도 뒤져서 아직 설정이 안 된 새 워드프레스 인스턴스를 찾아내고, 몇 분 안에 친절하게 대신 설정해 주기도 하죠.
알 수 없습니다.
CA가 CT 로그에 게시하는 겁니다. 공격자가 개인 키를 가지고 있으면, CA나 CT 로그를 거치지 않고 인증서에 서명하는 걸 막을 방법이 없어요.
막을 방법은 없지만, 주요 브라우저와 아마 다른 프로그램들도 그런 인증서는 신뢰하지 않습니다. https://en.wikipedia.org/wiki/Certificate_Transparency#Mandatory_certificate_transparency
아니요, 알 수 없습니다.
무슨 말씀인지 모르겠네요. 브라우저든 아니든 eMudhra가 발급하는 모든 인증서는 SCT를 생성해야 합니다.
공격자가 eMudhra의 개인 키로 발급한 인증서가 최신 브라우저에서 검증되게 하려면 CT 로그에 올라가야 합니다.
하지만 'pip'이 파이썬 휠을 설치할 때 쓰는 연결만 중간자 공격하려는 거라면, 거기서는 CT 기록을 아예 확인하지 않습니다.
그럼 모든 소프트웨어를 업그레이드해서 CT 기록을 쓰게 해야 하는 건가요?
맞습니다만, CT를 안 하는 클라이언트는 SCT 약속이 빠져 있어도 신경 쓰지 않을 겁니다. [수정: 원래 "SCT 약속을 깬다"고 썼는데, 그건 말이 안 되는 표현이네요.] 그건 나중에 그 인증서를 다른 곳에서 보게 돼야 알아챌 수 있는 일이고요…
전부 가정에 가깝고 가능성도 낮지만, 그런 식으로 downloads.openwrt.org¹ 같은 곳을 공격해 볼 수는 있습니다. 특히 opkg의 TLS 클라이언트를 일반 브라우저와 구별할 수 있다면요.
(¹ 다행히 OpenWRT를 비롯한 대부분의 패키지 저장소는 패키지 무결성과 신뢰성을 HTTPS에 의존하지 않습니다. 그리고 OpenWRT는 "특이한" TLS 클라이언트 스택을 쓴다면 가장 취약할 겁니다.)
이 댓글 위에 이 사용자 이름이 있어서 놀랐습니다.
아니요, 인증서는 SCT가 없거나 잘못된/쓰레기 SCT를 달고도 발급될 수 있고, SCT를 확인하지 않는 클라이언트에서는 문제없이 작동합니다. 브라우저 이외의 상호작용은 대부분 그렇습니다.
좀 더 풀어서 말하면, 브라우저가 아닌 환경에서만 이뤄지는 공격이 어느 정도 표적을 정해서 하는 것이라면 십중팔구 발각되지 않습니다. 공격자가 맞서야 하는 건, 일부러 시간을 들여 검증하는 편집증 있는 사용자를 우연히 만날 확률뿐이니까요.