Vous avez peut être vu passer le vent de panique qui souffle sur TOR depuis qu’Eric Filiol, directeur du laboratoire de recherche en cryptologie et virologie de l’ESIEA, a annoncé le fruit du travail de son équipe sur le réseau « onion routé », venant ébranler la confiance dans l’anonymisation offerte par TOR. Rappelons que dans certains pays, moins cléments que le notre concernant la liberté d’expression (si ça existe!), l’anonymat est la seule manière d’exprimer des points de vues politiques, culturels, religieux ou artistiques…
Première surprise, Eric Filiol annonce 181 nodes cachés découverts grâce à un algo maison, cartographiant le réseau TOR sur une Google Map :
« Il existe des noeuds cachés non répertoriés dans le code source. Seule la fondation TOR connaît ces routeurs cachés. On a développé un algorithme compliqué pour les identifier. On en a écrit une librairie (181 TOR bridges découverts à ce jour). C’est une base non publique mais il est illusoire de penser que ce niveau de sécurité n’est pas accessible (…) Le code source sera mis à disposition mi-novembre. »
On apprend également que sur les plus de 9000 nodes, environ 1500, seraient vulnérables à des escalations de privilèges.
Le routage complexe de TOR a lui été semble t-il mis en défaut par les chercheurs, ce par le biais d’un virus agissant sur la mémoire et provocant des embouteillages sur certains noeuds. Ainsi il devient possible selon le chercheur d’orienter les flux sur des nodes… en somme, de la prédiction de routage…on sent bien ce qui va venir juste après.
« J’infecte une partie du réseau TOR, je peux contrôler les flux qui passent. »
Il devient par ce biais, sans avoir besoin de saturer le réseau, de créer des micro-congestions afin de faciliter le packet sniffing.
Mais il y a plus fâcheux : la couche de chiffrement, assurant la secret dans le transport des données, toujours selon Eric Filiol, ne serait pas au top :
« La cryptographie implantée dans TOR est mauvaise…On a réduit considérablement le degré de deux des trois couches de chiffrement. »
Le directeur de recherche du laboratoire indique également que la fondation n’a pas très bien réagi à l’annonce de ces travaux :
« La fondation a fait une demande de manière agressive pour me faire comprendre en évoquant la dimension de ‘responsible disclosure’. Mais tout ce qui m’importe, c’est de savoir si c’est légal ou pas »
Et enfonce le clou :
« On ne peut pas imaginer que la fondation derrière TOR ne soit pas consciente de ses failles »
Cette dernière accusation semble elle, plus grave et surtout moins objective car comme le souligne ITEspresso, elle sous-entend que la finalité du réseau TOR, qui a obtenu le soutien financier du gouvernement américain ne serait pas si limpide que cela. Et ça pour tout vous dire, je peine à y croire. Quoi qu’il en soit, en attendant la conférence qui se tiendra à la fin du mois à Sao Paulo au Brésil où l’équipe de chercheurs devrait dévoiler ses travaux, mon sentiment est que :
1° Eric Filiol n’est pas du genre à bluffer
2° Les vecteurs d’attaques expliqués sont tout à fait crédibles
3° Si la sécurité est une affaire de confiance, alors, le réseau TOR est aujourd’hui ébranlé.
Je me permet de publier les quelques observations que j’ai fait à l’HADOPI concernant les spécifications des dispositifs de filtrage, c’est assez sommaire car chaque point mériterait à lui seul que l’on s’y appesantisse bien plus. Les voici livrés de manière brute.
AVERTISSEMENT : les spécifications des moyens de sécurisation de la HADOPI peuvent profondément évoluer, il est donc nécessaire que les personnes concernées se manifestent et enrichissent ces spécifications avec des remarques ou fassent part de leurs inquiétudes sur divers points. En tout cas je vous encourage à le faire, ce n’est pas du temps perdu. La loi est là, il faut maintenant l’appliquer, à nous de faire en sorte que ce soit avec le moins de casse possible.
Le problème des réseaux sans fil publics
Les abonnés SFR utilisent souvent la connexion de leur voisin à leur insu (connectivité en roaming même depuis leur domicile). Il me semble important de demander à cet opérateur (comme à Free avec son service FreeWifi, même si ce dernier attribue une adresse ip différente de celle de la box à laquelle le freenaute est connecté) des chiffres sur cette pratique.
Ces réseaux publics avec portail captif sont très souvent vulnérables à un bypass d’authentification par encapsulation tcp over DNS.
Les réseaux publics déployés dans des lieux publics sont aussi souvent (même très souvent) mal configurés, un scan du lan une fois connecté au portail captif permet aisément de trouver l’ip de l’AP, ses ports ouverts, et donc l’interface d’administration. pour l’interface HTTP le mot de passe est souvent bien modifié, ce qui est très rarement le cas de l’accès console via ssh à ce même AP.
Toujours pour ces réseaux publics, les firmwares sont très rarement à jour, et donc exploitables.
Filtrage sur les protocoles (En fonction de la taille, des formats, débits, profils utilisateurs , débits, volumes et plages horaires).
Appliquer une politique de sécurité en fonction de ces critères est hasardeux, le risque de surblocage est très important. Le filtrage sur un protocole n’est pas acceptable en soi, c’est une discrimination par défaut, pas plus que ne l’est une approche statistique, même si l’on sait qu’à la sortie des écoles, un fichier de 700 mégas avec une extension .avi a 90% de chances d’être un fichier contrefait.
L’usage d’un protocole P2P pour des raisons légitimes ne peut pas être entravé, même par un simple avertissement. Dans le cadre de la cellule familiale, si un enfant utilise un protocole de P2P pour une raison légitime et que ses parents n’ont ne serait-ce qu’un avertissement, il partiront du principe que le P2P est une technologie problématique et donc proscrite.
L’analyse des configurations des postes clients (logiciels installés) risque d’être un gros frein, à moins que les journaux produits ne puissent être exploités que par l’utilisateur. De trop nombreux utilisateurs de Windows utilisent des logiciels crackés et vont prendre peur que cet outil agisse comme un mouchard.
Outils de journalisation
le principe du double archivage des journaux me semble acceptable, je n’ai aucun problème avec ça.
j’ajouterai la journalisation des adresses mac des clients du lan, qui même falsifiables sur le poste client, peuvent être corrélées avec les durées de session et donc être utiles pour disculper une personne victime d’une intrusion sur son réseau sans fil. Cependant, il est à noter que des box comme certaines anciennes Livebox proposent par défaut une fonctionnalité obligeant les postes clients à déclarer les mac adress pour pouvoir se connecter au WLAN (ces box sont livrées avec du WEP activé par défaut). Le résultat, c’est que l’intru, à l’aide d’un outil de sniffing wireless comme aircrack, peut repérer les mac adress connectées à la box (et donc autorisées) visionner le volume de trafic entre le point d’accès et le client, et donc usurper la mac d’un client autorisé (mac spoofing).
le contrôle de l’utilisateur sur les données de journalisation chiffrées est un bon point, l’utilisateur doit pouvoir demander ponctuellement le déchiffrement de son journal et s’assurer que la version non chiffrée n’a pas été altérée par un simple diff.
L’anonymisation des journaux envoyés pour déchiffrement des données collectées est très importante.
La sécurité est indissociable de la notion de confiance, et je ne vois pas comment l’HADOPI dont la mission initiale est de faire diminuer l’échange de fichiers contrefaits peut être un tiers de confiance acceptable par les utilisateurs. Même anonymisée, cette fonctionnalité sera en toute logique boudée des utilisateurs.
Concernant le stockage de données issues des contrôles des flux réseaux sur le LAN de l’utilisateur, en ce qui me concerne je refuserai catégoriquement qu’une machine connectée à mon réseau local aille scanner d’autres machines de mon LAN, même si ces informations restent sur le poste clients, il serait par exemple mal venu de compromettre une machine de mon LAN sous OpenBSD ou Linux parce qu’un logiciel sous Windows a décidé de stocker des informations sur mon LAN. Je n’accorde aucune confiance à ces moyens de sécurisation sur une machine cliente.
La problématique des ordinateurs portables se connectant sur mon LAN (amis, famille) qui stockeraient des informations sur mon réseau domestique me fait froid dans le dos. Si un tel dispositif est labellisé, j’interdirai purement et simplement la connexion de tiers sur mon réseau de peur qu’un défaut de mise à jour ou une faille ne vienne compromettre une partie de mon LAN. Au mieux je demanderai la désinstallation complète du dispositif de sécurisation à un tiers pour le laisser se connecter à mon LAN. Qu’on le veuille ou non, cette fonctionnalité est assimilable à un mouchard, elle est donc à proscrire.
Systèmes d’exploitation libres et moyens de sécurisation
Les systèmes d’exploitation libres disposent déjà d’outils performants de sécurisation (de la vraie sécurisation qui lutte contre des accès frauduleux et qui ne condamne pas un usage). Les Unix libres disposent par défaut de Packet Filter et GNU/Linux de Netfilter/Iptable. Ces outils correctement configurés sont suffisants pour assurer un niveau de sécurité satisfaisant, tout dispositif supplémentaire est non seulement inutile et aucun crédit ne saurait leur être accordé. Tout labellisé qu’il soit, un tel dispositif a par exemple fort peu de chance d’apparaître dans les packages d’OpenBSD.
Même si ces solutions existent, elles ne seront jamais intégrées dans des distributions car ni leur fondement légal, ni leur philosophie, sont compatibles avec les logiciels libres.
Le principe des listes et solutions de contrôle parental
De ce point de vue, je n’ai aucun problème, à la seule condition que la configuration par défaut du dispositif fasse apparaître clairement les sites filtrés et qu’aucun site ne soit filtré à l’insu de l’utilisateur. Attention, ceci exclu de fait certaines solutions. Ces listes doivent être lisibles et éditables par l’utilisateur. Aucun site ne doit être placé dans une liste noire à l’insu de l’utilisateur.
Le principe des listes peut convenir mais il est par exemple hors de question qu’une société tierce, comme OPTENET, qui semble avoir des liens affirmés avec les milieux intégristes catholiques et qui a déjà montré en Australie son zèle à filtrer secrètement des sites parfaitement légaux, devienne le garant de ma morale ou de celle de mes enfants. cf : http://bit.ly/be4M7f
« Ces listes (centaines de milliers d’éléments, en général) sont définies et mises à jour par diverses organisations ou groupes d’ordre éthique. » : permettez moi d’en douter, OPTENET équipe aujourd’hui l’éducation nationale et n’est pas un tiers de confiance fiable à mes yeux.
Les problèmes de normalisation au niveau européen
Cette digression sur Optenet me fait sérieusement réfléchir sur une éventuelle compatibilité (et sur le papier elle se doit de l’être) avec les dispositifs européens de filtrage normés (ils devraient l’être au début de l’année 2011). Il va de soi que non seulement je vais m’opposer haut et fort à ce que la France se base, contre les avis de l’AFNOR, sur une norme européenne dont on sait qu’elle a été tronquée par des intérêts privés et qu’elle présente un caractère prêtant à une grande suspicion.
A la veille du vote de l’article 4 de la Loppsi, si nous avons le moindre soupçon de mise en place d’outils un peu trop « polyvalents », nous nous y opposerons fermement et avec les arguments idoines.
Protection antivirale
« Un antivirus car l’application devra se protéger contre les différentes attaques qui ne manqueront pas de surgir contre elle-même. Elle devra détecter des logiciels de contournement, etc. »
Cette définition fonctionnelle me semble erronée.
Il existe déjà des éditeurs proposant des solutions antivirales, je ne comprends pas ce que ceci vient faire dans un dispositif labellisé par la HADOPI. Par définition l’usage d’un antivirus est nécessaire quand c’est trop tard.
Enfin ajouter un antivirus a des solutions antivirales existantes alourdira la charge dédiée à la sécurité de manière inutile en diminuant sensiblement les performances des machines des utilisateurs.
Le coeur du problème : l’analyse dynamique de flux
« Le but de ce module est d’inspecter dynamiquement le contenu entrant et sortant du trafic sur les interfaces du réseau de la machine de l’utilisateur. »
Cette fonctionnalité est dangereuse et ne produira que pour seul effet d’amputer les internautes d’une partie d’Internet.
Quid des logs produits ?
Quid des protocoles exotiques ou nouveaux non répertoriés par l’éditeur ?
Quid du comportement de cette fonctionnalité sur les outils d’anonymisation de trafic (TOR/Freenet) ?
« En cas de découverte d’une configuration atypique, une notification de bas niveau est générée. »
Là encore c’est très discutable, quid de la défense d’un internaute pour justifier une configuration atypique nécessitée par un usage légal, quid de sa valeur au moment de défendre sa bonne foi ? On s’oriente vers des écueils juridiques où les utilisateurs ont tout à perdre : cette fonctionnalité doit impérativement être indépendamment désactivable
Des mesures de sécurité qui n’en sont pas
Page 24 : « (pas de sécurisation WPA, SSID en clair, routeur avec aucun contrôle sur les adresses MAC des appareils se connectant à lui, etc.) ».
Un SSID en clair n’est pas une vulnérabilité (même masqué, un SSID est détectable, ainsi que le BSSID, par de simples outils d’analyse de réseaux sans fil)
Un dispositif de contrôle des adresses mac n’est pas non plus un dispositif de sécurité sérieux (il est contournable en 5 secondes).
Leur absense n’ont donc pas à générer d’alerte. Il est même dangereux de définir ces mesures comme des mesures de sécurité car ceci sème le trouble chez certains utilisateurs qui se pensent sécurisés sous prétexte que leur SSID est invisible.
Un point intéressant qui a le mérite d’expliquer clairement les intentions du dispositif
Page 24 : « L’application doit aussi conseiller et guider l’usager pour les divers appareils qui ne sont pas des ordinateurs (lecteur DVD, Boitier multimédia, etc.) mais qui sont susceptibles de posséder des fonctions de téléchargement avec une problématique de contrefaçon. » Ces dispositifs tendent donc explicitement à limiter les usages de matériels possédant des fonctionnalités de téléchargement. Comme ça c’est clair, l’idée est de « sécuriser contre le téléchargement », mais pas de sécuriser les données personnelles de l’utilisateur. Cette phrase a elle seule discrédite l’ensemble de la démarche, on est plus dans la sécurisation, on est bien dans le registre de la surveillance.
Un point de détail assez amusant
Un peu plus loin (P.27), la solution propose même de « bloquer toutes les connexions ; » … là, vous avez intérêt à avoir une hotline assez sérieuse et ça promet de grands moments…
Contournement du dispositif et contre mesures
La sécurisation des moyens de sécurisation est illusoire, l’histoire nous montre que _tous_ ces dispositifs ont été compromis au moins une fois. L’exploitation à grande échelle est restreinte par la diversité. Si un mécanisme labellisé et donc présent dans toutes les solutions est faillible, le risque d’une exploitation à grande échelle est inéluctable. Un moyen de sécurisation ne saurait réussir à comprendre ce qu’il se passe dans une machine virtuelle, seules des traces « réseau » pourraient apparaître dans les journaux. Si elles sont chiffrées, seul un mécanisme de signature de trafic pourrait permettre de repérer une tentative de contournement et cette perspective est inquiétante et sa pratique généralisée n’est pas souhaitable. Toute approche de reconnaissance de contenus, ne saurait se faire que sur un fondement légal valable et motivé par des faits graves. Par delà les problématiques de priorétarisation de trafic légitime, elle posera à terme des problèmes car il est tentant d’utiliser cette technique pour des causes non légitimes. Nettoyer Internet de contenus copyrightés n’est à mon sens pas une cause légitime et constituerait un détournement non souhaitable de cette technologie.
Je m’inquiète de voir apparaître un dispositif supplémentaire sur les réseaux mobiles, même si ce n’est pas ce qui est clairement expliqué dans le document (page 8). Les réseaux mobiles sont déjà assez filtrés (usage manifeste du DPI) pour que l’on ajoute une couche supplémentaire de filtrage.
En conclusion
Je persiste et signe, l’HADOPI est illégitime dans cette mission, l’intitulé « moyens de sécurisation » est séduisant mais il est trompeur quant aux objectifs. C’est le droit d’auteur qu’on protège en condamnant des usages et non les internautes.
Le risque de voir ces solutions labellisées HADOPI répondre aux normes européennes en font un outil rêvé de contrôle moral et politique basé sur la peur du gendarme, effet renforcé par le délit de négligence caractérisée. Si sur la forme certains points de ce document semblent techniquement corrects, le fond et les motivations de la démarche l’invalident à mes yeux totalement.
Même labellisés, ces moyens de sécurisation n’auront donc pas droit de citer chez moi et je déconseillerai vivement leur installation.
Hackito Ergo Sum est le rendez-vous international que vous fixe le hackerspace /tmp/lab. L’édition 2011 se tiendra du 7 au 9 avril et reunira, on peut leur faire confiance, de nombreux talents pour offrir des interactions de haut niveau. L’appel à participation vient tout juste d’être lancé. Si vous avez des choses à partager, qu’il s’agisse de code ou de bidouille matérielle, cet événement est un incontournable : conférences de haut niveau, capture the flag, des rencontres qui s’adressent aussi bien aux bidouilleurs qu’aux institutionnels ou représentant d’organisation gouvernementale.
La HADOPI ne sera surement pas oubliée, quelque part entre le hacking d’Echelon et de SCADA, un set « Governmental firewall and their limits (Australia, French’s HADOPI, China, Iran, Denmark, Germany, …) » est prévu et je ne saurai trop recommander aux représentants de la HADOPI d’y participer pour comprendre que les limites ne sont pas que philosophiques et que les dangers sont bien réels.
HES 2011 c’est aussi et surtout l’espoir de voir un jour la France rattraper son retard historique sur les autres pays européens en matière de hacking. Faut il encore préciser que le hacking est une discipline noble, utile, favorisant l’innovation et la créativité, indiscociable de la recherche informatique ou de la recherche en général, et qui ‘na rien à voir avec le « piratage ».
A noter que HES2011 se cherche encore des sponsors, n’hésitez pas à les contacter si vous pensez que l’image de votre institution ou de votre entreprise peut trouver une cohérence à s’associer avec un évènement de ce type dont on sait par avance qu’il ne peut être qu’une réussite vu le sérieux reconnu du /tmp/lab pour l’organisation d’évènements (comme le Hacker Space Festival) et sa faculté à regrouper aisément des spécialistes très reconnus dans leur discipline.
HES 2011 : le call for paper
–[ Synopsis:
Hackito Ergo Sum conference will be held from April 7th to the 9th of 2011 in Paris, France.
Following last edition’s success, HES2011 will be a bigger event with even more talks, focusing on hardcore computer & network security, insecurity, vulnerability analysis, reverse engineering, research and hacking, and will try to keep the high quality content. Our dear Program Committee is there to ensure this.
HES will this year be a fully international-oriented conference, 100% in English, aiming to gather the best security researchers, experts and decision makers in one room.
–[ Introduction:
The goal of this conference is to promote security research, broaden public awareness and create an open forum so that communication between the researchers, the security industry, the experts and the public can happen.
Last year, we pioneered a domain with the first Capture The Flag (CTF) contest on FPGA, with excellent result that exceeded by far our expectations. This year, new contests will run with hopefully even more diverse and new approaches to security. Of course, network-based CTF and lockpicking contest will still happen.
We will have a specific session for new works, including slots for new presenters -i.e. typically people whose personal research are extremely interesting but who do not usually present at conferences- because security innovations occur at the fringe of the security industry, very often by passionate people, and that’s what we are and love. Submissions from students, academics or otherwise passionate people from anywhere on the internet are therefore most welcome.
We will also have an anonymous side track so that people who wish to present sensitive subjects can do so in total freedom. As we believe the academic system as setup a good precedent with anonymous submissions, review and voting, we wish to pursue this direction by providing researcher a way to share important contribution without being concerned with politics and other non-research influences.
This conference will try to take into account all voices in order to reach a balanced position regarding research and security, inviting businesses, governmental actors, researchers, professionals and the general public to share concerns, approaches and interests for this topic.
During three days research conferences, solutions presentations, panels and debates will aim to view and determine the future of IT security.
–[ Content of the Research Track:
We are expecting submissions in English only. The format will be 45 mins presentation + 10 mins Q&A.
Please note that talks whose content will be judged too commercial or biased toward a given vendor will be rejected.
For the research track, preference will be given to offensive, innovative and highly technical proposals covering (but not restricted to) the topics below:
[*] Attacking Software
* Automating vulnerability discovery
* The business of the 0-day market
* Non-x86 exploitation
* New classes of software vulnerabilities and new methods to detect
software bugs (source or binary based)
* Static and Dynamic binary or source-based analysis
* Current exploitation on Gnu/Linux WITH GRsecurity/SElinux/OpenWall/SSP
and other current protection methods
* Kernel land exploits (new architectures or remote only)
* New advances in Attack frameworks and automation
* Secure Development Life Cycle and real-life development experiences
[*] Attacking Infrastructures
* Botnets and C&C abuses
* Exotic Network Attacks
* Telecom (from VoIP to SS7 to GSM & 3G/4G RF hacks)
* Financial and Banking institutions
* SCADA and the industrial world, applied.
* Governmental firewall and their limits (Australia, French’s HADOPI,
China, Iran, Denmark, Germany, …)
* Law enforcement : how to / how to deceive / how to abuse.
* Satellites, Military, Intelligence data collection backbones
(« I hacked Echelon and I would like to share »)
* Non-IP (SNA, ISO, make us dream…)
* M2M
* Wormable vulnerabilities against protocols & infrastructures
* Tim Shelton (aka Redsand) (HAWK Network Defense) @redsandbl4ck
* Ilja Van Sprundel (IOActive)
* Raoul Chiesa (TSTF)
* Dhillon Andrew Kannabhiran (HITB) @hackinthebox
* Philip Petterson (aka Rebel)
* The Grugq (COSEINC) @thegrugq
* Emmanuel Gadaix (TSTF) @gadaix
* Kugg (/tmp/lab)
* Harald Welte (gnumonks.org) @LaF0rge
* Van Hauser (THC)
* Fyodor Yarochkin (Armorize) @fygrave
* Gamma (THC, Teso)
* Pipacs (Linux Kernel Page Exec Protection)
* Shyama Rose @shazzzam
–[ Fees:
Business-ticket (3 days) 120 EUR
Public entrance (3 days) 80 EUR
Discount for Students below 26 (3 days) 40 EUR
Discount for CVE publisher or exploit publisher in 2010-2011(3d) 40 EUR
One-day pass 40 EUR
Volunteers (Must register, see below) (3 days) 0 EUR
–[ Trainings
The list of trainings for HES2011 will be announced shortly after CFP publishing. You can still send us training description to hes2011-orga AT_lists.hackitoergosum.org if you want to offer some training. Trainings will happen from Monday 4th of April until Wednesday 6th of April, just before the conference.
–[ Sponsors:
We are looking for sponsors. Entrance fees and sponsors fees are used to fund international speakers travel costs and hosting facility. Please ask for the HES2011 Sponsor Kit at hes2011-orga __AT__ lists.hackitoergosum.org.
–[ Volunteers:
Volunteers who sign up before 2011-03-01 get free access and will need to be present onsite two days before (2011-04-05) if no further arrangement is made
with the organization.
–[ Journalists:
Journalists are welcome, but are required to comply with simple rules to ensure the mutual respect among adults we aim to bring in hackito. In particular, filming or taking pictures of attendees without their prior agreement is totally prohibited. « We shall respect privacy and people » is the only motto.
–[ Greetz:
We would like to thank the HES2010 Team, its reviewing committee and all the volunteers for their time and dedication in making this event a success. Thumbs up to the /tmp/lab hackerspace for their support and the final HES party which was a tremendous success.
We would also like to greet all the speakers of last year’s edition for the quality of their presentation and the great time we shared in Paris : you are all most welcome back in Paris for the 2011 edition.
Likewise, we’d like to thank last year’s sponsors for their unconditional support. Feel free to support us again for this 2011 edition.
Finally, we would like to thank all the people that participated to last years edition : the conference is the people 🙂 See you all in April !
–[ Synopsis:
Hackito Ergo Sum conference will be held from April 7th to the 9th of 2011 in Paris, France.
Following last edition’s success, HES2011 will be a bigger event with even more talks, focusing on hardcore computer & network security, insecurity, vulnerability analysis, reverse engineering, research and hacking, and will try to keep the high quality content. Our dear Program Committee is there to ensure this.
HES will this year be a fully international-oriented conference, 100% in English, aiming to gather the best security researchers, experts and decision makers in one room.
–[ Introduction:
The goal of this conference is to promote security research, broaden public awareness and create an open forum so that communication between the researchers, the security industry, the experts and the public can happen.
Last year, we pioneered a domain with the first Capture The Flag (CTF) contest on FPGA, with excellent result that exceeded by far our expectations. This year, new contests will run with hopefully even more diverse and new approaches to security. Of course, network-based CTF and lockpicking contest will still happen.
We will have a specific session for new works, including slots for new presenters -i.e. typically people whose personal research are extremely interesting but who do not usually present at conferences- because security innovations occur at the fringe of the security industry, very often by passionate people, and that’s what we are and love. Submissions from students, academics or otherwise passionate people from anywhere on the internet are therefore most welcome.
We will also have an anonymous side track so that people who wish to present sensitive subjects can do so in total freedom. As we believe the academic system as setup a good precedent with anonymous submissions, review and voting, we wish to pursue this direction by providing researcher a way to share important contribution without being concerned with politics and other non-research influences.
This conference will try to take into account all voices in order to reach a balanced position regarding research and security, inviting businesses, governmental actors, researchers, professionals and the general public to share concerns, approaches and interests for this topic.
During three days research conferences, solutions presentations, panels and debates will aim to view and determine the future of IT security.
–[ Content of the Research Track:
We are expecting submissions in English only. The format will be 45 mins presentation + 10 mins Q&A.
Please note that talks whose content will be judged too commercial or biased toward a given vendor will be rejected.
For the research track, preference will be given to offensive, innovative and highly technical proposals covering (but not restricted to) the topics below:
[*] Attacking Software * Automating vulnerability discovery * The business of the 0-day market * Non-x86 exploitation * New classes of software vulnerabilities and new methods to detect software bugs (source or binary based) * Static and Dynamic binary or source-based analysis * Current exploitation on Gnu/Linux WITH GRsecurity/SElinux/OpenWall/SSP and other current protection methods * Kernel land exploits (new architectures or remote only) * New advances in Attack frameworks and automation * Secure Development Life Cycle and real-life development experiences
[*] Attacking Infrastructures * Botnets and C&C abuses * Exotic Network Attacks * Telecom (from VoIP to SS7 to GSM & 3G/4G RF hacks) * Financial and Banking institutions * SCADA and the industrial world, applied. * Governmental firewall and their limits (Australia, French’s HADOPI, China, Iran, Denmark, Germany, …) * Law enforcement : how to / how to deceive / how to abuse. * Satellites, Military, Intelligence data collection backbones (« I hacked Echelon and I would like to share ») * Non-IP (SNA, ISO, make us dream…) * M2M * Wormable vulnerabilities against protocols & infrastructures
[*] Attacking Hardware * Hardware reverse engineering (and exploitation + backdooring) * Femto-cell hacking (3G, LTE, …) * BIOS and otherwise low-level exploitation vectors * Real-world SMM usage! We know it’s vulnerable, now let’s do something * WiFi drivers and System on Chip (SoC) overflow, exploitation and backdooring. * Gnu Radio hacking applied to new domains
[*] Attacking Crypto * Practical crypto attacks from the hacker’s perspective (RCE, algo modeling, bruteforce, FPGA …) * Algorithm strength modeling and evaluation metrics * Hashing functions pre-image attacks * Crypto where you wouldn’t think there is
We highly encourage any other presentation topic that we may not even imagine.
–[ Submissions:
[*] Required information:
Submitions must (see RFC 2119 for the meaning of this word) contain the following information:
* Speaker’s name or alias* Biography* Presentation Title* Description* Needs: Internet? Others?* Company (name) or Independent?* Address* Phone* Email* Demo (Y/N)
We highly encourage and will favor presentations with a demo.
Submissions may contain the following information:* Tool* Slides* Whitepaper
[*] How to submit:
Submit your presentation and materials at:http://hackitoergosum.org/apply/
–[ Workshops:
If you want to organize a workshop or any other activity during the conference, you are most welcome. Please contact us at: [email protected]
–[ Dates:
2010-11-15 Call for Paper2011-02-20 Submission Deadline2011-02-21 Acceptance notification2011-03-01 Program announcement2011-04-07 Start of conference2011-04-09 End of conference
–[ Program Committe:
The submissions will be reviewed by the following program committee:* Tavis Ormandy (Google) @taviso* Matthew Conover (Symantec) @symcmatt* Jason Martin (SDNA Consulting, Shakacon)* Stephen Ridley @s7ephen* Mark Dowd (AzimuthSecurity) @mdowd* Tiago Assumpcao* Alex Rice (Facebook) facebook.com/rice* Pedram Amini (ZDI) @pedramamini* Erik Cabetas* Dino A. Dai Zovi (Trail Of Bits) @dinodaizovi* Alexander Sotirov @alexsotirov* Barnaby Jack (IOActive) @barnaby_jack* Charlie Miller (SecurityEvaluators) @0xcharlie* David Litchfield (V3rity Software) @dlitchfield* Lurene Grenier (Harris) @pusscat* Alex Ionescu @aionescu* Nico Waisman (Immunity) @nicowaisman* Philippe Langlois (P1 Security, TSTF, /tmp/lab) @philpraxis* Jonathan Brossard (Toucan System, P1 Code Security, /tmp/lab) @endrazine* Matthieu Suiche (MoonSols) @msuiche* Piotr Bania @piotrbania* Laurent Gaffié (Stratsec) @laurentgaffie* Julien Tinnes (Google)* Brad Spengler (aka spender) (Grsecurity)* Silvio Cesare (Deakin University) @silviocesare* Carlos Sarraute (Core security)* Cesar Cerrudo (Argeniss) @cesarcer* Daniel Hodson (aka mercy) (Ruxcon)* Nicolas Ruff (E.A.D.S) @newsoft* Julien Vanegue (Microsoft US) @jvanegue* Itzik Kotler (aka izik) (Security Art) @itzikkotler* Rodrigo Branco (aka BSDeamon) (Checkpoint) @bsdaemon* Tim Shelton (aka Redsand) (HAWK Network Defense) @redsandbl4ck* Ilja Van Sprundel (IOActive)* Raoul Chiesa (TSTF)* Dhillon Andrew Kannabhiran (HITB) @hackinthebox* Philip Petterson (aka Rebel)* The Grugq (COSEINC) @thegrugq* Emmanuel Gadaix (TSTF) @gadaix* Kugg (/tmp/lab)* Harald Welte (gnumonks.org) @LaF0rge* Van Hauser (THC)* Fyodor Yarochkin (Armorize) @fygrave* Gamma (THC, Teso)* Pipacs (Linux Kernel Page Exec Protection)* Shyama Rose @shazzzam
–[ Fees:
Business-ticket (3 days) 120 EUR
Public entrance (3 days) 80 EURDiscount for Students below 26 (3 days) 40 EURDiscount for CVE publisher or exploit publisher in 2010-2011(3d) 40 EUROne-day pass 40 EURVolunteers (Must register, see below) (3 days) 0 EUR
–[ Trainings
The list of trainings for HES2011 will be announced shortly after CFP publishing. You can still send us training description to hes2011-orga AT_lists.hackitoergosum.org if you want to offer some training. Trainings will happen from Monday 4th of April until Wednesday 6th of April, just before the conference.
–[ Sponsors:
We are looking for sponsors. Entrance fees and sponsors fees are used to fund international speakers travel costs and hosting facility. Please ask for the HES2011 Sponsor Kit at hes2011-orga __AT__ lists.hackitoergosum.org.
–[ Volunteers:
Volunteers who sign up before 2011-03-01 get free access and will need to be present onsite two days before (2011-04-05) if no further arrangement is madewith the organization.
–[ Journalists:
Journalists are welcome, but are required to comply with simple rules to ensure the mutual respect among adults we aim to bring in hackito. In particular, filming or taking pictures of attendees without their prior agreement is totally prohibited. « We shall respect privacy and people » is the only motto.
–[ Greetz:
We would like to thank the HES2010 Team, its reviewing committee and all the volunteers for their time and dedication in making this event a success. Thumbs up to the /tmp/lab hackerspace for their support and the final HES party which was a tremendous success.
We would also like to greet all the speakers of last year’s edition for the quality of their presentation and the great time we shared in Paris : you are all most welcome back in Paris for the 2011 edition.
Likewise, we’d like to thank last year’s sponsors for their unconditional support. Feel free to support us again for this 2011 edition.
Finally, we would like to thank all the people that participated to last years edition : the conference is the people 🙂 See you all in April !
On a encore récemment parlé de SCADA à l’occasion de la propagation du ver Stuxnet qui visait des systèmes SCADA Siemens. Sa cible et ses auteurs présumés, comme son fonctionnement, ont été largement commentés et ceci est du à la nature des équipements sur lesquels les systèmes SCADA opèrent. L’une des 4 vulnérabilités inconnue jusqu’à Stuxnet, et qui affectait Windows, a tout juste été fixée. Stuxnet par son aspect ultra élaboré est soupçonné d’être l’oeuvre d’une agence gouvernementale dans le but de mettre à mal une centrale nucléaire iranienne. Nous n’aurons probablement jamais le fin mot de l’affaire mais ceci a peut être été l’occasion pour certains d’aller jeter un oeil sur la sécurité de ces systèmes dédiés au monitoring et à l’acquisition de données d’équipements industriels ou de génie civil, divers et variés.
Ce qui se passe aujourd’hui, en dehors du mystère Stuxnet, résulte de dizaines d’années de mauvaises pratiques sécuritaires chez quelques éditeurs et dans le secteur de l’informatique industrielle. La situation est toutefois assez inquiétante et tous les pays concernés devraient méditer un audit sans concession de ces infrastructures, ne serait-ce, que pour évaluer le risque, souvent amoindri au prétexte que ces équipements sont rarement interconnectés.
Si certains systèmes ne présentent que peu de risques, des systèmes dédiés à des sites bien identifiés comme à risque (ponts, tunnels, lignes de transport ferroviaire, installations nucléaires…) devraient faire l’objet d’attentions nouvelles.
Sans céder à la paranoia, il serait bienvenu, même au niveau français et c’est pas Ossama qui me contredira, de prendre la mesure exacte des risques de scénarios noirs sur ces systèmes et essayer de comprendre si nous y sommes préparés.
Le weekend prochain, du 29 au 31 Octobre 2010, le /tmp/lab vous convie au Plastic Hacker Space Festival, temple français de la culture DIY où ça cause de tout pour tout fabriquer.
Usinette, Fablab, RepRap, transidentités et transpalettes : l’univers du D.I.Y croise, pour cette nouvelle édition trans-disciplinaire, les univers variés de l’autogestion, de la post-pornographie et des séxualités plurielles, des questions de genre, de l’architecture, de l’environnement,…, et sème le trouble au cœur de nos habitudes en reposant la question de nos désirs.
Plastique, électronique et chair pour fabriquer presque tout : enfin tous les moyens de réaliser ses envies et de construire un monde à son image.
Il n’est plus question de se demander “de quoi demain sera fait?” mais “comment veut-on faire demain?”.
De nombreux sites web ainsi que la presse se sont fait l’écho de récentes remontrances émanant des services secrets américains à la France. La loi HADOPI était en cause. Le spectre d’une menace d’écoutes généralisées pour faire la chasse à l’échange de fichiers soumis au droit d’auteur est en passe de devenir un problème de sécurité nationale. Et c’est pas comme si les USA n’avaient pas d’intérêt à défendre leur industrie culturelle. Pourquoi sommes nous pionniers de « l’Internet civilisé » ? Les américains sont ils moins civilisés que nous ? On peut se demander pourquoi les services de renseignement français n’ont pas cherché à tuer dans l’oeuf les velléités de contrôle des populations à la gloire du sacro-saint droit d’auteur.
Les USA se sont posés il y a bien longtemps la question : est il opportun de menacer de mettre sous écoute sa population ? Il faut bien comprendre que dans la logique américaine, il y a une longue tradition du renseignement. L’exemple le plus connu des réseaux de renseignement en grande partie mis en place par les USA se nomme Echelon, il s’agit d’un réseau d’écoute planétaire capable d’intercepter n’importe quel type de communication (téléphone, internet, fax…). Il fonctionne sur dictionnaire, une liste de mots clés fait réagir le système, le message est ensuite intercepté, puis analysé, de manière informatisée, puis par des moyens humain. La France aussi est dotée de son réseau d’interception, baptisé Frenchelon. Il existe cependant une différence notable entre les USA et la France sur la finalité de ces outils. Les USA concentrent leur effort sur le renseignement exterieur et apportent le plus grand soint à ne pas utiliser ces outils contre leur propre population. De notre côté, en France, on ne s’embarrasse pas vraiment avec de telles considérations et à écouter Marc Guez (président d’une association caritative dont l’objet est la préservation des revenus issus des phonogrammes en plastique et le sauvetage les artistes des méfaits d’Internet), c’est tout à fait naturel, c’est déjà en place, alors pourquoi pas l’utiliser pour servir ses intérêts à lui, quitte à s’exposer à des répercutions particulièrement dangereuses.
Je m’étais à une époque amusé avec Google Map à aller jeter un oeil sur les infrastructures américaines pour les comparer aux infrastructures françaises et j’avais constaté que les français étaient quand même bien plus pudiques que les américains sur la question, jugez par vous même :
Voici des installations d’Echelon à Menwith Hill vues du ciel, difficile de les rater, c’est tellement net qu’on pourrait presque lire les plaques d’immatriculation des voitures qui y sont stationnées.
Echelon, site de Menwith Hill
Voici maintenant des installations de la DGSE à Domme dans le Périgors et qui constituent une petite partie du réseau Frenchelon, les arbres sont eux parfaitement nets, en revanche, nos grandes oreilles, on tente gentiment de les cacher.
Installations d'écoutes de la DGSE
Si les deux sites précédents sont parfaitement connus, on trouve sur Google Maps d’autres endroits sur le globe qui laissent assez rêveur, comme ce petit coin paumé au milieu de nul part, Wales, en Alaska. On croit y distinguer un peu le même type de boules blanches… et quand on recule un peu, plus au nord, on voit une énorme piste d’atterrissage… et on se demande du coup quel type de fret peut desservir les 4 baraques de pêcheurs qui semblent border cette côte sauvage du grand nord américain.
Wales, Alaska
L’objectif de ce billet n’est pas vraiment de comparer les infrastructures de Frenchelon à celle d’Echelon, mais cette petite digression me semblait nécessaire afin de de vous montrer que des réseaux entiers destinés à intercepter les communications sont bien en place et qu’en plus c’est loin d’être nouveau.
Ce qui est relativement nouveau en revanche, c’est l’engouement des français pour l’anonymat sur Internet, je crois que des gens comme Cupuccino, Korben ou Fabrice vous le confirmeront à la lecture de leurs statistiques, de très nombreux internautes se documentent sur l’art et la manière de télécharger tranquillement, et pour ça, ils n’hésitent pas à se tourner vers des solutions de chiffrement plus ou moins élaborées. L’usage massif de ce ces solutions créent inéluctablement une forme de bruit par convolution qui pourraient vite s’avérer gênant pour les autorités habilitées à mener des écoutes pour des affaires autrement plus sérieuses que le téléchargement.
Toujours plus chiffré, toujours plus simple d’utilisation, les solutions se font à la fois plus grand public, plus qualitatives et font monter en compétences les internautes sur des problématiques dont ils n’avaient guère à se soucier il y a quelques mois. Est-ce souhaitable ? Surement pas. Il n’est jamais souhaitable qu’un concitoyen éprouve un besoin de se cacher pour pratiquer ce qui en plus de 10 ans est devenu un usage. Et je dois dire que je suis particulièrement surpris du silence du ministère de la Défense à ce sujet. J’ai beaucoup de mal à comprendre que l’armée n’ait pas alerté les pouvoirs publics sur le risque d’une démocratisation du chiffrement. Certes, la France compte parmi ses services des mathématiciens de talent capables de casser des algorithmes incroyables, ou des d’informaticiens doués, capables de se jouer de mauvaises implémentations de ces protocoles de chiffrement, mais dans le cadre d’une écoute « sur dictionnaire » (c’est de cette manière qu’opère un outil comme Echelon, je ne sais pas trop pour son pendant français), on se doute bien qu’il est plus compliqué et plus coûteux en terme de traitement de repérer une information intéressante sur un flux de données chiffrées de plusieurs dizaines ou centaines de milliers de personnes que quand on a traiter un flux de données chiffrées de quelques centaines d’individus.
Si la NSA ne se sent pas très à l’aise avec HADOPI, on se demande ce que peuvent en penser les communautés du renseignement français, je serai fort curieux d’entendre leur son de cloche là dessus, comme par exemple savoir s’ils ont été consultés avant la mise en oeuvre du dispositif HADOPI ou encore de ce qu’ils pensent d’une utilisation des technologies de reconnaissance de contenu (Deep Packet Inspection) pour faire la chasse aux téléchargeurs, alors que ces techniques leur étaient jusque là réservées… mais comme on l’a vu ci-dessus, nos services savent se faire discret.
Aujourd’hui ce qui m’inquiète le plus, c’est cette crise de confiance entre le gouvernement et ses administrés qui commence à devenir une tendance lourde : les internautes cherchent des moyens de se protéger… de l’Etat.
Comme le dit fort justement Benjamin Bayart, dans une démocratie, il est nécessaire que l’on puisse prendre le maquis, en revanche, quand on a 20% de la population qui souhaite le prendre, c’est qu’on a un sérieux problème.
L’anonymat sur le Net est quelque chose de bien trop sérieux pour laisser une place au hasard. Dans certain pays, il est le garant de la liberté de certaines personnes (journalistes, opposants politiques…), pour certaines personnes, une erreur et leur vie peut être mise en danger. Dans le premier billet de cette petite série, nous avons fait la différence entre la protection du contenu et du contexte. Nous avons vu que la protection des contenus passait par le chiffrement des données et que la protection du contexte, bien plus complexe, nécessitait un ensemble de mesures adaptées à des problématiques variées et qu’il existait une forte interdépendance entre ces mesures. Ce que l’on souhaite quand on parle d’anonymat, c’est bien évidemment une solution capable de protéger tant le contenu que le contexte.
Nous allons nous pencher maintenant sur quelques solutions d’anonymat communément utilisées et tenter de comprendre ce qu’elles protègent exactement.
Utiliser le wifi du voisin : sachez dans un premier temps que ceci est parfaitement illégal, à moins que vous n’ayez expressément été invité à le faire. Sinon ça porte un nom : intrusion et maintien dans un système de traitement automatisé de données, auquel la LOPPSI devrait même venir ajouter une usurpation d’identité, et ça coûte relativement cher, à savoir de deux ans d’emprisonnement et de 30000 euros d’amende (Loi Godfrain amendée par la Loi dans la Confiance en l’Economie Numérique dont le petit nom est LCEN), et 3 ans et 45000 euros d’amende en cas de modification ou destruction de données. Dans le cas de l’utilisation de la connexion wifi d’un tiers, lanonymat est loin d’être garanti. L’administrateur du réseau local peut très bien intercepter vos données directement sur son LAN et ce type d’intrusion est facilement détectable (tien une ip en plus sur le réseau)… Si en plus vous faites tout passer en clair, vous avez intérêt à faire extrêmement confiance en la bienveillance ou l’ignorance de votre victime… au fait vous êtes bien sur que le réseau wifi utilisé n’est pas tout simplement un honeypot uniquement destiné à intercepter vos données personnelles ? Bref vous l’aurez compris, cette solution n’en est pas une, en outre elle protège une partie du contexte, mais surement pas le contenu.
Les serveurs proxy : un serveur proxy permet de masquer son IP pour une utilisation donnée correspondant au port utilisé par une communication. On trouve aisément des proxy pour les usages les plus fréquents (navigation web, transferts de fichiers…). Les proxy ne sont pas une solution satisfaisante pour l’anonymat, il ne protègent qu’une toute petite partie du contexte. Il est impératif d’utiliser SSL pour protéger le contenu de la communication et la protection du contexte peut également être améliorée en utilisant plusieurs proxy en chaîne (proxy chain). Attention, la contrepartie, c’est que chaque proxy est également un maillon faible puisqu’il peut loguer les connexions. Les proxy sont cependant un terme très générique et il convient de porter son choix sur les proxy anonymes qui ne loguent pas les communications et ne révèlent pas votre adresse ip à tous vents (attention, toujours dans le cadre d’une communication sur un port donné). On distinguera également les proxy SOCKS et CGI (généralement une page web avec une barre d’adresse dans laquelle on place l’url que l’on souhaite visiter discrètement), d’une manière générale les proxy SOCKS sont plus difficilement identifiables par le site cible que les CGI. Attention enfin aux proxy open socks, il s’agit en fait souvent de machines compromises par des hackers qui peuvent prendre un malin plaisir à intercepter vos données. Les proxy payants peuvent donc êtres considérés comme plus fiables. Les proxy ne gèrent pas correctement la protection du contexte, la protection du contenue, si elle est assurée par SSL peut également être faillible par Man in the Middle.
Le chaînage de proxy : une méthode également assez répandue mais qui a pour effet de ralentir les surfs, est de passer par plusieurs serveurs proxy. Là encore ce n’est pas parce qu’on utilise 3 ou 4 proxy de suite que l’on peut se considérer comme réellement anonyme. Ces proxy doivent être anonymes, ne pas loguer les connexions et ceci ne dispense absolument pas de chiffrer les contenus, l’utilisation de SSL n’est pas une option, mais là encore, certains vous diront à raison que SSL c’est bien … mais… Les protocoles plus exotiques apporteront donc une sécurité accrue mais seront évidemment plus difficiles à mettre en place ou à utiliser. C’est ce genre de solution, couplé à des règles drastiques sur les noeuds qui composent son réseau, que repose la solution JonDonym (JAP) : géographiquement distribués, préalablement audité, opérateurs de noeuds conventionnés, JonDonym est une solution de proxychain assez évoluée qui tend à protéger le contexte de manière quasi satisfaisante pour peu que l’utilisateur observe quelques bonnes pratiques complémentaires (comme utiliser pour surfer une machine virtuelle sous OpenBSD avec une redirection du serveur X sur SSH, la désactivation ds cookies ou de toutes les extensions de navigateur dangereuses dont nous allons parler un peu plus loin…). Attention cependant JonDonym se traîne une réputation sulfureuse, et des rumeurs de backdoors ont couru. La police allemande se serait intéressée de près à ce réseau.
Les VPN : Un VPN est un réseau privé virtuel. On le dit virtuel car il n’y a pas de ligne physique dédiées qui relie les nœuds. On le dit également privé parce qu’il utilise le chiffrement. Les VPN utilisent un chiffrement fort entre les nœuds pour accentuer la protection du contenu (on ne se contente pas de faire confiance aux noeuds). Une des principales différences entre un proxy et un VPN est que le proxy opère sur la couche applicative du modèle OSI, alors que le VPN opère sur la couche réseau. Le VPN est donc naturellement plus résistant à des fuites d’adresses IP. En clair, un proxy anonymise une application (un client mail, un navigateur…), un VPN, lui, tend à anonymiser le trafic d’un OS, c’est à dire l’ensemble de ses applications en opérant sur la couche réseau permettant à ces applications de communiquer. Usuellement les services VPN utilisent des noeuds dans des juridictions offshore mais ceci ne suffit pas. En outre, les vertus anonymisantes des VPN ont largement été survendues, d’ailleurs, il n’est pas rare que certains (mêmes gros) acteurs qui prétendent ne pas loguer les connexion, en pratique, les loguent. Autant vous le dire tout de suite, les providers américains loguent, ils en ont la quasi obligation(Patriot Act).
Tor : Tor est une solution d’anonymat basée sur le concept d’onion routing (routage en oignon), il implique un chiffrement des données préalable qui, passant de noeud en noeud se voit cryptographiquement dénudé d’une couche, d’où son nom. Le concept d’onion routing a initialement été développé par l’US Navy et Tor est son implémentation la plus connue. Tor est un réseau semi-centralisé qui se compose d’un programme et d’un réseau d’environ 200 noeuds. Un utilisateur peut utiliser le réseau passivement ou choisir de relayer le trafic d’autres utilisateurs. Les communications passent par trois noeuds avant d’atteindre un noeud de sortie. Les routes des noeuds sont chiffrées, ainsi que le contenu. Chaque nœud enlève une couche de chiffrement avant de transmettre les communications. Contrairement à SSL, Tor est connu pour être résistant à des attaques par Man in the Middle en raison d’un chiffrement sur 80 bits (pas énorme mais suffisant) de l’authentification post communication. Nous reviendront dans le prochain billet sur Tor, ses vulnérabilités, ainsi que sur Freenet et I2P. Nous verront pour ces solutions que le contexte est faillible.
Les maillons faibles
Ce qui va suivre est loin d’être exhaustif, ces quelques éléments ne sont là que pour vous guider un peu mieux sur les bonnes solutions et les bonnes pratiques, en fonction du niveau de protection de vos données personnelles recherché. Il y a dont une bonne et une mauvaise nouvelle (nous creuserons plus tard la mauvaise). On commence par la mauvaise la quasi intégralité des solutions sont plus ou moins vulnérables aux éléments de protection de contexte ci-dessous. La bonne est que ce n’est pas innéluctable et que vous connaissez très bien votre pire ennemi, c’est à dire vous même.
Les plugins de navigateurs bavards : Le premier maillon faible, c’est votre navigateur web et d’une manière générale toutes les applications qui se connectent à l’internet. Si sur la route, les protocoles de chiffrement peuvent vous protéger, vous n’êtres pas du tout à abri d’un plugin de navigateur trop bavard. Au hit parade de ces extensions, Acrobat Reader, Windows Media, QuickTime, et Flash.
Les réseaux trop sociaux et les identifications un peu trop fédératrices : L’identification sur un site web, particulièrement quand il s’agit d’un super réseau social tout de javascript vêtu avec de supers API faites dans le but louable de rapprocher des personnes qui ne se connaissent pas et exportables sous forme de widgets sur des sites web tiers… toutes ressemblance avec un certain Facebook est purement pas du tout fortuite… est un danger énorme pour vos données personnelles. Il est même particulièrement simple de révéler votre véritable adresse IP en exploitant l’API du dit réseau social. La règle de base est donc de ne jamais s’identifier sur plus d’un site à la fois… finit les 57 onglets dans votre fenêtre de navigateur si vous voulez la paix, il faut être avant tout méthodique : une machine virtuelle = une authentification sur le Net. Au dessus, vous vous exposez de fait à un vol de session.
Les mauvaises implémentations logicielles : Un mécanisme de sécurité, comme un algorithme de chiffrement, peut être compromis, ou plutôt contourné, suite à une mauvaise implémentation. Là encore c’est dramatiquement banal, on a par exemple tous encore tête la réintroduction d’une faiblesse d’implémentation du mécanisme de génération des clef WPA des BBox, les box du fournisseur d’accès Internet Bouygues. Attention, les mauvaises pratiques de développement ne touchent pas que des clients lourds, elles touchent aussi des sites web… oui même des gros sites très célèbres… surtout des gros sites très célèbres. Ainsi, un XSS bien placé et c’est le vol de session. Un simple cookie est susceptible de dévoiler votre véritable identité. Dans le monde de la sécurité les cookies ont deux fonctions : être mangés ou être supprimés (non acceptés c’est encore mieux).
L’interface chaise / clavier : Si vous ne voyez pas de quoi je parle, il s’agit tout simplement de l’utilisateur lui même. Le vrai problème est qu’aujourd’hui, non seulement tout est fait dans les systèmes d’exploitation moderne pour vous masquer le plus posssible les couches complexes (combien de personnes ici savent comment fonctionnent une pile TCP/IP), mais tout ces marchands de sécurité, FAI en tête exploitent votre méconnaissance du réseau et s’en font un business particulièrement lucratif. Avec HADOPI, tout ce petit monde a une occasion rêvé pour vous vendre des solutions tantôt de sécurisation, tantôt de contournement. Le résultat est le même et la démarche est toute aussi sujette à réflexion.
Le contenu cible : En fonction de votre solution d’anonymat, les sites que vous visitez peuvent eux aussi représenter une menace, il n’est pas rare que certains sites, eux mêmes victimes de failles distribuent du malware et compromettent la sécurité des données personnelles de leur visiteurs. D’autres encore, spécialement destinés à piéger les visiteurs, n’hésiteront par exemple pas à doter un formulaire de contact ou d’inscription d’une fonction de keylogin (une pratique pas courante mais existante sur certains sites de warez et destinée à dépouiller les visiteurs qui auraient la mauvaise idée d’utiliser pour ces sites les mêmes mots de passe qu’ils utilisent pour leur compte Paypal ou leur messagerie).
Dans le troisième et prochain billet de cette série, nous aborderons plus en détail les attaques possibles sur les solutions d’anonymat. Le billet sera donc un peu plus technique que celui-ci.
On en causait il y a peu ici, Stuxnet, un mystérieux virus s’en prendrait à des infrastructures industrielles. Le risque est la destruction physique d’équipements industriels, pouvant impliquer des pertes en vie humaines. À ce jour, c’est la Chine qui serait la plus touchée en nombre par le virus qui y revendique plus de 6 millions de machines infectées, une information qui contraste assez avec celle en provenance d’Iran, où les autorités affirment s’être débarrassées du worm. Siemens a effectivement publié un antidote mais l’élaboration de l’attaque n’a pas fini de faire causer dans les conventions relatives à la sécurité informatique. La persistance du virus et sa propagation soutenue pour le système ciblé reste inquiétante et tout triomphalisme me semble personnellement un peu prématuré.
Le New York Times aurait de son côté trouvé un indice, une référence biblique, qui viendrait conforter un peu plus la thèse soutenue par certains, venant à pointer du doigt les services secrets israéliens et peut être même, américains… à moins qu’il ne s’agisse d’une diversion, ce qui est fort probable également, vu l’enjeu et la réalisation de ce vers qui s’appuie sur pas moins de 4 failles 0day et le vol de certificats électroniques de constructeurs. L’attaque a été préparée de manière savante et on imagine difficilement qu’elle soit l’oeuvre de personnes ne disposant pas de moyens considérables.
En trame de fond, la polémique pourrait même devenir un cas d’école pour certains équipementiers, qui, comme Siemens, dont les équipements étaient la cible initiale de Stuxnet, risquent d’avoir un peu de travail en terme de communication clients sur la sécurisation de leurs dispositifs à usages industriels. Siemens aurait par exemple recommandé à ses clients de ne pas installer d’antivirus au motif que ceci pourrait ralentir le système ou inviterait à laisser les mots de passe de connexion à la base de données inchangés.
Je vous invite à lire l’interview de Stephan Tanase sur le MagIT pour comprendre les enjeux et les raisons de la perplexité de tous les experts qui se sont intéressés à ce dossier, ainsi que l’article tout frais de Mag-Securs qui se penche sur les auteurs supposés de l’attaque.
Voici un thème dont j’aimerai beaucoup vous parler librement, mais voilà, ça ne va pas être possible. Sans pratiquer la langue de bois et en essayant de faire très court, je vais simplement ici vous faire part de mon sentiment sur une infection qui cible en ce moment l’Iran, l’Inde, le Pakistan et une poignée d’autres pays en Asie du sud est, mais aussi dans une moindre mesure, les continents européens et américains (voir la carte de la propagation).
SCADA, ou Supervisory Control And Data Acquisition, est un système de surveillance et d’acquisition de données qui existe maintenant depuis plusieurs décennies. SCADA opère le monitoring d’infrastructures, depuis la gestion de l’énergie dans un immeuble jusqu’à la température du noyau d’un réacteur nucléaire en passant par les ponts, les tunnels, les gazoducs, les oléoducs … Ça ne vous rappelle rien ? Moi comme ça, je pense un peu au scénario de Die Hard 4.
En clair, si un pays cherchait à paralyser un autre pays, en vue d’une attaque, SCADA serait une cible de choix. Quand j’ai commencé à m’intéresser au délit de négligence caractérisée, je me suis demandé ce que SCADA était devenu depuis l’arrivée du web… et bien c’est une … scadastrophe. On trouve certains systèmes accessibles depuis le Net, dont certains sans authentification. Ils ne sont certes pas simples à trouver, ce ne sont certainement pas les plus sensibles… mais on en trouve, et l’apparition des iPhones et autres blackberry y est surement pour quelque chose. On trouve même des clients lourds SCADA sur Megaupload pour tout vous dire… Certains chefs d’entreprises qui déploient ce genre de systèmes de contrôle aiment bien, en mobilité, garder un oeil sur leur production. Je n’irai pas plus loin pour l’instant sur le sujet et je vous donne, peut être, rendez-vous l’été prochain, pour un talk sur ce thème.
Depuis quelques mois maintenant, une infection virale, Stuxnet, cible des équipements SCADA du constructeur SIEMENS. Sa propagation, particulièrement ciblée sur, semble t-il, les infrastructures iraniennes, a de quoi soulever quelques interrogations. Les autorités iraniennes affirment que le worm n’a pour l’instant pas fait de dégâts, mais ne prépare t-il pas une attaque qui risque d’en faire bien plus (embarque t-il une bombe logique ?). Ce sont plus 30 000 machines en Iran qui en sont actuellement victimes.
Autre interrogation légitime, qui a pu mettre en place une stratégie de propagation aussi ciblée si ce n’est un État ? Certains n’hésitent pas à affirmer qu’il s’agit d’une attaque bien dirigée contre les infrastructures nucléaires iraniennes, et très franchement, je doute qu’elle soit l’oeuvre de militants Greenpeace. S’il est encore un peu tôt pour parler d’une cyber guerre, vu d’ici, ça y ressemble quand même drôlement. Israël et la Russie sont même pointés du doigt, mais à ce jour, rien ne nous autorise à l’affirmer avec certitude. Quoi qu’il en soit, le spectre d’une agence gouvernementale plane sur Stuxnet et il semble que des moyens considérables aient été déployés pour rendre cette infection possible (des moyens humains pour toucher les infrastructures sensibles en leur coeur et des moyens techniques pour coder ce worm).
Techniquement, Stuxnet exploiterait non pas un mais 4 0day (une véritable débauche de moyens !) pour s’engouffrer dans la faille LNK découverte en juin dernier et présente dans pratiquement toutes toutes les versions de Windows (jusqu’à Seven… « c’était mon idée »). Il embarquerait un rootkit et un chiffrement très complexe à casser pour cibler le Simatic WinCC de Siemens, ses systèmes SCADA et tendrait à tenter d’infecter la base de données à laquelle ces solutions se connectent. L’exécution du payload rendue possible par l’exploitation de la faille LNK permet, depuis une simple clef USB liant un appel de lien .ink, de compromettre le système en exécutant du code malicieux… c’est assez imparable et particulièrement élaboré.
Stuxnet inquiète et à juste titre, sa persistance n’est pas faite pour rassurer et on se demande qui pourrait déployer autant de moyens pour compromettre un système aussi sensible, et surtout, dans quel but.
En tout, cas… moi je dis ça mais je dis rien hein… j’en connais qui devraient sérieusement se pencher sur cette question au lieu de faire la chasse aux téléchargeurs de mp3. La compromission de SCADA, c’est tout sauf de la science fiction, et c’est tout sauf rigolo… des vies sont en jeu, et là je ne parle pas de pirates qui tuent les artistes en provocant des AVC par DDoS… mais de vrais méchants qui pourraient tuer de vrais gens.
EDIT : c’est en fait un beau CSRF sur une nouvelle feature de Twitter… juste un CSRF tout pas beau et tout vieux qui est la cause de cette nouvelle propagation (voir les commentaires ci-dessous avec le code d’exploitation). Pas de risque de compromission de vos données… pour l’instant, juste une belle iframe toute sale qui ne serait jamais arrivée là avec un code propre.
Il semble que Twitter soit pour la seconde fois cette semaine victime d’une attaque. Constaté à l’instant sur l’interface web. Les timelines se retrouvent pourries de mots doux à caractére pornographique avec un joli link qui ira lui même contaminer la timeline de vos followers…
Je n’ai pas encore le détail de l’attaque mais l’url postée semble faire un truc bizarre exploitant l’API de Twitter, à vérifier.
Bref il semble que Twitter attire l’attention de beaucoup de petits malins et que l’application elle même soit gavée de trous de sécurité… Mais qu’attendent ils pour se payer un véritable audit ?
Ce site utilise des cookies pour faciliter votre confort de navigation et sauvegarder vos préférences. Vous pouvez tout accepter, ou sélectionner ceux que vous souhaitez accepter.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Durée
Description
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Vous avez peut être vu passer le vent de panique qui souffle sur TOR depuis qu’Eric Filiol, directeur du laboratoire de recherche en cryptologie et virologie de l’ESIEA, a annoncé le fruit du travail de son équipe sur le réseau « onion routé », venant ébranler la confiance dans l’anonymisation offerte par TOR. Rappelons que dans certains pays, moins cléments que le notre concernant la liberté d’expression (si ça existe!), l’anonymat est la seule manière d’exprimer des points de vues politiques, culturels, religieux ou artistiques…
