Archive for Securité

L’identification des personnes par la HADOPI

Salut les manchots,

Un petit post inspiré de la news de {niKo[piK]} où l’on peut lire entre autre que Hadopi va étendre sa surveillance à d’autres sources, genre téléchargement direct, forum, moteur de recherche etc…

A chaque fois que je lis un article relatant les frasques de l’Hadopi je suis toujours interpellé par le principe d’identification des suspects.

Laissons de côté l’aspect “obstruction à la liberté”, “vol de données privées” etc… Je me doute que c’est LE sujet le plus critique et sujet à débat, mais regardons uniquement le processus qui permet à Hadopi d’identifier un coupable en comparaison au système bancaire.

D’abord un petit extrait d’un document de la CNIL (document complet ici)

Les mécanismes permettant de réaliser l’authentification des personnes sont
catégorisés en trois familles selon qu’ils font intervenir:
– ce que l’on sait, par exemple un mot de passe,
– ce que l’on a, par exemple une carte à puce,
– une caractéristique qui nous est propre, par exemple une empreinte digitale
ou encore une signature manuscrite. Pour rappel, la loi Informatique et
Libertés subordonne l’utilisation de la biométrie à l’autorisation préalable
de la CNIL2 .
L’authentification d’un utilisateur est qualifiée de forte lorsqu’elle a recours à une
combinaison d’au moins deux de ces méthodes.

Le monde du Paiement Bancaire

Dans le monde bancaire on applique à la lettre ce principe puisque que l’identification d’une personne est prouvée par la possession d’une carte bancaire (ce que l’on a) et un code secret (ce que l’on sait).

Le processus de livraison de ces deux informations ne peut être identique. Donc une carte est livrée par un canal de distribution et le code secret original doit être livré par un autre canal de distribution.

Lors d’un paiement bancaire sur internet, vous devez manipulez deux paramètres de l’authentification forte, j’ai donné ici la combinaison “Carte / Code Secret”, mais ça peut être autre chose comme une grille unique composée de nombres qui vous est donnée par votre banque. Lors de la confirmation du paiement, il vous est demandé le 4ème chiffre de la 22ème colonne de cette fameuse grille que vous êtes le seul à posséder.

En plus de tout ça, la banque doit vous offrir l’intégrité de votre message. Hors de question donc qu’un hacker qui se trouve au milieu puisse modifier le message pour envoyer le paiement vers un numéro de compte que lui seul maîtrise.

Pour l’intégrité du message, soit on fait appel à la signature (on se met au niveau des données), ou alors on fait appel au SSL qui est un tunnel qui garantit l’intégrité du message depuis le browser jusqu’au serveur. C’est un peu moins puissant mais c’est souvent accepté et acceptable.

Cette manière de procéder (les deux paramètres pour l’authentification forte + l’intégrité du message) va engendrer la non-répudiation des données, c’est-à-dire l’impossibilité pour l’émetteur du message (ici du paiement bancaire) de nier qu’il est responsable de ce message.

Le monde Hadopi

En gros, Hadopi vous espionne pour savoir si vous téléchargez de manière illégale de la musique, des films, ou autres matériel protégé par le droit d’auteur.

Hadopi devrait être capable, comme dans le monde bancaire, de lever le boucliernon-répudiation en cas de contestation de la part de l’accusé.

Hadopi peut-elle le faire ?

Non car Hadopi surveille des noeuds de réseau, et même si ces noeuds se trouvent chez le fournisseur d’accès internet:

  1. Une personne ne peut être liée à une IP, il n’y a pas moyen de faire ça tant que le fournisseur lui même ne fournit pas une méthode d’authentifation forte entre l’utilisateur et lui. Pour l’instant seul un code est demandé et les box sont interchangeables.
  2. En supposant que le point 1 est rempli (ça sous-entend que votre box est personnalisée, qu’elle vous a été donnée en main propre par une personne qui vous a demandé confirmation sur votre identité et que ce n’est pas la même personne qui vous a remis le code secret par défaut), il n’y a aucune intégrité sur les paquets qui sortent de votre machine, ça veut dire que tout ce que vous pensez envoyer comme info peut-être modifié avant d’arriver chez votre FAI.
  3. En supposant que le point 2 est rempli (ça sous-entend que TOUS vos paquets envoyés de votre machine sont soit signés, soit encryptés, histoire d’avoir l’intégrité des paquets), ça ne vous protège pas contre les virus, qui eux vont bénéficier de la position de man-in-the-browser.

Conclusion

Hadopi ne peut prouver une quelconque culpabilité tant qu’ils utilisent cette manière d’authentifier les personnes. Ils tentent malgré tout de lier un abonnement avec une personne physique, l’utilisation de cet abonnement rend responsable la personne physique abonnée de tout ce qui sort de la machine…Mais c’est de la grosse connerie. On ne PEUT PAS faire un lien entre une personne qui paye un abonnement et des trames TCP/IP qui arrivent chez le FAI, ce n’est pas fiable. C’est encore pire en tenant compte du fait que la Hadopi capture des paquets n’importe ou et ensuite contacte le FAI pour identifier le possesseur de l’IP.

En supposant que vous êtes infectés par un virus et que votre machine est contrôlée par un pirate, le pirate vous fait télécharger des chansons de manière illégales en clair et il récupère le tout depuis votre machine vers la sienne de manière cryptée. Que va déduire Hadopi avec ce qu’il peut voir ?

On peut même imaginer que le pirate ne souhaite pas profiter de votre téléchargement mais juste de vous nuire, ça le rendrait intraçable une fois le virus installé, et vous seriez seul coupable. Si la Hadopi va au procès, il vous sera impossible de prouver votre innocence car vous n’êtes peut-être pas au courant qu’un virus télécharge quelque chose.

A cela la Hadopi peut contre-attaquer en disant que chaque personne physique payant un abonnement est responsable de la “bonne santé” de la machine qui se connecte à l’internet. A cela je réponds une fois de plus que ce n’est pas recevable. Si vous allez sur des sites fiables, ces même sites ont peut-être été hackés et vous avez été victime via XSS ou SQL injection. Il ne faut pas oublier non plus que Comodo a été hacké (j’en parle ici) et ses certificats ont été corrompus, n’importe quel site équipé de ces certificats à cette époque (avant la révocation des certificats) était vulnérable et surtout pouvait être un “faux site” contrôlé par un hacker et donc susceptible de vous infecter, donc même avec la meilleure volonté du monde on ne peut pas garantir que sa machine est sans virus.

Les banques connaissent la problématique et remboursent le client en cas de problème car pour l’instant elles acceptent de vivre avec le risque. Quelle est la réponse de la Hadopi face aux personnes infectées et coupables selon elles de téléchargement ?

 

 

Virus sous Linux… BackDoor.Wirenet.1

Salut les manchots,

Forcément ça devait finir par arriver…Un cheval de troie sous GNU/Linux a fait irruption dans notre calme et paisible vie de défenseur des libertés.

Ce virus vole les mots de passes entrés dans Opera, Firefox et Chrome, ainsi que les mots de passes stockés dans des applications comme Thunderbird, SeaMonkey et Pidgin. Il est a noter qu’il est compatible GNU/Linux et Mac OS/X.

D’après ce que je lis, le virus n’est pas des plus compliqué à neutraliser… Pour l’instant une seule IP vers le Command and Control Server (C&C) : 212.7.208.65

(Pour comprendre un C&C, explication dans ce podcast)

Il n’est pas non plus très bien caché, il a un nom fixe : WIFIADAPT

Si vous faites une recherche sur ce nom dans votre system et que vous ne trouvez rien, à priori, vous n’êtes pas infecté.

Pour ceux qui voulaient une application concrète d’Iptables, pour empêcher le virus de se connecter au C&C il suffit de bloquer les paquets en destination de cette adresse avec la commande suivante:

iptables -A OUTPUT -d 212.7.208.65 -j DROP

Pour ceux qui ne seraient pas des fidèles du podcast, j’ai tenté une explication des règles iptables dans le podcast “Parole De Tux” n°6

Ce qui aurait été intéressant de connaitre, c’est le vecteur de propagation de ce virus. Pour l’instant on n’a pas plus d’info que ça… Affaire à suivre donc…

Quelques liens:

 

Fiabilité de l’Ubuntu Software Center

Salut les manchots

J’étais occupé à répondre au dernier commentaire de “Anonymous” sur le podcast 05 quand j’ai vu que ma réponse commençait à déborder doucement. J’en fais un post, une fois n’est pas coutume…

Je copie le commentaire de l’auditeur:

Pas d’accord avec un truc. J’ai vraiment du mal à imaginer un logiciel frauduleux entrer dans le Ubuntu Sofware Center. Il faudrait que “LaMafia” ait accès au dépôts officiels, arrive à duper Canonical…

Il me paraît beaucoup plus probable que si Ubuntu avait 90% de parts d’utilisateurs, “LaMafia” mettrait un “JessicaAlbaSextapeCodec.deb” sur un site web aguichant, ou bien créerait un site demandant d’ajouter un dépôt maison.

On est bien d’accord sur le fait que “LaMafia” utiliserait un site web avec un .deb vérolé. Pour le contrôle sur le virus et pour leur anonymat ce serait beaucoup plus facile. De plus, même si quelqu’un découvre qu’un virus se trouve sur le site et rapporte l’info au C.E.R.T. ou autre organisme de défense du net, il n’est pas du tout évident d’obtenir sa fermeture. Au contraire de l’Ubuntu Software Center qui une fois averti, aura vite fait de retirer l’application.

L’auditeur suppose aussi peut-être (j’espère qu’il viendra confirmer si il repasse par ici) que  “déposer un virus qui ne fait rien d’autre qu’être un virus est très difficile”… Et là, encore une fois, on est bien d’accord.

Mais attention, “LaMafia” ne va jamais déposer un virus, mais plutôt un jeu ou un utilitaire qui fonctionne ET qui contient un virus…C’est toujours le même problème, si on peut te tromper sur la marchandise, tu es une victime potentielle.

Suite à ce post, je me suis demandé le niveau d’authentification d’un développeur qui veut soumettre son application à Ubuntu. Pour ça, il faut analyser le processus d’enregistrement d’application. Tout est expliqué ici:
http://developer.ubuntu.com/publish/

En réalité, il serait compliqué d’infecter l’Ubuntu Software Center si:

  • On peut faire une Identification “sérieuse” des personnes qui déposent des softs.

D’après ce que je vois, il suffit d’un enregistrement, login / mot de passe. Il faut être enregistré mais comment savoir que c’est la bonne personne derrière un login ? Coment détecter les faux comptes ?

  • Ubuntu n’autorise que les softs Open Source

Un soft open source est lisible et un virus est très vite détecté par le premier curieux qui met son nez dedans. Pour les logiciels déjà compilés, il faut faire de l’analyse très poussée et ce n’est pas toujours possible.

Toujours est-il qu’en ce qui concerne l’Ubuntu Software Cented ce n’est pas le cas, on peut déposer des softs propriétaires sans obligation de donner les sources.

  • Le contrôle de l’application par Canonical est poussé (reverse engineering sur les binaires pour vérifier qu’il n’est pas infecté)

Ce n’à pas l’air d’être le cas non plus. Je lis sur le site à la page http://developer.ubuntu.com/publish/application-states/:

A reviewer is looking at your app.  We’ll perform basic grammar and profanity checks on the provided information, maybe recommend some improvement.  We’ll also check that the tarball you’ve submitted actually successfully builds into a binary package, and upload it to a ppa.

Que faut il retenir de tout ceci ?

Et bien je dirais que l’Ubuntu Software Center n’est sans doute pas le meilleur endroit pour déposer une application infectée, mais si ‘étais pirate et que je devais vraiment passer par ce canal pour infecter des utilisateurs, je publierais une application

  1. gratuite, car si ce n’est pas le cas je dois donner un numéro de compte ou l’argent sera versé dont j’ai accès et donc je deviens traçable
  2. Sous licence propriétaire pour ne pas que mes sources soient analysées par des manchots ;-)

Il est à noter que ce raisonnement est valable aussi pour les applications qu’on trouve dans le store de google ou d’Apple à savoir les trois points suivants:

  • Niveau d’Authentification des personnes qui déposent des programmes
  • Politique de transparence des sources
  • Analyse des programmes proposés

Bonne fin d’été à tous, je m’en vais en vacances chez les Ch’tis