banner website

Détection d’intrusion dans un environnement Kubernetes avec FALCO

Introduction

Selon le rapport du CESIN de Janvier 2022, 1 entreprise sur 2 a été victime d’une cyberattaque en 2021. Avec la pandémie, les cyberattaques ont littéralement explosé à travers le monde. Hausse régulière des ransomwares, exploitation de failles en tout genre… 

On observe même des mineurs de crypto-monnaies qui sont installés à l’insu des utilisateurs. Ils tournent parfois pendant des années avant d’être repérés ! C’est pourquoi la sécurité des applications et services est primordiale. D’après les analystes, cette tendance va s’accélérer. Il est donc essentiel de l’anticiper en élevant son niveau de sécurité.

En plus des bonnes pratiques mises en oeuvre lors de la phase de développement d’une application (code review, SAST, linters, etc) il est essentiel de déployer, un système de monitoring complet, et un système de réponse aux incidents

Regardons du côté de la détection d’intrusion dans un environnement Kubernetes.
Comment repérer une intrusion au sein des pods ?
Comment détecter des comportements alarmants lors du runtime ?

"La détection d’intrusion consiste à analyser les activités sur les applications et services déployés pour détecter tout comportement anormal."

Petit rappel sur la détection d’intrusion

Pour repérer ces tentatives d’intrusions sur des applications et des serveurs, la plupart des systèmes de détection d’intrusion d’hôtes se basent sur les appels systèmes de ces derniers.

Avec l’adoption croissante du Cloud et de la conteneurisation des applications, la détection d’intrusion a dû s’adapter à ces nouveaux environnements.

Sur Kubernetes, on retrouve notamment Falco, un outils open source qui a pour but de sécuriser le « runtime » du cluster, qu’il s’agisse des noeuds ou encore des applications déployées. 

Cas d’usage d’intrusion : le grand classique

Imaginons le scénario suivant :

  • Une application pour un site internet déployée dans un pod sur un cluster GKE,
  • Et un attaquant qui réussit à gagner l’accès au pod au travers d’une vulnérabilité sur le site internet.
  1. L’attaquant exploite une vulnérabilité du site pour communiquer avec le container (on parle de Command Injection) ;
  2. Il réussit à récupérer la clé privée d’un service account GCP monté sur le pod ;
  3. Grâce à des droits plus élevés que nécessaire associés au service account, l’attaquant peut désormais accéder à d’autres services : Cloud SQL, Buckets, etc.
  4. Après avoir mis la main sur les disques et les sauvegardes hébergées sur le projet, il chiffre toutes les données avec un ransomware.

Ce scénario peut sembler pessimiste si l’on regarde les prérequis nécessaires, pourtant les erreurs de configuration mentionnées sont relativement courantes :

  • Des vulnérabilités connues n’ont pas été détectées à cause d’un manque de scan de vulnérabilité dans la chaîne de déploiement ;
  • L’injection d’une clé privée d’un service account plutôt que l’utilisation d’un service comme Workload Identity ;
  • L’utilisation de services accounts par défaut possédant des privilèges bien plus élevés que nécessaires…

En quelques heures, l’attaquant passe d’une vulnérabilité sur un site internet, à un contrôle total des données de votre projet.

Tech Team

Voici à quoi pourrait ressembler ce scénario avec la matrice du framework Mitre ATT&CK :

Améliorer la détection avec Falco

Regardons ce que Falco peut nous apporter…
Falco est conçu pour repérer un certain nombre de cas inhabituels, tels que :

  • Élévation de privilèges ;
  • Lancement d’un terminal ;
  • Modifications de droits ;
  • Connexions réseaux ou mutations de socket inattendues…

Et bien d’autres.

"Falco va nous aider à surveiller nos conteneurs en utilisant les appels systèmes et en alertant lorsqu’une règle est enfreinte."

Reprenons notre scénario d’intrusion précédent et assumons que Falco est cette fois :

  1. Installé dans le cluster où l’application est déployée ;
  2. Configuré pour alerter via un channel Slack, tout comportement anormal sur ce cluster, notamment les accès aux fichiers des pods déployés.

Pour simplifier la démonstration, l’application web déployée se base sur l’image Damn Vulnerable Web Application Docker container, ce qui nous permet de simuler l’injection de commandes facilement.

Comme lors du scénario précédent, l’attaquant réussit à exploiter une faille sur le site web pour interagir directement avec le système du container et cherche à récupérer un éventuel service account. Après quelques minutes de recherches, il trouve le service account GCP monté sur le pod dans le dossier /var/run/secret/cloud.google.com :

				
					"type" : "service_account",
"project_id" : "      "
"private_key_id" : "     "
"private_key" : "-----BEGIN PRIVATE KEY ----- "     "
"client_email": "falco-demo    .iam.gserviceaccount.com",
"client_id": "118036766133618365248",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://oauth2.googleapis.com/token",
"auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
"client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/falco-demo%4    .iam.gserviceaccount.com"
				
			

Cependant, l’affichage du fichier déclenche cette fois-ci immédiatement l’alerte Falco, qui a été configurée pour détecter ce type de comportement :

affichage Falco

On voit ainsi que l’utilisateur apache “www-data” a accédé au fichier contenant la clé privée du service account GCP attaché au pod.

Grâce à cette réactivité, l’attaquant est stoppé et ne peut pas pivoter vers d’autres services GCP.

"Le fait d’être prévenu en temps réel va permettre de pouvoir agir rapidement et de révoquer la clé qui est maintenant compromise."

Conclusion

Nous avons pu observer l’importance et la nécessité de s’équiper d’un système de détection d’intrusion. Pour aller plus loin, il est tout à fait possible de visualiser les events sous forme de dashboards avec Grafana par exemple.
Mais le monitoring ne s’arrête pas à la détection et la visualisation, vient ensuite l’action de :

  • Stopper l’attaque,
  • Corriger la faille,
  • Vérifier les autres containers et applications et surtout…
  • Coupler la détection à un système de réponse aux incidents.

Références

Kubernetes
Kubernetes (K8S) est un système open-source permettant d’automatiser le déploiement, la mise à l’échelle et la gestion des applications conteneurisées.
https://kubernetes.io/fr/

Falco
Créé par Sysdig, Falco est un projet open source de la CNCF depuis 2018.
Il est le premier projet de sécurité d’exécution à rejoindre la CNCF en tant que projet de niveau incubation.
Falco agit comme une caméra de sécurité détectant les comportements inattendus, les intrusions et les vols de données en temps réel.
https://falco.org/

CNCF (Cloud Native Computing Foundation)
Projet de la Linux Foundation fondé en 2015, qui aide à faire progresser de nombreux projets open source comme Kubernetes, Prometheus et Envoy.
https://www.cncf.io/

Rapport du CESIN Janvier 2022
https://www.cesin.fr/actu-7eme-edition-du-barometre-annuel-du-cesin-enquete-exclusive-sur-la-cybersecurite-des-entreprises-francaises.html

Nous rejoindre

Faites partis de l’aventure OP-Rate en rejoignant une équipe avec des valeurs fortes de sens. Vous voulez en savoir plus sur nos offres, rdv juste ici 👇

ARTICLES

CONTACTER un expert