크레이지J의 탐구생활

점프 타이밍을 맞춰 선인장과 새를 피해 최대한 멀리 달리세요! 속도가 점점 빨라지고, 점수가 오르면 날아다니는 새도 등장합니다. 최고 기록은 브라우저에 저장됩니다.

조작: 화면 터치/마우스 클릭, 키보드 스페이스 / ↑ / W (길게 누르면 높이, 짧게 누르면 낮게 점프)

물고기를 좌우로 움직여 위에서 떨어지는 장애물을 피하세요!

조작: 마우스/터치 좌우이동, 키보드 ← →

2026년 10월 20일, 인도의 인증기관(CA) eMudhra(emSign)의 8개 중간 CA 인증서 개인키가 치명적으로 약한 엔트로피로 생성되어 누구나 수학적으로 개인키를 추출할 수 있는 상태임이 공개되었다. Oracle은 10월 21일 긴급 보안 경고 CVE-2026-91403을 발표했으며, CVSS 3.1 기준 9.1점(Critical)의 심각도를 부여했다.

이 취약점은 Java의 JSSE(Java Secure Socket Extension) 컴포넌트에 영향을 미치며, 침해된 CA 인증서가 JVM의 신뢰 저장소(cacerts)에 포함되어 있어, 패치 없이는 위조된 TLS 인증서를 신뢰하게 된다.

1. 취약점 개요

영향 받는 버전

2. 사건 배경 - eMudhra CA 개인키 침해

2025년 4월 eMudhra의 키 생성 세레모니에서 극도로 낮은 엔트로피로 개인키가 생성되었다. 이로 인해 공개 인증서에서 수 밀리초 만에 개인키를 수학적으로 역산할 수 있게 되었으며, 총 8개 중간 CA의 16개 인증서(직접 발급 8개 + Sectigo AAA 크로스사인 8개)가 영향을 받았다.

침해된 개인키를 보유한 공격자는:

• 임의 도메인에 대한 유효한 TLS 인증서를 위조 가능
• MitM(중간자) 공격으로 HTTPS 통신을 가로채거나 위변조 가능
• 위조된 코드서명 인증서로 악성코드에 정상 서명 가능

3. Java가 특히 취약한 이유

Chrome, Firefox 등 주요 브라우저는 이미 10월 17~20일 사이에 긴급 차단 목록(CRLSets, CRLite, OneCRL)을 배포하여 보호된다. 그러나 Java JVM은 다음 이유로 여전히 취약하다:

즉, JVM에서 HttpClient, HttpsURLConnection, Spring WebClient, OkHttp 등으로 HTTPS 요청 시 기본 신뢰 저장소를 사용하면, 위조된 인증서를 그대로 신뢰하게 된다.

4. 외부 HTTPS 통신이 없는 환경의 안전성 분석

이 취약점의 핵심은 TLS 인증서 검증에 있다. 따라서 다음 조건을 모두 충족하는 환경이라면 직접적인 위험은 낮다:

결론: Java 8 취약 버전을 사용하더라도, 외부로 나가는 HTTPS 통신이 없고 외부 TLS 인증서를 검증하지 않는 환경이라면 이 취약점에 의한 직접적인 위험은 없다. 다만, 향후 기능 추가나 라이브러리 업데이트로 외부 통신이 발생할 수 있으므로 패치 적용을 권장한다.

⚠ 주의사항: 외부 HTTPS 호출이 없다고 단정하기 전에, 로깅 라이브러리(Log4j 등), 모니터링 에이전트, 라이선스 검증, NTP 클라이언트 등 애플리케이션이 간접적으로 HTTPS를 사용하는 경우가 없는지 반드시 확인해야 한다.

5. 진단 방법

5.1 Java 버전 확인

java -version

# 취약 여부 확인
# 8u511 이하, 11.0.33 이하, 17.0.21 이하, 21.0.13 이하 → 취약

5.2 침해 CA 인증서 존재 확인

# JDK 8
keytool -list -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit -v | grep -i "emSign"

# JDK 11+
keytool -list -cacerts -storepass changeit -v | grep -i "emSign"

# Comodo AAA (크로스사인 루트)도 확인
keytool -list -cacerts -storepass changeit -v | grep -i "AAA Certificate"

5.3 OpenJDK 공식 검증 프로그램 실행

# OpenJDK에서 제공하는 CheckCerts.java 다운로드 및 실행
# JDK 11+ 필요
curl -O https://cr.openjdk.org/~mr/CheckCerts.java
javac CheckCerts.java
java CheckCerts

결과에 "BAD ROOT"이 포함되면 패치가 필요하다.

5.4 외부 HTTPS 통신 여부 확인

# Java 프로세스의 외부 HTTPS(443) 연결 확인 (Linux)
# 실행 중인 Java 프로세스 PID 확인
pgrep -a java

# 해당 PID의 네트워크 연결 확인
ss -tnp | grep <PID> | grep ":443"

# 또는 netstat 사용
netstat -tnp | grep <PID> | grep ":443"

6. 대응방안

6.1 JDK 패치 적용 (최우선)

Oracle 또는 OpenJDK 벤더에서 배포한 패치 버전으로 업데이트한다. JDK-8395690 수정이 포함된 릴리스를 확인한다.

6.2 즉시 패치 불가 시 - blocked.certs 파일 업데이트

JVM의 blocked.certs 파일에 침해된 48개 SHA-256 해시를 추가하여 해당 인증서를 차단한다. cacerts에서 루트를 삭제하는 것보다 이 방법이 정확하다.

# JDK 11+
BLOCKED="$JAVA_HOME/lib/security/blocked.certs"

# JDK 8
BLOCKED="$JAVA_HOME/jre/lib/security/blocked.certs"

# 백업
cp "$BLOCKED" "$BLOCKED.bak"

# 48개 해시 추가 (침해된 16개 중간CA × 인코딩 변형)
cat << 'EOF' >> "$BLOCKED"

# eMudhra compromised intermediate CAs (2026-10-20 / CVE-2026-91403)
42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493
45A883F349AEDFD5F3A649B5498FFB121712BA8B448F3F2A91DBC5A766FCDDBE
0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19
62B7F9868263F72F6911FC78CEAF72C1979158B7368BF648683BB2AA39B02E72
98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B
5F1DED4DD590AF74631290CF073B122A2AAC6A1FA479778A0BD43579BD832699
CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F
7485B51C0ED192878FA1D2F948FB529AE1842CC5086C4B67F7BE5B2039DE9489
E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838
579480AEA166290BD3C643589E795FC0D0E54E86505D180F1DFF99EFD3199512
432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3
FD9D5C2DBBD4995AB69B8D50C439D9527B00529199C2FD01B2174EB58F07021F
9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4
A496E23AC0CAB8155FC9B117B97EAE368EFCBB9041AEC8804D5A308D2D01C2D8
4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1
84112972B8E59D14560AE7E7119654474AAD119990CF3722BFC1E3B91615E1FD
EOF

# JVM 재시작 필요

6.3 cacerts에서 루트 인증서 삭제 (대안)

blocked.certs 방식을 적용할 수 없는 환경에서의 대안이다. 단, emSign 루트만 삭제하면 Sectigo AAA 크로스사인 체인은 여전히 취약하므로 주의.

# JDK 8
keytool -delete -keystore $JAVA_HOME/jre/lib/security/cacerts -alias "emsignrootcag1 [jdk]" -storepass changeit
keytool -delete -keystore $JAVA_HOME/jre/lib/security/cacerts -alias "emsignrootcag2 [jdk]" -storepass changeit
keytool -delete -keystore $JAVA_HOME/jre/lib/security/cacerts -alias "emsigneccrootcag3 [jdk]" -storepass changeit
keytool -delete -keystore $JAVA_HOME/jre/lib/security/cacerts -alias "comodoaaaca [jdk]" -storepass changeit

# JDK 11+
keytool -delete -cacerts -alias "emsigneccrootcag3 [jdk]"
keytool -delete -cacerts -alias "comodoaaaca [jdk]"

# 주의: comodoaaaca 삭제 시 정상적인 Sectigo/Comodo 인증서도 신뢰 불가

6.4 임시 완화 - OCSP/CRL 검증 활성화

# Java 실행 시 JVM 옵션 추가
java -Dcom.sun.net.ssl.checkRevocation=true \
     -Dcom.sun.security.enableCRLDP=true \
     -jar your-application.jar

※ OCSP/CRL 서버 접근이 가능해야 하며, 성능 저하가 발생할 수 있다.

7. 주의사항 - cacerts에서 emSign만 삭제하면 불충분

일부 보안 권고에서 emSign 루트 인증서만 삭제하라고 안내하지만, 이는 불완전한 조치이다.

8. 타임라인

9. 참고자료

• Oracle Security Alert - CVE-2026-91403
• OpenJDK eMudhra 대응 가이드
• eMudhra CA 침해 공개 사이트
• Guillaume Laforge - JVM 취약점 상세 분석 및 blocked.certs 패치 방법
• Red Hat - RHSB-2026-012
• Ubuntu - eMudhra CA compromise fixes