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

lundi 18 novembre 2013

Le minimum vital pour sécuriser son Raspberry Pi

Les premières précautions se prennent directement via le menu de configuration sudo raspi-config On change son mot de passe si on ne l'a pas déjà fait.

On s'assure de désactiver le boot en mode desktop puisqu'on ne va pas utiliser l'interface graphique (option "enable boot to deskop").

Et comme on vient de désactiver la GUI on peut réduire la part de RAM utilisée par le GPU à 16Mo (option "memory split").

On s'assure d'être à jour niveau source sudo apt-get update
sudo apt-get upgrade
Ensuite on va se débarrasser du compte utilisateur par défaut (pi). On peut pour cela en créer un autre avec les mêmes groupes puis supprimer ou le désactiver le compte pi. J'ai préféré cependant récupérer le compte existant en le renommant. Pour cela on va devoir se loguer en root mais la connexion par ce compte est désactivée par défaut (cf le signe * à la place du hash du mot de passe dans /etc/shadow). root:*:15973:0:99999:7::: On va donc créer un login root par la commande suivante: sudo passwd root Qui ajoute le hash du mot de passe dans le fichier /etc/shadow root:$6$4SHHg7....kjIIHGYTL/:16027:0:99999:7::: Maintenant qu'on a un autre compte que le compte pi on peut se déconnecter et se reconnecter en tant que root. Puis on renomme le compte pi: usermod -l phi pi Et on transfère le compte home associé ainsi que son contenu usermod -m -d /home/phi phi Par précaution on re-désactive le login en compte root par: sudo passwd -l root Notez le point d'exclamation ajouté au début du hash et qui le rend donc inopérant: root:!$6$4SHHg7....kjIIHGYTL/:16027:0:99999:7::: Pour finir on va désactiver la possibilité de se connecter en root par ssh en éditant /etc/ssh/sshd_config: PermitRootLogin no
Puis: /etc/init.d/ssh restart
Ne pas oublier de faire une sauvegarde régulière du contenu de sa carte SD: fdisk -l (sous linux)
diskutil list (sous OSX)
puis:
sudo dd if=/dev/rdisk1 bs=1m | gzip > backup.gz (sous osx disk1 donne rdisk1)
que l'on pourra restaurer comme ceci gzip -dc /path/to/backup.gz | sudo dd of=/dev/rdisk1 bs=1m

lundi 11 novembre 2013

Son propre serveur mail sur Raspberry Pi grâce à iRedmail

Récemment j'ai fais le tour de l'excellent site Prism Break qui a le mérite de lister de manière concise et claire tout un tas d'outils connus uniquement des personnes avisés en sécurité informatique.

Parmi les liens j'ai pas mal étudié l'article suivant "NSA proof email in 2 hours" qui explique comment monter son propre serveur mail avec Postfix et Dovecot. Alors OK ça fonctionne, j'ai essayé, mais franchement c'est un pur truc d'autiste, on est dans la caricature du linuxien avec autant de commandes à taper. J'ai donc opté pour une solution beaucoup plus simple grâce au script iRedmail, et très peu onéreuse puisque fonctionnant sur un Raspberry Pi.

Le problème d'iRedmail est qu'on est totalement spectateur de l'installation et qu'au moindre problème on ne sait pas trop par où recommencer. Le script est clairement destiné à une machine fraîchement installée.

On commence donc avec une installation vierge de Raspbian que l'on prépare en changeant le mot de passe SSH (pi / raspberry par défaut), en étendent la partition à toute la SD et en paramétrant son hostname: (ex: myhost.dyndns.org). On peut tout faire à partir de: sudo raspi-config Ensuite j'ai eu quelques modifications à faire pour que le script iRedmail fonctionne sur le Raspberry.

Premièrement, iRedmail requiert officiellement 1Go de RAM. Je n'ai pas voulu perdre de temps à essayer avec moins donc j'ai suivi ce tuto pour installer zram et virtuellement doubler ma RAM (j'ai un raspberry model B). Résultat après l'installation de zram: pi@myhost ~ $ free -m
         total used free shared buffers cached
Mem: 438   53    384   0         8         23
-/+ buffers/cache: 22 416
Swap: 538   0     538
Ensuite la première fois que j'ai lancé le script j'ai été confronté à l'erreur suivante: dpkg: error processing dovecot-pop3d (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
dovecot-imapd
dovecot-sieve
dovecot-managesieved
dovecot-pop3d
E: Sub-process /usr/bin/dpkg returned an error code (1)
Et j'ai découvert qu'il fallait installer ipv6 pour que Dovecot s'installe correctement. La FAQ du raspberry donne la solution suivante pour activer l'ipv6 sudo modprobe ipv6 (activation immédiate)
ajouter une ligne ipv6 à /etc/modules (démarrage auto au boot)
Enfin pour des raisons de support et de manque de test, iRedmail ne supporte pas officiellement la plateforme ARM. Pour forcer l'installation il faut modifier le test d'architecture dans le script ./conf/global en ajoutant le cas armv6l case $arch in
    i[3456]86) export ARCH='i386' ;;
    x86_64|amd64) export ARCH='x86_64' ;;
   + armv6l) export ARCH='armhf' ;;
    *)
       echo "Your architecture is not supported yet: ${arch}."
      ! echo "Arm, i386 and x86_64 are supported by ${PROG_NAME}."
       exit 255
    ;;
esac
On est enfin prêt pour lancer le script: sudo bash iRedmail.sh Et à la fin de l'installation on n'oublie pas de supprimer le fichier de config temporaire qui contient nos mots de passe: rm /home/pi/Install/iRedMail-0.8.5/config Pour des raisons de performance et parce que je n'en avais pas besoin j'ai également désactivé l'antivirus ClamAV avec: Dans /etc/amavis/conf.d/50-user commenter:

#@bypass_virus_checks_maps = (
#    \%bypass_virus_checks,
#    \@bypass_virus_checks_acl,
#    $bypass_virus_checks_re,
# );

Puis:

sudo /etc/init.d/clamav-daemon stop
sudo /etc/init.d/clamav-freshclam stop

sudo update-rc.d -f clamav-daemon remove
sudo update-rc.d -f clamav-freshclam remove
Dans le futur peut être qu'arkos présentera une alternative intéressante et plus simple à mettre en neuve. Pour le moment Raspbian et iRedmail ont le mérite d'être des systèmes plus éprouvés.

jeudi 3 octobre 2013

Tempest, fuite d'information, interprétation du rayonnement ambiant

Présentation surprenante de Melissa Elliott à la conférence Defcon 21 concernant l'analyse du bruit ambiant produit par les sources de rayonnement de toute sorte.

Sa présentation se base sur l'utilisation d'une clé USB TV transformable en SDR du pauvre et déjà évoquée en détail dans des billets précédents sur ce blog.

Avec cet outil elle tente de reconstituer l'image d'un PC portable uniquement en interprétant le bruit radio émis par cet ordinateur chinois bas de gamme (bas de gamme = pas de blindage, chinois = absolument aucune conformité aux normes européennes d'émission).

C'est le même principe que le légendaire Tempest qui permet depuis l'arrivée des écrans cathodiques, et encore aujourd'hui avec les LCD, de recomposer précisément une image rien qu'en captant passivement le rayonnement émis par cet écran ou son câble d'alimentation.

Avec sa petite SDR, Melissa Elliott détecte un pic radio correspondant à la fréquence de l'horloge du PC, ainsi qu'un autre qui correspond au taux de rafraîchissement de l'écran (480x800x24x60Hz, résolution x nombre d'images par seconde x taux de rafraîchissement).

A noter que cela fonctionne également écran éteint puisque c'est en partie le câble du signal vidéo qui participe à la fuite d'information.

Dans le même genre d'application, on peut imaginer une base de données d'appareils électriques courants et de leur niveau et type d'émission selon leur activité. Grâce à cette emprunte numérique on pourra ensuite les identifier à distance ainsi qu'en déduire leur activité en temps réel. Les smart grid et autres compteurs électriques intelligents sont en partis basés sur ce principe. Un tel compteur peut très bien identifier les différents appareils connectés sur le réseau électrique de votre foyer, ainsi que l'utilisation que vous en faîtes.

Encore plus surprenant, l'analyse d'un disque dur, de l'activité de la RAM, ou du champ capacitif d'un écran tactile.

A ceci s'ajoutent les possibilités d'écoute plus classiques, mais souvent ignorées, des claviers bluetooth, des micros sans fil, etc.

Installer Kali Linux sur Android

Kali pour faire simple c'est Backtrack 6 et c'est très facile à installer sous android qu'ils vous disent. Et bien moi j'ai eu pas mal de pépins donc voici ma procédure et mes déboires.

J'ai installé Kali sur une carte SD, pour pouvoir avoir plus de place et pour la transférer d'un téléphone à l'autre sans avoir à tout réinstaller. Par précaution j'ai formaté la SD en ext4. Ensuite il faut installer Linux Deploy du Google Play et créer un profil Kali Linux

Sélectionner la distribution Kali Linux, paramétrer 8go de taille de disque pour être tranquille (4Go par défaut) et sélectionner la distribution compilée en armhf. L'armhf est une architecture qui supporte l'ARMv7 et est plus performante que l'armel, notamment grâce à la disponibilité d'instructions hardware sur les nombres à virgule. L'armel lui est plus compatible avec l'ancien matériel mais vous pouvez très probablement vous en passer

C'est le moment de cliquer sur "Install Linux Distribution", et c'est là que je me suis payé l'erreur suivante:
"
Mounting partitions:
/ ... fail
<<< end: install
"
Là j'ai galéré, repartionné ma SD card sous Linux en ext2 avec DiskUtility, tenté la formatter directement en adb shell sous android:
mk2fs /dev/mmncblock1 J'ai tenté de forcer le mount de la SD en read/write (mmcblock1p1 fait référence à la parition 1, mmcblock1p2 à la partition 2 car au final j'ai séparé ma SD en une partition ext2 et une en fat)
umount /efs
mount -o rw -t ext2 /dev/mmcblock1p1 /storage/sdcard1
Puis finalement après quelques reboot et réinstallation de Linux Deploy l'installation s'est lancée correctement donc et je ne suis pas sur du tout persuadé que mes manipulations précédentes en ai été la solution.

Quoiqu'il en soit une foit installée vous pouvez accéder à votre distribution Kali par SSH et par VNC. Soit en local directement sur le téléphone avec un client terminal ou VNC ou par l'intermédiaire d'un PC.

Si vous passez par un PC vous pouver vous connecter à votre téléphone via le cable usb en prenant soin d'exécuter les commandes suivantes sur le PC:
adb forward tcp:2222 tcp:22
adb forward tcp:59000 tcp:5900
Ensuite vous pouvez attaquer le localhost du PC comme si c'était votre téléphone android:
ssh android@localhost -p2222 A noter que le couple login/mot de passe installé par défaut n'est pas l'habituel root/toor propres aux distributions backtrack mais android/changeme

lundi 9 septembre 2013

Protéger toute sa maison avec un VPN au niveau routeur.

De plus en plus d'appareils autres que des PC ou des smartphones sont connectés. Consoles de jeux, télévisions, appareils photos, etc; peuvent désormais accéder au net. On se doute cependant que ces appareils, dont la connexion internet n'est pas la fonction première, sont bourrés de failles de sécurité. De plus ils ne disposent pas de la même exhaustivité de paramétrage que leurs ainés. L'IPV6 ou le WPA2 ne seront peu être pas supportés par exemple. Le VPN fait parti des spécificités de connexion que ces appareils ignorent. La seule solution passe alors par la tunnelisation générale au niveau du routeur.

Tunneliser par VPN l'ensemble des appareils branchés sur sa box a de nombreux avantages:

- plus besoin de paramétrer chaque appareil séparément
- possibilité de protéger des appareils ne supportant pas le VPN
- pas de risque de connexion en clair en cas de chute de la connexion car la connexion est directement au niveau WAN.

Ce montage est simple a réaliser avec un routeur flashé en DD-WRT.

Pour ce faire j'ai choisi d'utiliser la solution Wan Setup -> PPTP mais on peut également utiliser le service OpenVPN client pour encore plus de sécurité (le PPTP a quelques faiblesses cryptographiques). L'option Wan PPTP ne fonctionne que si le routeur DDWRT est un routeur secondaire. On aura donc le montage suivant: WAN ---- BOX  |---- PC 1 (192.168.1.100)
                    |-----PC 2 (192.168.1.101)
                    |-----DDWRT(192.168.1.102)  |----- PC 3 (192.168.2.100)
                                                             |----- PC 4 (192.168.2.101)
                                                             |- - -
On a avec cette installation deux sous réseaux différents, l'un se connectant en clair à Internet, l'autre redirigeant tous ses clients via un VPN. Si l'on a activé le WIFI sur les deux routeurs (la box et le dd-wrt) on pourra au choix se connecter sur le réseau en clair ou protégé.

On peut vérifier que l'on est bien connecté au VPN sur la page status / WAN de l'interface d'administration du DDWRT

mercredi 21 août 2013

Utiliser un smartphone en tant qu'oscilloscope

Quand on touche au hardware même très simple, un oscilloscope peu s'avérer très utile pour analyser ou vérifier le bon fonctionnement d'un montage. On en trouve d'occasion sur ebay pour moins de 100€, il en existe des portatifs neufs pour la même somme, ainsi que des modules USB à connecter sur un PC. Une alternative récente est d'utiliser son smartphone comme interface utilisateur de l'oscilloscope.

Côté Apple on a la société Oscium Oscium qui avait déjà attiré mon attention avec leur analyseur de spectre Wipry. A l'époque j'avais résisté à l'envie de l'acheter car malgré l'aspect très technologique et futuriste de l'interface et du capteur, les spécifications n'étaient pas à la hauteur et j'avais opté plutôt pour une SDR de bonne facture au même prix (Funcube Pro+)

Les produits de Oscium n'en restent pas moins très intéressants. Parmi ceux ci le iMSO-104 est un oscilloscope à signal mixte (analogique et digital) très bien fini et facilement accessible d'usage. Ils ont même un analyseur logique ! ;-D Par contre les prix ne sont absolument pas adaptés aux alternatives du marché (300€ pour l'oscilloscope iMSO-104)

Oscium imso 104 iphone 1

Côté Android, rien de surprenant, les offres sont plus open sources et mains dans le cambouis avec par exemple cet intéressant projet open hardware : l'Osciprime de la société Nexus Computing. Cet appareil fonctionne avec l'application OsciPrime Oscilloscope disponible sur le Google Play. Dans cette vidéo les auteurs présentent leur projet:


A défaut de posséder un appareil de saisi comme le iMSO-104 ou l'Osciprime, on trouve des applications encore plus simples sur les markets mobiles qui permettent d'utiliser la prise jack du téléphone comme entrée de données. Parfois les applications qui supportent un appareil USB dédié supportent aussi la prise jack. C'est le cas de l'application Osciprime.

Dans ce contexte d'utilisation de la prise jack micro, le montage le moins cher et le plus simple est l'oscilloscope à zéro dollar qui permet de réaliser un appareil de mesure basique pour un voltage compris entre 0 et 20V.

Un peu plus perfectionné on à ici un préamplificateur qui permet de supporter un plus grand domaine de voltage et surtout de protéger l'électronique du téléphone en cas d'erreur.

Dans tous les cas ces montage exploitant la prise jack sont limités par le convertisseurs analogique digital (ADC) du téléphone qui selon toute logique est destiné au traitement d'un signal vocal et donc plafonné à 44Khz de capacité d'échantillonnage.

mardi 9 juillet 2013

Utilisation de Lime Memory Extractor

La compilation de l'outil est l'étape la plus pénible, son utilisation est simple et bien expliquée dans la documentation. Pour lancer Lime sur votre mobile Android: adb push lime.ko /sdcard/lime.ko
adb forward tcp:4444 tcp:4444
adb shell
su

insmod /sdcard/lime.ko "path=tcp:4444 format=lime"
Ensuite côté PC pour récupérer le fichier de RAM: nc localhost 4444 > ram.line En lançant la commande insmod, Lime se lance directement et ne vous rendra le prompt que lorsqu'il aura extrait toute la mémoire via adb. Selon la quantité de RAM de votre téléphone (512Mo ? 1 ou 2 Go ?) cela peut prendre plusieurs minutes. Lime prend soin de n'allouer que 4ko de mémoire pour ses propres besoins et extrait toute la mémoire par ces 4Ko fixes afin de s'assurer de ne pas modifier la RAM par son propre fonctionnement. Dans le pire des cas on perdra donc uniquement ces 4Ko d'information. En référence, cette thèse en anglais sur le sujet de l'extraction de mémoire et l'utilisation de Lime en particulier, est intéressante.

lundi 8 juillet 2013

Dump mémoire sous Android

Une application mobile est sécurisée à un premier niveau par la compartementalisation du contexte d'exécution. Ensuite, si le développeur a fait son travail sérieusement, le code est robuste aux exploitations diverses et les échanges réseau sont chiffrés. On peut rajouter une couche de protection en chiffrant les fichiers sauvegardés (se pause alors le problème du stockage de la clé). En admettant que la sécurité des éventuels serveurs distants est garantie, il existe encore un espace ou toutes les informations que l'application cherche à protéger peuvent se retrouver en clair. Dans la mémoire vive de votre mobile. Dumper la mémoire de linux dans un fichier a toujours été possible par des moyens divers et de moins en moins simple pour des raisons de sécurité. Android cependant, est un peu différent et c'est pour cela qu'un certain Joe Sylve a développé Lime (Linux Memory Extractor, un outil spécifique à cet OS.

La documentation de Lime est assez claire mais elle date un peu et j'ai personnellement eu quelques problèmes à le faire fonctionner. Premièrement il faut le compiler spécifiquement pour votre noyau. Pour cela vous aurez besoin des sources du noyau tel que compilé par le constructeur. Par exemple ici pour Samsung. Théoriquement vous avez besoin uniquement de la config du noyau mais j'ai eu besoin de le compiler (sans pour autant l'installer) afin d'avoir un environnement permettant de compiler le module. Pour récupérer la configuration du noyau plusieurs méthodes.

Si vous avez de la chance la configuration est directement disponible sur votre mobile. adb push /proc/config.gz . Sinon vous pouvez tenter de l'extraire de l'image du noyau split_bootimg.pl boot.img
extract-ikconfig boot.img-kernel
Ou alors trouver la configuration dans le package de source du noyau en fonction du nom de code de votre téléphone. Les configurations se trouvent dans: /arch/arm/configs/XXXX_defconfig
J'ai utilisé la troisième solution et préparé les sources en compilant le noyau avec: make XXXX_defconfig
make
Lime se présente sous la forme d'un module noyau (.ko). Le plus pénible a été de trouver les bonnes commandes pour le compiler. J'ai retravaillé le makefile fournit avec les sources de Lime. La partie importante est la suivante: PWD := $(shell pwd)
KERNEL_PATH := /home/root/mydevice_kernel_src
GCC_PATH := /ndk-r8d/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/

$(MAKE) -C $(KERNEL_PATH) M=$(PWD) EXTRA_CFLAGS=-fno-pic CROSS_COMPILE=$(GCC_PATH)/arm-linux-androideabi- modules
Le paramètre important qui n'était pas dans la doc est l'argument -fno-pic sans lequel j'avais un "lime: Unknown symbol _GLOBAL_OFFSET_TABLE_ (err 0)" en chargeant le module. J'ai aussi eu un "File not found" alors que le lime.ko était bien présent mais c'est parce que j'avais utilisé le mauvais compilateur et insmod n'était pas très explicite sur la raison du problème.

lundi 24 juin 2013

Notes perso sur les composants de sécurité sous Linux (et donc en partie sous Android)

Principe des anneaux de sécurité:

Plus le numéro de l'anneau est faible plus il a de privilèges. Le noyau s'exécute dans l'anneau 0, Les drivers dans l'anneau 1 et 2, Les applications utilisateur dans l'anneau 3

Techniquement l'utilisateur root peut presque tout faire mais a légèrement moins de privilèges que le noyau

Isolation par les comptes utilisateurs:

Il est courant de créer un compte utilisateur par service (mysql, apache, ...) afin de ne donner à chaque service que le minimum de privilège nécessaire pour fonctionner. Pour interdire que quelqu'un se connecte en utilisant un de ces comptes utilitaires le shell est paramètré à /bin/false

Notion d'utilisateurs et de groupes:

Possibilité pour chaque fichier de spécifier les droits en lecture/écriture/exécution pour le propriétaire du fichier, pour son groupe, pour les autres. chown, chgrp, chmod Mots de passe

/etc/passwd contient la liste des utilisateurs. Historiquement il contenait le hash des mots de passe maintenant déportés dans /etc/shadow car /etc/passwd doit rester accessible à tous les utilisateurs pour d'autres fonctionnalités.

/etc/shadow contient les hashs des mots de passe et n'est accessible que par root.

chroot

chroot permet de changer le répertoire root courant. Pratique par exemple quand vous bootez d'un live cd et que vous voulez vous connecter en tant que root à une autre installation (ça sert à réinitialiser le mot de passe root d'une installation linux notamment) chroot permet de restreindre un processus à un répertoire racine. Sorte de virtualisation/sandboxing très basique au niveau de l'OS. Contournable. Autres système de virtualisation propriétaires disponibles. setuid, setgid

Les flag setuid et setgid, modifiables par la commande chmod permettent à des exécutables de s'éxécuter avec les privilèges d'un autre compte que celui du propriétaire. Par exemple chpasswd a un accès root quelque soit l'utilisateur qui l'exécute. Pour lister tous les exécutables en setuid root find / -perm -4000 -print Tout est traité sous la forme de fichier

Les périphériques sont traitées comme des fichiers que l'on peut lire et écrire. Ils sont accessibles dans /dev /proc est un répertoire virtuel qui permet d'accéder à des informations sur le système, le matériel, le noyau, ...

Access Control List

Access Control List étend la gestion des droit d'accè au delà de user/groupe/autre et permet un filtrage plus précis et plus complexe. Par exemple permet de définir une liste d'utilisateurs qui peuvent accéder à un certain répertoire. Pas installé par défaut.

Attribus de fichier

lsattr, chattr chattr +i rend un fichier inchageable même par root.
chattr +a (ajout seulement, impossible d'effacer le contenu du fichier) ACL et chattr utilisable uniquement par root par défaut

iptables

Le firewall le plus fréquent sous Linux.

lundi 6 mai 2013

Détecter que l'on sniffe votre trafic SSL/HTTPS

Tout trafic non chiffré en http classique peut être intercepté, analysé, remanié, etc.

La solution est donc de passer par du http sécurisé ou https. Pour intercepter ce trafic, un hacker devra réaliser une attaque dite de l'homme du milieu (man in the middle / MITM) en se plaçant entre vous et le serveur afin de fournir à votre navigateur un certificat SSL bidon. Ce certificat SSL bidon est créé par le pirate lui même, il pourra donc déchiffrer tout trafic chiffré par ce certificat. Tout navigateur digne de ce nom détectera l'invalidé du certificat et en préviendra l'utilisateur. Neuf personnes sur dix cliqueront pour juste faire disparaître le popup mais l'utilisateur averti ne se fera pas berné.

Il existe un cas plus difficile a détecter et c'est lorsque vous utilisez un PC qui n'a pas été installé par vous, typiquement au travail. Très souvent les PC de travail sont installés avec un certificat en plus qui permet au PC de s'authentifier auprès de l'intranet. Jusque là rien d'anormal. Sauf que l'existence de ce certificat officiellement reconnu par votre navigateur permet justement par effet de bord de se placer en position d'homme du milieu. Et ici pas de popup d'avertissement. Tout le trafic chiffré par ce certificat sera accepté sans broncher par votre navigateur. Il n'est pas dit que votre entreprise se livre à ce genre d'interception, mais elle en a la possibilité.

L'utilisateur averti pourra vérifier manuellement que les certificats utilisé pour se connecter sur des sites connus (Google, Yahoo, …) sont bien issues par ces sociétés. Mais pour faciliter cette détection Steve Gibson de GRC vient de publier un outil bien pratique. La page en question vous donne le hash de certains sites connus, tels que vu par les serveur de GRC. Le jeux consiste donc à afficher le hash des même certificats, vu de votre PC et de comparer. Si le hash est différent c'est que votre trafic SSL est intercepté et passe en clair quelque part sur le réseau de votre entreprise. Le principe de cet outil repose sur le fait que s'il est possible de confectionner un faux certificat pour n'importe quel site, il est quasiment impossible, disons très difficile, d'en réaliser un avec le même hash.

mercredi 1 mai 2013

Booster sa voiture grâce au port OBD

Pas trop le temps de mettre à jour le blog ces derniers temps. Je profite juste d'un petit moment de tranquillité pour poster un lien vers une video abordant mon obsession du moment à savoir le port OBD (On Board Diagnostic) des véhicules.

Rendu obligatoire sur toute automobile depuis 1996, le port OBD a suivit l'évolution technologique des voitures et c'est transformé d'un simple port de diagnostique à une accès direct à la reprogrammation de l'ECU de la voiture.

La vidéo en question aborde une des applications les plus intéressantes de la reprogrammation de l'ECU à savoir gagner en puissance et en performance. Pour faire court, le moteur de votre voiture est paramétré par le constructeur pour minimiser les pannes, garantir sa fiabilité, réduire sa consommation, ... Il est donc possible en optimisant certains paramètres d'exploiter le moteur à son vrai potentiel (en perdant les avantages décrits plus haut bien sur et en risquant de ruiner sa voiture si l'on ne sait pas ce que l'on fait).

Au delà de la simple reparamétrisation certains vont jusqu'à réécrire leur propre firmware comme par exemple ici Open ECU

A noter que l'auteur de cette video Aaron Higbee, fait partit du groupe Intrepidus Group cher à mon coeur car ils sont actif dans le domaine de la sécurité mobile et du NFC.

Le PDF de la présentation est disponible ici

samedi 16 février 2013

BYOD et sécurisation des mobiles

Le BYOD ou Bring Your Own Device identifie la tendance de ces dernières années qui fait que les gens partagent leur téléphone (ou PC) entre un usage pro et un usage perso. Cette situation est évidemment un cauchemar au niveau sécurité et confidentialité; d'où l'apparition récente de plusieurs solutions pour sécuriser et isoler l'environnement pro de l'environnement perso.

Les différentes solutions reposent sur des principes similaires. Soit on offre un téléphone spécifique complètement sécurisé, soit on propose d'isoler complètement la partie pro sur un téléphone grand public. Pour ce faire on va créer une sorte de "machine virtuelle" en encapsulant les applications professionnelles afin de sécuriser tous leurs échanges de données locales ou à distance, data ou voix. Dans ce dernier cas, le fournisseur fournit en général sa propre solution de serveur VPN sur lequel le client mobile peut venir se connecter. Le serveur permet parfois une administration à distance de la flotte. Les technologies utilisées reposent généralement sur du SSL, du VPN, du SIP + TLS et du SRTP.

Parmi les solutions déjà existantes nous avons de grosses sociétés françaises:

Casidian Cybersecurity et son offre Moseo Smart déjà disponible sur iPhone, Android et Blackberry. Solution classée "Top Secret" niveau sécurité.

 Thales Communication & Security et son offre Teopad. Fonctionne uniquement sur Android pour le moment et permet d'utiliser des applications standards de l'Android Market mais dans un environnement complètement sécurisé.

Bull via sa filiale Time Reversal Communications qui propose le SPhone. Ici il s'agit d'un téléphone bien spécifique qui n'est même pas un smartphone. On se doute qu'il est probablement plus sécurisé d'utiliser un téléphone conçu spécialement pour cela mais ce type de solution ne répond pas vraiment aux problèmes réels des sociétés.

Evidemment les Etats Unis ne sont pas en reste:

A commencer par la NSA elle-même, qui développe sa propre version sécurisée d'Android. Le système utilise une carte SIM data uniquement, la seule exception aux communications non chiffrées étant les appels d'urgence, mais le moindre appel au 911 entraîne une réinitialisation complète du téléphone.

Ceux qui veulent pousser l'étude un peu plus loin pourront potasser les recommandations de la NSA pour les objectifs de sa solution dans son Mobility Capability Package v2.0. Le document décrit de manière pragmatique comment communiquer de manière sécurisé avec un téléphone grand public. Ils insistent notamment sur:
  • La nécessité d'utiliser deux niveaux de chiffrement. Ex: IPSec + Voix/Data chiffrée.
  • Le besoin d'une infrastructure à clé publique (PKI) gouvernementale.
  • Le fait que ces solutions ne deviennent réalistes que sur des réseaux haut débit (3G+/4G minimum).
A noter également l'existence du projet ZPhone de Phil Zimmermann le créateur de PGP lui même. Je n'ai pas eu le temps d'étudier cette solution pour le moment mais la notoriété de son auteur mérite de s'y intéresser.


Pour finir, RIM la société Canadienne, qui est le seul constructeur de mobile à proposer nativement ce genre de solution avec son Blackberry Balance.


Si vous voulez en savoir plus sur les autres solutions disponibles et leur principe de fonctionnement je vous conseille l'étude Garner Technology Overview of Mobile Application Containers for Enterprise Data Management and Security.

dimanche 3 février 2013

VPN et partage de connexion sous OSX

Petite subtilité que je viens de découvrir sous OSX. J'ai un Mac sous OSX 10.8.2 Mountain Lion connecté au net via ethernet et j'utilise la fonction de partage de connexion pour partager l'ethernet via le WiFi de mon Mac. J'utilise mon iPhone comme client de la connexion partagée.

Lorsque je suis en déplacement, j'utilise un VPN via la fonction de base d'OSX (pas de client tiers tel que Tunnelbclick, qui est bourré de failles de sécurité cela dit en passant). Hors, j'ai réalisé que si l'hôte OSX est bien connecté via le VPN, le trafic de la machine cliente (mon iPhone) ne passe par le VPN de l'hôte.

J'ai joué avec les options "Send all traffic over VPN connection / Envoyer tout le trafic sur la connexion VPN" ainsi qu'avec l'ordre de priorité des interfaces "Set service order / Définir l'ordre des services" sans succès. Ces critères ne semblent avoir aucun effet sur mon problème de départ.

En fait on peut spécifier dans les paramètres de partage, quelle connexion on veut partager et il faut sélectionner l'interface virtuelle correspondant à votre VPN pour que le client en profite aussi.

Une alternative consiste à abandonner le VPN sur l'hôte et à configurer le VPN côté client WiFi.

A noter que je n'ai jamais réussi à faire fonctionner cette fonction sous Windows sans recourir à une application tierce telle que CCProxy. Sous Windows lorsque l'on utilise le partage une connexion, Windows reconfigure l'interface partagée en lui associant d'office une IP (192.168.1.1 de mémoire). Hors cette IP rentre en conflit avec l'IP attribuée précédemment par DHCP par la box ou le routeur sur lequel est connectée la machine Windows. Vous avec donc réussi à mettre la machine partagée et son client en réseau mais par la même occasion vous avez détruit la connexion Internet d'origine. Si quelqu'un a une solution à se problème je suis preneur. (Autre que reconfigurer le routeur pour que le DHCP fournisse la bonne adresse à Windows).