1 Vulnérabilités OpenSSL et OpenSSH de Debian et ses dérivés
Cette semaine, l'équipe de sécurité du projet Debian a publié un bulletin de sécurité relatif à une faiblesse dans le générateur de pseudo-aléa mis en œuvre dans le paquetage OpenSSL. Celui-ci s'applique à la version stable (Etch) de la distribution Debian ainsi qu'aux versions de développement : testing et unstable. Par ailleurs le CERTA a publié l'avis CERTA-2008-AVI-239 sur le même sujet.
Dans les faits, l'aléa utilisé pour générer les clefs ne serait qu'un simple dérivé du PID (Process Identifier), donc aisément prévisible. Ceci constitue, très clairement, une grave faiblesse dans le système cryptographique fourni par Debian dans OpenSSL. Il est à noter que toutes les distributions dérivées de Debian Etch sont concernées. Ainsi, le présent article et les recommandations associées sont applicables également à Ubuntu, Xandros, MEPIS, KNOPPIX....
Les implications en terme de sécurité sont assez importantes car les clefs privées ou les certificats utilisés par des services réseaux s'appuyant sur SSL pour leur chiffrement (FTPS, HTTPS, DNSSEC, OpenVPN, ...) doivent être considérés comme non-fiables. Dans ce contexte, il est possible pour un attaquant de prédire et de réutiliser les clefs privées utilisées lors d'échanges chiffrés entre clients et serveurs et de réaliser ainsi des attaques de type « homme au milieu » (« Man in the middle »).
Un deuxième bulletin de sécurité a été publié par Debian et par le CERTA expliquant que la vulnérabilité présente dans OpenSSL s'appliquait aussi à OpenSSH. Ce dernier s'appuyant également sur cet aléa faible. En d'autres termes, tout bi-clef (couple clef publique / clef privée) généré à partir de la commande ssh-keygen (incluse dans le paquetage vulnérable) est également à considérer comme non-fiable. Là encore, la vulnérabilité s'applique à toutes les distributions dérivées de Debian.
Un autre cas concerne l'utilisation de certificats utilisés dans le contexte d'une IGC (Infrastructure de Gestion de Clef). En effet, un certificat client produit de façon fiable mais signé par une autorité de certification utilisant des clefs de signature non-fiables devient, de facto, non-fiable lui aussi. Le cas le plus grave serait une autorité de certification racine non-fiable.
Recommandations :
Cette vulnérabilité est considérée comme critique en particulier si vous avez mis en œuvre des services s'appuyant sur SSL pour le chiffrement sur une plate-forme Debian ou assimilée. Une mise à jour des paquetages ssh et libssl ne sera pas suffisant. Il conviendra de s'assurer que les paquetages suivants ont été correctement mis à jour :
- openssh-client ;
- openssh-server ;
- openssh-blacklist.
http://www.certa.ssi.gouv.fr/site/CERTA-2008-AVI-239/
http://www.certa.ssi.gouv.fr/site/CERTA-2008-AVI-246/
Le dernier paquetage contient la liste des clefs reconnues par Debian comme étant non-fiables.
Toute clef produite avec OpenSSL ou OpenSSH par un système d'exploitation Debian stable entre le 8 avril 2007 (date de sortie de la version stable actuelle Etch, mais septembre 2006 pour la version testing) et la date de sortie de la mise à jour OpenSSL ou OpenSSH est non-fiable. Les clefs présentes dans /etc/ssh devront été remplacées par de nouvelles. Il faudra également examiner les bi-clefs présents dans les répertoires .ssh/ des utilisateurs. Généralement ses clefs sont de la forme : id_dsa ou id_rsa pour les clefs privées et id_dsa.pub ou id_rsa.pub pour les clefs publiques. Il est à noter que le chemin d'accès et le nom de ces clefs est entièrement paramétrable. Ces informations ne sont donc données qu'à titre indicatif.
Le projet Debian met à disposition un outil nommé ssh-vulnkey permettant de faire une recherche rapide des bi-clefs ssh présents sur une machine et de déterminer si ceux-ci sont fiables. Cette outil n'est pas parfait et peut ne pas trouver certaines clefs. Dans le doute, il est plutôt recommandé de remplacer tous les bi-clefs existants (SSL/SSH) par de nouveaux une fois les mises à jours appliquées.
Enfin le CERTA vous engage fortement à être très attentif aux journaux d'événements des serveurs utilisant du chiffrement basé sur OpenSSL ou disposant d'un serveur sshd.
2 Les incidents traités cette semaine
2.1 Fausse alerte ?
Un correspondant du CERTA lui a signalé que son antivirus levait une alarme lors de la navigation sur un site. Le fichier en cause ne s'est pas révélé agressif à l'encontre du poste de l'internaute. Toutefois, ce fichier, un javascript, avait des traits inhabituels. La manière dont il était invoqué et d'autres aspects du sites semblaient anormaux. Le CERTA a contacté l'administrateur qui s'est montré surpris de la présence de ce script. Son analyse des journaux de connexion lui a permis de détecter des compromissions par attaques classiques, de type PHP-include. Les mesures correctives ont alors été prises.
Dans cet incident, l'alarme n'est pas pertinente vis-à-vis de l'ordinateur de l'internaute. Par contre, son signalement s'est montré très utile à l'administrateur du serveur web.
Cette attitude constructive de l'internaute ne dispense évidement pas l'administrateur d'un serveur de procéder à une analyse régulière des journaux de son serveur.
2.2 Les métadonnées...encore
Cette semaine, dans le cadre d'un incident, le CERTA a analysé un serveur web. Il s'est avéré que celui-ci contenait de nombreux fichiers de bureautique (Word, Excel, PDF...). Ils étaient mis à disposition des internautes par les auteurs qui pensaient, ayant vérifié le contenu des documents, ne pas divulguer d'informations confidentielles. Ces fichiers ont été par ailleurs indexés par des moteurs de recherche. L'analyse des métadonnées contenues a permis de récupérer des informations telles que des adresses de courriels, des noms et des informations réseau (y compris des adresses MAC). La définition des métadonnées est abordée dans l'article « Les métadonnées surprennent encore » du bulletin d'actualité CERTA-2008-ACT-001 du 4 janvier 2008. L'existence de ces informations est de plus en plus connue et elles sont faciles d'accès. Des outils reposant sur des moteurs de recherche permettent de synthétiser automatiquement un rapport HTML de toutes les métadonnées disponibles sur un site et elles peuvent par exemple être utilisées pour des attaques en ingénierie sociale.
La présence d'informations réseaux dans les documents de bureautique peut, à valeur d'illustration, être due à la méthode employée par Microsoft pour créer un identifiant unique du système sur lequel a été créé le fichier, le GUID (Globally Unique IDentifier). En effet, dans une machine, l'une des informations globalement unique est l'adresse physique d'une carte réseau. Cette adresse est concaténée telle quelle à d'autres informations pour créer le GUID. Elle ne permet d'identifier que la machine à partir de laquelle le document a été créé, le GUID n'étant pas touché par les modifications du contenu. L'auteur du virus Melissa, qui se propageait via un document Word malveillant, a été identifié par corrélation entre le GUID du document infecté et celui de documents publiés sur un site internet et dont la source était traçable.
2.3 Documentation
- Bulletin d'actualité CERTA-2008-ACT-001 du 4 janvier 2008 :
http://www.certa.ssi.gouv.fr/site/CERTA-2008-ACT-001.pdf
- «Document Metadata and Computer Forensic» de Jeffrey R. Jones :
http://www.infosec.jmu.edu/reports/jmu-infosec-tr-2006-003.pdf
3 Compromissions de machines par un fichier PDF
3.1 Précisions sur les publications du CERTA
Le CERTA a mis à jour l'avis CERTA-2008-AVI-053 concernant des vulnérabilités liées au lecteur Adobe Reader. Certaines de ces vulnérabilités ont fait l'objet d'un article dans le bulletin d'actualité CERTA-2008-ACT-007 du 15 février 2008. Celui-ci précisait que les corrections apportées par Adobe ne concernaient que la branche 8 du lecteur. La branche 7 a été délaissée et les utilisateurs ont été fortement incités par l'éditeur à changer de version.
Une mise à jour a été publiée par l'éditeur le 06 mai 2008 et corrige également les vulnérabilités pour cette branche 7 délaissée.
3.2 Les vulnérabilités corrigées
Les vulnérabilités corrigées par cette mise à jour ainsi que celle de février sont :
- CVE-2008-0667 : une fonction de la bibliothèque JavaScript Adobe (DOC.print) pourrait être appelée à l'ouverture d'un document spécialement construit afin d'envoyer une ou plusieurs requêtes d'impression à l'insu de l'utilisateur.
- CVE-2007-5666 : le chemin d'accès à des bibliothèques "Security Provider" peut être contourné et permettre de charger un fichier arbitraire dans le répertoire contenant le document PDF malveillant.
- CVE-2007-5663 : la mise en oeuvre de JavaScript dans le module Escript.api ne serait pas correcte et permettrait sous certaines conditions d'exécuter du code arbitraire.
- CVE-2008-0726 : les arguments attribués à la fonction Adobe JavaScript printSepsWithParams ne sont pas suffisamment contrôlés. L'exploitation de cette vulnérabilité peut conduire à un dépassement d'entier et la corruption d'une zone mémoire afin d'exécuter du code arbitraire.
- CVE-2008-2042 : l'appel à la fonction app.checkForUpdate peut entraîner via une fonction de retour (callback) un débordement de tampon.
- CVE-2007-5659 et CVE-2008-5663 : plusieurs débordements de tampon seraient possibles, notamment via des méthodes JavaScript comme Collab.collectEmailInfo. Ces vulnérabilités ne sont pas toutes documentées.
3.3 Les risques associés
Le CERTA signale que plusieurs codes malveillants se propagent actuellement via des documents au format PDF. Ces codes peuvent exploiter l'une des vulnérabilités citées ci-dessous ou des fonctionnalités intrinsèques au format. A valeur d'exemple, le format précise certaines classes d'action :
- OpenAction détaille des actions à lancer à l'ouverture du document ;
- Action précise des actions à lancer suite à une opération de l'utilisateur via le document (clic sur une adresse réticulaire, formulaire et envoi de courriel, etc.).
Certaines de ces actions se manifestent par la présence de fonctions comme l'envoi d'un formulaire (SubmitForm) ou l'accès à une adresse (URI).
La combinaison de ces actions peut permettre, à l'ouverture d'un document PDF spécialement construit, de dérober de l'information sur le poste de l'utilisateur ou d'accéder à d'autres ressources.
Un fichier PDF est constitué d'un ensemble d'objets qui se trouvent dans le code source du document. Ces objets permettent de décrire l'apparence des pages, l'interaction avec des données et d'autres objets...
Il s'agit d'un format très riche. Les codes malveillants peuvent se dissimuler dans des objets sous forme de flux (streams) compressés et obfusqués de différentes manières. Ces variétés rendent la tâche des antivirus très difficile, et le taux de détection de tels codes malveillants est souvent très faible.
3.4 Les recommandations du CERTA
Le CERTA tient donc à rappeler ici quelques bonnes pratiques :
- ne pas ouvrir de fichiers ne provenant pas d'une source de confiance ;
- mettre à jour les lecteurs Adobe Reader ou utiliser un lecteur alternatif aux fonctionnalités moins riches ;
- configurer ces lecteurs au plus strict usage ;
- signaler à son responsable de sécurité (RSSI) tout document suspect.
3.5 Documentation
- Documents de référence Adobe sur les formats PDF :
http://www.adobe.com/devnet/pdf/pdf_reference.html
- Article « Retour sur les vulnérabilités d'Adobe Reader » du bulletin CERTA-2008-ACT-007, 15 février 2008 :
http://www.certa.ssi.gouv.fr/site/CERTA-2008-ACT-007.pdf
4 Sortie de Fedora 9
Fedora 9 est depuis peu disponible en téléchargement. Cette nouvelle version comporte quelques modifications de sécurité :
- possibilité de stockage des mots de passe sous forme de condensats SHA-256 et SHA-512 ;
- changement du comportement du pare-feu. Désormais, le pare-feu filtre tous les ports dans sa configuration par défaut, à l'exception du port 22/tcp (habituellement utilisé par le service SSH) ;
- améliorations de SELinux pour affiner le contrôle des accès.
De plus, le programme d'installation Anaconda prend en charge le chiffrement des systèmes de fichiers. Si ce chiffrement semble une bonne idée de prime abord, notamment pour se protéger d'un éventuel vol de disque dur, il reste une arme à double tranchant. En effet, en cas de panne du disque, de défaillance du système de fichiers, ou de perte du mot de passe, il est très difficile voire impossible de récupérer les données. À noter que le système de fichiers ext4 (futur remplacement de ext3) est reconnu par Fedora 9.
4.0.1 Documentation
- Notes de version de Fedora 9 :
http://docs.fedoraproject.org/release-notes/
5 Nouvelle attaque via des protocoles de messagerie instantanée
Cette semaine, de nombreux articles ont fait état d'une nouvelle attaque se propageant via les messageries instantanées MSN/Live Messenger et ICQ. Une arnaque du même type avait fait l'objet d'un article dans le bulletin d'actualité CERTA-2008-ACT-007. Ce code malveillant se propage de manière classique via ce type d'outil. Tout d'abord, il est nécessaire que la victime se rende sur un site Internet malveillant pour soit-disant vérifier la liste des personnes ayant bloquée son adresse. Pour avoir cette liste il est nécessaire de fournir l'identifiant et le mot de passe de la messagerie instantanée. Après validation, les données sont ainsi subtilisées et utilisées pour se connecter à l'insu de l'utilisateur à son compte de MSN ou ICQ. Une fois la connexion frauduleuse établie, un message est envoyé à l'ensemble des contacts sous la forme d'un lien vers un site. Ce lien peut avoir plusieurs formats comme :
- m0bil3.info ;
- c-oo-l-st-uff.info ;
- pe0ples.info ;
- bidule.fr.
Ces liens sont généralement précédés du début de l'adresse de l'utilisateur compromis. Par exemple un utilisateur ayant pour adresse prenom.nom@domaine.tld enverra des messages à ces contacts sous la forme d'un lien : http://prenom.nom.c-oo-l-st-uff.info.
Le compte de messagerie compromis, il est alors possible pour les personnes se cachant derrière ces sites d'envoyer des courriels indésirables ou d'usurper l'identité des victimes. Le but principal de ce genre de compromission est de constituer une base de données afin d'envoyer pourriels et codes malveillants.
Le CERTA rappelle qu'il ne faut jamais cliquer sur un lien suspect même si celui-ci semble fourni par une personne de confiance. Il est important de vérifier que l'envoi du lien est volontaire et non fait à l'insu de l'utilisateur propriétaire du compte de messagerie. De plus, il est fréquent que le même mot de passe soit utilisé pour différents comptes. Il est alors possible de compromettre plusieurs comptes en une seule action. Les personnes malveillantes en profitent également pour enregistrer les données personnelles renseignées dans le profil utilisateur. Les clients de messagerie instantanée doivent également être mis à jour car ils sont eux aussi vulnérables comme le rappelait un article du bulletin d'actualité CERTA-2007-ACT-051.
5.1 Documentation
- Bulletin d'actualité CERTA-2008-ACT-007 du 15 février 2008 :
http://www.certa.ssi.gouv.fr/site/CERTA-2008-ACT-007.pdf
- Bulletin d'actualité CERTA-2007-ACT-051 du 21 décembre 2007 :
http://www.certa.ssi.gouv.fr/site/CERTA-2007-ACT-051.pdf
- Note d'information sur les mots de passe CERTA-2005-INF-001 :
http://www.certa.ssi.gouv.fr/site/CERTA-2005-INF-001.pdf