Исследователь обнаружил ошибку в системе проверки доменов у удостоверяющего центра SSL.com. Баг позволял получать TLS-сертификаты для чужих сайтов и, вероятно, им уже пользовались хакеры. Теперь SSL.com отозвал 11 выданных по ошибке сертификатов, один из которых был связан с Alibaba.
Получив такой сертификат, мошенники могли создавать убедительные вредоносные копии сайтов для фишинга или расшифровывать перехваченный HTTPS-трафик между сайтами и их посетителями.
Перед выдачей TLS-сертификата для конкретного домена, удостоверяющий центр должен проверить, действительно ли пользователь контролирует этот домен. SSL.com позволяет создать для домена запись DNS TXT_validation-contactemail, в которой в качестве значения указан контактный адрес электронной почты.
Как только эта DNS TXT-запись будет создана, и пользователь запросит сертификат для домена, SSL.com отправит код и ссылку на указанный адрес почты. Перейдя по этой ссылке и введя код, человек доказывает, что является администратором домена и после этого может получить сертификат для своего сайта.
Об уязвимости в этом процессе на прошлой неделе рассказал человек под ником Sec Reporter. Он объяснил, что проблема заключалась в том, что при получении запроса на выдачу сертификата, SSL.com проводил проверку владения доменом и «ошибочно считал доменом имя хоста из email-адреса утвердителя».
То есть SSL.com будет считать человека владельцем домена, который фигурирует в email-адресе, указанном в _validation-contactemail. Так, если указать адрес vulture@example.com (при условии, что атакующий может получить письмо по этому адресу и перейти по ссылке из него), SSL.com выдаст сертификат для домена example.com. При этом неважно, владение каким доменом пользователь хотел подтвердить на самом деле. А если вместо example.com указать домен почтового провайдера, ситуация становится тревожной.
В своем отчете Sec Reporter продемонстрировал, что можно указать адрес электронной почты на @aliyun.com, якобы доказывая владение произвольным доменом, и в результате получить сертификаты для aliyun.com и www.aliyun.com — почтового сервиса и публичного облачного сервиса китайского интернет-гиганта Alibaba.
Исследователь подчеркивает, что не является администратором, хостмастером или веб-мастером aliyun.com, а параметр _validation-contactemail для этого домена вообще не был настроен.
Фактически это означает, что любой, кто заметил ошибку в процессе проверки SSL.com, мог запросить и получить TLS-сертификат для чужого сайта. Затем эти сертификаты могли использоваться для подделки настоящего сайта, фишинга, атак типа man-in-the-middle и так далее.
После предупреждения исследователя представители SSL.com отозвали 11 выданных из-за этого бага сертификатов. Один из них был получен самим Sec Reporter для сайта aliyun.com, чтобы продемонстрировать уязвимость. Об остальных SSL.com не раскрыла почти никаких подробностей, перечислив их следующим образом:
• *.medinet.ca — канадский поставщик программного обеспечения и услуг для здравоохранения (сертификат выпущен в июне 2024 года);
• help.gurusoft.com.sg (дважды) — сайт поддержки сингапурской компании, занимающейся технологиями цепочек поставок (сертификат выпущен в январе 2025 года);
• banners.betvictor.com — предположительно рекламный домен для игорного сайта BetVictor (сертификат выпущен в январе 2025 года);
• production-boomi.3day.com — производитель оконных жалюзи (сертификат выпущен в марте 2025 года);
• kisales.com и medc.kisales.com (в общей сложности четыре раза) — сертификат выпущен в марте 2025 года.
Вероятно, сертификаты для этих доменов не были выпущены хакерами. Однако они были выданы из-за бага, поэтому их пришлось отозвать в качестве меры предосторожности.
В отчете об инциденте, опубликованном ранее на этой неделе, специалист SSL.com Ребекка Келли (Rebecca Kelley) подтвердила, что в одном из методов проверки права владения доменом (domain control validation, DCV) была обнаружена ошибка.
«Неправильная реализация метода DCV, указанного в SSL.com CP/CPS, раздел 3.2.2.4.14 (Email to DNS TXT Contact), приводила к ошибочной выдаче сертификата на имя хоста адреса электронной почты утвердителя», — подтвердила Келли.
В настоящее время этот метод DCV отключен, и SSL.com работает над устранением проблемы. Компания пообещала опубликовать полный отчет об инциденте не позднее 2 мая текущего года.
