SSTIC 2020 – JOUR 3

SSTIC 2020 – JOUR 3

Comme tous les ans, XMCO vous propose une revue de certaines conférences du SSTIC.

Introduction

Le SSTIC, Symposium sur la Sécurité des Technologies de l’Information et des Communications, est une conférence francophone réputée pour la qualité technique des sujets présentés.

L’édition du SSTIC a pris cette année une tournure très spéciale. En raison de la crise COVID-19, les conférences ont été enregistrées en amont et sont diffusées en direct et gratuitement en ligne.

Pour maintenir une interactivité malgré tout, les organisateurs ont également mis en place un chat IRC permettant de poser des questions aux conférenciers au cours de l’évènement.

Comme tous les ans, XMCO a suivi cette conférence et vous propose un résumé tous les jours de quelques conférences choisies parmi celles diffusées dans la journée. Ces dernières seront également regroupées au sein de notre prochain numéro d’ActuSecu.

Références SSTIC :

 

Finding vBulletin 0-days through poor man’s symbolic execution, Charles Fol

Contexte

Charles Fol de la société Lexfo a démarré la 3e et dernière journée du SSTIC en présentant la méthode qu’il a suivie pour identifier des vulnérabilités d’injection SQL sur le produit vBulletin (cf. Une vulnérabilité critique affectant les forums vBulletin a été corrigée).

vBulletin est un forum payant implémenté en PHP. Ses fonctionnalités vont même au-delà du simple Board ; il peut être classé comme un CMS aujourd’hui.
Ce produit a été sujet à 34 CVE depuis 2008, dont 10 vulnérabilités publiques liées à des injections SQL, motivant le conférencier dans ses recherches. Une vulnérabilité avait également fait grand bruit en 2019, puisqu’elle menait à une exécution de code à distance sans authentification préalable (CVE-2019-16759).

Charles Fol a d’abord rappelé l’architecture logicielle de vBulletin partant des points d’entrées utilisateur (requêtes HTTP) aux requêtes SQL en elles-mêmes.

  1. Les entrées utilisateur sont d’abord collectées par une API (sous /ajax/api//?params).
  2. L’API exploite des bibliothèques, gérant des catégories de données par des classes dédiées.
  3. Ces bibliothèques manipulent des données au travers de QueryDefs, méthode permettant de construire des requêtes SQL.
  4. Enfin, les requêtes SQL sont exécutées sur le moteur de base de données.

Le conférencier a pu identifier plus de 1000 références de méthode d’API, plus de 850 références de méthode de bibliothèque et plus de 250 références de méthode QueryDefs. Devant le nombre de combinaisons possibles est venue la nécessité de développer un script pour une analyse automatique afin d’identifier des injections.

 

Outils développés

Deux outils ont été développés pour l’analyse. Ceux-ci n’ont pas encore été publiés par leur auteur.

Le premier outil de type Static Taint Analysis permet d’identifier des variables de QueryDefs contrôlables par un utilisateur externe via les paramètres d’API. Pour ce faire, il convertit le code PHP en arbre de syntaxe abstraite (AST) puis parcourt toutes les branches pour sortir une liste de valeurs contrôlées. 345 entrées utilisateur contrôlables ont été identifiées au sein de 245 QueryDefs.

Le deuxième outil est utilisé pour vérifier l’exécution symbolique, en vérifiant la présence effective et le type des paramètres, puis en reconstruisant la requête complète. Les types sont listés et l’exploitabilité des paramètres est vérifiée (contrôle / échappement ou non).

Ces outils ont permis d’identifier 2 résultats exploitables d’injection SQL, dont une vulnérabilité exploitable sans authentification préalable. Cette vulnérabilité est référencée CVE-2020-12720. Les paramètres concernés sont listés en capture suivante.


Article_1(1)
Source de vulnérabilité d’injection SQL identifiée grâce à l’outil présenté
source : sstic.org
 

Enfin, Charles Fol a proposé une méthode pour obtenir de l’exécution de code arbitraire en exploitant l’injection SQL identifiée.

Pour transformer la vulnérabilité en exécution de code à distance, l’attaquant réalise une résiliation du mot de passe d’un administrateur. Il récupère le jeton de lien de changement de mot de passe en base de données grâce à l’injection SQL. Une fois administrateur applicatif, il lui est possible d’obtenir de l’exécution de code en téléversant un nouveau module sur le CMS vBulletin.

 

Sécurité des infrastructures basées sur Kubernetes, Xavier Mehrenberger

Contexte

Au cours de la seconde conférence, Xavier Mehrenberger établit un état de l’art des meilleures pratiques de sécurisation d’un cluster Kubernetes. Kubernetes, ou k8s, est une solution populaire d’orchestration de conteneurs, répondant aux besoins de mise à l’échelle et de maintien d’une infrastructure distribuée.

Le conférencier profite de la première partie de sa présentation pour revenir sur la définition des composants principaux d’un cluster Kubernetes. On peut citer parmi ceux-ci :

  • un Node, qui désigne une machine physique ou virtuelle hébergeant un composant applicatif ;
  • un Pod, qui désigne un ensemble de conteneurs s’exécutant sur un Node ;
  • un Service, qui permet de rendre l’application accessible par le réseau ;
  • un Kubelet, qui désigne l’agent s’exécutant sur chaque Node pour gérer le lancement et la configuration des Pods ;
  • l’API Server, composant central du cluster qui expose les éléments de configuration aux différents Kubelets présents dans l’infrastructure. L’API Server réalise l’interface avec le support de stockage etcd, distribué au sein du cluster.

 

Axes de durcissement

Par la suite, Xavier Mehrenberger énonce une série de points de contrôle propres à la solution Kubernetes en vue d’améliorer la sécurisation d’un cluster. Nous détaillons dans la suite de cet article certains de ces points.

Durcissement du système d’exploitation

Étape indispensable sur tous les types d’infrastructure applicative, la phase de durcissement du système doit comporter :

  • un travail de veille en vulnérabilités et de mise à jour des composants utilisés ;
  • une revue des privilèges, aussi bien au niveau des comptes locaux et comptes applicatifs qu’au niveau de la plateforme d’hébergement ;
  • l’application de règles de pare-feu pour les services locaux.

Gestion des secrets

Une étape importante consiste à recenser l’ensemble des secrets utilisés au sein de l’infrastructure (tels que les comptes applicatifs ou les secrets d’authentification) en vue de configurer leurs paramètres de sécurité. Parmi les recommandations énoncées, on distingue :

  • l’utilisation d’objets de type Secret. Ceux-ci permettent de stocker les secrets de manière chiffrée au sein de la mémoire distribuée etcd du cluster.
  • la revue de configuration d’une éventuelle application de gestion des secrets, telle que HashiCorp Vault par exemple.

Règles de filtrage réseau

En supplément des règles de base de filtrage par pare-feu, Kubernetes propose des objets NetworkPolicies qui décrivent des règles déclaratives à appliquer selon les types de composants. Il est par exemple recommandé d’interdire aux Pods ou au composant Scheduler de contacter directement le support de stockage etcd. L’accès à ce stockage doit impérativement être délégué à l’API Server.


Article 2 - 1
Représentation de configuration de filtrage réseau recommandée
(source: sstic.org)

Configuration de l’API Server

La configuration par défaut de l’API Server ne respecte pas les Meilleures Pratiques de sécurité, ce qui représente un risque pour l’infrastructure. Le conférencier recommande ainsi :

  • de désactiver l’authentification anonyme via l’option –anonymous-auth=False ;
  • d’appliquer la propriété NodeRestriction, qui empêche tout Kubelet d’effectuer des modifications sur un Node différent de celui sur lequel il s’exécute.

Activation de la Propriété SecComp

La propriété SecComp permet de définir une liste blanche des appels système autorisés. Activée par défaut sur Docker, mais désactivée par Kubernetes, cette propriété peut être définie au niveau d’un Pod ou à l’échelle du cluster.

Revue des autorisations

La réalisation d’une revue des autorisations d’un cluster Kubernetes passe par l’analyse des objets Roles et RoleBindings. Les Roles définissent des jeux d’actions autorisées, qui sont liés à un profil via les objets RoleBindings. Une liste de l’ensemble de ces objets suivie d’une analyse des chemins d’attaque permet ainsi de déterminer les risques de compromission du cluster et d’y répondre de manière adéquate.

Gestion des images

L’utilisation de conteneurs implique l’apparition de risques inhérents à la provenance des images utilisées. Ainsi, Xavier Mehrenberger préconise de n’utiliser que des images signées par des éditeurs de confiance, et de s’assurer de la sécurité des dépôts d’où proviennent ces images.

 

Conclusion

Le conférencier termine sa présentation en recommandant l’utilisation d’outils d’analyse automatique tels que kubesec et kube-bench.

En complément de cette présentation, XMCO vous recommande de visionner la conférence SSTIC diffusée ce même jour Process level network security monitoring and enforcement with eBPF (Guillaume Fournier) présentant un outil de filtrage fin d’un point de vue réseau et DNS.

Enfin, XMCO vous recommande également la lecture du dossier consacré à Kubernetes au sein de l’ActuSécu #51.

 

MI-LXC: Une plateforme pédagogique pour la sécurité réseau, Francois Lesueur

Francois Lesueur, maître de conférences à l’INSA Lyon, présente MI-LXC (Mini-Internet using LXC), un support pédagogique aidant à la formation à la sécurité des réseaux.

LXC pour Linux Containers est un système de virtualisation permettant de déployer un environnement de plusieurs machines virtuelles à partir d’un même noyau Linux.

 

Réalisations

Les travaux réalisés par le conférencier comportent en premier lieu la création d’un framework permettant de déployer et de configurer une infrastructure simulant un Internet de petite taille. Le framework est accompagné d’une infrastructure de base qui peut être utilisée dans le cadre de travaux pratiques d’enseignement. Basée sur l’utilisation de conteneurs Linux LXC, cette infrastructure comporte :

  • 11 autonomous system (AS) dont le routage est préconfiguré avec le protocole BGP ;
  • un serveur racine DNS accompagné d’un serveur DNS secondaire ;
  • une autorité de certification basée sur l’implémentation ACME de Let’s Encrypt ;
  • un réseau d’entreprise volontairement vulnérable ;
  • un poste dédié à la réalisation des attaques.


Article_3(1)

Topologie de l’infrastructure de base de MI-LXC
(source: sstic.org)
 

François Lesueur revient sur le framework qu’il a développé. Ce framework est composé de fichiers de configuration JSON accompagnés de scripts Bash à exécuter pour déployer les différents conteneurs et appliquer leur configuration.

 

Travaux pratiques

En seconde partie de sa présentation, le maître de conférences détaille trois exercices qui ont été développés et intégrés à ce projet.

TP implémentation HTTPS

Cet exercice propose de rejouer l’ensemble de la chaîne de création d’une nouvelle autorité de certification, jusqu’à l’installation du nouveau certificat racine sur une machine grand public. L’exercice comporte également une partie consistant à réaliser une attaque sur le protocole BGP dans le but d’ajouter un certificat illégitime au sein de l’autorité de certification.

TP tests d’intrusion

Cet exercice consiste à suivre les étapes de compromission du réseau d’une entreprise. Il comporte 4 parties orientées respectivement exploitation Web, social-engineering, élévation de privilèges et de mouvements latéraux et verticaux (techniques de pivots).

TP Segmentation réseau

Ce dernier exercice fait suite à l’exercice d’intrusion. Il propose de découvrir les fonctionnalités du pare-feu Linux iptables dans le but de corriger les défauts de segmentation précédemment identifiés.

 

Conclusion

François Lesueur conclut sa présentation en précisant les points forts de son projet, ainsi que ses axes d’amélioration. Ses travaux présentent l’avantage de proposer une architecture complexe légère et facile à déployer, qui peut être exécutée sur toute machine grand public. Enfin, il propose d’intégrer des scénarios d’attaque supplémentaires ainsi que de diversifier les technologies intégrées à son architecture pour les futures étapes de son projet.

La page de ce projet est accessible sur le lien suivant :

 

Que faut-il attendre de DNS-over-HTTPS?, Francois Contat, Grégory Bénassy, Julien Buttin Le Meur, Olivier Levillain

 

Contexte

Le service DNS permet d’effectuer la résolution des domaines en adresse IP.

Pour démarrer la présentation, Olivier Levillain d’abord rappelé la problématique sécurité d’implémentation du protocole DNS : les communications avec le serveur DNS sont réalisées en clair sur le réseau. De fait, le fournisseur d’accès à Internet, ou toute personne en capacité d’écoute passive est capable de connaître le détail des domaines contactés par un utilisateur.

Pour pallier ce problème, deux protocoles sont disponibles :

  • DNS over TLS, ou DoT (RFC7858). Par construction, le protocole DNS est encapsulé au sein de la couche chiffrée TLS. Ceci nécessite l’utilisation d’un nouveau port (853).
  • DNS over HTTPS, ou DoH. Celui-ci a l’avantage de réutiliser le port Web standard (443).

Mozilla et Google ont fait le choix d’intégrer DoH au sein de leurs navigateurs Firefox et Chromium.

 

Expérience

Lorsque des résolutions de noms sont réalisées localement, au sein de réseaux internes, DoH présente le risque d’exfiltration de données vers un serveur DNS hors du réseau, placé sur Internet.

Article 4
Risque d’exfiltration de données DNS locales vers un serveur DNS tiers via DoH
(source : sstic.org)
 

Une plateforme de tests a été mise en place via des conteneurs, pour des versions Firefox 59 à 76 sous Debian. Sur Windows, des versions Chromium de 78 à 81 et Firefox 76 ont été déployées sur cette même plateforme. Ainsi, les chercheurs étaient en mesure :

  • d’inspecter les échanges effectués en sorties des instances ;
  • de modifier la configuration locale des navigateurs.

Cette étude s’attache à vérifier que les implémentations de DoH au sein des navigateurs ne présentent pas de risques de sécurité. Les chercheurs ont réalisé diverses tentatives de connexion et observé les résultats obtenus pour chacun des navigateurs.

 

Résultats

Firefox

Les tests réalisés sur l’implémentation de DoH dans Firefox révèlent des défauts importants :

Firefox propose 5 modes de fonctionnement de DoH différents. Parmi ces 5 modes, 2 ne sont plus supportés depuis la version 76 de Firefox (mode 1 et mode 4), ce qui résulte en un basculement vers le protocole DNS en clair.

Cependant, lorsque l’un de ces 2 modes est activé par l’utilisateur, l’interface graphique de Firefox affiche une case cochée indiquant à tort que DoH est activé. L’utilisateur est donc induit en erreur en pensant que son trafic DNS est effectivement chiffré alors que ce n’est pas le cas.

Un autre paramètre de configuration locale est dédié à la désactivation de DoH si la connexion passe par un VPN ou un proxy. Néanmoins, l’analyse rapportée par les conférenciers révèle que ce paramètre est actuellement ineffectif sur la version Linux du navigateur.

De plus, sur présentation d’un certificat de serveur DoH invalide, Firefox réagit en basculant vers une connexion DNS standard en clair sans prévenir l’utilisateur.

Cependant, Firefox présente l’avantage de rendre configurables les paramètres de DoH via la configuration locale. Parmi ces paramètres, excluded-domains permet de désactiver DoH pour certains domaines spécifiques. Ce paramètre peut être utilisé pour se prémunir des risques d’exfiltration de données expliqués en début de la partie précédente.

 

Chromium

Chromium embarque par défaut une liste de serveurs DoH connus. Depuis la version 80, toute requête transmise à l’un de ces serveurs résulte en un basculement automatique vers le protocole DoH.

Chromium proposera à ses utilisateurs de paramétrer DoH à partir de sa version 83. Les résultats des tests indiquent que le navigateur se comporte de la manière attendue, sans nécessiter d’action de la part de l’utilisateur.

Enfin, tout comme Firefox, Chromium réagit à la présentation d’un certificat DoH invalide en basculant vers une connexion DNS en clair sans prévenir l’utilisateur.

 

Conclusion

Bien que la sécurisation de DNS relève d’une problématique d’importance, l’implémentation actuelle de Firefox est affectée de défauts impactant son bon fonctionnement et la transparence à ses utilisateurs. De plus, Firefox et Chromium partagent tous deux l’inconvénient de basculer sur le protocole DNS non chiffré sans prévenir les utilisateurs, ce qui présente encore un risque inhérent à la protection de la vie privée.


Arthur Gautier