Аналіз інциденту eMudhra CA: Ключові висновки та вплив

Резюме

Індійський сертифікаційний центр eMudhra випадково випустив вісім проміжних сертифікатів, пов’язаних з небезпечними приватними ключами. Цей компроміс може дозволити атакуючим створювати дійсні сертифікати TLS та підпису коду для довільних імен хостів в Інтернеті. Проблема становить значний ризик для клієнтів підключених до мережі, особливо вбудованих систем і пристроїв, які не отримали актуальні оновлення безпеки.

Дослідження

Дослідження визначило, що інцидент виник з небезпечних приватних ключів, пов’язаних з проміжними сертифікатами eMudhra. Аналіз зосереджений на виявленні цих сертифікатів у мережевому трафіку за допомогою Zeek шляхом порівняння їх гешей Subject Public Key Info (SPKI). Цей підхід є більш надійним, ніж порівняння відбитків сертифікатів, оскільки він також враховує перехресно підписані сертифікати та потенційну зміну підпису.

Пом’якшення

Основні постачальники браузерів та операційних систем додали уражені сертифікати до механізмів недовіри, таких як CRLSet у Chrome та OneCRL у Mozilla. Користувачі повинні переконатися, що їхні пристрої повністю оновлені, щоб отримати ці зміни недовіри. Для мережевого моніторингу розгорніть пакет Zeek emudhra-weak-keys дозволяє виявити уражені сертифікати під час рукостискань TLS.

Відповідь

Коли Compromised_Intermediate_Cert помітки з’являються в журналах Zeek, команди безпеки повинні розслідувати як кінцевий хост, так і підключеного клієнта. А Compromised_Intermediate_Cert_Established сигнал попереджає, що клієнт успішно прийняв потенційно шахрайський сертифікат. Організації повинні також перевірити статус патчів вбудованих, застарілих та потенційно застарілих пристроїв у своєму середовищі.

Виконання симуляції

• Опис атаки та команди: Супротивник отримав сертифікат від компрометованого проміжного CA eMudhra. Щоб обійти стандартні засоби безпеки, вони налаштували шкідливого слухача, який представляє цей сертифікат під час рукостискання TLS. Мета – встановити канал C2, який здається використовуючим дійсний, хоча й компрометований, ланцюг довіри. Ми будемо симулювати це, використовуючи openssl щоб розмістити локальний веб-сервер, використовуючи сертифікат, що імітує метадані/відбиток компрометованого сертифіката eMudhra, змушуючи сенсор Zeek викликати “notice” на основі його логіки ідентифікації.

• Сценарій регресійного тесту:

  # 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"