Archives de catégorie : Vulnérabilités

La catégorie des vulnérabilités recense quelques failles marquantes ou typiques. Cela peut être une faille touchant beaucoup de monde, ou le cœur des mécanismes de sécurité, ou encore dans les caractéristiques techniques ou leur résolution sortent du lot commun.

Attaques sur la mémoire RAM

Rien ne va plus dans le monde de l’informatique : on s’attaque à la mémoire sans vergogne. Exemples :

  • Martèlement mémoire (cf Wikipédia en français mais surtout en anglais), où on arrive physiquement à modifier de façon déterministe (= voulue et contrôlée) les bits voisins en RAM.
  • Flip Feng Shui (cf silicon.fr), qui est un type de martèlement mémoire. Comme seulement certaines zones y sont sensibles, cette technique consiste à pousser le système sous-jacent à stocker les informations critiques (comme les clés de chiffrement) dans les zones sensibles au martèlement mémoire1, et par d’autres techniques lire ces zones. Le Flip Feng Shui est une discipline japonaise d’agencement d’un habitat pour optimiser le flux d’énergie…

Voir aussi

Intel, des failles (ter)

Non, il ne faut pas croire que cela m’amuse de recenser les failles matérielles sur les processeurs (Intel ou autre). Au contraire : cela m’inquiète au plus haut point, sans m’étonner outre mesure, car la complexité des processeurs est devenue telle qu’il devient quasi-impossible de maîtriser l’ensemble de sa conception. En sécurité informatique, plus c’est complexe, plus c’est dur à sécuriser.

Nouvelle faille : Foreshadow

Traduisons ce qu’on trouve sur le site dédié (rappel : un site dédié avec un joli nom de faille et un beau logo sont les minimum syndicaux pour toute faille qui se vend respecte).

Foreshadow is a speculative execution attack on Intel processors which allows an attacker to steal sensitive information stored inside personal computers or third party clouds. Foreshadow has two versions, the original attack designed to extract data from SGX enclaves and a Next-Generation version which affects Virtual Machines (VMs), hypervisors (VMM), operating system (OS) kernel memory, and System Management Mode (SMM) memory.

Foreshadow est une attaque de type exécution spéculative (comme Spectre et Meltdown) touchant les processeurs Intel (les pauvres !) permettant à un attaquant de dérober des informations sensibles stockés sur des ordinateurs personnels ou dans le cloud (il est écrit third party, mais en vérité cela touche toute infrastructure, interne ou externe, cloud ou pas, qui compte sur un [[Évasion de machine virtuelle|hyperviseur]] de virtualisation pour isoler des environnements et des machines, cf juste en dessous).

Foreshadow a deux versions : l’attaque originale, conçue pour extraire des données des enclaves SGX (censées justement éviter cela…) et une nouvelle génération « NG » (de l’attaque) qui affecte les machines virtuelles, les hyperviseurs VMM (Virtual Machine Manager, hyperviseur utilisé dans le cloud Azure), la mémoire du noyau du système d’exploitation et la mémoire utilisée par le mode « management de système » (SMM).

Encore du Meltdown ?

Foreshadow est une variante de Meltdown1, de type exécution spéculative, dont la source a fini par être identifiée par Intel dans le cache L1 (L1TF, L1 Terminal Fault). Hélas, une fois ce constat réalisé, Intel a remarqué que cela avait d’autres conséquences2, d’où la création de deux variantes appelées « NG ».

Composants impactés

Virtual Machines Manager

Les bulletins ne sont pas très clairs sur ce point, car ils parlent de VMM sans trop de précision. D’après ce qu’en dit OVH3, les failles touchent bien les hyperviseurs en général, et non uniquement le VMM d’Azure.

Système d’exploitation

Idem pour l’OS, quasiment jamais mentionné dans les publications. Toutefois Linux est bel est bien touché lui aussi, cf les publications des différents éditeurs. Il n’y a pas que Windows…

System Management Mode

Il s’agit d’un mode spécial d’exécution du processeur, dont les caractéristiques sont :

  • Se situe dans une mémoire spéciale et séparée (SMRAM) ;
  • Peut accéder à l’ensemble du système et des entres/sorties, y compris la mémoire de l’OS et d’un hyperviseur ;
  • Est appelé par une interruption spécifique (SMI, System Management Interrupt) ;
  • Possède un gestionnaire logiciel (SMI handler) pour exécuter des opérations basées sur différentes SMI.

C’est un peu technique mais en gros ça signifie qu’il s’agit d’un mode qui a accès à tout, et qu’on l’imagine réservé pour un usage spécifique et bien délimité.

SGX

SGX est une enclave sécurisée, présente dans certains processeurs Intel, et conçue pour que personne ne puisse venir y lire le contenu : cela permet de cacher des informations très sensibles, comme des clés de chiffrements, dans une infrastructure tierce.

Conditions d’exploitation

Maigre consolation : la faille se situe au niveau core, c’est-à-dire qu’un processus ne peut utiliser cette vulnérabilité que contre un autre processus s’exécutant sur le même cœur du processeur4. Cela concerne les processeurs récents (ce qui est le cas de tous les processeurs SGX), de génération Sandy Bridge ou suivantes, car Intel assigne un cache L1 dédié pour chaque cœur5.

Logiquement, avec un processeur 4 cœurs, il n’y a qu’une chance sur 4 de subir l’attaque, et il est peu probable (impossible ?) pour un processus, qui plus est lancé dans une machine virtuelle, de choisir le processeur sur lequel il s’exécute.

Multiplié par le nombre de cœurs et de machines virtuelles, la probabilité baisse encore, surtout que la difficulté sera surtout de réussir à exécuter le programme d’attaque sur le même cœur de processeur que la cible. Après, une machine virtuelle peut demander à s’exécuter sur plusieurs processeurs virtuels, donc sur plusieurs cores, mais ça se paye. Et dans un environnement mutualisant des milliers de processeurs, ça peut devenir coûteux.

Correctifs

On peut renforcer l’isolation par les mesures suivantes :

  • En s’assurant qu’un core n’est pas partagé entre plusieurs machines virtuelles en même temps ;
  • Lorsque deux machines se suivent séquentiellement sur un core, alors on s’assure que le cache L1 est bien effacé ;
  • En ayant un environnement dédié (hyperviseur dédié chez AWS) pour empêcher le partage des CPU.

En ce qui concerne SMM, une mise-à-jour de microcode et de firmware semble nécessaire6.

Sinon désactiver l’hyperthreading est un moyen (coûteux à mon avis) d’empêcher l’exploitation de la faille ; on ne le réactivera qu’avec précautions, mais tout cela est bien expliqué sur le site de Xen.

Liens utiles

Sur Linux

  • Ubuntu : https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/L1TF et https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2018-3646.html
  • Red Hat : https://access.redhat.com/security/vulnerabilities/L1TF
  • Suse : https://www.suse.com/support/kb/doc/?id=7023077

RedHat propose une présentation rapide de Foreshadow, assez bien faite.

Liens internes

  • [[Évasion de machine virtuelle|Evasion de machine virtuelle]]
  • Intel, des failles ([[Intel, des failles|première vague]], [[Intel, des failles (bis)|deuxième vague]])

Site officiel

  • https://foreshadowattack.eu/
sans_cadre

SuperFish

SuperFish est un outil publicitaire qui a défrayé la chronique en février 2015. Sa principale fonction était de délivrer de la publicité ciblée, en analysant le trafic réseau de l’ordinateur où il est installé. Le problème est qu’il est aussi capable de déchiffrer les communications théoriquement sécurisées (par SSL ou TLS), via des techniques de type man-in-the-middle. Il a été installé sur de nombreux ordinateurs Lenovo.

Epilogue

Lenovo Ordered to Pay $7.3M in Superfish Fiasco

S3

S3 (Amazon Simple Storage Service) est un service de stockage d’objets en ligne d’Amazon Web Services (AWS). Bien que très pratique, il peut être très mal utilisé. Résultat : on assiste en ce moment à un florilège de divulgation de données via des S3 fonctionnant très bien mais mal paramétrés.

Il existe des variantes avec d’autres produits mal configurés, comme le service ElasticSearch, qui peut se révéler tout aussi fatal aux informaticiens peu consciencieux (ou débordés), ou la base MongoDB mal sécurisée par défaut.

Continuer la lecture →

ElasticSearch

ElasticSearch est un moteur de recherche et d’analyse RESTful distribué, d’après son site web (elastic.co). Très utilisé et même proposé sous forme de service par AWS, ce produit permet de gérer des recherches sur de grandes quantités de données.

C’est bien.

Mais cela devient moins amusant quand on le configure mal, les informaticiens pouvant être peu consciencieux ou débordés. Le résultat est alors sans appel : des moteurs de recherche internet (comme Shodan) indexent (trop) facilement les contenus mal protégés, et l’énorme quantité des données gérées par ElasticSearch deviennent purement et simplement disponibles et accessibles à la moindre requête anonyme.

Continuer la lecture →

KRACK

Un petit incident concernant le protocole utilisé dans quasiment tous les réseaux wifi actuels, auquel on a donné le nom évocateur de KRACK, est apparu (c’est-à-dire qu’on a communiqué publiquement dessus) aujourd’hui (16 octobre 2017).

En quelques mots : une personne (un équipement) captant physiquement le signal wifi WPA2 d’un réseau, même chiffré en bonne et due forme, peut déchiffrer tout le trafic, et donc lire tout ce qui y passe : la couche de protection WPA2 devient inutile. Si les informations qui transitent sur le réseau ciblé sont en clair, alors on peut les lire sans que vous ne vous en aperceviez. Par contre ce qui est chiffré au niveau supérieur (https, ssh, etc) reste tel quel, avec le niveau de protection attendu.

Il s’agit du genre de problème de sécurité1 énorme dont la célébrité lui vaut d’avoir son site web dédié, ses articles de presse et même un tweet du Ministère de l’Intérieur français. Quant aux solutions, elles seront longues à mettre en place car le protocole lui-même est en cause : même en le suivant scrupuleusement et sans erreur, votre implémentation est à risque. Et comme il est mis en place massivement depuis 15 ans, imagions ensemble le nombre d’équipements (réseaux et ordinateurs) à mettre à jour.

Patch à droite ou à gauche ?

Je n’arrive pas à voir clair pour le moment : je ne sais pas s’il suffit de mettre à jour le client pour éviter le problème, ou s’il faut que le client et le serveur (routeur) soient tous les deux corrigés. Je suppose que pour une correction totale incluant le protocole, il faudra que l’ensemble des équipements soient mis à niveau. Mais il semblerait que patcher le client suffise. A suivre.

Windows

Côté Windows, la mise-à-jour de sécurité semble dater du 10 octobre 2017, soit quelques jours avant la publication des premières infos sur le sujet. Le détail ne sera publié que le 1er novembre, le temps que les correctifs se diffusent. Un article détaillé (paper) est toutefois déjà disponible. S’il décrit en détail le problème, je n’ai pas vu de détail sur les exploitations possibles ; seuls quelques scénarios sont esquissés (en attendant l’ACM Conference on Computer and Communications Security du 1er décembre).

Dans sa mise-à-jour d’octobre, Microsoft a corrigé la vulnérabilité suivante : CVE-2017-13080. Après, une bonne douzaine de CVE ont été réservées pour la description de tous les problèmes identifiés, donc ça semble un peu peu. On verra par la suite…

WPA3

En juin 20182, une nouvelle version de la norme WPA, estampillée 3, voit le jour sous sa forme finale, avec la promesse de combler les failles présentes dans la version 2, ainsi que la limitation des attaques par dictionnaire. WPA3 n’est pas encore obligatoire, et un dispositif WPA2 pourra se connecter sur du WPA3. Espérons que cela n’introduise pas de faille du genre Freak.

Voir aussi

Heartbleed

Heartbleed est le nom donné à une faille dans une implémentation d’openSSL.

OpenSSL : c’est quoi ?

Avant toute chose, il faut savoir que SSL (dont les versions récentes s’appellent TLS) est un protocole qui permet de chiffrer des communications sur internet et d’authentifier une machine (un serveur web par exemple). Chiffrer, c’est rendre illisible un message à tous ceux qui ne disposent pas de la clé de déchiffrement. Ce protocole est très utilisé sur internet, et openSSL est un des outils d’implémentation de SSL parmi les plus utilisés.

Quand vous vous connectez de manière sécurisée sur un site web, vous passez par https et plus de la moitié de serveurs web dans le monde utilisent openSSL pour réaliser cette connexion https.

Quelle est la faille ?

La faille permettrait à un attaquant d’avoir accès à certaines données chiffrées lors des communications SSL sur les sites utilisant les versions vulnérables. En conséquence, certains mots de passe (voire certains certificats) pourraient être compromis et donc réutilisés par l’attaquant.

Quel est le composant touché ?

La faille est exploitable quand une version vulnérable d’openSSL est installée sur le serveur web. OpenSSL est un logiciel open source. Seules certaines versions sont vulnérables :

La branche 0.9.8 n’est pas touchée, et la correction est présente à partir de la version 1.0.1g. 

Sources

  • http://heartbleed.com/
  • https://www.openssl.org/news/secadv/20140407.txt
  • https://www.20minutes.fr/high-tech/1348577-20140410-heartbleed-faire-proteger-faille-securite-geante
  • http://www.lemonde.fr/technologies/article/2014/04/11/faille-heartbleed-les-sites-pour-lesquels-il-est-conseille-de-changer-son-mot-de-passe_4399564_651865.html
  • http://www.lemonde.fr/technologies/article/2014/04/09/une-enorme-faille-de-securite-dans-de-nombreux-sites-internet_4397995_651865.html
  • https://www.nextinpact.com/news/86941-heartbleed-openssl-et-question-securite-expliques-simplement.htm

StageFright

Dévoilée durant l’été 2015, StageFright est une faille concernant les systèmes Android. Elle a été découverte dans une bibliothèque multimédia servant à lire des vidéos envoyées par MMS, et permettrait de prendre le contrôle du terminal (smartphone ou tablette) à l’insu de l’utilisateur.

Qui est concerné ?

Cette bibliothèque est  utilisée par les systèmes Android depuis la version… 2.2, ce qui fait qu’environ 95% des terminaux Android seraient, au final, concernés.

Les versions les plus vulnérables seraient les 2.3 (« Gingerbread ») et 4.0 (« Ice Cream Sandwich »). A l’inverse, les versions plus récentes (ultérieures à  4.0) semblent légèrement moins vulnérables.

Quels sont les problèmes ?

Les principaux problèmes sont de deux natures :

En effet, l’écosystème Android est très fractionné et hétérogène : de multiples versions de l’OS sont actives, et le déploiement des mises-à-jour dépend fortement des partenaires (constructeurs et opérateurs). Il est donc malheureusement possible que le correctif n’atteigneque très lentement (voire jamais) certains terminaux Android.

Et maintenant ?

Suite à cette faille, Google, Samsung et LG se sont engagés sur la voie de mises-à-jour mensuelles du système d’exploitation Android, à l’instar de ce que fait Microsoft. C’est une bonne chose en termes de sécurité, mais cela ne représente qu’une partie seulement des terminaux.

La seule solution efficace (en attendant la correction au niveau système) est de désactiver le chargement automatique des photos et vidéos (principalement dans les applications de gestion de SMS/MMS comme Hangout), et de ne pas lire les SMS/MMS de provenance inconnue. Hélas, là encore, le mode opératoire dépend de la version d’OS Android utilisée… On peut le trouver par exemple chez Avast (https://www.avast.com/fr-fr/faq.php?article=AVKB230).

Bug SSL (Apple)

Je classe la vulnérabilité CVE-2014-1266 parmi les énigmes de sécurité informatique, comme l’affaire TrueCrypt, car les circonstances entourant ce bug SSL sont mystérieuses, et n’ont pas l’air d’avoir été éclaircies (en 2018).

Comme son nom l’indique, cette faille a été découverte en 2014.

Poodle

Poodle est le nom donné à une faille inhérente au protocole SSL v3.

Désactivation de SSLv2 et SSLv3 sur Plesk

Sur Plesk, il est possible de désactiver SSL v2 et v3 de façon définitive, grâce à un paramètre disablesslv3 qu’il faut positionner à true. J’avoue avoir eu un peu de mal à trouver comment faire, mais une fois que c’est fait, cela débarrasse de ce boulet !

Pour plus d’informations, il faut aller sur le forum Plesk. Et pour mémoire, voici la manip : 

# mysql -uadmin -p`cat /etc/psa/.psa.shadow` -Dpsa -e "insert into misc values('disablesslv3', 'true')"


# /usr/local/psa/admin/bin/httpdmng --reconfigure-all

La 1ère ligne positionne le paramètre, la 2e permet de reconstruire les configurations nécessaires. Pour vérifier, tapez : 

# cat /var/www/vhosts/system/*/conf/last_nginx.conf | grep ssl_protocols

Il s’agit de la configuration de nginx, et les vieux SSL doivent avoir disparu.

Voir aussi Logjam.

Freak

Une de plus ! Freak est une faille quasiment de conception de SSL. Une fonctionnalité, diront certains.

Dans les années 1990, l’administration américaine s’inquiétait de la prolifération des systèmes de chiffrement, et craignait de ne plus en avoir le contrôle (comprendre : ne plus pouvoir déchiffrer les messages codés, en cas de besoin). Elle a donc décidée d’interdire l’exportation de tout ce qui était indéchiffrable avec les moyens de l’époque, d’où une limitation de la taille de clés (par exemple).

Les outils se sont adaptés en conséquence, prévoyant un mécanisme spécial « export » qui ramenait automatiquement à des valeurs convenables la complexité du chiffrement lors d’un échange, même si les deux parties pouvaient faire beaucoup mieux.

Avec le temps, cette limitation est tombée, mais le mécanisme servant à réduire la taille des clés a été reconduit dans la plupart des outils utilisés. Et on s’en est rendu compte seulement en 2015, alors que cette fonctionnalité était largement documentée, et n’était même pas cachée1 !

FREAK a touché toutes les bibliothèques SSL/TLS ou applications utilisant SSL/TLS ayant respecté la réglementation… et oublié de supprimé cette limitation quand les règles se sont assouplies. Exemple : openSSL, S-Channel, Chrome…

Liens externes

Logjam

Logjam est une nouvelle faille dans le désormais périlleux chemin de la cryptographie, touchant une étape de négociation lors d’une connexion [[TLS|SSL/TLS]]. Même si, comme Freak, son exploitation n’est pas forcément facile, cela va imposer à moyen terme l’augmentation de la longueur de certaines clés, ou l’utilisation de certains algorithmes à la place de certains jugés trop faibles, ce qui aura surtout pour effet de compliquer encore la vie des webmasters (et des navigateurs web).

En effet, à force d’augmenter la solidité des mécanismes de sécurité, on finit par demander beaucoup de calculs à la fois au serveur et au navigateur ; or tout le monde n’est pas obligatoirement à niveau, et on pourrait finir (par exemple) par rendre certains sites inaccessibles aux utilisateurs dont les ordinateurs (ou les navigateurs web) ne sauraient pas composer avec cette complexité croissante.

Une synthèse, avec un outil de test ainsi que les recommandations à suivre sont ici : weakdh.org.

Désactivation sur Plesk

Sur Plesk, si vous avez une version 2.2 d’Apache couplé à nginx, il faudra un peu ruser pour ne plus être exposé à Logjam. pour plus d »infos, allez voir le forum.

Il faut en premier lieu créer un fichier DH personnalisé, de complexité (longueur) suffisante : 

openssl dhparam -out dhparams.pem 2048

Ensuite, il faut un template personnalisé pour ses sites web, dans /usr/local/psa/admin/conf/templates/custom/domain. Le fichier à modifier est nginxDomainVirtualHost.php. Il faut ajouter l’option ssl_dhparam en lui mettant le fichier que l’on vient de créer. 

ssl_ciphers                 HIGH:!aNULL:!MD5;


ssl_prefer_server_ciphers   on;


ssl_dhparam             /dhparams.pem;

Ensuite on reconfigure et ça devrait aller. 

# /usr/local/psa/admin/bin/httpdmng --reconfigure-all

Pour vérifier, tapez : 

# cat /var/www/vhosts/system/*/conf/last_nginx.conf | grep dh_param

Liens externes

  • http://www.nextinpact.com/news/94144-logjam-apres-freak-nouvelle-faille-dans-chiffrement-connexions.htm
  • http://forum.odin.com/threads/ssl-poodle-sslv3-bug.323338/#post-761018
  • https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf

AMD, des failles

Allez, mettons tout le monde d’accord : AMD aussi à ses failles, tout comme Intel. Et son site dédié, sans quoi une faille n’est pas une faille. Comme souvent, les détails ne sont pas dévoilés1 immédiatement, tant qu’on n’a pas essayé de remédier à ces problèmes, mais cela reste inquiétant.

Continuer la lecture →

4G

La 4G est un standard pour la communication des téléphones mobiles, dont plusieurs normes sont issues, comme LTE, WiMax, etc. Ce standard est basé sur IP, protocole internet.

Tout ce qui est informatique peut être attaqué

Or, comme je me le fais remarquer judicieusement, tout ce qui est informatique peut être attaqué d’une manière ou d’une autre. Des petits malins chercheurs se sont amusés à disséquer ce standard, et le résultat est implacable : il existe des tas de façons1 de trouer, poutrer, pirater un réseau 4G2. Triste époque.

Et ça va de mal en pis : en 2020, d’autres chercheurs estiment que la 4G LTE est complètement trouée et qu’il faudrait tout changer (émetteurs et récepteurs, donc toutes les antennes radios actuels et tous les smartphones actuels). Il n’y a que moi que ça inquiète ?

Icons made by photo3idea_studio from www.flaticon.com

Ghost

Ghost est une vulnérabilité touchant une libraire Linux, qui a été détectée puis… rien. Il a fallu plus d’un an et demi pour que cette faille soit prise en compte.

Liens

  • http://securityintelligence.com/wordpress-ghost-vulnerability
  • http://www.tomshardware.fr/articles/ghost-faille-linux-glibc,1-55391.html