Сотовые операторы ополчились на Samsung Absolute LoJack

Samsung хочет ввести перманентную блокировку смартфонов

Компания Samsung Electronics предложила интересное средство против воров телефонов. Корпорация решила установить в каждый свой смартфон так называемый «kill switch», который сделает похищенные аппараты нерабочими. Однако крупнейшие американские сотовые операторы AT&T Inc., Verizon Wireless, United States Cellular Corp., Sprint Corp. и T-Mobile US Inc. отказались от подобного решения.

Они не пожелали использовать Absolute LoJack в качестве обязательной функции. По мнению операторов сотовой связи, подобная кнопка выключения может быть использована хакером. Отметим, что власти, наоборот, требуют, чтобы производители смартфонов включили подобные функции в свои продукты. Таким образом, они надеются бороться с кражами смартфонов, ведь 1 из 3 ограблений в США непременно связано с хищением мобильного гаджета. В прошлом году из-за этого рядовые потребители потеряли $30 млрд.

Samsung уже попробовала внедрить Absolute LoJack в некоторые из своих готовых устройств, однако в США операторы убрали эту программную добавку и начали продавать чистый смартфон. Предполагается, что сотовые компании просто не желают терять деньги от страховок за краденные аппараты. Тем временем корейская компания продолжает работать с Secure Our Smartphones (SOS) Initiative и многими сотовыми партнерами, чтобы найти удачное решение предотвращения краж смартфонов.

Интересно, что сейчас в Северной Америке популярные смартфоны Samsung Galaxy поставляются без LoJack, но вы можете оформить подписку и получить данную услугу. Организация, представляющая интересы беспроводных провайдеров, – CTIA-The Wireless Association – утверждает, что перманентный «kill switch» потенциально может открыть новые перспективы для хакеров. Теоретически взломщики могут по собственному требованию отключать мобильные устройства, которые принадлежат государственным чиновникам или министерствам.

Расширения 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