Encore un outil d’analyse automatique de la configuration SSH

J’ai découvert ssh-audit au travers de l’article de Korben_ssh-audit et j’ai cru déprimer.

Encore un outil de conformité qui vend du rêve et pipote du vent. Dans les faits, il servira surtout à générer de l’activité pour des auditeurs sans imagination, à rajouter des pages à un rapport d'auditeur novice qui manquera son but de conseiller son client, à justifier le prix d'une prestation vendue abusivement.

Sur la forme, on reçoit un vomi informationel en stdout où le rouge prédominant semble viser avant tout à créer ce sentiment anxiogène si cher à ces experts cyber.

Plus grave, cet outil ne permettra aucun gain en terme de résilience.

Je propose dans cet article de remettre l'église au milieu du village en commançant par analyser les risques qui pèsent sur le service SSH. De prendre un minimum de recul et d'adopter une vision ingénieur.

Chemins d’attaque via le service SSH et profil de l’attaquant

En l’absence de RCE (Remote Code Execution, ou Exécution de Code à Distance) publiquement connue sur le système Linux, un potentiel attaquant cherchant à en prendre le contrôle vise tout particulièrement le service SSH. Il permet en effet l’administration à distance du système, et à ce titre constitue un point d’entrée critique ; En d’autres termes, si l’attaquant parvient à gagner un accès via ce service, c’est presque toujours échec et mat pour le défenseur.

Le schéma suivant référence les différents chemins d’attaque possible. Alors si j'en ai oublié, n'hésitez pas à me l'indiquer par un petit courriel :

Niveau de l’attaquant

Je me suis inspiré de la classification du niveau d’attaquant tel qu’évaluée par les Critères Communs notamment dans l’annexe B.6 Calculating attack potential :

• Layman : C’est M./Mme Michu. Elle est vénère, mais sait faire que des trucs basiques ;
• Proficient : C’est le nerd boutonneux. Il reste motivé et fait preuve d'une idéologie naze, mais ne saura mettre en place que des trucs déjà accessibles sur Internet avec éventuellement un peu d’imagination et un peu de debugging pour que ça recompile et que l’exploit s’exécute ;
• Expert : C’est l’expert cyber avec beaucoup d’autonomie. Il a 10 années d’expérience pentest derrière lui, et a potentiellement écrit dans la presse spécialisée ;
• Élite : C’est un groupe d’attaquant avec de gros moyens pour atteindre l’excellence technique en interne ou en payant un mercenaire / une société tierce pour développer un zéro-day.

Accessibilité de la cible

L’attaquant peut opérer depuis le réseau local, ou doit attaquer depuis un réseau distant. Cette différence implique une difficulté structurelle lourde pour l’attaquant distant, mais les hypothèses pour avoir un attaquant local sont périlleuses côté défenseur :

• Si l’attaquant est distant, il ne pourra réaliser d’attaque par interception man-in-the-middle qu’en compromettant un routeur FAI qui transporte le flux légitime. Le prérequis pour intercepter un flux SSH distant est très lourd ;
• Si l’attaquant est sur le réseau local, il peut facilement réaliser ces attaques MITM.

Chemins d’attaque

Les principaux chemins d’attaque sont les suivants :

• Le plus classique, le bruteforce du mot de passe SSH ; Humiliation assurée en cas de mot de passe pourri ;
• Celui qui étonne toujours, le man-in-the-middle SSH. Et oui, ce n’est pas parce qu’on utilise SSH qu’on se protège du MITM. Il faut encore faire attention avec qui on s’authentifie et avec qui on chiffre. Si on ne vérifie pas les empreintes du serveur, et si on s’authentifie en login / password, alors on est exposé. Mais on fait toujours attention, me direz-vous. Bien sûr. Certes, mais combien de robots de sauvegardes, scripts de transferts de fichiers, outils de supervision, etc. utilisent les options suivantes :

StrictHostKeyChecking = no
UserKnownHostsFile = /dev/null

• Celui que personne n’envisage, la backdoor SSH. Enfin, on n’est pas passé loin, mais il ne s’agit que de ce que l’on connait publiquement. Donc un attaquant de niveau Élite pourrait en avoir d’autres… ;
• Celle qui humilie le sysadmin, le service SSH non patché contre une vulnérabilité connue. Par exemple, même si elle date un peu, celle liée à la vulnérabilité OpenSSL ;
• Évidemment, nous laissons de côté le rejeu de mot de passe, le vol de clef privée non pritégée, le vol de ticket kerberos, etc. ;
• Celle dont tous les cryptopathes rêvent : Briser la cryptographie sous-jascente liée à l’authentification SSH.

Évaluation des mesures de protection

Méthodes de protection qui fonctionnent

• Force est de constater que si le service n’est pas accessible, il ne sera pas compromis. La recommandation la plus forte consiste à justement le rendre inaccessible. Concernant une box OVH, comme celle où ce blog est hébergé, il suffit de restreindre l’accessibilité aux adresses publiques habituelles du domicile de l’auteur ; Bien qu'un attaquant pourrait louer une box OVH dans le même sous-réseau OVH que la mienne, disons que ça monte quand même le niveau de l’attaquant. Ceci dit, une variante en entreprise consiste à ne permettre l’accès aux réseaux d’administration que par authentification VPN medium-hardware (carte à puce ou token physique), ce qui ne fait pas uniquement porter le risque sur d’autres équipements, mais impose deux barrières de sécurité distinctes ;
Recommandation 1 Mettez en place un confinement réseau si possible, à défaut du filtrage réseau, de manière à restreindre l'accessibilité du service SSH aux seuls adresses légitimes.
À noter cependant que le pare-feu local peut être contourné pour un attaquant justement présent sur ce réseau local ;

• Finalement, les mesures de sécurité les plus drastiques relatives uniquement au service SSH consistent à forcer l’authentification par clef, s’assurer de la mise à jour du package de la distribution, (qui au passage invalide certains algorithmes obsolètes), et restreindre l’écoute du service SSH sur l’interface d’administration.
Recommandation 2 Imposer une authentification SSH par clef. Kerberos reste très bien également, surtout si le ticket initial s'obtient par pkinit. Dans les deux cas, protéger votre clef privée par du medium-hardware si possible (token Yubikey, carte à puce, TPM, etc.
Recommandation 3 Assurez-vous d'une mise à jour régulière de votre service SSH.

Méthodes de protection cargo-cult-security

• Évidement, le classique fail-2-ban. Tellement intéressant d’accepter d’avoir un temps de retard sur l’attaquant et de lui proposer la méthode d’authentification la plus pourrie qui soit pour le bloquer a posteriori…
• Durcir les paramètres cryptographiques. Alors, en soi, ce n’est pas une mauvaise idée ; mais commencer par ça démontre clairement une mécompréhension du travail de l’attaquant.
• La politique de mot de passe durcie côté Linux avec le plugin-pam-qui-va-bien.
Attention Personne ne peut garantir factuellement la robustesse du mot de passe, ni encore moins qu’il n’est pas réutilisé par l’admin ailleurs dans le SI ou pire dans une base ayant fuité sur Internet. L'actualité regorge d'articles de bases de mots de passe compromis. Ça en devient ridicule. Arrêtez de vous authentifier par mot de passe. Vraiment.
• “Cacher” le service SSH en lui assignant un port d’écoute élevé. Bon, je le fais aussi, mais c’est pour avoir des journaux moins pourris, pas pour me protéger !

Bilan

Un service SSH à jour, avec les algorithmes cryptographiques par défaut, “à-poil-sur-Internet”, mais imposant une authentification par clef, présente nettement moins de risque de compromission qu’un service permettant l’authentification par mot de passe et disposant d’un durcissement des paramètres Diffie-Hellman.

Donc, arrêtez avec ces outils de conformité (vis-à-vis de quel référentiel ?) vomissant des lignes rouges anxiogènes sur les paramètres crypto.

Réflechissez ! Faites un travail d'ingénieur pas de comptable. Pourquoi pas une note de conformité sur 20 à la fin. Vous la présenterez à l'attaquant quand il aura compromis votre SSH.

Faites votre propre analyse de risque !

Jugez-vous d’avantage vraisemblable qu’un attaquant casse la crypto par défaut sous Debian, ou qu’il parvienne à trouver le mot de passe de l'un de vos utilisateurs dans un leak ? Et si vous redoutez l’attaquant qui effectivement peut casser la crypto même par défaut d'une distribution sérieuse, n’est-il pas temps de protéger tout vos services d’administration par un VPN qualifié, et d’imposer une authentification par medium-hardware ? En faisant certes, une fois tout ce travail en place, un tour sur le nettoyage des algorithmes crypto moins robustes.