Apple отказалась предоставить исходные коды правительству Китая

Apple отказалась предоставить исходные коды правительству Китая

Apple отказалась предоставить исходные коды правительству Китая

В ходе слушаний в Конгрессе США главный юрисконсульт компании Apple Брюс Сьюелл (Bruce Sewell) сообщил, что власти Китая неоднократно обращались к Apple с требованием предоставить в их распоряжение исходные коды продуктов компании.

В минувший вторник (19 апреля 2016 года), во время дебатов Конгрессе, капитан полиции Чарльз Коэн (Charles Cohen) обвинил Apple в том, что компания раскрыла исходные коды своих решений властям Китая. Коэн не привел не единой фактической улики в подтверждение своих слов, вместо этого он сослался на многочисленные публикации в СМИ.

«Я видел несколько новостных публикаций, в которых говорилось о том, что Apple представила исходные коды iOS китайской стороне», — заявил капитан, не конкретизировав, о каких публикациях идет речь.

К вопросу Коэна присоединились конгрессмены, в очередной раз обеспокоившись тем, что Apple всё-таки могла иметь некий универсальный ключ шифрования, который скрывает от властей США, но предоставила Китаю. Сколь бы смешным ни выглядели эти обвинения, главный юрисконсульт компании ответил на них с максимальной серьезностью. Сьюелл сообщил, что власти Китая действительно предъявляли такие требования и за последние два года неоднократно запрашивали исходные коды продуктов Apple, однако компания всякий раз отвечала отказом, передает xakep.ru.

«Мы не предоставляли исходные коды китайскому правительству. 19 месяцев назад у нас не было ключа [шифрования], который мы затем по-тихому “выбросили”. Эти обвинения беспочвенны», — подвел итог Сьюелл.

Интересно, что практически одновременно с этим инцидентом в Конгрессе, компания Apple опубликовала свежий отчет о доступности сервисов и данных (transparency report). В документ вошла информация о второй половине 2015 года. За шесть месяцев (с июля по декабрь 2015 года) Apple получила 1021 запрос от правоохранительных органов США и Канады на раскрытие данных о 5201 аккаунта. Но североамериканские власти отнюдь не были лидерами в данном вопросе. Так, за эти полгода Китай направил Apple 32 запроса о 6724 аккаунтах.

 

2

 

Согласно отчету, 82% запросов от правоохранительных органов стран Северной Америки были удовлетворены хотя бы частично, то есть компания раскрыла данные о 4420 аккаунтах. Какие именно данные были раскрыты в каждом случае, неизвестно. Это мог быть email, номер телефона или банковской карты, уникальный ID, использующийся для доступа к iCloud или iTunes.

Для стран Европы, Ближнего востока, Индии и Африки были удовлетворены 50% запросов. Китайская сторона получила желаемое в 54% случаев. В отчете отдельно отмечено, что запросы от правоохранительных органов Китая в основном были связаны с расследованиями фишинговых кампаний.

Информацию относительно устройств Apple запрашивали гораздо чаще. Компания поясняет, что такие обращения, чаще всего, связаны с украденными или потерянными гаджетами. То есть компания может предоставить информацию о владельце устройства и его контакты. Устройства считали по уникальным серийным номерам и IMEI.

 

1

Расширения 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 разных версий:

  • 144.0.7559.97 (Stable)
  • 145.0.7632.18 (Beta)
  • 146.0.7647.4 (Dev)
  • 146.0.7653.0 (Canary)

В Google подтвердили возможность подобной атаки по стороннему каналу, но заявили, что решить проблему нереально.

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