Кажется, у разработчиков сегодня проблемы, а у криптографии сегодня выходной.
Исследователь Скотт Хелм обнаружил, что приватные ключи восьми промежуточных удостоверяющих центров eMudhra можно восстановить из публичных сертификатов меньше чем за секунду.
Один из ключей — буквально число 4.
Другие — 56, 115, 156, 230, 155, 66 и 237.
Нет, это не пароль от Wi-Fi. Это приватные ключи удостоверяющего центра, которому доверяли программные продукты и операционные системы.
Как вообще такое возможно?
Ключи использовали эллиптическую криптографию P-384. Нормальный приватный ключ должен быть случайным 384-битным числом. Пространство возможных значений настолько огромное, что перебор считается практически невозможным.
Но здесь вместо случайного числа оказались значения от 4 до 237.
47 байт нулей и один байт данных.
Вместо криптографической защиты — угадайка на 256 вариантов.
Исследователь взял публичные сертификаты, перебрал возможные значения и восстановил все восемь ключей. При этом сами сертификаты внешне выглядели корректно.
Что это означает на практике?
Обладатель такого ключа может выпускать поддельные сертификаты для чужих доменов.
Если атакующий окажется на сетевом маршруте между клиентом и сервером, а клиент продолжит доверять скомпрометированной цепочке, появляется возможность выдать себя за настоящий сайт и перехватить или изменить передаваемые данные.
И это не обязательно браузер.
Серверные API, Python, Go, Node.js, curl, CI/CD-пайплайны, контейнеры и всевозможные фоновые службы — всё это может использовать собственные хранилища сертификатов и по-разному обрабатывать отзыв скомпрометированных удостоверяющих центров.
Хелм продемонстрировал проблему на практике: в его тестовой среде curl принял поддельный сертификат для api.stripe.com и сообщил SSL certificate verify ok.
Это был контролируемый тест, а не доказательство взлома самого Stripe. Но демонстрация показывает, насколько опасным может оказаться устаревшее хранилище доверия.
Браузеры уже начали блокировать скомпрометированные сертификаты. Но на этом история не заканчивается.
Google, Mozilla и другие участники экосистемы принимают меры по отзыву и блокировке сертификатов. Однако обычные TLS-клиенты не всегда проверяют отзыв сертификатов в реальном времени.
А что насчёт устройств, которые годами не получают обновлений? Старых роутеров, камер, терминалов и промышленного оборудования?
Для них проблема может оказаться гораздо сложнее: даже если производитель отреагирует, обновить хранилище доверенных сертификатов удаётся далеко не всегда.
Вся безопасность HTTPS держится не только на математике, но и на том, насколько правильно люди реализуют эту математику.
Можно поставить самые современные серверы, настроить TLS, включить MFA и потратить месяцы на защиту периметра. А потом обнаружить, что один из корней доверия оказался построен на числе 4.
Источники:
🔗 Исследование Скотта Хелма: https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/
🔗 Реакция Google: https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/
🔥 Проверьте свои хранилища доверия. Потому что зашифрованное соединение и доверенное соединение — не всегда одно и то же
Исследователь Скотт Хелм обнаружил, что приватные ключи восьми промежуточных удостоверяющих центров eMudhra можно восстановить из публичных сертификатов меньше чем за секунду.
Один из ключей — буквально число 4.
Другие — 56, 115, 156, 230, 155, 66 и 237.
Нет, это не пароль от Wi-Fi. Это приватные ключи удостоверяющего центра, которому доверяли программные продукты и операционные системы.
Как вообще такое возможно?
Ключи использовали эллиптическую криптографию P-384. Нормальный приватный ключ должен быть случайным 384-битным числом. Пространство возможных значений настолько огромное, что перебор считается практически невозможным.
Но здесь вместо случайного числа оказались значения от 4 до 237.
47 байт нулей и один байт данных.
Вместо криптографической защиты — угадайка на 256 вариантов.
Исследователь взял публичные сертификаты, перебрал возможные значения и восстановил все восемь ключей. При этом сами сертификаты внешне выглядели корректно.
Что это означает на практике?
Обладатель такого ключа может выпускать поддельные сертификаты для чужих доменов.
Если атакующий окажется на сетевом маршруте между клиентом и сервером, а клиент продолжит доверять скомпрометированной цепочке, появляется возможность выдать себя за настоящий сайт и перехватить или изменить передаваемые данные.
И это не обязательно браузер.
Серверные API, Python, Go, Node.js, curl, CI/CD-пайплайны, контейнеры и всевозможные фоновые службы — всё это может использовать собственные хранилища сертификатов и по-разному обрабатывать отзыв скомпрометированных удостоверяющих центров.
Хелм продемонстрировал проблему на практике: в его тестовой среде curl принял поддельный сертификат для api.stripe.com и сообщил SSL certificate verify ok.
Это был контролируемый тест, а не доказательство взлома самого Stripe. Но демонстрация показывает, насколько опасным может оказаться устаревшее хранилище доверия.
Браузеры уже начали блокировать скомпрометированные сертификаты. Но на этом история не заканчивается.
Google, Mozilla и другие участники экосистемы принимают меры по отзыву и блокировке сертификатов. Однако обычные TLS-клиенты не всегда проверяют отзыв сертификатов в реальном времени.
А что насчёт устройств, которые годами не получают обновлений? Старых роутеров, камер, терминалов и промышленного оборудования?
Для них проблема может оказаться гораздо сложнее: даже если производитель отреагирует, обновить хранилище доверенных сертификатов удаётся далеко не всегда.
Вся безопасность HTTPS держится не только на математике, но и на том, насколько правильно люди реализуют эту математику.
Можно поставить самые современные серверы, настроить TLS, включить MFA и потратить месяцы на защиту периметра. А потом обнаружить, что один из корней доверия оказался построен на числе 4.
Источники:
🔗 Исследование Скотта Хелма: https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/
🔗 Реакция Google: https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/
🔥 Проверьте свои хранилища доверия. Потому что зашифрованное соединение и доверенное соединение — не всегда одно и то же
Просмотры: 5