Post-Exploiting a Compromised ETCD

Каждый кто имел дело с тестированием Kubernetes, знает что etcd является одним из ключевых компонентов Control Plane любого кластера и практически каждая методология пентеста k8s описывает этот компонент, как хранилище секретов (паролей, API токенов, SSH ключей и пр)

etcd - это распределенное хранилище типа key-value, основанное на алгоритме консенсуса Raft 🤪, в котором хранятся секреты и метаданные о состоянии кластера, взаимодействие с которой осуществляется с помощью etcdctl по gRPC API протоколу protobuf, простыми словами данные передаются в сериализованном виде. Кстати, древние версии etcd вообще не предполагали аутентификацию, с etcd v2.1.0 (2015 год) подвезли Basic Auth по REST API. С точки зрения атакующего риски и потенциальные возможности чтения секретов в /registry/secrets/$namespace/$secret понятны и очевидны. А вот возможности пост-эксплуатации с точки зрения обеспечения закрепления в обход механизмов безопасности AdmissionControllers раньше даже не рассматривались😎

Предположим ситуацию, в ходе пентеста удалось найти серты для доступа к etcd или получить доступ каким-нибудь другим чудесным способом🔮

/etc/kubernetes/pki/etcd/ca.crt

/etc/kubernetes/pki/etcd/server.crt

/etc/kubernetes/pki/etcd/server.key

С помощью инструмента kubetcd, который по сути является оберткой над auger, который сериализует/десериализует данные etcd в protobuf можно автоматизировать пост-эксплуатацию:
☑️ Создавать новые привилегированные поды в обход политик безопасности Kyverno и пр.
☑️ Reverse shell на привилегированных подах с доступом на ноду
☑️ Изменять метаданные подов (время создания)
☑️ Закрепление через создание подов в default namespace (не видно через kubectl get pods)

Запись доклада автора инструмента Luis Toro Puig с KubeCon China 2023, слайды и статья c детальным описание функциональности