Как заполучить любой сертификат в Интернете? Просто попросите у SSL.com

Сертификационный центр SSL[.]com оказался в центре скандала после того, как исследователь информационной безопасности, скрывающийся под псевдонимом Sec Reporter, продемонстрировал уязвимость , позволившую выпустить поддельный TLS-сертификат для домена крупного китайского облачного сервиса Alibaba Cloud.

Суть ошибки заключалась в реализации метода проверки контроля над доменом через DNS-запись. По замыслу, пользователь, желающий получить сертификат, должен добавить в DNS текстовую запись с адресом электронной почты, чтобы получить уникальный код для подтверждения. Однако система ошибочно интерпретировала домен почтового адреса как подтверждённый. Таким образом, если кто-либо мог принимать почту на, например, vulture@example[.]com, он внезапно получал возможность запросить сертификат и для самого example.com.

Sec Reporter воспользовался этой недоработкой, указав почтовый адрес на домене aliyun.com и получил сертификаты для aliyun[.]com и www[.]aliyun[.]com, принадлежащих Alibaba. Хотя исследователь не являлся владельцем или администратором ресурса, система SSL[.]com всё равно подтвердила право на выпуск сертификатов.

Ошибку уже признали в SSL[.]com и начали её устранять. Было отозвано 11 сертификатов, выданных с использованием этого метода. Помимо aliyun.com, в список попали домены канадской компании Medinet, сингапурского поставщика логистических решений Gurusoft, сервиса рекламы BetVictor и других менее известных ресурсов.

На данный момент неизвестно, использовались ли эти сертификаты злоумышленниками в реальных атаках, но сама возможность такого сценария — серьёзная угроза . Подобные сертификаты могли бы быть использованы для создания поддельных сайтов, кражи данных и перехвата зашифрованного трафика, что особенно опасно в контексте фишинга и атак типа «человек посередине».

Компания уже временно отключила спорный метод проверки, пообещав представить полный отчёт об инциденте не позднее 2 мая. Согласно предварительным данным, проблема возникла из-за неправильной реализации пункта 3.2.2.4.14 в политике сертификации SSL[.]com, где описан процесс валидации через электронную почту, указанную в DNS.

Инцидент подчёркивает важность надёжной реализации всех уровней безопасности в инфраструктуре цифровых сертификатов, особенно в тех механизмах, где автоматизация сочетается с доверием к DNS.