Специалисты по кибербезопасности выявили критическую уязвимость в процессе валидации доменов удостоверяющего центра SSL.com. Обнаруженный дефект позволял злоумышленникам получать действительные TLS-сертификаты для любых доменов без подтверждения реального права владения ими.
Механизм эксплуатации уязвимости
Проблема заключалась в некорректной реализации метода проверки контроля над доменом (Domain Control Validation, DCV) через DNS TXT-записи. При стандартной процедуре владелец домена создает специальную DNS TXT-запись с указанием контактного email-адреса. Однако система SSL.com ошибочно интерпретировала доменное имя из этого email-адреса как подтвержденный домен, независимо от того, какой домен фактически проходил проверку.
Потенциальные последствия для безопасности
Эксплуатация данной уязвимости открывала широкие возможности для проведения фишинговых атак и перехвата HTTPS-трафика. Злоумышленники могли использовать полученные сертификаты для создания убедительных копий легитимных сайтов или осуществления атак типа man-in-the-middle, компрометируя защищенные соединения между пользователями и веб-ресурсами.
Масштаб проблемы и принятые меры
В результате инцидента SSL.com был вынужден отозвать 11 некорректно выданных сертификатов. Среди затронутых доменов оказались ресурсы крупных организаций, включая облачный сервис Alibaba (aliyun.com), канадского поставщика медицинского ПО Medinet и сингапурской технологической компании Gurusoft.
Технические детали уязвимости
Исследователь, известный как Sec Reporter, продемонстрировал уязвимость на примере домена aliyun.com. Используя email-адрес на этом домене, он смог получить действительные TLS-сертификаты для aliyun.com и www.aliyun.com без какого-либо контроля над этими ресурсами. Примечательно, что для успешной атаки даже не требовалось наличие DNS TXT-записи _validation-contactemail в целевом домене.
В настоящее время SSL.com временно отключил скомпрометированный метод DCV и работает над исправлением уязвимости. Компания обязалась представить детальный отчет об инциденте до 2 мая. Данный случай подчеркивает критическую важность тщательного тестирования механизмов проверки доменов в инфраструктуре открытых ключей и необходимость регулярного аудита процедур безопасности удостоверяющих центров.
