Zoom предоставит сквозное шифрование всем, но попросит данные взамен

Zoom предоставит сквозное шифрование всем, но попросит данные взамен

Zoom предоставит сквозное шифрование всем, но попросит данные взамен

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

Ранее представители Zoom обещали end-to-end только платным клиентам, что, конечно, вызвало массу вопросов и критики в отношении политики сервиса видеосвязи.

Например, правозащитники встали на сторону пользователей и обвинили Zoom в намеренном склонении людей к использованию платных версий сервиса: «если хотите дополнительную защиту ваших звонков — платите».

Однако в имплементации сквозного шифрования тоже было не всё так просто, если копнуть поглубже. Ранее разработчики утверждали, что пользователи должны пожертвовать некоторыми функциональными возможностями.

После внедрения end-to-end нельзя будет вклиниваться в звонки. Также сквозное шифрование может послужить укрытием для киберпреступников.

Однако на сегодняшний день, по словам гендиректора Zoom Эрика Юаня, платформа для видеоконференций решила эти проблемы. Так что же, бесплатным пользователям просто так предоставят сквозное шифрование?

Нет. Юань в своём блоге объяснил, что люди должны передать некоторые персональные данные, чтобы получить возможность использовать end-to-end. Не нравится? Как отметил генеральный директор, можете всегда переключить Zoom на стандартный уровень шифрования.

Новая атака на кеш 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