Lobsters

About the compromised eMudhra intermediate CAs

침해된 eMudhra 중간 인증기관에 관하여

eMudhra가 운영하는 TLS 중간 인증기관 6곳의 개인 키가 유출돼 공격자가 임의의 웹사이트에 유효해 보이는 인증서를 발급할 수 있게 됐습니다. Apple은 기기에서 해당 인증서를 차단하고 있지만, 일부 macOS 명령줄 도구는 별도 인증서 묶음을 참조하므로 관리자에게 임시 조치 방법을 안내합니다.

에디터 노트

문제의 범위는 브라우저와 명령줄 도구가 서로 다른 신뢰 저장소를 참조한다는 점입니다. Apple 프레임워크를 쓰는 앱은 자동 차단되지만 /etc/ssl/cert.pem을 검사하는 일부 도구는 향후 macOS 업데이트 전까지 차단을 놓칠 수 있다고 Apple이 설명합니다. 루트 CA 제거는 해당 파일을 쓰는 모든 도구에 영향을 주며, 정상 인증서까지 검증하지 못할 수 있다는 제약도 명시했습니다. 댓글은 Apple이 왜 CA 묶음을 바로 갱신하지 않았는지 질문하며 OS 업데이트나 Rapid Security Response로 배포할 수 있지 않았느냐고 추측합니다. 이는 댓글 작성자의 해석이며 Apple의 설명에는 배포 지연 이유가 없습니다. 수동 명령은 임시 우회책으로 제시됐고, 정식 수정은 향후 업데이트에 달려 있습니다.

AI 요약

Apple은 eMudhra가 운영하는 중간 인증기관(CA) 8곳의 개인 키가 침해됐다고 밝혔습니다. 이 가운데 코드 서명 인증서를 발급하는 2곳은 Apple 프레임워크에서 신뢰하지 않으며, 나머지 6곳은 TLS 인증서를 발급합니다. 공격자는 유출된 키로 어떤 웹사이트에 대해서든 유효해 보이는 인증서를 만들 수 있었습니다. eMudhra와 Sectigo는 영향을 받은 인증서를 폐기했습니다.

영향을 받은 인증서와 Apple의 차단

6개 TLS 중간 CA마다 인증서가 두 종류씩 있어 총 12개 인증서가 대상입니다. 하나는 emSign Root TLS CA - G3를 거쳐 emSign ECC Root CA - G3에 연결되고, 다른 하나는 Sectigo가 교차 서명해 AAA Certificate Services에 연결됩니다. Apple은 2026년 10월 19일부터 이 12개 인증서를 차단하기 시작했고, 10월 23일에는 emSign ECC Root CA - G3도 차단하기 시작했습니다. 추가 차단 변경도 기기에 자동으로 전달되므로 일반 사용자는 별도 소프트웨어 업데이트를 설치하지 않아도 Safari, Mail과 Apple 네트워킹·보안 프레임워크를 쓰는 앱에서 차단이 적용됩니다.

명령줄 도구의 차이

macOS나 Xcode Command Line Tools에 포함된 curl, git, python3, ruby, perl, openssl 가운데 일부는 Apple의 프레임워크 대신 /etc/ssl/cert.pem을 확인합니다. 이 파일에 연결되는 루트 CA 인증서를 신뢰하는 도구는 Apple의 차단 상태나 인증서 폐기 여부를 확인하지 않을 수 있습니다. Apple은 향후 소프트웨어 업데이트로 이 파일을 갱신할 예정입니다. 자체 루트 인증서 목록을 쓰는 앱이나 도구도 Apple의 차단과 /etc/ssl/cert.pem을 이용하지 않을 수 있어 해당 개발자에게 문의해야 합니다.

업데이트 전 수동 조치

업데이트를 기다리지 않으려는 관리자는 /etc/ssl/cert.pem에서 차단 대상 인증서가 연결되는 루트 인증서를 제거할 수 있습니다. 먼저 기존 파일을 /etc/ssl/cert.pem.orig로 백업합니다. 백업 파일이 이미 있으면 명령은 이를 덮어쓰지 않습니다. 이어 awk로 emSign ECC Root CA - G3 항목을 제외한 임시 파일을 만들고, 비어 있지 않은지 확인한 뒤 권한과 소유자를 root와 wheel로 설정해 원본을 교체합니다.

이 조치만으로는 Sectigo가 교차 서명한 6개 인증서가 AAA Certificate Services를 통해 검증될 수 있습니다. 이를 막으려면 선택적으로 AAA Certificate Services도 같은 방식으로 제거해야 합니다. 두 루트 CA를 제거하면 영향을 받지 않은 중간 CA를 거쳐 이 루트에 연결되는 일부 웹사이트 인증서도 해당 파일만 참조하는 도구에서 검증하지 못할 수 있습니다. openssl과 grep 명령으로 두 루트 인증서가 파일에 남아 있는지 확인할 수 있습니다. 결과에 오류가 나타나면 백업에서 복원해야 합니다.

이 변경은 /etc/ssl/cert.pem을 쓰는 모든 도구에 적용됩니다. macOS 업데이트가 이 파일을 Apple 버전으로 교체할 수 있으므로, Apple의 변경을 포함한 업데이트를 설치하기 전까지는 업데이트 후 파일을 다시 확인하고 필요한 경우 제거 작업을 반복해야 합니다. 관리자는 관리자 계정으로 명령을 실행하거나 기기 관리 도구로 배포할 수 있습니다.

Lobsters 반응

  • @yossarian — 이 상황은 전체적으로 이해하기 어렵습니다. Apple은 Security.framework를 통해 침해된 중간 인증서와 이를 발급한 루트 CA의 신뢰를 성공적으로 폐기했지만, 비그래픽 사용자 영역에서 널리 쓰는 CA 묶음에서는 같은 조치를 하지 못했습니다. 대신 대부분의 사용자는 이 지원 페이지를 알게 되더라도 셸 명령으로 직접 수정해야 합니다.
    • @craigstuntz — 더 이해하기 어려운 점은 Homebrew curl은 SecTrust를 통해 검증하지만 Apple이 배포하는 curl은 그렇지 않다는 점입니다.
    • @yossarian — 저는 Homebrew 유지관리자입니다. Homebrew curl은 기본적으로 자체 CA 묶음을 쓰는 것으로 압니다. SecTrust API를 이용할 수도 있지만 macOS에서 더 이상 권장되지 않고 TLS 1.3을 지원하지 않아 기본 설정은 아닙니다. 기본 제공 curl도 같은 방식일 수 있으므로, 결국 Apple이 자체 CA 묶음을 업데이트하지 않았다는 문제입니다.
    • @mxey — 제 추측으로는 CA 묶음을 바꾸려면 OS 업데이트를 내야 하는 것 같습니다.
    • @yossarian — 저도 그렇게 생각했지만 macOS에는 몇 년 전부터 Rapid Security Response 기능이 있습니다. 원칙적으로는 재부팅이 필요하지 않을 수도 있는 RSR로 배포할 수 있습니다.
    • @msangi — 그럴 가능성이 큽니다. OS 업데이트를 배포할 수 있었을 텐데 그렇게 하지 않은 점이 이상합니다.

원문: Apple Support / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗