mardi 17 décembre 2013

Enfin un podcast français sur la sécurité informatique

Quelle bonne surprise de découvrir ce nouveau podcast, le Comptoir Sécu ! Moi qui écoute depuis des années des dizaines de podcats dans tous les domaines je ne peux que regretter le manque de choix dans notre langue; et lorsque j'en trouve, le manque de qualité. C'est dotant plus dommage que la cyber sécurité est un domaine ou la France a de très bonnes compétences malgré la naïveté/malhonnêteté de nos gouvernements face au sujet.

J'ai écouté les deux derniers épisodes du Comptoir Sécu et j'ai été agréablement surpris. Le côté buvette de la cyber sécurité me rappelle le format PaulDotCom. Bravo les gars !

Comptoir sécu 1

lundi 16 décembre 2013

Prise de contrôle de l'électronique d'une voiture via ses ECU

Des voitures, du hacking, une présentation humoristique de Charlie Miller et Chris Valasek, que rêver de mieux ! Les deux compères se sont attaqué entre autres à une Toyota Prius dont ils arrivent à contrôler un bon nombre de fonctions purement électroniques (compteur de vitesse, jauge d'essence, ...) mais également des actions physiques telles que le contrôle du volant, l'accélération, le pré serrage des ceintures. A noter que s'ils parviennent à faire tourner le volant c'est parce que la voiture est équipée d'un système d'assistance au stationnement et donc de la mécanique pour actionner le volant électriquement.

Démonstration de l'assistance au stationnement (park assist) sur une Peugeot 208

Dans leur présentation exhaustive ils citent comme principale source d'information l'étude Comprehensive Experimental Analyses of Automotive Attack Surfaces que j'avais déjà commentée lors d'un billet fin 2012.

Leur contrôle du véhicule reste assez chaotique du fait qu'ils ne maîtrisent pas directement le firmware ECU. Pour agir sur le comportement de la voiture ils injectent des messages sur le bus CAN mais leurs paquets sont mélangés à ceux, officiels de la voiture et le mélange des deux peut provoquer des résultats inattendus. Dans la présentation on les voit devoir "rebooter" la voiture, mais aussi la briquer et devoir l'emmener au garage.

La présentation video: Defcon 21 - Adventures in Automotive Networks and Control Units


dimanche 15 décembre 2013

SELinux sur Raspberry Pi (recompilation du noyau)

La configuration par défaut du noyau du Raspberry Pi ne permet pas de faire fonctionner SELinux. Il est donc nécessaire de préalablement recompiler un noyau. Ma principale source d'information pour la compilation a été la page suivante. Ainsi que ce billet pour les options de compilation à ajouter.

On peut compiler directement sur Raspberry mais il faut compter une demi journée de compilation. J'ai donc choisi de compiler sous une VM Ubuntu. J'avais installé une Ubuntu x64 par habitude mais j'ai réalisé qu'il aurait été plus pratique de compiler sous un OS 32 bits comme le Raspberry Pi.

Pour pouvoir compiler un noyau 32 bits sur un OS x64 j'ai du installer libc6-i386 pour éviter l'erreur "bmc-2708 no such file or directory". sudo apt-get install libc6-i386 J'ai également du installer tout l'environnement de compilation 32 bits sans lequel la compilation échoue dès le début avec un "libz.so.1: cannot open shared object file" sudo apt-get install ia32-libs Vient ensuite l'installation de l'environnement de compilation ARM. sudo apt-get install gcc-arm-linux-gnueabi make ncurses-dev Puis le téléchargement et installation des outils de compilation correctement paramétrés pour l'architecture matérielle du Raspberry Pi. Télécharger et extraire l'archive suivante. Comme l'explique la page officielle, ces outils ne sont théoriquement pas nécessaires mais leur utilisation évite d'avoir à correctement configurer ceux présents sur votre installation Linux existante. Les commandes suivantes assurent que ce sont bien les outils Raspberry Pi qui vont être pris en compte lors de la compilation: ln -s /home/myaccount/tools-master/arm-bcm2708/arm-bcm2708-linux-gnueabi/bin/arm-bcm2708-linux-gnueabi-gcc /usr/bin/arm-bcm2708-linux-gnueabi-gcc

export CCPREFIX=/home/myaccount/tools-master/arm-bcm2708/arm-bcm2708-linux-gnueabi/bin/arm-bcm2708-linux-gnueabi-

export KERNEL_SRC=/home/myaccount/linux-rpi-3.6.y
Une fois notre VM ainsi préparée on peut passer au téléchargement des sources sur le github officiel de Raspbian que l'on extraira dans /home/myaccount/linux-rpi-3.6.y précédemment cité.

Avant de compiler le noyau il faut le configurer et le plus simple est de repartir de la configuration que vous avez sur votre installation existante de Raspbian: scp pi@rpiaddress:/proc/config.gz ./ (transfert de la config sur votre Ubuntu)
zcat config.gz > .config
mv .config $KERNEL_SRC
make ARCH=arm CROSS_COMPILE=${CCPREFIX} oldconfig
Ensuite comme indiqué dans le le billet suivant, éditez à la main le fichier de configuration avec les paramètres ci-dessous: CONFIG_AUDIT=y
CONFIG_AUDIT_LOGINUID_IMMUTABLE=y
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
# CONFIG_SECURITY_SELINUX_DISABLE is not set
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
# CONFIG_DEFAULT_SECURITY_SELINUX is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_LOCALVERSION="-MonNoyau"
Notez la personnalisation de CONFIG_LOCALVERSION qui va permettre d'installer les modules recompilés dans un répertoire spécifique "/libs/modules/3.6.11-MonNoyau" plutôt que d'écraser les modules déjà présents. On conserve ainsi les deux versions en cas de problème.

Puis on compile et on exporte les modules dans un répertoire séparé en vue de leur installation sur le Pi. make ARCH=arm CROSS_COMPILE=${CCPREFIX}
make ARCH=arm CROSS_COMPILE=${CCPREFIX} modules
export MODULES_TEMP=~/modules
make ARCH=arm CROSS_COMPILE=${CCPREFIX} INSTALL_MOD_PATH=${MODULES_TEMP} modules_install
Reste à déplacer le contenu de ~/modules sur le Raspberry ansi que le noyau lui même vers /boot/kernel.img. Le site officiel parle d'installer arch/arm/boot/Image mais on peut également installer la version compressée arch/arm/boot/zImage.

Si on a personnalisé CONFIG_LOCALVERSION on peut facilement vérifier la prise en compte de son nouveau noyau après un reboot par la commande: uname -a Linux XXX.dyndns.org 3.6.11-MonNoyau #538 PREEMPT Tue Dec 10 22:40:16 BST 2013 armv6l GNU/Linux

mercredi 11 décembre 2013

SELinux sur Android

Au départ développée par la NSA, SELinux est une surcouche destinée à sécuriser Linux plus en profondeur. SELinux est intégrée par défaut dans à peu prêt toutes les distributions Linux depuis 2003. Elle est cependant désactivée par défaut ce qui fait que peu de gens l'utilisent.

SELinux introduit une couche de sécurité de type MAC (Mandatory Access Control) par rapport au système traditionnel DAC (Discretionary Access Control).

Le DAC c'est le système de sécurité classique de Linux, à base de comptes utilisateurs, de groupes, de permissions en lecture, écriture, exécution, ... Le problème de ce système est que la sécurité repose sur le bon paramétrage de chaque application, de chaque bibliothèque. Un utilisateur non concerné par la sécurité peut faire n'importe quoi et faire un chmod 777 sur tout son compte. De plus, en DAC l'utilisateur root est omnipotent. C'est ce que la commande sudo essaye de réguler justement.

Un système MAC est plus précis, plus bas niveau. Avec, il est possible de réguler l'accès aux sockets, à la mémoire, aux processus, etc. Sous SELinux la sécurité MAC surpasse la sécurité DAC. Ainsi un répertoire en 777 ne sera accessible qu'aux utilisateurs autorisés par le MAC. Typiquement, le répertoire home d'une utilisateur ne sera lisible que par lui, et ceci quelque soit les permissions linux classiques.

En DAC chaque développeur doit décider des permissions à donner à son application ainsi qu'aux données et fichiers de configuration utilisés ou générés par cette application. En MAC tout ceci est décidé par l'administrateur via une politique de sécurité générale.

Concrètement parlant SELinux fonctionne en associant à chaque fichier du système un ensemble d'attributs supplémentaires. On peut manipuler ces attributs via l'option -Z de nombreuses commandes systèmes classiques (ex: ls -Z) La politique de sécurité liste les comportements autorisés ou interdits et ces règles sont appliquées via ces attributs supplémentaires. Par exemple on aura une règle "Le serveur Apache ne peut pas accéder au fichier /etc/shadow"

Le point faible de SELinux c'est que tout repose sur la politique de sécurité, elle même complexe à écrire. Heureusement il en existe des déjà toutes faites très exhaustives.

Originellement introduit dans Android via Cyanogen, SELinux est désormais officiellement disponible sur l'AOSP Android depuis la 4.3. Attention cependant, elle n'est pas activée par défaut et même activée elle ne régule le fonctionnement que de quelques services systèmes. On est donc loin d'un OS correctement sécurisé. Pour le moment, n'en déplaise à certain, iOS (non jailbreaké) reste un OS plus sur.

Dans cette vidéo un responsable du projet à la NSA commente le portage de SELinux sur Android.

SELinux Android