I. Présentation
Comme sous GNU/Linux tout est fichier, il convient de vérifier systématiquement la provenance des éléments téléchargés ainsi que ceux déjà en place sur le système. Pour cela, on doit alors calculer une empreinte de l’élément en question : fichier ou téléchargement. On parle aussi de fingerprint, de message-digest ou encore de checksum. Il s’agit d’une valeur de 128 bits correspondant à une somme de contrôle, calculée à partir de l’élément quel qu’il soit : archive, fichier(s), image ISO…
REMARQUE : on parle également de l’empreinte d’un fichier comme d’un hash ou d’une somme de contrôle. En ce qui concerne ce billet, nous nous intéresserons tout particulièrement aux éléments téléchargés, pus qu’à ceux déjà en place qui nécessitent un autre type d’outil appelé IDS (Intrusion Detection System) qui fera l’objet d’un autre tutoriel.
Je vous propose de détailler ici le processus de vérification des différents éléments que l’on peut télécharger sur des sites référencés, tels que fichiers, archives, image ISO ou encore système complexes. Un checksum MD5 n’a d’autre but que de garantir la provenance du fichier d’origine voire d’un groupe de fichiers. Son intérêt majeur est de permettre la vérification de l’intégrité des données ainsi récupérées. Cela couvre le risque d’une perturbation ou d’un problème réseau, ayant pour conséquence, lors d’un téléchargement, de corrompre une archive ou un fichier en cours de déploiement. Mais, cela permet aussi de s’assurer qu’aucune attaque d’individus peu scrupuleux, détournant ou falsifiant les fichiers vitaux du système, n’a eu lieu.
REMARQUE : il existe différents formats d’algorithmes de calcul d’empreinte : SHA-1, SHA-2 et même, aujourd’hui, SHA-3. MD5 est l’une des fonctions de l’algorithme SHA-1 qui est normalement obsolète. Il est conseillé d’utiliser les fonctions de l’algorithme SHA-2. Mais, pour des besoins de calculs et de vérifications rapides, on peut toutefois encore utiliser md5sum.
En résumé, en comparant l’empreinte MD5 (ou autre) du fichier que l’on souhaite récupérer à celle que le site de téléchargement nous fournit, on peut ainsi être certain que l’élément récupéré correspond bien à celui distribué officiellement par le site de récupération et qu’il n’a été en aucune manière corrompu. On garantit ainsi qu’il s’agit bien du même fichier et que ce dernier est entier (non tronqué) et surtout non falsifié.
II. Un peu d'histoire
Les fonctions de hachage MD5 ont été inventées en 1991. Mais, en 1996, deux éventualités de collision ont été découvertes via ces mêmes fonctions. Cela signifie qu’avec deux entrées différentes, on peut réussir à obtenir la même signature d’empreinte. Cela a été conforté par la découverte en 2004 de véritables collisions complètes. Par ailleurs, ce genre de signature peut être facilement cassée grâce à des attaques de type arc-en-ciel (aussi appelée rainbow table).
Ce genre de problématique correspond en cryptanalyse à une structure de données, permettant de retrouver un mot de passe à partir de son empreinte. Il s’agit d’une amélioration des compromis temps-mémoire proposé par Martin HELLMAN dans les années 1980. La table arc-en-ciel est constituée de paires de mot de passe où chaque ligne est composée d’un mot de passe de départ et un mot de passe d’arrivée. Ainsi, pour calculer la table, on établit des chaînes grâce à un mot de passe initial. Celui-ci subit une série de réductions et de hachage afin d’obtenir des éléments intermédiaires (avec mot de passe et empreintes correspondantes).
La fonction de réduction transforme une empreinte en un nouveau mot de passe. Afin d’éviter les problèmes de collision, plusieurs fonctions de réductions doivent être utilisées. Ainsi, après plusieurs milliers d’itérations, on obtient un mot de passe en bout de chaîne. C’est celui-ci qui sera stocké avec le mot de passe d’origine de cette chaîne. Le reste de la chaîne n’est alors pas conservée afin de limiter l’utilisation de la mémoire nécessaire.
REMARQUE : il est toutefois possible de retrouver les différentes étapes intermédiaires en calculant l’ensemble de la chaîne à partir de l’élément en tête de liste.
On recommence avec un autre mot de passe pour établir une nouvelle chaîne et ainsi de suite jusqu’à la constitution d’une nouvelle table dont les statistiques soient suffisantes pour garantir le succès de l’attaque.
Exemple : table arc-en-ciel avec trois fonctions de réduction :
En parallèle, l’algorithme de hachage SHA-1 a été publié en 1995. Mais, de la même manière que pour MD5, des chercheurs ont mis en évidence des attaques possibles contre ce mécanisme et cela a très vite été remplacé par l’algorithme SHA-2, fournissant alors des fonctions plus complexes telles que SHA-224 (avec la commande sha224sum), SHA-256 (avec la commande sha256sum), SHA-384 (avec la commande sha384sum) et SHA-512 (et la commande sha512sum). Depuis 2015, il existe même un algorithme SHA-3 encore plus complexe.
III. Utilitaire md5sum
Sous GNU/Linux, l’utilitaire md5sum est en général partie intégrante de la distribution. Si toutefois ce n’était pas le cas, on peut installer le package coreutils afin de permettre de disposer de la fonctionnalité d’empreinte MD5 et de sa commande md5sum. Tout ce qu’il y a à faire alors est de se placer dans le répertoire contenant l’élément à vérifier et à exécuter la commande suivante :
$ md5sum Fichier
Exemple : pour effectuer la vérification du fichier /etc/passwd :
$ md5sum passwd
2d8d90df3c4b84eb9e281a3f10767aa5 passwd
Bien évidemment, si l’on ne se trouve pas dans le dossier ou répertoire du fichier à vérifier, il faut alors fournir le chemin d’accès à celui-ci en absolu (en d’autres termes le chemin complet) :
$ md5sum /etc/passwd
On peut alors facilement imaginer vérifier n’importe quel type de fichier, comme par exemple une archive compressée au format .tar.gz (ou même au format .tar.xz) :
$ md5sum LibreOffice_6.3.4_Linux_x86-64.tar.gz
La valeur affichée doit bien sûr être la même que celle fournie par l’éditeur (ou l’auteur dans le cas d’un package), de l’élément à télécharger, qu’il s’agisse d’un package, d’une archive ou d’une image ISO. On peut facilement rediriger l’empreinte récupérée dans un fichier texte en vue d’effectuer des traitements ou des comparaisons ultérieurement :
$ md5sum Fichier > Fichier.cksum
Ensuite, pour effectuer la vérification, on peut alors exécuter la commande suivante permettant de vérifier la présence de n’importe quel changement :
$ md5sum -v -c Fichier.mksum
Cela fonctionne aussi avec d’autres fonctions de calcul d’empreinte tels que sha256sum ou sha512sum qui sont moins risqués. De plus, si un fichier comporte une anomalie ou une différence par rapport à l’original, md5sum le signalera automatiquement.
REMARQUE : il est possible de réaliser l’empreinte de plusieurs fichiers en simultané grâce à l’instruction suivante (ou en combinant avec une commande find) :
$ md5sum Fichier1 Fichier2
De façon générale, on peut formaliser le calcul de l’empreinte d’un fichier de la façon suivante :
$ echo -n “MonFichier“|md5sum 2d8d90df3c4b84eb9e281a3f10767aa5 -
ATTENTION : si l’on souhaite calculer l’empreinte d’une chaîne de caractères (ou d’un mot de passe) cela est tout à fait possible mais il faut alors exécuter la commande suivante :
$ echo -n “Chaine“|md5sum <Digest Chaine>
IV. Vérification d'archives
En ce qui concerne les archives, qui contiennent la plupart du temps des systèmes plus complexes, voire des applications ou des suites logicielles, on peut bien sûr continuer d’utiliser md5sum, mais il est fortement conseillé d’utiliser à la place sha256sum (ou mieux encore sha512sum).
REMARQUE : ce que l’on vient de dire des archives est également vrai pour des fichiers de type image ISO.
En fait, MD5 permet de garantir l’intégrité des données, mais pas nécessairement leur provenance. Pour cela, on doit utiliser un autre outil. Par exemple, si l’on se réfère aux archives du code source du noyau linux disponible sur le serveur http://ftp.lip6.fr/pub/linux/kernel/sources/ (quel que soit la version jusqu’à v4.x), on remarquera des fichiers au suffixe évocateur .sign contenant des lignes comme celle décrite ci-dessous :
----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJbcJ/kAAoJEHm+PkMAQRiGI4QH/RbfO3a0w6JHlNl6DxDbMpluAT7oGfC08YO1pJ8ZJcIPiOAxOQ0SUcI/RIcgYWtM3/2/k6FC7txCbDmE/3PW8bWNFqdn+1qtL3DUAG5GH9vbC8aTmNh2EvEkH96vWh7zBQZrOt6H3kiwrHdcfHVPDdu6JHf8ecsyYtF1Y2XrSQq4nzs298FbAkDkR+IQ0oV28kOoHv0MwHJ2ofvKcNffQ3StJrypnkqCTQEX0IGWUwz/N5xMp0e3eM+gE7FsWsIcTZNbWk7hBbQ2rbytq30OZTVNfRRHR4qVnFp8G7jKS4CdEQVfTgwl4KL15Ri7tdY0LUS3dTafITJ8LTXtd/Er7Io==Ub5V
-----END PGP SIGNATURE-----
Il s’agit en fait d’un fichier de signature GPG (anciennement PGP – Pretty Good Privacy passée sous licence privée et remplacée par Gnu Privacy Guard), permettant de garantir la provenance dudit fichier. Les signatures de ce type reposent sur une méthode de chiffrement à clé publique. Cela permet à un développeur (ou un groupe de développeurs de signer de manière électronique son œuvre : un fichier de code, une archive, un message voire même une image ISO, en utilisant sa clé secrète (aussi appelée clé privée). Cette dernière ne devrait (et ne doit d’ailleurs jamais) être divulguée publiquement.
Afin de vérifier une signature, on utilise alors l’homologue de la clé privée, appelée par opposition : clé publique. Celle-ci, en revanche est mise à la disposition de tous et est présente d’ordinaire dans un serveur de clés. Si l’on reprend l’exemple du code source du noyau linux il nous faut alors récupérer la clé publique correspondant au projet de “Kernel Linux“. Dans le cadre de projets reconnus, si les développeurs sont consciencieux on devrait systématiquement trouver une page dédiée au signalement du numéro de clé à utiliser. En ce qui concerne le noyau linux, on trouve cette page à l’adresse suivante http://www.kernel.org/signature.html. Ainsi, la clé recherchée est 0x517D0F0E.
REMARQUE : généralement sur cette même page on dispose également des empreintes de chaque développeur du projet, comme c’est le cas du projet du noyau linux :
Ainsi, pour poursuivre la démarche et récupérer la clé publique du projet (qu’il s’agisse d’une image ISO ou d’archives), il nous faut utiliser le logiciel Gnu Privacy Guard (autrement dit : gpg). Si celui-ci n’est pas encore installé, il faut pour cela exécuter la commande suivante :
$ yum install gnupg
REMARQUE : sur une distribution Debian ou Ubuntu, la commande utilisera plutôt le gestionnaire de package apt :
$ apt-get install gnupg
Après quoi, on peut alors récupérer la clé publique souhaitée en exécutant l’instruction ci-dessous :
$ gpg --keyserver wwwkeys.pgp.net --recv-keys 0x517D0F0E
gpg: requête de la clé 517D0F0E de wwwkeys.pgp.net...
gpg: clé 517D0F0E: clé publique importée
gpg: Quantité totale traitée: 1
gpg: importée: 1
Dès lors, on peut alors vérifier la validité de l’archive en combinant maintenant l’ensemble des informations :
- Clé publique : contenu du fichier de signature
- Archive : linux-4.18.7.tar.xz (à décompresser avec l’utilitaire unxz)
- Fichier de signature : linux-4.18.7.tar.sign
$ gpg –verify linux-4.18.7.tar.sign linux-4.18.7.tar.xz
REMARQUE : depuis quelques temps déjà il existe une version plus récente de gpg appelée gpg2. De plus, dans la documentation officielle le serveur de clé à interroger est généralement hkp://keys.gnupg.net. Mais, la plupart du temps on n’arrive pas à récupérer les clés publiques. Il vaut mieux en cas de message d’erreur interroger hkp://pgp.mit.edu.
D’ailleurs en utilisant cette nouvelle version, on dispose également de l’information du développeur concerné par ce code :
$ gpg2 –keyserver hkp://pgp.mit.edu –recv-keys <PubKey>
Cela permet d’afficher alors le résultat sous la forme suivante :
On constate ainsi que dans le cas présent le développeur n’est autre que Greg KROAH-HARTMAN, membre éminent de l’équipe de développement du noyau linux, aux côtés de Linux TORVALDS, que l’on peut joindre à l’adresse greg@kroah.com. Ainsi, on est certain qu’il ne s’agit pas d’un vague développeur au fond d’un garage qui est l’auteur de ce code et on valide ainsi la provenance de la source du téléchargement.
IV. Vérification du paquetage
Peut-être le savez-vous, mais les paquetages (qu’il s’agisse de .rpm ou de .deb) sont également équipés d’un mécanisme de signature PGP permettant, comme on l’a vu précédemment avec les archives (ou les images ISO) de vérifier l’intégrité du téléchargement et la provenance dudit package.
REMARQUE : la vérification d’intégrité de paquetage ne vaut que pour un fichier à télécharger, non encore installé sur le système. Par ailleurs, dans la majorité des cas, les paquetages récupérés appartiennent à des dépôts officiels et/ou déclarés : CentOS, RHEL, Fedora…
Par défaut, l’utilitaire yum vérifie l’intégrité des paquets qu’il installe en utilisant la clé GPG du dépôt. Cette vérification permet de confirmer l’origine “contrôlée“ du paquet et d’assurer que celui-ci n’a pas été altéré depuis sa mise en ligne, volontairement (acte de piratage) ou non (problème de téléchargement). Lorsque la vérification échoue il est déconseillé d’installer le paquet incriminé. Toutefois, on peut malgré tout passer outre et effectuer la vérification à l’aide de l’utilitaire rpm. Prenons comme hypothèse de travail, que nous souhaitions installer le package postfix sur notre serveur et que pour cela, nous devons le télécharger depuis le site https://centos.pkgs.org/7/centos-x86_64/postfix-2.10.1-7.el7.x86_64.rpm.html. Après avoir récupéré le package, il est alors possible d’utiliser la commande suivante :
$ rpm --checksig postfix-2.10.1-7.el7.x86_64.rpm
Dans ce cas, soit on a préalablement chargé la signature et on recevra un message comme celui-ci-dessous :
postfix-2.10.1-7.el7.x86_64.rpm: md5 gpg OK
Dans le cas contraire, on recevra le message suivant :
postfix-2.10.1-7.el7.x86_64.rpm: digests SIGNATURES PAS OK.
ATTENTION : lorsqu’on se retrouve avec un paquet rpm non signé à installer (ce qui n’est généralement pas le cas d’un paquet issu d’un dépôt officiel), on peut tout de même l’installer via la commande suivante :
# yum localinstall –nogpgcheck <Package>.rpm
Enfin, si l’on dispose du fichier de signature .asc correspondant au paquet récupéré, il suffit alors d’exécuter la commande suivante pour l’intégrer au système :
# rpm --import postfix.asc
On peut également effectuer cette opération d’import à partir d’une adresse URL. Par exemple, pour intégrer la signature de MySQL, on pourrait exécuter :
# rpm --import http://dev.mysql.com/doc/refman/5.1/en/checking-gpg-signature.html
On rappelle également que dans les fichiers .repo de déclaration de dépôts, on trouve un champ gpgcheck (ainsi que enabled pour l’activation ou non de cette option) et le champ gpgkey fournissant les indications de récupération des signatures.
En ce qui concerne les paquets .deb des distribution Debian, on trouve également un moyen de vérifier que le paquet à installer provient bien de son mainteneur et qu’il n’a subi aucune altération. On parle de scellement de paquets. La signature, en tant que telle ne se fait pas directement au niveau du paquet mais au niveau de la Release et de sa signature Release.gpg. Ce fichier est placé sur les miroirs Debian indiqué dans le fichier /etc/apt/sources.list. Il fournit la liste des différents fichiers Packages, accompagnés de leur somme de contrôle MD5, SHA1 et SHA256. Ces dernières permettant de vérifier que le contenu du paquet n’a pas été altéré.
Les fichiers Packages intègrent à leur tour une liste de paquets Debian ainsi que leur somme de contrôle afin de garantir que leur contenu n’a pas lui non plus été altéré. La gestion des clés de confiance s’effectue via l’utilitaire apt-key, fourni par le package apt. Ce dernier tient à jour un trousseau de clés publiques GPG, utilisées pour vérifier les signatures des différents fichiers Release.gpg obtenus depuis le ou les miroirs Debian.
REMARQUE : on peut bien sûr se servir de ce programme pour ajouter manuellement des clés supplémentaires (lorsqu’on souhaite ajouter des miroirs autres que les officiels). Mais, dans le cas courant, seules les clés officielles Debian sont vraiment utiles.
Les clés sont automatiquement maintenues à jour par le package debian-archive-keyring qui installe les trousseaux de clés dans le répertoire /etc/apt/trusted.gpg.d. Toutefois, on notera que la première installation de ce même paquet pose problème car, même s’il est signé (comme les autres packages), cette signature ne peut être à son tour vérifiée de façon externe. Aussi, le principe consiste-t-il à vérifier les empreintes (aussi appelées fingerprints) des clés importées, avant de leur faire aveuglément confiance et d’installer de nouveaux paquets. Pour se faire, il suffit d’exécuter la commande suivante :
# apt-key fingerprints
Ce genre de commande permet de lister, pour une distribution Debian, les empreintes (ou fingerprints) des clés importées. En les comparant avec celle du package à télécharger, cela permettra de leur faire confiance ou non avant leur installation :
Exemple : fichier xz-utils.md5sums contenant les empreintes des fichiers du package xz-utils :
Cet outil permet de générer des listes de sommes de contrôle à partir des archives .deb pour des paquets n‘en possédant pas. Toutefois, là encore, ce programme, s’il n’a pas été lancé depuis un média sûr avec une version déjà vérifiée de debsums. Du coup, des outils associés pour valider les autres paquets déjà installés, ne seront pas d’une grande utilité en matière de sécurité et d’intégrité.
V. Conclusion
Lors de la durée de vie du système d’exploitation vous pourrez aussi être amenés à utiliser des outils gérant l’intégrité des fichiers de l’ordinateur à posteriori tels que tripwire, AIDE, integrit ou d’autres outils du même genre.
Voilà, vous pouvez maintenant vous consacrer à vos empreintes. Vous savez désormais tout ou presque concernant l’intégrité et l’identification de la provenance de vos téléchargements. Alors j’espère que désormais afin de limiter le risque potentiel de virus, de vers ou d’autres attaques sournoises sur vos systèmes vous penserez à vérifier l’un et l’autre dès lors que vos effectuerez un chargement de fichiers, d’image ISO ou de paquetages.
