Mozilla и Apple забанят удостоверяющие центры WoSign и StartCom

25f295dcee544f6da7a953f54890de65.jpeg

Расследование, проведённое Mozilla, показало, что китайский удостоверяющий центр WoSign (о бесплатных сертификатах которого был ряд статей на Хабре) за последние пару лет допустил вопиющее количество нарушений.

2015

Началось с мелочей: корпорация Google (которая постоянно ведёт мониторинг сертификатов), засекла неоднократный выпуск сертификатов с одинаковыми серийными номерами, что формально является нарушением стандартов. Были отмечены и другие лёгкие отклонения от правил.

Казалось бы, ничего серьёзного. Но это уже само по себе — сигнал удостоверяющему центру обратить внимание на происходящее, наладить и ужесточить механизмы проверок. Однако политика выдачи сертификатов, применяемая WoSign, отстаёт от их же собственной практики. Изменения в политику вносились после инцидентов, чтобы задним числом сгладить и оправдать допущенные отклонения.

Кроме того, были обнаружены недочёты в системе проверки «является ли получатель сертификата владельцем домена, сертификат для которого он запрашивает». Сами по себе не критичные, они всё же могли упростить выдачу сертификата злоумышленникам. Например, подтверждение владения доменом можно было выполнить, используя динамические порты (выше 50000). В Mozilla же придерживаются мнения, что выдача сертификатов должна производится с использованием лишь привилегированных портов (1024 и ниже). Хуже всего то, что WoSign не включала в логи номера портов, следовательно, масштаб проблемы невозможно оценить в полной мере.

Следом подоспели серьёзных уязвимости. Первая позволяла злоумышленнику, владеющему поддоменом, получить сертификат на весь домен. Обнаружившему это исследователю удалось получить фиктивные сертификаты GitHub (например, test.github.io), Microsoft и Alibaba. WoSign знала об уязвимости на протяжении 14 месяцев, но не исправила её, ограничившись отзывом сертификатов, содержащих «github» в имени домена. Выдача ошибочных сертификатов продолжалась. Оставшиеся проблемные сертификаты компания согласна отозвать лишь в случае обращения со стороны владельцев пострадавших доменов.

Вторая уязвимость оказалась воистину эпичной. После успешного прохождения проверки на владение доменом злоумышленник имел возможность добавить в список проверенных доменов любой посторонний домен. Абсолютно любой. Уже безо всякой проверки.

Словно этого было мало, WoSign втихомолку приобрела израильский удостоверяющий центр StartCom. Более того, когда ребята из Mozilla намекнули, что «так делать нехорошо» (и это мягко сказано, такое сокрытие нарушает политику Mozilla), WoSign принялась всё отрицать и пытаться предотвратить обнародование этих сведений.

Когда стало ясно, что шила в мешке не утаишь, компания выпустила пресс-релиз, признавшись в «осуществлении инвестирований». При этом единственным руководителем StartCom и одновременно CEO WoSign является один и тот же человек. Вдобавок, существуют технические доказательства того, что StartCom в настоящий момент использует большую часть инфраструктуры WoSign. Многовато получается совпадений для «компаний, которые действуют и управляются независимо друг от друга», как гласит пресс-релиз WoSign.

2016

Следующий год WoSign начала с того, что выпустила сертификаты SHA-1 с поддельной датой выдачи. Дату «отмотали» на месяц назад, что позволило избежать блокировки со стороны популярных браузеров, которые договорились с 2016 года принимать лишь сертификаты SHA-2, поскольку из-за роста вычислительных мощностей алгоритм SHA-1 уже сдаёт позиции и признан недостаточно стойким.

Три сертификата удалось разоблачить из-за невнимательности WoSign: внедрённые в три из них STC-метки (signed certificate timestamp) указывали на середину января 2016, из чего явно следует, что сертификаты не могли быть созданы раньше этого времени.

Ещё 62 выявили благодаря тому, что они были выданы в воскресенье, что совершенно нехарактерно для WoSign — в выходной день сотрудники в Китае не работают и сертификаты не выдаются. Есть и другие косвенные свидетельства подлога даты.

И всё это несмотря на то, что в документации CAB Forum чётко оговорено, что сертификаты, выпущенные в 2016 году, не должны использовать SHA-1:

Effective 1 January 2016, CAs MUST NOT issue any new Subscriber certificates or Subordinate CA certificates using the SHA‐1 hash algorithm.

В июле отличилась уже StartCom со своим сервисом StartEncrypt, запущенном в качестве ответа популярному Let’s Encrypt. Просто поменяв один параметр POST-запроса в конце автоматической проверки, можно было добиться того, что сертификат будет подписан не «StartCom Class 1 DV Server CA», а «WoSign CA Free SSL Certificate G2» или даже «CA 沃通根证书» (ещё одним корневым сертификатом WoSign). Некоторые из из этих сертификатов, выпущенные StartCom и подписанные «WoSign CA Free SSL Certificate G2», к тому же, датировались задним числом.

Формально, выпуск задним числом не запрещён, но это, несомненно, дурная практика. К тому же, WoSign всячески отрицала, что подделывала дату выпуска этих сертификатов. Её представители утверждали, что к этому времени уже убрали с «боевых» серверов код, который выпускал сертификаты задним числом. Но тогда становится совсем непонятно, как же парни из StartCom смогли использовать код, который даже сама WoSign уже использовать перестала?

В целом, этот эпизод демонстрирует безалаберность программистов — если в процессе выпуска сертификатов крутится неиспользуемый и опасный код, то он рано или поздно выстрелит. Что и произошло.

Кроме того остаётся открытым вопрос, а как вообще StartCom так лихо смогла выпустить сертификат от имени WoSign? Ведь. как мы помним, CEO WoSign уверял всех, что компании работают совершенно независимо друг от друга.

Дальше — больше: в StartEncrypt обнаружили парочку интересных уязвимостей. Одна позволяла, например, через API в качестве подтверждения контроля над доменом указать путь к любому существующему файлу. Скажем, залить файл на dropbox.com и указать путь к нему… С помощью другой, злоумышленник мог получить сертификат для любого сайта, поддерживающего OAuth 2.0 — google.com, facebook.com, paypal.com, linkedin.com, login.live.com, выбирайте на любой вкус.

И наконец, в сентябре 2016 года кто-то из сообщества заметил, что на скриншоте, приложенном к одному из отчётов WoSign, виден вывод утилиты dig из пакета bind-utils. И версия этой утилиты — 9.7.3–8.P3.el6. «el6» означает «Red Hat Enterprise Linux 6». Конечно, поддержка RHEL6 оканчивается лишь в этом году, но вот актуальная версия bind-utils в ней — 9.8.2–0.47.rc1.el6. А 9.7.3–8.P3.el6 соответствует не обновлённому пакету прямиком из 2011 года. За пять лет в апстриме закрыты 19 уязвимостей. Пусть ни одна из них не была критической, невольно задаёшься вопросом, в WoSign за столько лет не удосужились пропатчить лишь один сервер или, может, всю инфраструктуру?

И что в итоге?

Moziila решила на год перестать доверять сертификатам WoSign и StartCom. Но лишь новым. Выданные ранее остаются в силе. Этот год удостоверяющие центры должны потратить на исправление недостатков, а потом пройти проверки. Иначе, их сертификаты будут заблокированы навсегда.

Корпорация Apple ознакомилась с отчётом и объявила что iOS, и macOS на неопределённый срок прекращают доверять сертификатам обоих удостоверяющих центров, которые выпущены после 19 сентября 2016 года.

Реакция остальных крупнейших игроков на рынке браузеров (Google и Microsoft) пока неизвестна.

© Geektimes