Est ce qu’avoir un cluster exposé suffit à être vulnérable à IngressNightmare ? En fait ça dépend.
Alors qu’est ce qui fait qu’on est vulnérable et surtout, qu’est ce qu’il faut patcher en premier ?
Lorsque la faille IngressNightmare a été médiatisée, j’ai cru au début qu’il suffisait d’un accès à un endpoint HTTP derrière un nginx dans kubernetes pour risquer de se faire attaquer. Mais en fait pas exactement.
C’est plus compliqué mais c’est surtout une faille moderne, dans le sens où elle implique une chaînes de plusieurs problèmes qui n’ont pas l’air si graves pris un à un.
Attention je n’ai pas dit qu’il ne faut rien faire ! Je veux surtout que vous compreniez la faille pour être en mesure de la corriger efficacement.
Comme toujours, vous pourrez télécharger les exemples et tester chez vous pour mieux comprendre comment ça marche.
— Chapitres —
00:00 Intro
00:17 Exemple avec k3s
04:05 Le mystérieux Ingress Controller
08:56 L’Admission controller, oublié dans l’API
15:19 C’est quoi le problème avec nginx alors ?
22:51 Une injection pour executer du code
28:47 Il reste une librairie à uploader…
33:54 remédier pour de bon
Liens :
L’article de la faille : https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities
Les manifest dans k3s (on s’en lasse pas) : https://docs.k3s.io/installation/packaged-components
Vagrant : https://developer.hashicorp.com/vagrant
nginx ingress controller : https://docs.nginx.com/nginx-ingress-controller/
Doc nginx du paramètre client_body_in_file_only : https://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_in_file_only
Top comments (0)