AlgoBlog

Les actualités et nos conseils sur la sécurité

Tous publics
Afficher seulement les articles tous publics
Public technique
Affichement seulement les articles techniques

La vache qui root

Jonathan 25 octobre 2016 Public technique

Une faille corrigée peut réapparaître quelques années plus tard. C'est le cas pour une faille hautement critique découverte par Phil Oester dans le kernel Linux. La faille vieille de 9 ans est une élévation de privilège, c'est à dire qu'un utilisateur avec des droits restreints peut exécuter une action avec des droits administrateurs (root dans le cas présent).

Dirty COW

La vulnérabilité est surnommée Dirty COW en référence au mécanisme Copy-On-Write du noyau Linux. Elle correspond à la CVE-2016-5195. Comme écrit plus haut, il s'agit d'une faille permettant à un simple utilisateur d'exécuter des programmes avec les privilèges root. Cette faille est d'autant plus critique que :

  • Il est facile d'écrire un exploit, une liste de POC est disponible ici
  • La faille est présente dans quasiment toutes les différentes distributions Linux, on peut citer Debian, Ubuntu et certaines version de RedHat...

La faille a déjà été corrigée pour les distribution RedHat, Debian et Ubuntu, pour les autres il faudra attendre avec patience...

Fonctionnement

Dans le noyau Linux, lorsqu'un processus souhaite écrire dans un fichier, une copie de ce dernier est créée au moment de l'écriture : c'est le mécanisme de Copy-On-Write. La vulnérabilité est basée sur cette fonctionnalité. L'exploitation est décomposée en plusieurs étapes :

  • Récupérer l'adresse mémoire de la copie du fichier avec la fonction mmap(). Le contenu du fichier est "mappé" en mémoire.
  • Effectuer parallèlement deux actions à l'aide de 2 threads:
    1. La première action est une écriture en boucle dans la zone mémoire pour générer des copies (Cow) de la zone.
    2. La deuxième action est l'utilisation de la fonction madvice() avec l'argument MADV_DONTNEED. Ce dernier indique au système qu'il peut libérer la zone mémoire utilisée.

La combinaison de ces deux actions peut provoquer une race condition, c'est à dire que l'écriture est effectuée avant que la copie en mémoire soit créée.

La vidéo suivante permet de donner plus de détails techniques sur l'exploit et la faille en elle-même:

Démonstration

Je me connecte en tant que root, pour créer un fichier accessible uniquement en lecture

(jonathan)$ sudo -s
(root)$ echo "Je suis root, personne ne peut modifier ce fichier" > test_DirtyCow
(root)$ exit
(jonathan)$ ls -ltr test_DirtyCow
-rw-r--r-- 1 root root 51 oct.  26 11:02 test_DirtyCow
(jonathan)$ echo "Algosecure is the best!" > test_DirtyCow
-bash: test_DirtyCow: Permission non accordée

Je ne peux donc pas modifier le fichier avec mes droits actuels. Je vais maintenant utiliser le POC dirtyCow pour modifier le fichier

(jonathan)$ ./dirtyc0w test_DirtyCow "Algosecure is the best et peut réécrire le fichier            "
mmap 7f6921ee3000

madvise 0

procselfmem 2005032704
(jonathan)$ cat test_DirtyCow 
Algosecure is the best et peut réécrire le fichier
(jonathan)$ echo "Algosecure is the best!" > test_DirtyCow
-bash: test_DirtyCow: Permission non accordée

Le fichier a bien été modifié. Cependant si le contenu à écrire dans le fichier dépasse la taille réelle du fichier, l'écriture sera tronquée. Inversement, si le contenu est plus petit, alors seul les n premiers octets du fichier seront écrasés.

Ce test n'est pas significatif de la criticité de la vulnérabilité. Cependant, en modifiant un fichier comme /etc/shadow ou les exécutables /bin/ls, /bin/cat, /bin/ping les conséquences seraient beaucoup plus importantes.

Pour aller plus loin...

Cette faille ne touche pas uniquement les machines Linux, elle concerne également tous les terminaux Android. Ce lien explique comment procéder pour la version Android.

Implémenter correctement le HTTPS

Benjamin 16 septembre 2016 Public technique

Le HTTPS est la solution la plus simple pour fournir une couche de sécurité aux utilisateurs de son site ou application web. Mais il n'est pas toujours facile de correctement l'implémenter. Nous allons passer en revue les principaux écueils liés à ce protocole.

Qu'est-ce que le HTTPS ?

Le HTTPS est la version sécurisée du protocole HTTP. Il permet de se connecter à des sites Internet sans que le contenu des données échangées, ni même les URL complètes des sites visités, ne soit récupérables par un pirate informatique.

Toutefois, il ne suffit pas d'activer le HTTPS, il faut correctement le paramétrer. Chaque année, de nouvelles faiblesses sont découvertes dans le protocole TLS sur lequel se base le HTTPS afin de chiffrer les échanges de données. Ainsi, les administrateurs système doivent régulièrement faire évoluer les paramètres de sécurité afin de se parer d'éventuelles attaques.

Les différentes versions de SSL/TLS

Le protocole SSL (Secure Socket Layer) est apparu au milieu des années 90, avec pour but d'assurer l'intégrité et la confidentialité des données échangées, mais aussi l'authentification du serveur (et parfois, des clients). Deux versions ont été disponibles : le SSL v2 et le SSL v3. Ce protocole a rapidement été suivi par son évolution : le protocole TLS (Transport Layer Security), à partir du début des années 2000. Ce dernier connaît actuellement trois versions : TLS v1.0, TLS v1.1, TLSv1.2, et la version 1.3 devrait être disponible en 2017.

Utiliser le protocole SSL est aujourd'hui considéré comme non-sûr suite aux attaques DROWN (SSL v2) et POODLE (SSL v3). Le protocole TLS v1.0 a quant a lui été touché par l'attaque BEAST. Ainsi, il est recommandé de n'utiliser que les versions les plus récentes du protocole TLS : TLS v1.1 et TLS v1.2.

Les cipher suites, ou suites cryptographiques

Une suite cryptographique est un groupement d'algorithmes dont chacun va assurer la sécurité d'une partie de la communication entre un client et le serveur. Chaque suite se compose ainsi (source : Mozilla) :

  • d'un algorithme d'établissement des clés (comme RSA, DH, ou ECDH) ;
  • d'un algorithme d'authentification du tiers (comme RSA, DSA ou ECDSA) ;
  • d'un algorithme de chiffrement des données (comme RC4, DES, AES) et taille de clés ;
  • d'un algorithme de hachage permettant l'authentification et la vérification des messages (SHA1, SHA256).

La sécurité de ces suites cryptographiques dépend fortement de l'algorithme de chiffrement des données. En effet, c'est principalement lui qui est remis en cause ; on pense notamment à l'algorithme RC4, considéré comme obsolète suite à la découverte de plusieurs vulnérabilités. Plusieurs attaques affectent cet algorithme, dont la plus connue de toutes : Bar Mitzvah.

Au niveau des recommandations, Mozilla fournit sur son wiki une page pour déterminer la cipher suite la plus adaptée en fonction des contraintes de compatibilité de l'environnement étudié. Trois configurations-type sont ainsi disponibles : "Old", "Intermediate" et "Modern".

Les certificats

Un certificat est une carte d'identitié numérique permettent d'identifier un hôte. Il permet de s'assurer que l'on communique avec le bon serveur, et non un serveur contrôlé par un attaquant. On y lit notamment la période de validité du certificat, et l'autorité de certification qui a validé (ou signé) notre certificat. Il est nécessaire de faire attention à différents problèmes qui peuvent se poser par rapport au certificat par rapport aux propriétés suivantes :

  • la période de validité ;
  • la fonction de hashage ayant permis de signer le certificat ;
  • le sujet du certificat (dans le cas d'un site, il s'agit du nom de domaine) ;
  • l'autorité de certification ayant signé le certificat.

Si l'un de ces points n'est pas conforme, au mieux, le navigateur de l'utilisateur lui affichera un avertissement, et au pire, il empêchera l'accès au site. Bientôt, les navigateurs afficheront également un message d'erreur pour les certificats dont la signature a été générée avec l'algorithme SHA-1 plutôt que SHA-2. Il peut en effet être victime de collisions, c'est à dire qu'il est possible de générer un autre certificat avec exactement la même signature.

Il est donc recommandé de faire appel à des autorités de certifications reconnues et réactives par rapport aux normes de sécurité. Nous recommandons généralement Let's Encrypt ou StartSSL, qui ont l'avantage d'être gratuites.

La clé

Pour chiffrer les échanges, le serveur envoie son certificat à l'utilisateur, celui-ci contenant sa clé publique. Des faiblesses ont été trouvées suggérant que les clés de taille trop faibles pourraient mener les échanges à être déchiffrés, notamment par la NSA qui possède une forte puissance de calcul.

Il est aujourd'hui recommandé d'utiliser des clés d'une taille minimale de 2048 bits, voire de 4096 bits lorsque cela est possible.

La renégociation

Lors d'une connexion HTTPS, il arrive parfois que les paramètres de sécurité doivent être renégociés. Toutefois, laisser la possibilité aux clients de demander cette renégociation ouvre la possibilité pour un attaquant de forcer la renégociation à la baisse, pour que la connexion utilise des paramètres permettant un déchiffrement plus rapide des échanges.

Il est recommandé de désactiver la renégociation initiée par les clients, et d'activer le mode de renégociation sécurisée du serveur.

La compression

Le fait d'activer la compression sur le protocole SSL/TLS expose les données échangées à l'attaque CRIME, permettant notamment de récupérer des cookies de connexion via l'analyse statistique des paquets échangés entre un client et le serveur.

Il est recommandé de désactiver la compression sur le protocole SSL/TLS afin d'éviter cette attaque.

HSTS (HTTP Strict Transport Security)

Le HSTS est un mécanisme de sécurité assez récent. Il s'agit d'une instruction que le serveur renvoie aux navigateurs des clients, et qui leur indique que pendant une certaine durée (généralement plusieurs mois), ils ne doivent se connecter au serveur que de manière sécurisée.

Lorsqu'un navigateur se connecte pour la première fois à un site utilisant HSTS, il enregistre que pour ses futures visites, si la connexion au serveur ne peut pas s'établir de manière sécurisée (certificat expiré, nom de domaine différent du sujet du certificat...), la connexion doit tout simplement être bloquée. L'utilisateur ne pourra pas accepter le risque et passer outre l'avertissement de sécurité en ajoutant une exception.

Ce mécanisme permet de se prémunir des attaques de type Man in the Middle. En revanche, il y a deux inconvénients :

  • Cela nécessite que les administrateurs système puisse toujours garantir une connexion sécurisée au serveur. Par exemple, il ne faut pas que le certificat arrive à expiration, et ce n'est pas si facile.
  • Lors de sa première connexion au serveur, le client sera "vulnérable". En effet, ce n'est que lors de la première connexion que le client recevra l'instruction de la part du serveur, comme quoi la connexion doit être sécurisée. Un attaquant réalisant une attaque de type Man in the Middle dès la première connexion d'un client au site web pourra faire échouer ce mécanisme de sécurité.

Pour parer au deuxième inconvénient, il est possible de faire enregistrer son nom de domaine sur une liste qui est intégrée dans les navigateurs récents. Ainsi, le client sera en sécurité dès sa première connexion au serveur.

Conclusion

Nous avons passé en revue les principaux éléments de sécurité d'une connexion HTTPS. D'autres mécanismes existent, notamment TLS_FALLBACK_SCSV, pour éviter qu'un attaquant ne puisse faire baisser le niveau de chiffrement d'une connexion. D'autres mécanismes vont sans doute voir le jour.

Ainsi, il est important pour les administrateurs système de se maintenir au courant des nouvelles vulnérabilités trouvées, et sur les nouveaux mécanismes qu'il est possible de mettre en place afin d'assurer l'intégrité et la confidentialité des échanges client-serveur. En ce sens, AlgoSecure peut vous aider à analyser la configuration HTTPS de vos sites, à comprendre les problèmes détectés, et à mettre en place une configuration sécurisée.