DEV Community: Bilal Benamrouche

Troubleshooting Rancher Cluster Agent Issue

Bilal Benamrouche — Thu, 26 Oct 2023 13:28:13 +0000

Rancher is a popular Kubernetes management platform that simplifies the deployment and management of Kubernetes clusters. Rancher offers built-in monitoring capabilities to help you gain insights into your cluster's performance and health. However, like any software, issues may arise. In this document, we'll explore one main problem encountered when upgrading a cluster related to Rancher, which is Cluster Agent is not connected and how to troubleshoot it.

Rancher Cluster Agent Issues
In this case, when trying to upgrade the cluster in Rancher to a newest version of kubernetes using terraform, the cluster enters to an unavailable state and our upgrade ends with error, so we must solve this issue to continue.

The error was that the cluster_agent component was not connected.

1. Troubleshooting Steps
In order to resolve the issue we passed several steps of troubleshooting:

1.1. Verify that the Rancher cattle-cluster-agent deployment in your cluster is running:

kubectl get deployments cattle-cluster_agent -namespace cattle-system -o yaml

The result shows that the pods in the deployment cattle-cluster agent were correctly in the state running 😟 .

1.2. Lets now check the logs of the cluster agent pods:

kubectl logs cattle-cluster-agent-748cc64689-kr6k8 -n cattle-system

INFO: Using resolv.conf: search cattle-system.svc.cluster.local svc.cluster.local cluster.local nameserver xxxxxxxx options ndots:5
INFO: https://rancher.k3s.cn/ping is accessible
INFO: rancher.k3s.cn resolves to xxxxxxxx
INFO: Value from https://rancher.k3s.cn/v3/settings/cacerts is an x509 certificate
time="2023-09-21T10:51:09Z" level=info msg="Listening on /tmp/log.sock"
time="2023-09-21T10:51:09Z" level=info msg="Rancher agent version v2.6.13 is starting"
time="2023-09-21T10:51:09Z" level=info msg="Connecting to wss://rancher.k3s.cn/v3/connect/register with token starting with xxxxxxxxxxxx"
time="2023-09-21T10:51:09Z" level=info msg="Connecting to proxy" url="wss://rancher.k3s.cn/v3/connect/register"
time="2023-09-21T10:51:09Z" level=info msg="Starting /v1, Kind=Service controller"

So, the logs does not really show a significants informations to resolve the issue 😟.

1.3. We must understand how the cattle-cluster-agent works and how it must be deployed on the cluster. To find that, we check the documentation on Rancher and we found that the cattle-cluster-agent deployment uses a set of tolerations to be deployed on master node and not a worker node, these tolerations on cattle-monitoring-system deployment will dynamically trigger and take the same tolerations based on taints used on master nodes of the cluster and it must be deployed on these master nodes. Otherwise the cattle-cluster-agent deployment will be deployed with a default tolerations:

1.4. If we check the pods of our cattle-cluster-agent deployement:

kubectl get pods -n cattle-system -o wide

We see that cattle-cluster-agent is deployed on the worker nodes not on the master nodes and if we check the toleration present on the deployment, we found the default tolerations, we talked about in 1.3, and not the tolerations based on taints of our master nodes.

The tolerations on the deployment:

      - effect: NoSchedule
        key: node-role.kubernetes.io/controlplane
        value: "true"
      - effect: NoSchedule
        key: node-role.kubernetes.io/control-plane
        operator: Exists
      - effect: NoSchedule
        key: node-role.kubernetes.io/master
        operator: Exists

Tolerations based on taints present on the master nodes:

        - effect: NoSchedule
          key: node-role.kubernetes.io/controlplane
          value: "true"
        - effect: NoExecute
          key: node-role.kubernetes.io/etcd
          value: "true"

So this is why our cattle-cluster-agent deployment is considered as unconnected, when we modify the cluster for the upgrade, the cluster-agent is not triggered dynamically with the correct tolerations to be deployed on the master nodes 👌.

2. Solutions

To resolve this problem, we consider two suggestions:

2.1. Now we know that the cattle-cluster-agent deployment must trigger on the taints present on the master nodes. To do that, we apply a new taint on all the master nodes (in our case three master nodes):

     kubectl taint nodes master-km01 test=true:NoSchedule
     kubectl taint nodes master-km02 test=true:NoSchedule
     kubectl taint nodes master-km03 test=true:NoSchedule

wait a few seconds and we check the cattle-cluster-agent again, we see that the deployment is now trigger on the tolerations of the master nodes and it is running on the them:

        - effect: NoSchedule
          key: test
          value: "true"
        - effect: NoSchedule
          key: node-role.kubernetes.io/controlplane
          value: "true"
        - effect: NoExecute
          key: node-role.kubernetes.io/etcd
          value: "true"

And the cluster is now on the active state:

After that we can remove the added taint with:

     kubectl taint nodes master-km01 test=true:NoSchedule-
     kubectl taint nodes master-km02 test=true:NoSchedule-
     kubectl taint nodes master-km03 test=true:NoSchedule-

2.2. Before modifying the cluster for upgrade, make sure to ignore the import manifest of the cattle-cluster-agent deployment so it will not be re-installed. In our case using terraform, we have to comment the line on terraform code which is responsible of the import manifest and apply the terraform after:

#rke_addons =https://url_to_your_manifest/v3/import/xxxxxxxxxxx_c-jpg8f.yaml

3. Conclusion
Troubleshooting Rancher Cluster Agent issue can be challenging, but by following the steps outlined in this document, you can identify and resolve common problems that may arise. If the issues persist, consider consulting Rancher's official documentation or seeking help from the Rancher community for more specific guidance.

Thanks for reading! I’m Bilal, Cloud DevOps consultant at Stack Labs.
If you want to join an enthusiast Infra cloud team, please contact us.

SSTIC 2022 - Symposium sur la sécurité des technologies de l'information et des communications

Bilal Benamrouche — Fri, 17 Jun 2022 09:52:58 +0000

Dans cet article, nous allons vous résumer quelques présentations de la conférence SSTIC, Symposium sur la sécurité des technologies de l'information et des communications, qui a eu lieu à Rennes du 1er au 3 juin 2022.

Building Open Security Tooling For Fun & Profit (Conférence d'ouverture) - Colin O'Flynn

La conférence SSTIC commence son premier jour par la présentation de Colin O’Flynn sur les outils open source utilisés dans la sécurité matérielle. Cette présentation nous parle de travaux actuels et futurs dans le domaine de l'outillage de sécurité matérielle, y compris des projets tels que l'analyse de puissance et l'outillage d'injection de fautes.

Les différents points de la présentation portaient sur :

Les outils de sécurité matérielle open source

Dans cette partie des solutions académiques matérielles de test et d’analyse sont présentées. Ces outils permettent de faire (comme exemple) l’analyse side channel d’un dispositif cryptographique AVR XMEGA.

On y présente notamment ChipWhisperer, un outil d’attaque side channel sur les dispositifs embarqués permettant de valider la résistance de ces systèmes embarqués à des attaques. En particulier, ChipWhisperer se concentre sur l'analyse de la puissance qui utilise les informations récupérées par la consommation d'énergie d'un dispositif pour mettre en oeuvre une attaque, mais également sur les attaques de tension et d'horloge qui perturbent brièvement l'alimentation ou l'horloge d'un dispositif pour provoquer un comportement involontaire (comme bypasser une vérification de mot de passe).

https://github.com/newaetech/chipwhisperer

On établit également une comparaison entre le coût de développement de ces outils et le bénéfice de lancer des affaires en les commercialisant.

Outils de sécurité, nouvelle génération

OpenTitan

OpenTitan est le premier projet open source qui élabore un modèle de référence transparent et de haute qualité ainsi que des directives d'intégration pour les puces RoT (root of trust) en silicium.

https://opentitan.org/

PicoEMP - Open Source EMFI

L’une des méthodes de vérification de fiabilité matériel est l’injection de faute qui permet d’injecter des données dans le dispositif matériel, voir son comportement et décider s'il est robuste aux défauts ou pas. Un outil qui permet de faire de l’injection de fautes est présenté dans cette partie, il s’agit d’une bobine contrôlée à l’aide de matériels électronique (Ras-Pi). Il permet d’envoyer dans la bobine du courant électrique dans le but de générer un champ magnétique avec lequel on pourra injecter des fautes dans le dispositif cible.

https://github.com/newaetech/chipshouter-picoemp

Analyse de consommation énergétique

Une autre méthode présentée, elle permet également d’analyser la fiabilité d’un système matériel, il s’agit de l’analyse de consommation. Cette méthode permet de comparer la consommation du système en fonction des calculs et les algorithmes cryptographiques utilisés et essayer d’en déduire des informations utiles pour le déchiffrement.

La conférence est conclue par une démo sur le dispositif d’injection de fautes.

https://static.sstic.org/videos2022/1080p/ouverture_2022.mp4

Smartphone et forensique : comment attraper Pegasus for fun and non-profit - Etienne Maynier

Etienne Maynier est chercheur pour le programme d’Amnesty Tech, filiale d’Amnesty International constituée d’avocats, de hackers et de chercheurs en sécurité

Dans cette présentation, Etienne Maynier, nous présente son approche forensic sur le logiciel Pegasus, un outil d’espionnage développé par NSO Group. Ce logiciel est l’un des plus employés par certains pays et entités juridiques afin d’obtenir des informations par des moyens douteux (utilisation massive de vulnérabilités 0-day). Il a été utilisé par exemple dans l’affaire d’Ahmed Mansoor, blogueur activiste émirien des droits de l’homme condamné à 10 ans de prison ferme pour atteinte à la sécurité de l’état.

Le projet donne naissance au Mobile Verification Toolkit, un framework permettant d’automatiser le processus de récolte de traces forensic d’éventuelle infection par Pegasus. Les traces incluent notamment :

les liens malveillants reçus par SMS sur le téléphone de la victime
Historique de navigation permettant de détecter les attaques par redirection d’url
Logs réseau du téléphone : ces logs permettent de faire le lien entre un processus et son utilisation du réseau (ces logs on permis d’établir une liste de noms de process Pegasus),
ID status Cache : contient des traces du compte iCloud qui a intéragi avec le téléphone, ce qui permet de découvrir les compte iCloud de NSO Group ainsi que de pouvoir avoir le nom de leurs clients,

MVT permet de construire une timeline des attaques afin de mieux comprendre les différents schémas d’attaque utilisés par NSO Group.

Cet outil a permis de lever le voile sur la vulnérabilité Megalodon et son exploitation sur iPhone ainsi que de mieux comprendre l’utilisation de Pegasus à des fins d’espionnage.

https://static.sstic.org/videos2022/1080p/smartphone_et_forensic__comment_attraper_pgasus_for_fun_and_non-profit.mp4

Analyse forensique de la mémoire de GnuPG - Nils Amiet & Sylvain Pelissier

GnuPG est l’implémentation GNU du standard OpenPGP. Cet outi permet la transmission de messages signés et chiffrés permettant de garantir l’authenticité, l’intégrité et la confidentialité.

La présentation est focalisée sur l’analyse forensique de GnuPG (GPG). L’agent gpg-agent permet de mettre en cache les mots de passe dans le but de faciliter et minimiser les accès mémoire et gagner en temps d’exécution. Dans un premier temps, ce travail met en évidence un problème de nettoyage de la mémoire de libgcrypt, qui permet de lire 8 octets du mot de passe dans le cache de GPG. Ensuite, il démontre des techniques générales pour récupérer les mots de passe complets dans le cache de GPG à partir d'une image de la mémoire de gpg-agent ou du système complet. Pour démontrer leur travail, deux modules d'extension pour Volatility sont fournis, ils permettent de récupérer un mot de passe stocké dans le cache de GPG.

Dans cette présentation le chiffrement AES est utilisé avec une fonction de dérivation de clés. Ces clés sont stockées en mémoire. Avec l’image mémoire, le but est de retrouver l’ensemble de clés stockées en mémoire et ensuite les utiliser avec l’outil Volatility, un outil open source pour l'extraction l'extraction d'artefacts numériques à partir d'échantillons de mémoire volatile (RAM), afin de récupérer les mots de passe (démo dans la vidéo).

https://static.sstic.org/videos2022/1080p/gnupg_memory_forensics.mp4

Surface d’attaque des solutions Active Directory Self-Service

Antoine Cervoise et Wilfried Becard ont présenté plusieurs vulnérabilités et scénarios d’attaque sur les solutions AD Self Service.

Certaines entreprises ont recourt à ces services d’AD Self Service (abrévié ADSS) **afin de permettre à leurs employés de réinitialiser leur mot de passe de manière autonome.

L’ADSS permet de réduire le nombre d’appels au support, de fluidifier le processus de réinitialisation et permet ainsi pour l’entreprise de réduire le coût du support. On peut également lister d’autres avantages comme le fait de pouvoir réinitialiser le mot de passe même si le support est fermé ou encore de réinitialiser son mot de passe sans être connecté aux infrastructures de l’entreprise en exposant la solution sur internet.

Architecture d’un ADSS

Voici l’architecture type d’un ADSS :

Le serveur de la solution ADSS héberge une application Web qui possède un compte de service ainsi qu’un compte du domaine qui lui permet de réinitialiser les mots de passes des utilisateurs.

Le client peut être un client lourd, un navigateur ou un mobile.

Surface et scénario d’attaque

Voici la surface d’attaque d’un ADSS :

Client lourd pré-authentifié
Process de déploiement des clients lourds
Application web qui a accès à un compte privilégié de l’AD

Et les scénarios d’attaque envisagés :

Client lourd
- Attaquant avec un accès physique à l’ordinateur d’un employé
- Employé malicieux essayant d’élever ses privilèges
Serveur web
- Exploitation d’une vulnérabilité présente dans l’API du service web

Ils ont ensuite compromis le client lourd en présentant un fausse application web qu’ils contrôlent car le client lourd peut être configuré pour autoriser les connexions en HTTP ou ne vérifie pas le certificat envoyé par le serveur.

Une fois connecté sur le faux service, l’application web peut grâce à la ligne suivante faire apparaître une fenêtre d’impression :

<script>document.print();<script>

Ce qui permet par la suite d’invoquer une invite de commande avec les droits système.

Wilfried a ensuite présenté la partie exploitation du serveur de l’ADSS, que je vous laisse regarder dans la vidéo (lien à la fin de l’article).

Recommandations

Voici les bonnes pratiques à appliquer pour réduire le risque lié à l’utilisation d’un ADSS.

Client lourd :

Ne pas déployer le client lourd sur les serveur (et à fortiori un contrôleur de domaine)
Mettre à jour le client lourd
Forcer la vérification des certificats
Chiffrer les disques de l’ordinateur

Serveur :

Mettre à jour le serveur
Réduire les privilèges du compte du domaine au strict minimum
Utiliser les solutions déjà existantes, notamment pour le déploiement des clients lourds on peut utiliser les GPO ou SCCM
Restreindre l’accès à la partie admin (filtrage IP par ex.)
Mettre en place un CAPTCHA pour empêcher le bruteforce
Mettre un WAF en frontal pour intercepter les attaques

Un grand merci à eux pour leur présentation très claire et instructive !
Si vous souhaitez regarder leur présentation, la vidéo est disponible sur le site du SSTIC :

https://static.sstic.org/videos2022/1080p/surface_dattaque_des_solutions_active_directory_self_service.mp4

Practical timing and SEMA on embedded OpenSSL’s ECDSA — Adrian Thillard, Franck Rondepierre, Guenael Renault, Julien Eynard

Les attaques par temps de réponse sont une classe d'attaques par canal auxiliaire permettant à un adversaire de récupérer des données sensibles en observant le temps d'exécution d'un algorithme sous-jacent. Plusieurs bibliothèques cryptographiques se sont révélées vulnérables à ces attaques, permettant souvent des récupérations de clés privées. Bien que des articles récents aient montré que ces menaces sont bien connues des développeurs, ces bibliothèques sont souvent laissées sans correctif, en raison de la charge perçue de la mise en œuvre de contre-mesures efficaces. Au lieu de cela, de nombreuses bibliothèques ont choisi de modifier leur modèle de menace et de ne plus considérer les attaques où l'adversaire a un accès local à la cible.

Adrian Thillard nous présente ces travaux sur la recherche d'attaques par temps de réponse dans la librairie OpenSSL.

https://static.sstic.org/videos2022/1080p/practical_timing_and_sema_on_embedded_openssls_ecdsa.mp4

DroidGuard: A Deep Dive into SafetyNet - Romain Thomas

SafetyNet est un composant Android développé par Google pour vérifier l’intégrité des appareils. Ces vérifications sont utilisées par les développeurs pour empêcher l’exécution de leurs applications sur des appareils ne respectant pas certaines contraintes de sécurité (appareil rooté, firmware customisé, émulé, bootloader modifié).

SafetyNet permet aux développeurs d'applications critiques de s'assurer que leurs applis ne tournent pas dans des environnements compromis (jeux vidéos, fintech, apps de messagerie).

La conférence est un état de l’art de l’implémentation courante de SafetyNet et de ses mécanismes internes. On présente plus particulièrement le fonctionnement du module DroidGuard : architecture de la VM, ses mécanismes internes ainsi que les différents security checks effectués par SafetyNet pour détecter des outils comme Magisk, des émulateurs, des appareils rootés et même Pegasus.

Fonctionnement de SafetyNet

SafetyNet est une API que le développeur appelle en fournissant un nonce pour éviter des attaques de rejeu et une API_KEY pour l’authentification côté Google Backend. Le SDK de SafetyNet va packager ces informations et les envoyer à travers un Intent (format de message sur Android) à GMS Core.

GMS Core effectue des checks d’intégrité sur le téléphone (vérifications de la présence de certains binaires liés au rootage notamment) et package un message Protobuf (format de sérialisation de données structurées) qui va contenir des informations sur l’état du téléphone, il va également déclencher une requête à DroidGuard avec le message Protobuf.

DroidGuard effectue une requête au Backend Google avec le message Protobuf auquel est ajouté un token unique. Le Backend Google détermine si l’appareil est intègre, signe le message avec une clé cryptographique et renvoie le message signé. Enfin, GMS Core renvoie le message signé à l’application qui a fait la demande.

https://static.sstic.org/videos2022/1080p/droidguard_a_deep_dive_into_safetynet.mp4

OASIS: un framework pour la détection d'intrusion embarquée dans les contrôleurs Bluetooth Low Energy

La présentation est centrée sur la sécurité d’un protocole largement utilisé dans la communication IoT, le protocole Bluetooth Low Energy. Ils parlent dans un premier temps le principe de protocole BLE et ses différents avantages, ils présentent ensuite, OASIS, un Framework générique permettant d’automatiser l’instrumentation des contrôleurs BLE, pour y inclure des modules de détection d’attaques.

ça existe un certain nombre d’attaques sur les systèmes embarqués visant les contrôleurs Bluetooth Low Energy. Introduire un moyen de détection d’attaque sur ces contrôleurs va donc apporter un vrai avantage, ils expliquent donc le contexte d’OASIS avec des solutions de détection sur trois types d'attaques différentes.

OASIS: Module de détection - GATTACKER

Le principe de ce module est d’analyser en temps réel le délai entre l’émission de deux paquets par un même émetteur. Dans le cas d’une attaque, l’émission d’autres paquets par l’attaquant va impliquer une superposition de ces parquets avec le trafiquer légitime ce qui va mener à la réduction de ce temps d’émission entre deux paquets. On collecte les timestamps de chaque paquet d’un même émetteur et on calcule le temps intertrame successif, ensuite on estime l’intervalle minimum et on établi un seuil correspondant au pire cas ligitime.

OASIS: Module de détection - BTLEJUICE

Ce module de détection est basé sur le principe que le périphérique reçoit une demande de connexion et en parallèle de la validation et l’établissement de cette connexion, il initie également une opération de scan. Donc on peut détecter l’attaque si on remarque une émission de paquet utilisant le même Bluetooth Devise Adresse de périphérique en parallèle de la connexion.

OASIS: Module de détection - BTLEJACK

Ce module permet de détecter le type d’attaque de détournement de connexion (Hijacking), le but est d’analyser en temps réel le nombre de paquets consécutifs émis par le slave dont le CRC est invalide

Architecture d’OASIS

Dans la deuxième partie de la présentation, l’architecture OASIS est présentée. elle est basée sur trois principaux blocs:

Un firmware analyser basé sur la rétro-ingénierie automatique, où on procède à faire une analyse automatique de firmware du contrôleur BLE et générer automatiquement les fichiers de la configuration et du wrapper décrivant une cible matérielle.
Des logiciels de détection embarqués qui sont indépendants de la plate-forme, ils implémentent le calcul des métriques (temps intertrames).
Build system qui, en fonction des fichiers en entrée, va générer une liste de patches à appliquer sur le contrôleur matériel

La présentation est conclue par des travaux expérimentaux montrant l’efficacité de dispositif de détection implémenté - OASIS.

https://static.sstic.org/videos2022/1080p/oasis_un_framework_pour_la_detection_dintrusion_embarquee_dans_les_controleurs_bluetooth_low_energy.mp4

TPM is not the holy way

Depuis quelque temps, les ordinateurs embarquent des puces sécurisées appelées TPM. Cette puce, appelée Trusted Platform Module (TPM), est utilisée pour générer et protéger les secrets utilisés par l'ordinateur. Elle est par exemple utilisée lors du boot d’un OS, et permet à chaque composant de vérifier cryptographiquement le composant sous-jacent avant de l'exécuter.

Benoît Forgette nous présente durant cette conférence les travaux qu'il a pu mener sur l'émulation du système d'exploitation et l'interception des communications vers le TPM. Ces travaux lui ont permis de mettre en évidence des mauvaises configurations sur cette puce.