Google раскрыл подробности обеспечения безопасности своей инфраструктуры

Google раскрыл подробности обеспечения безопасности своей инфраструктуры

Google раскрыл подробности обеспечения безопасности своей инфраструктуры

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

Некоторые интересные особенности:

  • Во всех серверах используются собственные материнские платы и сетевые компоненты, разработанные инженерами Google и произведённые под контролем представителей компании. Оборудование, включая периферийные устройства, оснащены специальным чипом, отвечающим за безопасную идентификацию и аутентификацию устройства на аппаратном уровне. Программные компоненты, включая прошивки, загрузчики, ядро и базовые образы систем проверяются по цифровой подписи. Таким образом в инфраструктуре могут применяться только проверенные аппаратные и программные элементы, содержащие корректную цифровую подпись.
  • В ситуациях, когда серверное оборудование приходится размещать в чужих датацентрах, оборудование Google отгораживается в собственный периметр физической безопасности, в котором для доступа применяются независимые биометрические датчики, камеры наблюдения и металлодетекторы.
  • Данные записываются на жесткие диски и SSD-накопители только в зашифрованном виде, что позволяет защитить их от несанкционированного доступа и возможных вредоносных действий, инициируемых со стороны прошивок, используемых в накопителях. Шифрование реализуется на аппаратном уровне. Жизненный цикл каждого накопителя скрупулезно отслеживается - если накопитель выходит из под контроля Google, он проходит многоэтапный процесс очистки с двумя независимыми проверками качества исполнения операции. Если устройство не может быть очищено, например, в результате сбоя накопителя, оно подвергается физическому уничтожению в измельчителе, передает opennet.ru.
  • Для выполнения виртуальных машин в облачной инфраструктуре Google применяется модифицированная версия гипервизора KVM, исправления всех проблем в котором возвращаются в upstream. Для ограничения отдельных сервисов в виртуальных машинах может применяться более высокий уровень изоляции на основе контейнеров и sandbox-технологий.
  • Весь создаваемый сотрудниками код проходит несколько стадий проверки, включая fuzzing-тестирование, статический анализ, автоматическое и ручное рецензирование. Ручное рецензирование проводится специальной группой, в которую входят эксперты в области безопасности, криптографии и защиты операционных систем. Код также должен быть одобрен как минимум одним сторонним инженером, не входящем в число авторов проверяемого проекта. С другой стороны, все вносимые в код правки обязательно должны быть подтверждены сопровождающим, ответственным за этот код.
  • Весь развиваемый в Google исходный код хранится в одном централизованном репозитории, в котором для аудита доступны все текущие и прошлые версии сервисов. Серверная инфраструктура может быть настроена на выполнение бинарных файлов сервиса, собранных только из определённой ревизии исходных текстов, прошедшей тестирование и рецензирование.
  • Разделения сети на сегменты и применение пакетных фильтров не относится к числу первичных систем обеспечения безопасности, внутренняя сетевая безопасность основывается на разделении полномочий на уровне доступа к отдельным сервисам и приложениям. Сотрудник получает доступ к ограниченному числу внутренних приложений, которые принимают запросы от работника только в контексте обращения с корректно обслуживаемой клиентской системы, из разрешённой подсети и ожидаемого физического местоположения (например, персонал, отвечающий за Gmail имеет доступ только к сервисам, связанным с данной системой).
  • Обмен данными между сервисами осуществляется с применением шифрования и криптографических методов аутентификации и авторизации. Каждый сервис выполняется в общей инфраструктуре, имеет свой криптографический идентификатор, который используется для идентификации сервиса при приёме запросов или обращении к другим сервисам. Криптографические идентификаторы также используется клиентами, чтобы удостовериться, что они обратились к требуемому серверу, и серверами для ограничения доступа клиентов к данным и методам.

 

 

  • При необходимости обработки сервисами запросов из глобальной сети применяется специальная прослойка - Google Front End (GFE), которая проверяет корректность сертификатов для TLS-соединений, выполняет балансировку нагрузки и осуществляет защиту от DoS-атак. Полученный запрос перенаправляется к сервису с использованием защищённого внутреннего RPC-протокола.
  • Для персонала применяется двухфакторная аутентификация. Применяемые сотрудниками клиентские системы проверяются на предмет применения всех имеющихся обновлений и установки только разрешённых приложений. Пользовательские приложения, загрузки файлов, браузерные расширения и просматриваемый web-контент проходит проверку на предмет допустимости использования на корпоративных клиентских устройствах.
  • Все действия сотрудников, требующие расширенных привилегий, по возможности автоматизированы. При необходимости проведения ручной работы по администрированию инфраструктуры или привилегированного доступа к системам требуется получения разрешения от двух ответственных лиц и по возможности открывается доступ к ограниченному отладочному API, позволяющему произвести отладку не касаясь конфиденциальной информации. Весь доступ сотрудников к пользовательской информации отслеживается и журналируется через систему низкоуровневых обработчиков. Работники службы безопасности и автоматизированные системы выполняют мониторинг активности сотрудников и выявляют нетипичную активность.

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