В пытающемся конкурировать с Lets'Encrypt сервисе автоматической выдачи SSL-сертификатов StartEncrypt, развиваемом удостоверяющим центром StartCom (торговая марка StartSSL), выявлена критическая проблема с безопасностью, позволяющая получить заверенный удостоверяющим центром сертификат для не принадлежащего пользователю домена. Например, можно получить SSL-сертификаты для google.com и facebook.com, которые будут восприняты в браузерах как заслуживающие доверия.

Проблема присутствует в реализации механизма проверки принадлежности домена заявителю. Как упоминалось в опубликованном две недели назад анонсе, проверка выполняется закрытым приложением, представляющим собой "черный ящик", отправляющий сетевые запросы к внешнему API. Энтузиасты заинтересовались подобной сетевой активностью и в процессе анализа приложения, нашли в нём серию уязвимостей, позволяющих запросить сертификат, обманув стадию проверки принадлежности домена.

Первая уязвимость связана с тем, что для проверки контроля за доменом запрашивается файл "/signfile", но путь к этому файлу также указывается при запросе к API, что позволяет указать в запросе к API любой URL и получить сертификат для любого сайта, на который могут быть загружены сторонние данные. Например, файл можно загрузить на dropbox.com и указать путь к этому файлу при обращении к API, после чего StartEncrypt посчитает, что домен dropbox.com принадлежит пользователю, запросившему сертификат.

Вторая уязвимость расширяет возможности атаки сайтами, на которых допускаются перенаправления URL. При загрузке проверочного файла StartEncrypt обрабатывает редиректы, поэтому для получения сертификата чужого сайта не обязательно загружать на него данные, достаточно организовать перенаправление на свой хост. Функция перенаправления на URL при завершении сеанса определена в спецификации OAuth 2.0, что позволяет получить сертификат для любого сайта, поддерживающего OAuth 2.0. Например, сертификат можно получить для google.com, facebook.com, paypal.com, linkedin.com, login.live.com и т.п.

Кроме того, несколько уязвимостей выявлены в коде клиентского приложения: клиент не проверяет сертификат сервера при обработке ответов API, при загрузке проверочного файла не выполняется проверка типа контента (проверочный файл можно загрузить под видом изображения), приватный ключ (/usr/local/StartEncrypt/conf/cert/tokenpri.key) сохраняется с правами 0666, что позволяет любому локальному пользователю прочитать и изменить его.

Источник: http://www.opennet.ru/opennews/art.shtml?num=44708