eMudhra CA 사고 분석: 주요 발견 및 영향

요약

인도 인증 기관 eMudhra는 보안되지 않은 개인 키와 연결된 8개의 중간 인증서를 실수로 발급했습니다. 이 취약성으로 인해 공격자가 인터넷상의 임의 호스트 이름에 대해 유효한 TLS 및 코드 서명 인증서를 생성할 수 있습니다. 이 문제는 주로 최신 보안 업데이트를 수신하지 않은 임베디드 시스템 및 장치와 같은 네트워크 연결된 클라이언트에게 심각한 위험을 나타냅니다.

조사

조사 결과, 이 사건은 eMudhra 중간 인증서와 관련된 보안되지 않은 개인 키에서 비롯되었음을 확인했습니다. 분석은 Zeek를 사용하여 이러한 인증서의 주제 공개 키 정보(SPKI) 해시를 일치시켜 네트워크 트래픽에서 식별하는데 중점을 둡니다. 이 접근 방식은 교차 서명 인증서 및 잠재적인 서명 변조 가능성을 고려하기 때문에 인증서 핑거프린트 일치보다 더 신뢰할 수 있습니다.

완화 조치

주요 브라우저 및 운영 체제 공급업체는 영향을 받은 인증서를 Chrome의 CRLSet 및 Mozilla의 OneCRL과 같은 불신 메커니즘에 추가했습니다. 사용자는 이러한 불신 변경 사항을 수신하기 위해 장치가 최신 상태인지 확인해야 합니다. 네트워크 모니터링을 위해서는 Zeek 패키지를 배포하십시오. emudhra-weak-keys TLS 핸드셰이크 중에 영향을 받은 인증서를 감지할 수 있습니다.

대응

Zeek 로그에 Compromised_Intermediate_Cert 알림이 나타나면, 보안 팀은 수신 호스트와 연결 클라이언트를 조사해야 합니다. Compromised_Intermediate_Cert_Established 경고는 클라이언트가 잠재적으로 사기성 인증서를 성공적으로 수용했음을 나타냅니다. 조직은 또한 임베디드, 레거시 및 기타 잠재적으로 오래된 장치의 패치 상태를 환경 전반에 걸쳐 검증해야 합니다.

시뮬레이션 실행

• 공격 서사 및 명령: 적은 eMudhra 중간 CA에서 인증서를 취득했습니다. 표준 보안 통제를 우회하기 위해, 그들은 TLS 핸드셰이크 동안 이 인증서를 제시하는 악성 리스너를 설정합니다. 목표는 유효하지만 침해된 신뢰 체인을 사용하는 것처럼 보이는 C2 채널을 설정하는 것입니다. 우리는 다음을 사용하여 이를 시뮬레이트할 것입니다. openssl 를 사용하여 침해된 eMudhra 인증서의 메타데이터/핑거프린트를 모방하는 인증서를 사용하여 로컬 웹 서버를 호스팅하고, Zeek 센서에 이를 ‘알림’으로 트리거하도록 강제합니다.

• 회귀 테스트 스크립트:

  # 1. 침해된 eMudhra 서명을 모방하는 모의 인증서를 생성합니다 
  # 실제 시나리오에서는 공격자가 실제 침해 인증서를 사용합니다.
  openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes -subj "/C=IN/ST=State/L=City/O=eMudhra/CN=Compromised_Test_CA"
  
  # 2. 이 인증서를 사용하여 로컬 웹 서버를 시작합니다
  # 백그라운드 프로세스를 사용하여 서버를 호스팅합니다
  openssl s_server -accept 4443 -cert cert.pem -key key.pem -quiet &
  SERVER_PID=$!
  
  # 3. 서버 초기화 대기
  sleep 2
  
  # 4. TLS 핸드셰이크를 트리거합니다 (이는 Zeek 트래픽을 생성합니다)
  # 참고: 실제 실험실에서는 Zeek 센서가 이 인증서를 'Compromised_Intermediate_Cert'로 식별하는 
  # 특정 스크립트/플러그인과 함께 구성되어야 합니다
  curl -k https://localhost:4443
  
  # 5. 정리 (정리 섹션에서 처리)
  kill $SERVER_PID

• 정리 명령:

  # 생성된 모의 인증서 파일을 제거하고 서버를 중지
  rm -f key.pem cert.pem
  # 서버 프로세스가 여전히 실행 중인 경우:
  pkill -f "openssl s_server"