Gartner: 60% виртуальных серверов защищены хуже, чем физические

Gartner: 60% виртуальных серверов защищены хуже, чем физические

...

Исследование компании Gartner показало, что около 60% виртуальных серверов защищены существенно хуже, чем физические серверы. Gartner отмечает, что чаще всего пользователи заменяют физические серверы виртуальными и это идет в ущерб безопасности ИТ-системы. Хуже того, аналитики говорят, что на рынке пока нет по-настоящему комплексных и надежных средств для защиты виртуальных серверов и появятся они лишь к 2012 году.

Согласно данным прогноза Gartner, в 2015 году лишь 30% виртуальных сервизов будут менее защищены, чем физические.

"Сама по себе виртуализация не наносит ущерба безопасности, но многие проекты по развертыванию виртуальных систем проводятся без необходимого аудита безопасности и некоторые проблемы в случае работы виртуальных систем носят фундаментальный или архитектурный характер. Чем больше ИТ-систем мы переносим, тем больше различных уровней безопасности надо было бы учитывать, но этого не делается. Особенно это важно, когда виртуализуются какие-то критически важные инфраструктурные проекты", - говорится в данных Gartner.

В компании идентифицировали шесть наиболее типичных проблем, связанных с виртуализацией. Во-первых, почти 40% проектов делаются без привлечения специалистов по информационной безопасности на начальных стадиях. "Как правило, большинство компаний просто говорят, что ничего не изменилось, у них уже есть достаточно защищенные решения. Но этот аргумент не учитывает наличие дополнительного критического важного слоя - гипервизора в котором работает система виртуализации", - говорят в Gartner.

Во-вторых, уязвимость, связанная с одной виртуальной платформой или виртуализатором, автоматически ставит под угрозу все остальные операционные системы на данном сервере. "Гипервизор - это новая платформа, которая может содержать еще не обнаруженные уязвимости", - говорится в отчете.

В-третьих, следует озаботиться проблемой обеспечения безопасности загрузки самого гипервизора и сделать такие условия работы системы, чтобы свести вероятность несанкционированных изменений в гипервизоре минимальной. Кроме того, дополнительные риск несут в себе устройства, обеспечивающие сетевую безопасность, так как большая часть этих устройств пока еще не предназначена для работы в виртуализованных средах.

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

Источник 

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