Le système d'exploitation OpenBSD réputé pour sa robustesse (seulement deux vulnérabilités à distance dans l'installation par défaut, depuis très longtemps) aurait contenu des portes dérobées déposées volontairement par le FBI. Ces backdoors (portes dérobées) auraient été introduites dans le système d'exploitation il y a une dizaine d'années.

Rappelons qu'à l'époque ce système d'exploitation était celui des 13 serveurs DNS racine. En raison de l'expiration du délai de la clause de confidentialité signée avec le FBI, c'est Gregory Perry, un ancien contributeur du projet de cryptographie d'OpenBSD qui nous révèle ça.

Le but était de surveiller la circulation de données chiffrées, en insérant du code malicieux dans la pile réseau IPSEC d'OpenBSD. Theo de Raadt, le fondateur du projet OpenBSD, incite les utilisateurs de ce système à faire un audit du code concerné.

NdM : À ce jour, il est de rigueur d'être prudent : sur la liste de diffusion OpenBSD, Jason L. Wright explique que c'est un problème qui n'est plus d'actualité et relève de la légende urbaine. L'audit de code lancé par les développeurs a permis de trouver au moins deux bugs mais il serait hasardeux de les relier aux allégations de Gregory Perry. Pour plus de détails voir le nouveau mail de Theo de Raadt.

NdM 2 : A la suite des précisions apportées dans les commentaires de cette dépêche il s'avère que Gregory Perry n'a jamais été un contributeur du projet OpenBSD et que cet OS n'était pas installé sur les serveurs DNS racine.

Inverse, société spécialisée en développement et déploiement de logiciels libres, annonce la sortie de la version 2.0.0 de PacketFence. PacketFence est une solution de conformité réseau (NAC) entièrement libre, supportée et reconnue. Procurant une liste impressionnante de fonctionnalités telles un portail captif pour l'enregistrement ou la remédiation, une gestion centralisée des réseaux filaire et sans fil, le support pour le 802.1X, l'isolation niveau-2 des composantes problématiques, l'intégration au détecteur d'intrusions Snort et au détecteur de vulnérabilités Nessus - elle peut être utilisée pour sécuriser efficacement aussi bien des réseaux de petite taille que de très grands réseaux hétérogènes.

Ce bon vieux et néanmoins ami protocole HTTP fonctionne selon le principe très simple de "question-réponse" (ou requête-réponse). Rapidement les cookies ont été ajoutés au protocole afin de pouvoir garder un état lors d'une série de transactions, par exemple, d'un magasin en ligne, ou d'un site d'actualités tel LinuxFr.org. Depuis l'arrivée du cookie, c'est devenu le moyen de maintenir une session pour les utilisateurs des sites.

Personne n'est dupe et l'on sait très bien que ce cookie est un simple morceau de texte passant en clair dans les entêtes du protocole HTTP. Nous savons aussi qu'il suffit d'obtenir ce texte afin de voler l'identité de la personne. Nous savons que le meilleur moyen pour s'en protéger est d'utiliser la version sécurisée du protocole HTTP soit HTTPS.

Malheureusement, les sites comme Facebook ou Twitter utilisent le HTTP si rien d'autre ne leur est demandé. Pire, le site Facebook n'est pas entièrement fonctionnel via HTTPS (le seul que j'ai personnellement testé), le chat ne fonctionne pas.

C'est là qu'interviennent Eric Butler et Ian "craSH" Gallagher. "Comment faire réagir ces sites" a dû être la question de départ. Après maintes réflexions (je suppose), ils ont décidé d'amener la possibilité de détourner une session HTTP à un clic de souris de tous les utilisateurs de Firefox.

Et ils ont créé Firesheep, à utiliser sur tous vos wifi non-protégés. Cet outil va permettre de sniffer le réseau à la recherche de cookies se baladant et vous afficher, dans une interface simple et intuitive, la liste des personnes ayant un compte sur divers sites sociaux et sur le même réseau que vous. Il ne vous reste plus qu'à cliquer pour obtenir l'identité de cette personne sur le site en question.

Enfin, c'est ce que dit la publicité. Je ne l'ai pas testé, la version Linux n'est pas encore dehors, il y a uniquement la version Windows et la bêta pour Mac OS X. Mais comme c'est du logiciel Libre, vous pouvez rapidement adapter le code pour tourner sur Linux.

NdM : concernant LinuxFr.org, la liste des cookies utilisés est dans l'aide, et nous invitons à préférer l'accès par HTTPS (un cookie permet de forcer tous les accès suivants en HTTPS si quelqu'un se loggue en HTTPS). Voir aussi la discussion précédente sur Cadriciel d'espionnage/gestion de témoin de connexion evercookie 0.3.

Le septième Netfilter Workshop se tient cette année à Séville en Espagne. Il réunit les principaux développeurs de Netfilter, la couche pare-feu de Linux, plus connue par son outil iptables.

Cette rencontre permet aux développeurs du projet Netfilter de se rencontrer pour définir les orientations du projet, et également d'avancer sur les mises à jour de technologies à venir.

L'évènement se déroule du 18 au 21 octobre et un compte rendu est proposé par EdenWall. Le site est mis à jour en temps réel en suivant les différentes présentations des intervenants.

Mozilla a annoncé le 27 août 2010 que Firefox 4 inclurait le HSTS (HTTP Strict Transport Security). Cette amélioration permet d'éviter des problèmes de sécurité liés au basculement de HTTP au HTTPS en permettant au site web d'exiger une connexion sécurisée.

Comprendre et bien utiliser le fichier hosts, quel que soit votre système d'exploitation.

Le fichier hosts ?
Presque un gros mot pour la plupart des utilisateurs lambda, mais qui a le mérite d'être facile à comprendre et puissant dans son utilisation.

Dans cet article, il n'y aura pas grand-chose de très technique.

Cette dépêche est tirée du journal de patrick_g.

Le web commence à bouillonner au sujet des téléphones Motorola Droid X (basés sur le noyau Linux) et qui sont supposés s'autodétruire si on tente de flasher le système. Tout est parti de cet article sur le site Mydroidworld.com. L'info a ensuite été reprise sur Mobilecrunch.com puis sur Slashdot et maintenant Harald Welte (spécialiste des smartphones s'il en est) en parle sur son blog.

De quoi est-ce qu'il s'agit ?
Une puce (eFUSE) est chargée de vérifier le processus de boot du téléphone. Si tout est correct, c'est à dire si rien n'a changé par rapport au code d'origine Motorola, alors le boot continue normalement. En revanche si la puce détecte que le code du firmware a été modifié (à la suite d'un flashage par exemple) alors elle envoie une commande qui empêchera de façon permanente le démarrage du téléphone. Il ne pourra plus jamais s'allumer. Comme disent nos amis anglo-saxons : votre téléphone devient une brique ! "If the eFuse failes to verify this information then the eFuse receives a command to "blow the fuse" or "trip the fuse". This results in the booting process becoming corrupted and resulting in a permanent bricking of the Phone."

Seul Motorola connait les spécifications de la puce eFUSE et peut éventuellement réactiver le téléphone. Donc pour l'utilisateur c'est mort, il peut jeter son téléphone à la poubelle ou le transformer en coûteux presse-papiers. On connaissait déjà les puces de contrôle qui empêchent simplement le boot mais c'est, à ma connaissance, la première fois qu'on découvre un mécanisme d'autodestruction placée sciemment au coeur du hardware par un constructeur pour interdire le flashage de ses téléphones.

Bien entendu ça fait encore plus mal au coeur de savoir que ces téléphones sont basées sur Linux c'est à dire sur du logiciel libre devant posséder les 4 libertés classiques définies dans la licence GPL. C'est encore plus rageant quand on lit la prose de Lori Fraleigh sur le blog officiel des téléphones Motorola : "L'utilisation de logiciels open source, comme le noyau Linux ou la plateforme Android, dans une machine, n'oblige pas le téléphone faisant tourner ce code à permettre le flashing. Nous respectons les licences, y compris la GPLv2, pour chacun des packages open source de nos téléphones";.

C'est évidemment un argument massue en faveur de la licence GPLv3 qui interdit explicitement cette "tivoisation". Et en attendant n'achetez pas un téléphone Motorola car, comme le dit un commentaire sur Slashdot, "vous pouvez légalement acheter un pistolet qui ne tire que dans la direction de la personne pressant la détente, mais ça ne veut pas dire que c'est une bonne idée".

NdM : Attention cette information émane d'une seule source donc prudence. Voir également ce commentaire de SOULfly_B sur le journal d'origine.

Un challenge de sécurité (wargame pour les intimes) est mis en place pendant la durée des Rencontres Mondiales du Logiciel Libre, dans le cadre de la session Sécurité. Ici rien à gagner, vous travaillez pour la gloire. Si le challenge a du succès, il sera sans doute prolongé.

HACK IN ZE BOX CHALLENGE

Voici les informations d'accès au challenge :

• Machine : ssh://109.229.160.144
  
• Logins et mots de passe :
  • 
    CHALLENGE#1:exploitation
    amenra1/amenra
    
  • CHALLENGE#2:crackmes
    mars0/mars
    
  • CHALLENGE#3:python/network
    nept0/neptune
  
  

NdM : les informations données sont apparemment volontairement succinctes. Les personnes susceptibles de participer devraient trouver facilement ce qu'il faut faire.

GOOZE publie des tutoriels expliquant comment utiliser une carte à puce (smartcard) ou une clé USB (token) sous GNU/Linux et Mac OS X.

En lisant les tutoriels, vous apprendrez comment :

• Choisir un matériel compatible ;
  
• Installer et initialiser une smartcard ou un token ;
  
• Générer des clés RSA et certificats X.509 sur la carte ;
  
• Ouvrir une session en utilisant PAM ;
  
• S'authentifier sous OpenSSH ;
  
• Créer des VPNs : StrongSwan, etc.

Par ailleurs, GOOZE supporte les efforts des développeurs libres en offrant une carte de développement à 50 centimes d'euros, à condition qu'un descriptif du projet soit fourni. De nombreux développeurs libres ont répondu à l'appel et environ cinq cartes restent disponibles.

Parmi les projets ayant répondu à l'appel : OpenSC, Seahorse, OpenSSH, StrongSwan, etc.

NdM : la licence FEITIAN n'est pas une licence libre.

Vous pensiez madame Albanel, l'ancienne ministre de la culture, à côté de ses pompes lorsqu'elle a parlé du pare-feu d'OpenOffice.org en pleine Assemblée Nationale lors des débats hadopiens ? Détrompez-vous, elle était juste un peu en avance sur son temps. Mis au défi, Pollux, bien connu dans le domaine de la sécurité informatique et du libre, vient d'implémenter la fonction dans la célèbre suite bureautique. Le tout n'est pas un simple petit bidouillage ou une blague potache à l'aide d'une macro, mais une véritable petite architecture basée sur :

• OpenOffice.org (forcément !) ;
  
• nfqueue et python pour amener les paquets en espace utilisateur (l'auteur ne se voyait pas porter OOo en espace noyau) ;
  
• python-uno pour manipuler OOo ;
  

La communication entre la partie filtrante et la console d'admin se fait en XML-RPC avec pyUNOserver.

D'une simplicité déconcertante, il suffit juste de lister les ports à autoriser et OOo va les filtrer, Pollux en a de plus fait un outil daycidors-compliant en remontant graphiquement le nombre de paquets rejetés et acceptés, le tout mis à jour en temps réel ! Tous les détails sur son blog ! À proposer d'urgence à Orange pour remplacer leur console de téléchargement, car au vu des performances (~10 paquets par seconde), cela vous fera passer l'envie de faire du P2P !

InvisibleThings et plus précisément Joanna Rutkowska, chercheuse polonaise en sécurité, vient d'annoncer Qubes, un environnement Xen de travail sécurisé. J. Rutkowska a publié de nombreuses attaques (avec leur implémentation) sur Xen, la virtualisation matérielle ou plus récemment TrueCrypt.

L'objectif du projet est de fournir un environnement sécurisé par isolation (une VM pour le travail, une pour le surf, une pour le surf sécurisé etc) tout en fournissant les fonctionnalités nécessaires à sa réelle exploitation au quotidien.