Side-Channel Attacks and Cloud & Containers Security
Если вы зашли почитать данную статью, то вам явно интересна тема различных кибер атак и как от них защититься. Сегодня мы разберем такую тему, как side-channel атаки.
(Данный материал предлагается в образовательных целях и только в них, мы никого не призываем совершать подобного рода атаки)
Что такое Side-Channel атаки?
Side-Channel Attacks (SCA) — это атаки, которые используют косвенную информацию (побочные каналы), а не уязвимости в коде или протоколах. Злоумышленник анализирует физические параметры системы, такие как:
- Время выполнения операций (Timing Attacks)
- Электромагнитное излучение
- Потребление энергии
- Шум от работы жесткого диска (Да да, есть даже такой тип атак - акустический криптоанализ. Был прецедент, когда акустическая атака на RSA с помощью анализа ультразвука, издаваемого конденсаторами и катушками индуктивности, завершилась успешно. Можете почитать об этом на wikipedia)
- Кэш-память процессора (Cache Attacks)
Примеры SCA:
Spectre и Meltdown (2018): Эксплуатация спекулятивного выполнения процессоров для кражи данных из памяти.
CacheBleed (2016): Использование кэша для извлечения ключей шифрования.
Power Analysis: Анализ энергопотребления устройства при выполнении криптографических операций.
Хочу сам попробовать реализовать side-channel атаку!
Сейчас мы попробуем реализовать Side-Channel атаку через кэш браузера, который позволяет определить историю посещенных пользователем сайтов. Это возможно, потому что браузер кэширует ресурсы (изображения, CSS, JS), и время их повторной загрузки меньше, если они уже есть в кэше.
Как это работает? Не до конца понял.
- Пользователь посетил сайт example.com => его логотип (logo.png) сохраняется в кэше
- Злоумышленник создает страницу, которая пытается загрузить logo.png с example.com.
- Если время загрузки мало => ресурс есть в кэше => пользователь посещал example.com
- Успех! (Но не для нас….)
Этапы.
- Создадим простую web страницу, которая кидает fetch запросы на картинки с популярных соцсетей
2. Демонстрация
- Пользователь посещает vk.com → favicon.ico сохраняется в кэше.
- Затем открывает attacker.html.
- В консоли браузера злоумышленник видит:
Злоумышленник, добавив не 3 вебсайта для проверки, а 3 000 000, легко может понять, куда мы заходим, какими сервисами пользуемся. Эта информация в дальнейшем используется для продажи, и потом с целью рекламы именно тех сервисов и услуг, которыми вы интересовались.
Почему это Side-Channel Attack?
Побочный канал: Время загрузки ресурса.
Утечка данных: Информация о посещенных сайтах без прямого доступа к истории браузера.
Защита
Так, спасибо большое за такое интересную информацию, но как защититься от такого? Лично я не хочу, чтобы кто-то смотрел какие сайты я посещаю, это все-таки конфиденциальная информация. Не беда! Вот способы защиты от такого типа атак:
- Отключение кэша:
- На стороне сервера: Установите заголовки Cache-Control: no-store.
- В браузере: Используйте режим инкогнито.
- Блокировка сторонних запросов:
- Расширения вроде uBlock Origin или Privacy Badger.
Особенности облачных сред и контейнеров
Как Side-Channel Attacks угрожают облакам и контейнерам? Давайте рассмотрим особенности облаков и контейнеров.
Облачные среды:
- Мультитенантность: Физические ресурсы (CPU, память, сеть) делятся между множеством пользователей. К чему это может привести? К кэш-атакам - извлечению данных из кэша L1/L2/L3, к timing-атакам: измерение времени доступа к памяти.
- Виртуализация: Гипервизоры управляют виртуальными машинами (ВМ), но уязвимости в них (например, CVE-2018-3646 для гипервизоров) могут приводить к утечкам.
- Управляемые сервисы: Например, AWS Lambda, где пользователь не контролирует инфраструктуру.
Контейнеры (Docker, Kubernetes):
- Образы из ненадежных источников: Риск встроенных уязвимостей или малвари.
- Секреты в переменных окружения: Пароли, токены могут быть украдены через утечки.
- Изоляция через namespaces и cgroups: Слабее, чем у ВМ т.к. контейнеры делят ядро ОС. Приводит к тому, что можно анализировать данные в /proc (например, статистика использования CPU) или атака через eBPF - злоупотребление инструментами для мониторинга ядра.
Общие методы защиты для облаков & контейнеров
Для облачных сред:
Изоляция ресурсов:
- Используйте выделенные хосты (AWS Dedicated Hosts, Azure Dedicated Host).
- Включайте SGX (Intel Software Guard Extensions) для защиты данных в памяти.
Мониторинг аномалий:
- Инструменты вроде AWS GuardDuty или Google Cloud Security Command Center.
Шифрование данных:
- In-transit (TLS) и at-rest (AES-256).
Для контейнеров:
Запуск в sandbox-режиме:
- Можно использовать gVisor или Kata Containers для более мощной изоляции.
Сканирование образов:
- Инструменты Trivy, Clair, Anchore очень хорошо помогают с этим (Сам юзаю ежедневно).
Запрет root-доступа:
- Запускайте контейнеры с опцией --user nobody.
Seccomp и AppArmor:
- Ограничивайте системные вызовы для контейнеров.
Общие меры:
Обновления: Патчи для ядра, гипервизоров, ПО.
Минимизация шума: Отключите ненужные функции (например, гипертрединг).
Анализ уязвимостей CPU: Проверяйте модели процессоров на наличие дефектов (например, через MDS Scanner).
Лучшие практики
Для облака:
- Используйте multi-cloud стратегию, чтобы снизить риски провайдера.
- Включите контроль доступа на уровне ядра (например, SELinux).
Для контейнеров:
- Собирайте минималистичные образы (Alpine Linux).
- Храните секреты в vault (Hashicorp Vault, AWS Secrets Manager).