В системе проверки владения доменом удостоверяющего центра SSL.com обнаружена уязвимость, позволявшая получить TLS-сертификат для любого домена, предоставившего электронную почту атакующему.
Фактически для получения TLS‑сертификата было достаточно доступа к email с целевым доменом. Например, уязвимость позволяла получить TLS‑сертификат для доменов, используемых в общедоступных email‑сервисах, таких как gmail.com, yandex.ru, yahoo.com, outlook.com и icloud.com.
Уязвимость также давала злоумышленникам возможность проводить целевые атаки на сотрудников известных компаний и участников крупных проектов для захвата доступа к их email и получения TLS‑сертификатов для известных доменов. Например, взлом сотрудника Google, имеющего email [email=name@google.com,]name@google.com,[/email] позволял получить сертификат для домена google.com.
По информации OpenNET, уязвимость была вызвана ошибкой в реализации системы проверки владения доменом через подтверждение по электронной почте. Для получения подтверждения по email необходимо добавить в DNS‑зону домена, для которого запрашивается сертификат, DNS TXT запись «_validation‑contactemail». Например, «_validation‑contactemail.test.com DNS TXT [email=name@example.com».]name@example.com».[/email] После инициирования проверки домена на email name@example.com будет отправлен код подтверждения, ввод которого подтверждает владение доменом «test.com» и позволяет получить TLS‑сертификат для «test.com».
Суть уязвимости в том, что помимо домена «test.com», для которого был запрошен сертификат, признак подтверждения владения также выставлялся и для домена «example.com», используемого в email. Выявивший проблему исследователь продемонстрировал получение рабочего TLS‑сертификата для домена aliyun.com, применяемого в webmail‑сервисе китайской компании Alibaba.
В ходе тестовой атаки исследователь зарегистрировал проверочный домен «d2b4eee07de5efcb8598f0586cbf2690.test.dcv‑inspector.com» в сервисе «dcv‑inspector.com» и запросил для него TLS‑сертификат, добавив DNS‑запись: «_validation‑contactemail.d2b4eee07de5efcb8598f0586cbf2690.test.dcv‑inspector.com DNS TXT [email=myusername@aliyun.com».]myusername@aliyun.com».[/email]
После этого исследователь запросил на сайте SSL.com TLS‑сертификат для домена d2b4eee07de5efcb8598f0586cbf2690.test.dcv‑inspector.com и выбрал подтверждение по email.
Удостоверяющий центр SSL.com отправил проверочный код на myusername@aliyun.com и после ввода этого кода добавил в список верифицированных доменов не только «d2b4eee07de5efcb8598f0586cbf2690.test.dcv‑inspector.com», но и «aliyun.com». После этого исследователь успешно получил TLS‑сертификат для домена «aliyun.com», владение которым было подтверждено.
Удостоверяющий центр SSL.com до устранения ошибки заблокировал проблемный режим подтверждения и выявил 11 сертификатов, при выдаче которых была использована уязвимая схема проверки со сторонним доменом в email. Предположительно, в выявленных случаях отсутствуют признаки вредоносной активности. Тем не менее, данные сертификаты решено отозвать, так как они получены с использованием некорректного процесса проверки. В проблемных сертификатах фигурируют домены medinet.ca, help.gurusoft.com.sg, banners.betvictor.com, production‑boomi.3day.com, kisales.com и medc.kisales.com.
На момент написания новости в CLR‑списках SSL.com числится отозванным только один сертификат, полученный исследователем для сайта aliyun.com. При этом в предоставляемом SSL.com сервисе OCSP (Online Certificate Status Protocol) все сертификаты уже помечены как отозванные. В списках CRLSet (Google), disallowedcert.stl (Microsoft) и OneCRL (Mozilla) сертификаты пока имеют статус Not Revoked.
Источник новости: habr.com
