Вопрос или проблема
Я изучаю уязвимость CVE 2018-1002105, связанную с повышением привилегий в Kubernetes. Как удаленный неаутентифицированный пользователь, я хотел бы использовать сервер метрик, развернутый в моем кластере, для выполнения произвольных команд на любых подах.
Я довольно запутался, как это сделать. В настоящее время я отправил GET-запрос на kube api сервер, чтобы запросить обновление соединения до веб-сокета (CVE), а затем я использовал заголовок x-remote-header для выдачи себя за пользователя в кластере, который имеет доступ к серверу метрик (в данном случае я использовал X-Remote-User: system:serviceaccount:kube-system:horizontal-pod-autoscaler).
Тем не менее, я не могу выполнить команду exec, и я думаю, что причина в том, что у этого пользователя нет привилегий на выполнение команд. Как мне это проверить?
Я также подумываю о создании своего собственного пользователя с правами root, который сможет делать все, что он хочет в кластере, и выдать себя за него. Как мне это сделать и гарантировать, что у этого пользователя есть доступ к серверу метрик?
Итак, в первую очередь, вы не сможете использовать эту уязвимость без очень старой версии Kubernetes, так как она была исправлена в 2018 году. Из официального уведомления мы говорим о Kubernetes 1.12 на последней версии.
Способ, которым эта проблема эксплуатируется, описан довольно хорошо в этом блоге Unit42, и если вы ищете шаги и доказательство концепции, я сначала бы обратился к этому посту.
Путь атаки, который вы описываете, связан с агрегированными API-серверами, поэтому он применим только в том случае, если вы используете внешний агрегированный API сервер, такой как сервер метрик, и это было возможно, так как в те дни неаутентифицированные пользователи имели право делать запросы на открытие к агрегированным API серверам. Этот путь атаки был затвердын в 1.14, когда права неаутентифицированных пользователей к API-серверу были ограничены.
Чтобы ответить на некоторые другие касательные вопросы из вашего запроса. Лучший способ проверить свои права на кластер Kubernetes – это kubectl auth can-i --list, который вернет ваши права, определенные системой RBAC.
Если вы используете сервер метрик, развернутый в кластере Kubernetes, и у вас есть пользователь с правами cluster-admin (по сути, root), у него будут права изменять этот сервис, так как у него будут все права на рабочие нагрузки, развернутые в кластере.
Ответ или решение
Использование уязвимости CVE-2018-1002105 для повышения привилегий в Kubernetes
Ваша задача — изучить использование уязвимости CVE-2018-1002105 в Kubernetes для получения привилегий exec в кластере, на который у вас нет аутентифицированного доступа. Давайте детально рассмотрим описанные шаги и возможные подходы.
Понимание уязвимости
Важно отметить, что уязвимость CVE-2018-1002105 затрагивает проблемы с авторизацией для агрегации API-серверов. Эта уязвимость позволяет неаутентифицированным пользователям делать запросы к агрегированным API-серверам, что в основном применимо к старым версиям Kubernetes, выпущенным до версии 1.14. При использовании более новых версий Kubernetes эта уязвимость была устранена, и права неаутентифицированных пользователей были значительно ограничены.
Проверка текущих прав доступа
Чтобы проверить, какие права имеет ваш текущий пользователь, вам необходимо использовать команду:
kubectl auth can-i --listЭта команда покажет все разрешения, принадлежащие вашему пользователю, позволяя вам определить, есть ли у него доступ к запуску команд exec на подах.
Имитация пользователя с правами exec
Если текущий сервисный аккаунт (system:serviceaccount:kube-system:horizontal-pod-autoscaler) не обладает необходимыми правами exec, вы можете создать собственного пользователя с необходимыми привилегиями.
Создание пользователя с правами root
- Обращение к системе RBAC: Вам необходимо будет создать пользователя или сервисный аккаунт с ролью, которая включает права
execна подах. Это может быть сделано через манифесты YAML.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: <ваш-неймспейс>
name: exec-role
rules:
- apiGroups: [""]
resources: ["pods/exec"]
verbs: ["create"]- Создание сервисного аккаунта:
apiVersion: v1
kind: ServiceAccount
metadata:
name: exec-sa
namespace: <ваш-неймспейс>- Связывание роли с сервисным аккаунтом:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: exec-role-binding
namespace: <ваш-неймспейс>
subjects:
- kind: ServiceAccount
name: exec-sa
namespace: <ваш-неймспейс>
roleRef:
kind: Role
name: exec-role
apiGroup: rbac.authorization.k8s.ioПосле выполнения этих шагов, ваш сервисный аккаунт exec-sa будет иметь необходимые права exec, что позволит вам использовать его для выполнения команд в подах.
- Имитация нового пользователя: Теперь, используя ваш созданный сервисный аккаунт, вы сможете выполнять команды через API, имитируя его в заголовках запросов.
curl -X GET <API_SERVER_URL>/api/v1/namespaces/<ваш-неймспейс>/pods/<ваш-под>/exec?command=<ваша-команда>&container=<ваш-контейнер>&stdin=true&stdout=true&tty=true -H "Authorization: Bearer <TOKEN>"Заключение
Подводя итог, для успешного экрана и использования уязвимости CVE-2018-1002105, в первую очередь, убедитесь, что ваш кластер работает на старой версии Kubernetes, поскольку в новых версиях эта уязвимость была устранена. Следующее — проверьте свои права с помощью инструмента kubectl и создайте сервисный аккаунт, используя систему RBAC, с правами, необходимыми для выполнения команд exec. Этот процесс позволит вам преодолеть ограничения текущего пользователя и даст возможность управлять вашим кластером более эффективно.