Apple отказалась помещать бэкдор в iCloud — Британии пришлось отступить

Apple отказалась помещать бэкдор в iCloud — Британии пришлось отступить

Apple отказалась помещать бэкдор в iCloud — Британии пришлось отступить

В начале года стало известно, что британское правительство втайне потребовало от Apple создать бэкдор — лазейку, через которую можно получить доступ к зашифрованным данным всех пользователей iCloud по всему миру. Да, вопрос ставился именно так — всех пользователей.

Речь шла об обходе новой функции Advanced Data Protection (ADP), которая включает сквозное шифрование почти всей информации в iCloud — так, что даже сама Apple не может её расшифровать. Но в Лондоне, видимо, решили, что им это ни к чему.

Правительство захотело доступ ко всем пользовательским данным iCloud, включая те, что защищены сквозным шифрованием. Проблема в том, что технически это просто невозможно — у Apple нет ключей, а значит, и доступа.

Кроме того, для незашифрованных данных у полиции и спецслужб уже есть законные пути: можно пойти в суд, получить ордер, и тогда Apple, как правило, сотрудничает.

Но вместо этого власти попытались действовать скрытно: использовать закон, по которому Apple не имела права рассказывать о полученном требовании. Даже само судебное разбирательство должно было проходить в тайне.

Apple не могла прямо рассказать о том, что её вынуждают взломать собственную систему защиты. Вместо этого компания сделала ход конём: объявила, что больше не может предоставлять функцию ADP в Великобритании.

«Мы глубоко разочарованы тем, что наши пользователи в Великобритании останутся без защиты, которую даёт Advanced Data Protection. Мы никогда не создавали бэкдоры в наших продуктах и не собираемся это делать», — заявили в Apple.

Формально они ничего не нарушили — просто признали, что ADP в Британии недоступен. Но посыл был предельно ясен: «Нас заставляют, но мы не пойдём на это».

Британские власти долго упирались, но, по данным Financial Times, вмешались США — и, похоже, заставили Лондон отступить.

«Вице-президент США крайне раздражён этой ситуацией. Вопрос нужно решать», — рассказал один из чиновников британского регулятора.

По информации FT, в Вашингтоне прямо дали понять: если Британия будет настаивать на своём, это может сорвать технологические соглашения между странами. В итоге, по словам источников, Министерство внутренних дел Великобритании (Home Office), скорее всего, отступит.

Ни Apple, ни власти США и Британии официально ситуацию не комментируют. Но, судя по всему, пока битву за сквозное шифрование удалось отстоять.

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