Skip to content

SSHC : faille découverte via audit de code

Dans cet article, je vais vous présenter une faille de sécurité que j’ai récemment découverte sur un outil Open-Source : SSHC

Je me suis intéressé à SSHC dans le cadre d’une recherche sur des outils similaires à Putty (Windows) pour les systèmes Linux (en ligne de commande). SSHC permet effectivement de maintenir et d’utiliser une base de données chiffrée, celle-ci contenant les informations et mots de passe nécessaires à l’établissement d’une connexion SSH via une sélection par menu :

sshc-02
Utilisation de SSHC, choix de l’édition ou de l’établissement d’une connexion via un menu CLI

Suite à mes recherches, j’ai d’ailleurs fait un article à propos de SSHC sur mon autre site web IT-Connect : SSHC : gestionnaire de profils SSH en ligne de commande
En cherchant un peu à savoir comment fonctionnait cet outil, je suis aller jeter un œil sur son code source sur GitHub : https://github.com/e2ma3n/sshc/blob/master/sshc.sh

Je me suis tout particulièrement intéressé à la phase de chiffrement/déchiffrement de la base de données. En effet, lorsque la base de données est éditée (ajout/suppression d’information), le programme est obligé d’accéder à un mode édition qui doit faire parti d’un processus de déchiffrement – édition – chiffrement. C’est cette partie du code qui contient la vulnérabilité découverte.

Édition de la base de donnée

Techniquement, lorsqu’un utilisateur souhaite accéder à sa base de données chiffrée, il doit saisir le mot de passe (la clé) permettant de la déchiffrer, puis celle-ci est éditée via un éditeur géré par SSHC. Suite à la modification, l’administrateur ferme la base de données et doit ressaisir son mot de passe pour chiffrer à nouveau la base de données. Voici à quoi ressemble une base de données  SSHC lors de son édition :
sshc-01Techniquement, voici la fonction qui se charge de ce procédé :

# edite database
function edit_db {
     echo "$database_de" > /opt/sshc_v5/sshc.database.de
     nano /opt/sshc_v5/sshc.database.de
     echo -en "[+] encrypt new database, Please type your password: " ; read -s pass
     openssl aes-256-cbc -pass pass:$pass -a -salt -in /opt/sshc_v5/sshc.database.de -out $database_en
     rm -f /opt/sshc_v5/sshc.database.de &> /dev/null
     echo -e "\n[+] Done, New database saved and encrypted"
     echo '[+] ------------------------------------------------------------------- [+]'
     exit 0
}

Cette fonction est donc appelée lorsque l’on souhaite éditer la base de données SSHC.

On peut facilement voir qu’en ligne 3 le contenu de la variable « $database_de » est inscrit dans un fichier dont le nom et le chemin son hardcodés (non variabilisés). Il ne peut donc pas être modifié « facilement » dans via fichier de configuration par exemple. Ensuite, l’éditeur texte « nano » est lancé sur ce fichier, permettant à l’utilisateur de le modifier.

Les lignes 5 et 6 permettent de chiffrer à nouveau la base de données avec un mot de passe (une clé) saisie par l’utilisateur. Le fichier « temporaire » est ensuite supprimé via la commande « rm » et l’édition se termine. Il est ici intéressant de déterminer d’où provient cette variable « $database_de » et le contexte d’appel de cette fonction. En parcourant le code source, on peut notamment apercevoir cette ligne :

database_en="/opt/sshc_v5/sshc.database.en"

Ici, on trouve la variable « database_en« , on peut alors deviner :

  • en = encrypted
  • de = decrypted

La base de données se retrouve donc parfois déchiffrée et ce contenu déchiffré est mis dans la variable « $database_de« . Plus particulièrement, on retrouve la fonction de déchiffrement de la base de données suivante :

# decrypt database
echo -en "[+] Enter password: " ; read -s pass
database_de=`openssl aes-256-cbc -pass pass:$pass -d -a -in $database_en 2> /dev/null`
if [ "$?" != "0" ] ; then
    echo -e "\n[-] Error: Database can not decrypted."
    echo '[+] ------------------------------------------------------------------- [+]'
    exit 1
else
fi

Nous pouvons ici voir à la ligne 3 que le contenu de « $database_en » est déchiffré puis positionné dans la variable « $database_de« . Nous avons donc fait le tour du processus d’édition via le parcours du code source.

Stockage en clair de la version déchiffrée

Les plus affûtés d’entre vous aurons, je pense, déjà aperçu la vulnérabilité découverte. Nous voyons en effet dans la fonction « edit_db » que le contenu de « $database_de« , qui contient la version déchiffrée de la base de données, est stockée sur le système de fichier, plus précisément dans le fichier « temporaire » /opt/sshc_v5/sshc.database.de.

Lors de l’édition, il y a donc un laps de temps durant lequel un fichier texte en clair contient la liste des connexions et leur login/mot de passe associés sur le système, ceci est donc exploitable assez facilement, il nous « suffit » d’attendre qu’un utilisateur ouvre sa base de données SSHC pour édition puis d’aller simplement lire ou copier la version déchiffrée de la base de données SSHC sur le système.

Voici un script bash, pouvant être lancé par un utilisateur tiers du système et qui permet de copier le fichier /opt/sshc_v5/sshc.database.de dés que celui-ci est créé :

#!/bin/bash
while [ ! -f /opt/sshc_v5/sshc.database.de ] :
do
  sleep 1;
done
cp /opt/sshc_v5/sshc.database.de ~/sshc_database.de

Ici, je fait simplement un boucle sur la vérification de la présence du fichier. Dés que le fichier est détecté comme existant, la boucle prend fin, permettant ainsi l’exécution de la commande suivante qui se charge simplement de copier le fichier dans le « home » de l’utilisateur courant. Voici une vidéo qui expose plus clairement le contexte d’exploitation :

Dans cette vidéo, un utilisateur standard parvient à copier la base SSHC utilisée par l’utilisateur « root« .

Un mot sur l’umask par défaut sous Linux

L’umask sous Linux est simplement les droits par défaut qui vont être assignés à un fichier/dossier nouvellement créé. L’umask qui est par défaut défini pour les fichiers comme pour les répertoires est en fait « 022 » ce qui fait 666-022 = 644. Plus simplement on enlève les droits d’écriture (w = 2) sur le groupe et les autres donc on passe de « rw-rw-rw- » à « rw-r–r–». Plus clairement, un fichier créé par « root » peut être lu par n’importe quel utilisateur du système avec les droits Linux par défaut.
Concrètement, cela ne va dans le sens de la sécurité car le fichier /opt/sshc_v5/sshc.database.de créé par root est automatiquement lisible par tous.

Pour en apprendre plus sur l’umask et surtout savoir comment le modifier pour améliorer la sécurité de son système Linux, je vous oriente vers mon tutoriel sur IT-Connect : Gestion de l’umask sous Linux

Des pistes de résolution

Le renforcement de l’umask est bien sur une première piste de sécurisation, en rendant les fichiers nouvellement créés (par root notamment) illisibles aux autres utilisateurs du système, la faille est déjà plus ou moins corrigée car un utilisateur standard ne pourra plus copier aussi facilement le contenu du fichier déchiffré.
Une autre piste de sécurisation consisterait à variabiliser et à randomiser le nom et le chemin du fichier temporaire, en le nommant différemment à chaque nouvelle édition, il sera plus difficile pour un utilisateur tiers de savoir quel fichier copier.

Également, permettre à l’utilisateur de modifier le chemin du fichier via une variable serait une façon d’améliorer la sécurité de SSHC. On pourrait également penser à positionner le fichier temporaire dans le répertoire home de l’utilisateur qui lance SSHC, ce qui permettrait, en plus de cacher la présence du fichier temporaire aux autres utilisateurs , de rendre possible l’utilisation de SSHC par plusieurs utilisateurs sur un même système.

Une dernière piste à explorer consisterait à manipuler la version déchiffrée uniquement en mémoire dans le but de ne jamais la stocker sur le système de fichier, qui plus est en clair.

Après plusieurs mails et l’ouverture d’une issue sur le Github du projet, l’auteur de SSHC (E2MA3N – Iman Homayouni) a patché cette faille de sécurité et m’en a averti par mail. Voici la nouvelle fonction d’édition de la base de données :

# edite database
function edit_db {
    touch /opt/sshc_v5/sshc.database.de
    chown root:root /opt/sshc_v5/sshc.database.de
    chmod 600 /opt/sshc_v5/sshc.database.de
    echo "$database_de" > /opt/sshc_v5/sshc.database.de
    nano /opt/sshc_v5/sshc.database.de
    echo -en "[+] encrypt new database, Please type your password: " ; read -s pass
    openssl aes-256-cbc -pass pass:$pass -a -salt -in /opt/sshc_v5/sshc.database.de -out $database_en
    rm -f /opt/sshc_v5/sshc.database.de &> /dev/null
    echo -e "\n[+] Done, New database saved and encrypted"
    echo '[+] ------------------------------------------------------------------- [+]'
    exit 0
}

On voit donc que le fichier sshc.database.de est toujours créé au même endroit, mais les droits et propriétaires sont précisé avant d’y mettre un contenu sensible. Je n’ai pas eu le temps d’essayer de contourner cette nouvelle méthode de création, je vous encourage à tenter ! 🙂

Il serait notamment intéressant de ce pencher sur la façon dont est supprimé le fichier avec la commande « rm« , n’est-il pas possible dans ce cas de récupérer le fichier déchiffré via des outils de forensics ?

Voici l’advisory diffusé sur PacketStormSecurity : https://packetstormsecurity.com/files/137586/SSHC-5-0_encrypted_database_content_stealing.txt

Partager :
Published inAdvisory et Contributions

2 Comments

  1. R0m#

    Pour la suppression, il serait plus approprié d’utiliser la commande « shred ».
    Pour le fichier « sshc.database.de », hormis les droits de lecture je ne vois pas d’autres moyens de restreindre l’accès à ce fichier.

  2. Ou tout simplement, si un snapshot du disque est effectué lorsque le fichier déchiffré existe, cela laisse une vulnérabilité.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *