Apple несмотря на шифрование, имеет доступ к данным пользователей

Александр Панасенко 26 Января 2016 - 10:06

Общее

iOS

Apple

Средства криптографической защиты информации

Кибершпионаж

...

Apple несмотря на шифрование, имеет доступ к данным пользователей

Позиция компании Apple по поводу внедрения бэкдоров в продукты давно известна – она резко отрицательная. Руководство Apple не раз подчеркивало, что компания при всем желании не может читать сообщения iMessage, благодаря end-to-end шифрованию.

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

Журналисты издания Vice Motherboard пролили свет на очень интересную проблему. Оказывается, пользователи iCloud Backup не могут быть на сто процентов уверены в неприкосновенности своих данных, передает xakep.ru.

В 2014 году Тим Кук не без гордости заявлял, что Apple не сможет расшифровать сообщения iMessage, даже если получит соответственное судебное предписание – у компании попросту нет ключей шифрования.

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

Нужно признать, что Apple предлагает iCloud как опцию, а не навязывает сервис по умолчанию. Однако включить бэкапы iCloud пользователю предлагают в первую же минуту после активации iPhone или iPad. При этом ему не сообщают, что после активации iCloud Backup все «нечитаемые» сообщения станут очень даже читаемым. Локального шифрования iCloud не предлагает вовсе. То есть зашифровать данные самостоятельно и отправить их в облако, зная, что компания уже не сможет их прочесть, не выйдет.

Теоретически, получить доступ к пользовательским данным в облаке iCloud может кто угодно, начиная от спецслужб, имеющих решение суда на руках, и заканчивая хакерами, которые могут проникнуть на серверы компании.

Неизвестно, сколько пользователей насчитывается у сервиса iCloud Backup на данный момент. Наиболее «свежие» данные об iCloud датированы 2014 годом. В марте 2014 года специалисты консалтинговой фирмы Asymco подсчитали, что iCloud пользуется 500 млн человек. Так как в апреле 2013 года эта цифра равнялась 300 млн, можно приблизительно подсчитать количество пользователей на сегодня: их число уже приближается к миллиарду, если темпы роста аудитории не замедлились.

Официальных комментариев от компании Apple пока не поступало.

Пользователи, которых не устраивает такое положение вещей, пока могут предпринять следующие шаги:

Использовать локальные бэкапы через iTunes;
Отключить iCloud Backup: Settings -> iCloud -> Storage & Backup -> iCloud Backup.

Следующая главная новость »

SOC без иллюзий: от выбора технологий к реальной защите - обсудим в эфире AM Live! Регистрируйтесь »

Татьяна Никитина 04 Февраля 2026 - 21:18

Уязвимости программ Домашние пользователи Корпорации

Расширения Chrome могут слить секреты URL через атаку по стороннему каналу

Как оказалось, расширения Chrome можно использовать для слива кодов авторизации, сеансовых ID и других секретов из URL любой открытой вкладки. Никаких специальных разрешений для этого не понадобится, только доступ к declarativeNetRequest API.

Этот механизм, пришедший на смену webRequest API, позволяет расширениям сообщать браузеру, что следует изменить или заблокировать на загружаемой странице (заголовки, реклама, трекеры).

Правила обработки запросов при этом добавляются динамически, а фильтрация осуществляется по регулярным выражениям, соответствующим подмножествам знаков, которые могут присутствовать на определенных позициях в URL.

Исследователь Луан Эррера (Luan Herrera) обнаружил, что блокировку, диктуемую правилами, Chrome производит почти мгновенно, за 10-30 мс, а остальные запросы выполняются дольше (~50-100ms) — из-за сетевых подключений. Эту разницу во времени расширение может использовать для бинарного поиска с целью посимвольного слива URL.

// extensions/browser/api/web_request/extension_web_request_event_router.cc:1117-1127
case DNRRequestAction::Type::BLOCK:
  ClearPendingCallbacks(browser_context, *request);
  DCHECK_EQ(1u, actions.size());
  OnDNRActionMatched(browser_context, *request, action);
  return net::ERR_BLOCKED_BY_CLIENT;

Оракул для подобной тайминг-атаки строится с использованием chrome.tabs.reload для перезагрузки страницы и перехватчика chrome.tabs.onUpdated, помогающего отследить событие status === "complete". Замер времени между reload и завершением загрузки покажет, заблокирован запрос или успешно обработан.

Повторение проверок и бинарного поиска позволяет получить полный URL (с довеском после «?»), затратив на каждый знак строки несколько прогонов. Таким образом, можно незаметно для пользователя украсть включенные приложением в адрес секреты — токены OAuth и сброса пароля, API-ключи, ссылки на контент, закрытый для поисковых систем.

Проверка PoC проводилась на Windows 11 24H2 с использованием Chrome разных версий: