Половина ИТ-отделов не меняют заводские пароли IoT-устройств

Половина ИТ-отделов не меняют заводские пароли IoT-устройств

Половина ИТ-отделов не меняют заводские пароли IoT-устройств

Согласно анализу, проведенному CensusWide, 47 % ИТ-руководителей не меняют заводские настройки IoT-устройств, работающих в корпоративной среде, таким образом, доступ к этим устройствам можно получить, использовав пароль, установленный по умолчанию.

Учитывая, что в Великобритании зарегистрировано порядка 5,7 миллионов предприятий (по данным ForeScout), получается, что у 2,7 миллионов имеются серьезные проблемы с безопасностью, позволяющие злоумышленникам проникнуть в системы.

Проверка установленных по умолчанию паролей — пожалуй, первое, что предпринимают киберпреступники для того, чтобы проникнуть в сети организаций. Далее следует проверка на известные уязвимости, для которых уже есть общедоступные эксплойты, здесь стоит отметить, что 15 % руководителей сообщили, что не смогли (либо не захотели) установить обновления для своих устройств.

Лишь 54 % респондентов более-менее уверены в безопасности своих систем и каждого из устройств в отдельности. Многие все же понимают, насколько важно учесть все нюансы и обеспечить безопасность своего предприятия, поэтому 40 % опрошенных заявили, что планируют увеличить расходы на использование подключенных устройств.

72 % ИТ-руководителей, добавляя новые устройства к своей сети, опасаются последствий для безопасности.

«Попытка взлома IoT-устройства сама по себе не является проблемой. Дело в том, что эти устройства имеют доступ к огромным количествам чувствительных активов, а устройство IoT просто используется для доступа к этим данным. IoT-устройства являются самым слабым звеном в цепочке кибербезопасности бизнеса. Организации имеют нулевую видимость в этих устройствах, и они не защищены должным образом», — цитируют профильный СМИ генерального директора и соучредителя компании Cy-OT Натана Бэндлера.

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