Mozilla перестали доверять сертификатам от WoSign и StartCom

Mozilla перестали доверять сертификатам от WoSign и StartCom

Mozilla перестали доверять сертификатам от WoSign и StartCom

Mozilla решили отозвать доверие к новым сертификатам WoSign и StartCom несмотря на то, что компании предприняли необходимые меры для решения этого вопроса в положительную сторону.

Ранее Mozilla предложили наложить запрет на сертификаты, выданные китайскими властями WoSign и дочерней компании StartCom. Это было связано с множеством проблем, выявленных с января 2015 года.

Наиболее серьезная проблема, выявленная Mozilla связана с тем, что сертификаты были выданы задним числом. Также немаловажным явился факт, что WoSign не уведомила Mozilla о приобретении StartCom.

В этом месяце представители Mozilla встретились с представителями StartCom и Qihoo 360, крупнейшим акционером WoSign. По итогам встречи было принято решение уволить исполнительного директора WoSign, который одобрил выдачу сертификатов задним числом и полностью отделить WoSign от StartCom. 

Несмотря на эти меры, Mozilla решили запретить новые сертификаты, по их словам «из-за уровня обмана, демонстрируемого представителями этой компании».

В версии Firefox 51, выход которой намечен на 8 ноября, сертификаты WoSign и StartCom потеряют статус доверенных.

«Если вы получили сертификат, выданный одним из этих центров сертификации после 21 октября 2016 года, стоит иметь в виду, что такие сертификаты не будут действительными в продуктах компании Mozilla, например, таких как Firefox версии 51 и выше» - объясняет в своем блоге команда безопасности Mozilla.

Новая атака на кеш Nginx позволяет красть данные и ломать сайты

Исследователь YesWeHack Алекс Брумен описал вектор кибератаки Cache Key Injection. В случае её эксплуатации последствия для потенциальной жертвы опасные: обход контроля доступа, раскрытие закрытых страниц, отказ в обслуживании и при определённых условиях.

Как объясняет исследователь YesWeHack, проблема возникает не в Nginx по умолчанию, а в конфигурациях, где администраторы просто склеивают несколько значений переменной длины без разделителей. Например:

$scheme$host$request_uri$http_accept

Разных запроса два, а итоговая строка может получиться одна. Так, запрос к /h с заголовком Accept: ome*/* создаёт тот же ключ, что и обычное обращение к /home с Accept: */*.

Если атакующий успеет первым положить в кеш ответ 404, пользователи вместо главной страницы будут получать ошибку до очистки записи. Получается CPDoS — отказ в обслуживании с доставкой прямо из кеша.

 

Ещё веселее становится с закрытыми разделами. В лабораторном примере страница /admin была доступна только с localhost, но злоумышленник мог обратиться к /ad и перенести оставшуюся часть имени в соседний компонент ключа. Nginx видел разрешённый путь, однако доставал из кеша содержимое админ-панели.

При совпадении нескольких условий техника позволяет столкнуть HTTP- и HTTPS-запросы и записать в кеш страницу со ссылкой на атакующий JavaScript, превратив ошибку конфигурации в stored XSS. Даже Cloudflare не всегда спасёт: заголовок Authorization может провести запрос мимо его кеша прямо к уязвимому кешу Nginx.

 

Защита выглядит до смешного просто: не склеивать значения вслепую. Между элементами ключа нужны разделители или структурное кодирование, например:

$scheme|$host|$request_uri|$http_accept

Также следует проверять Host, перенаправлять HTTP на HTTPS и не кешировать аутентифицированные запросы.

RSS: Новости на портале Anti-Malware.ru