Система перевірки домену сертифікатів SSL.com мала нещасну помилку, яка була використана зловмисниками, щоб отримати без дозволу, цифрові церти для законних веб -сайтів.
З цими сертифікатами, зазначають, що шахраї можуть створити більш зухвалих шкідливих копій цих сайтів для таких речей, як фішинг довіри, або розшифрував перехоплення трафіку HTTPS між цими сайтами та їх відвідувачами.
А після того, як дізнавшись про цю недолік, SSL.com відкликав 11 неправильно виданих сертифікатів – один з них для Alibaba.
Отвір здається таким же простим, як це: як частина процесу перевірки того, що ви керуєте доменним іменем – і, таким чином _validation-contactemail Запис DNS TXT для домену зі значенням, встановленим на контактну електронну адресу.
Після того, як цей запис DNS TXT присутній, і ви вимагаєте сертифіката для домену, SSL.com надсилає код та URL -адресу на цю контактну адресу. Ви натискаєте на посилання та вводите код і встановлюєте, що ви є контролером домену і можете отримати сертифікат для свого сайту.
На жаль, через реалізацію баггі, SSL.com також вважає вас власником домену, який використовується для контактної електронної пошти. Якщо ви поставите в vulture@example.com, за умови, що ви можете взяти пошту на цю адресу та перейти за посиланням, SSL.com із задоволенням видав вам сертифікат для прикладу.com. Не має значення, в якому домені ви насправді намагалися перевірити право власності.
Swap example.com для постачальника веб -пошти, і раптом це стає трохи страшною ситуацією.
Як зазначив у п'ятницю звіт про помилку, опублікований у п’ятницю, який використовує ручку “репортер SEC”, коли SSL.com отримав запит на видання сертифіката, під час процесу перевірки домену “неправильно позначає ім'я хоста електронної адреси підтвердження як перевірений домен”.
SEC Reporter продемонстрував, що можна було надати електронну адресу @aliyun.com для випадкового домену, а також видати Certs для aliyun.com та www.aliyun.com – веб -поштою та публічним хмарним сервісом, яким керує китайський Інтернет -гігант Alibaba.
Подібність SSL.com з цього приводу страшно, оскільки це означає, що кожен, хто набрав хибний процес перевірки запису DNS, може вимагати та бути виданий, TLS CERT для чужого веб -сайту. Ці церти можуть бути використані для підробки законного сайту та дозволу атаки в середній середній, фішинг тощо.
Зараз SSL.com скасував 11 сертифікатів, виданих за допомогою цієї несправної логіки перевірки. Один з них був для Aliyun.com, отриманий дослідником, щоб продемонструвати вразливість безпеки. Інші? SSL.com не говорить, хто їх отримав, але перелічив їх наступним чином:
Важливо відзначити, що церти, створені для цих доменів, можуть бути не отримані зловмисно; Все, що ми знаємо, це те, що вони були видані через зламану систему перевірки, а це означає, що їх потрібно скасувати як запобіжні заходи.
У попередньому звіті про інцидент, опублікованому в понеділок, офіцер технічного дотримання SSL.com Ребекка Келлі підтвердила, що в одному з методів перевірки контролю домену (DCV) є недолік.
“Неправильна реалізація методу DCV, зазначеної в SSL.com CP/CPS, Розділ 3.2.2.4.14 (електронна пошта до контакту DNS TXT), що призвело до неправильного видання сертифіката на ім'я хоста електронної адреси затвердження”,-заявив Келлі в базі даних Mozilla Bugzilla.
Цей конкретний процес DCV – існують альтернативні методи перевірки доменів – відключений, поки SSL.com не зможе виправити недолік. Біз обіцяв повний звіт про інцидент 2 травня або до цього.
Ось п’ять кроків, плюс початкова фаза налаштування, репортер SEC надав для використання нагляду за перевіркою домену:
Як зазначалося в їх написанні, дослідник не є адміністратором, хостом, ані веб-майстром для aliyun.com, і _validation-contactemail для домену взагалі не був налаштований. “Отже, це неправильно”, – підсумував мисливець на помилки.
SSL.com подякував досліднику і пообіцяв, що “обробка цього інциденту з максимальним пріоритетом”.
Реєстр звернувся до запитань про помилку та чи є якесь слово, яке його експлуатують для нечітких цілей. Ми оновимо цю історію, коли отримаємо більше інформації. ®