Дослідник виявив помилку в системі перевірки доменів у засвідчувального центру SSL.com. Баг давав змогу отримувати TLS-сертифікати для чужих сайтів і, ймовірно, ним уже користувалися хакери. Тепер SSL.com відкликав 11 виданих помилково сертифікатів, один з яких був пов’язаний з Alibaba.

Отримавши такий сертифікат, шахраї могли створювати переконливі шкідливі копії сайтів для фішингу або розшифровувати перехоплений HTTPS-трафік між сайтами та їхніми відвідувачами.

Перед видачею TLS-сертифіката для конкретного домену, засвідчувальний центр має перевірити, чи дійсно користувач контролює цей домен. SSL.com дає змогу створити для домену запис DNS TXT_validation-contactemail, у якому як значення вказано контактну адресу електронної пошти.

Щойно цей DNS TXT-запис буде створено, і користувач запитає сертифікат для домену, SSL.com надішле код і посилання на вказану адресу пошти. Перейшовши за цим посиланням і ввівши код, людина доводить, що є адміністратором домену і після цього може отримати сертифікат для свого сайту.

Тобто SSL.com вважатиме людину власником домену, який фігурує в email-адресі, зазначеній у _validation-contactemail. Так, якщо вказати адресу [email protected] (за умови, що атакувальник може отримати лист за цією адресою і перейти за посиланням із нього), 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 травня поточного року.