🛠IngressNightmare или как снова что-то нашли

Всем привет, и да, я снова тут с постом, который никто особо не ждал, ведь выше есть пост, но пройти мимо такой темы я не смог. Сегодня расскажу более подробно про свежий и крайне неприятный инцидент в Kubernetes-мире.

❓Что стряслось и почему все в панике

Короче, ребята из Wiz недавно нашли серию критических уязвимостей в контроллере Ingress-NGINX для Kubernetes. Назвали это всё красиво и драматично – IngressNightmare. И поверьте, название выбрали неспроста: если коротко, то это пять CVE, из-за которых атакующий может спокойно выполнить код на ingress-контроллере и буквально угнать весь кластер со всеми секретами. И самое весёлое, что атакующему даже не нужны учётные записи или пароли, хватит одного кривого HTTP-запроса.

🔍 Технические подробности для тех, кто любит копаться в кишках

Суть этих уязвимостей кроется в недостаточной проверке входящих данных, которые разработчики Ingress-NGINX радостно вставляли напрямую в конфиги NGINX. Из-за этого через безобидные, казалось бы, аннотации (auth-url, auth-tls-match-cn, mirror-target) можно было внедрить произвольные директивы. Ну, например, какую-нибудь такую прелесть:

ssl_engine /tmp/malicious.so;

Именно это использовали исследователи Wiz в своём PoC. Ты просто отправляешь HTTP-запрос с большим телом, NGINX сохраняет это тело как временный файл, а потом через специальный AdmissionReview-запрос (без аутентификации!) загружает твою вредоносную .so библиотеку. И всё, поздравляю, теперь ты внутри контейнера с контроллером. Дальше читаешь секреты, токены и вообще делаешь, что хочешь.

‼️ Кто в опасности и как проверить себя любимого

Если ваша версия Ingress-NGINX ниже v1.12.1 (а ещё 1.11.5 и 1.10.7), то у вас серьёзные проблемы:
🔵 Узнать текущую версию можно через:

kubectl -n ingress-nginx get deploy ingress-nginx-controller -o=jsonpath='{.spec.template.spec.containers[0].image}'

🔵 Или через GitLab, найдя в манифестах YAML или Helm-чартах строку:

image: ingress-nginx/controller:v1.12.0

❔ Как с этим жить дальше

Что делать, если вы попали в этот клуб неудачников с уязвимой версией:

1. Срочно обновляйтесь до v1.12.1;

2. Пока не обновились, отключите admission-контроллер (controller.admissionWebhooks.enabled=false);

3. Ограничьте доступ к admission webhook с помощью Network Policy. Только API-сервер должен туда стучаться;

4. Просмотрите audit-логи Kubernetes и ищите подозрительные Ingress’ы с странными аннотациями.

Если вы не можете обновиться сразу (а кто из нас может?), хотя бы проверьте, что webhook не светит в интернет. В Wiz уже подсчитали, что около 6500 кластеров с открытым admission webhook доступны снаружи. Возможно, среди них есть и ваш.

👀 Личное мнение и мораль всей басни

Вот казалось бы, мелочь – не проверить пару строк кода, не закрыть пару портов, но в итоге получаешь катастрофу, достойную отдельного поста в моём канале. В очередной раз понимаешь, насколько всё хрупко и насколько важна роль команд AppSec и DevSecOps в крупных компаниях. В общем, проверьте свои кластеры, обновитесь и берегите нервы, они вам ещё пригодятся.

Спасибо, что дочитали мой очередной маленький монолог. Обещаю, скоро вернусь с чем-нибудь менее трагичным.

#devsecops #appsec