Análise do Incidente da eMudhra CA: Principais Descobertas e Impacto

Resumo

A Autoridade Certificadora Indiana eMudhra emitiu inadvertidamente oito certificados intermediários vinculados a chaves privadas inseguras. Este comprometimento pode permitir que atacantes gerem certificados TLS e de assinatura de código válidos para nomes de host arbitrários na internet. O problema apresenta um risco significativo para clientes conectados à rede, especialmente sistemas e dispositivos embarcados que não receberam atualizações de segurança recentes.

Investigação

A investigação determinou que o incidente se originou de chaves privadas inseguras associadas a certificados intermediários da eMudhra. A análise foca em identificar esses certificados no tráfego de rede com o Zeek, comparando os hashes das Informações da Chave Pública do Sujeito (SPKI). Esta abordagem é mais confiável do que a correspondência de impressões digitais de certificados, pois também considera certificados cruzados e possíveis maleabilidades de assinatura.

Mitigação

Principais fornecedores de navegadores e sistemas operacionais adicionaram os certificados afetados a mecanismos de desconfiança, como o CRLSet do Chrome e o OneCRL da Mozilla. Os usuários devem garantir que seus dispositivos estejam totalmente atualizados para receber essas alterações de desconfiança. Para monitoramento de rede, implantar o pacote Zeek emudhra-weak-keys permite a detecção de certificados afetados durante handshakes TLS.

Resposta

Quando Certificado_Intermediário_Comprometido notificações aparecem nos logs do Zeek, as equipes de segurança devem investigar tanto o host de destino quanto o cliente que está se conectando. Um Alerta_Estabelecido_Certificado_Intermediário_Comprometido indica que o cliente aceitou com sucesso um certificado potencialmente fraudulento. As organizações também devem verificar o status dos patches de dispositivos embarcados, legados e outros possivelmente desatualizados em seus ambientes.

Execução de Simulação

• Narrativa do Ataque e Comandos: O adversário obteve um certificado da CA intermediária eMudhra comprometida. Para contornar os controles de segurança padrão, eles configuram um ouvinte malicioso que apresenta este certificado durante o handshake TLS. O objetivo é estabelecer um canal C2 que parece usar uma cadeia de confiança válida, embora comprometida. Simularemos isso usando openssl para hospedar um servidor web local usando um certificado que imita o metadata/impressão digital do certificado eMudhra comprometido, forçando o sensor Zeek a gerar uma “notificação” com base em sua lógica de identificação.

• Script de Teste de Regressão:

  # 1. Gerar um certificado falso que imita a assinatura comprometida da eMudhra
  # Em um cenário real, o invasor usa o certificado comprometido real.
  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. Iniciar um servidor web local usando este certificado
  # Usamos um processo em segundo plano para hospedar o servidor
  openssl s_server -accept 4443 -cert cert.pem -key key.pem -quiet &
  SERVER_PID=$!
  
  # 3. Aguardar inicialização do servidor
  sleep 2
  
  # 4. Acionar o handshake TLS (Isto gera o tráfego Zeek)
  # Nota: Em um laboratório real, o sensor Zeek deve ser configurado com o
  # script/plugin específico que identifica este cert como 'Certificado_Intermediário_Comprometido'
  curl -k https://localhost:4443
  
  # 5. Limpeza (Retratada na seção de limpeza)
  kill $SERVER_PID

• Comandos de Limpeza:

  # Remover os arquivos de certificado falso gerado e parar o servidor
  rm -f key.pem cert.pem
  # Se o processo do servidor ainda estiver em execução:
  pkill -f "openssl s_server"