Исследователь обнаружил критическую ошибку в системе проверки доменов у удостоверяющего центра SSL.com, позволяющую получать TLS-сертификаты для чужих сайтов. Инцидент уже вызвал обеспокоенность, поскольку имеются подозрения, что злоумышленники могли воспользоваться этой уязвимостью. В результате SSL.com отозвал 11 сертификатов, один из которых был связан с Alibaba.
По словам исследователя с псевдонимом Sec Reporter, проблема заключается в неправильной реализации проверки владения доменом. SSL.com считал владельцем домена лицо, чья электронная почта указана в записи DNS TXT. Так, если вводится адрес vulture@example.com, удостоверяющий центр выдает сертификат для example.com, даже если запрашивающий не имеет никаких прав на этот домен.
Исследователь показал это на примере домена aliyun.com, ведь он мог получить сертификат, указав адрес электронной почты хостинг-провайдера. При этом он не является владельцем или администратором рассматриваемого домена. После уведомления исследователя, SSL.com отозвал сертификаты, чтобы предотвратить возможное использование этой уязвимости.
SSL.com подтвердил наличие ошибки в методе проверки владения доменом (domain control validation, DCV). Специалист компании Ребекка Келли заявила, что неверная реализация метода выдавала сертификат на имя хоста из адреса электронной почты, указанного в заявке.
Как выяснили в OpenNET, уязвимость позволяет получить TLS-сертификат для любого домена, если у злоумышленника есть доступ к почте, связанной с этим доменом. Это открывает потенциальные возможности для фишинга и атак типа man-in-the-middle. Это также усугубляет проблему безопасности для сотрудников крупных компаний, которые могут стать мишенями для атак.
На данный момент SSL.com отключил проблемный метод DCV и работает над исправлением. У компании нет информации о том, были ли использованы отозванные сертификаты в злонамеренных целях, но они решили отозвать их для повышения безопасности. Все сертификаты уже помечены как отозванные в системе OCSP, однако в блоклистах Google и Mozilla они пока значатся как не отозванные. SSL.com пообещала предоставить полный отчет об инциденте к 2 мая.