Sony et le PCI-DSS

Effrayant.

Although we are still investigating the details of this incident, we believe that an unauthorized person has obtained the following information that you provided: name, address (city, state, zip), country, email address, birthdate, PlayStation Network/Qriocity password and login, and handle/PSN online ID. It is also possible that your profile data, including purchase history and billing address (city, state, zip), and your PlayStation Network/Qriocity password security answers may have been obtained. If you have authorized a sub-account for your dependent, the same data with respect to your dependent may have been obtained. While there is no evidence at this time that credit card data was taken, we cannot rule out the possibility. If you have provided your credit card data through PlayStation Network or Qriocity, out of an abundance of caution we are advising you that your credit card number (excluding security code) and expiration date may have been obtained.

Et encore, ils ont pas la marque du gel douche de l'utilisateur. Pour les login/passwords, finalement on commence à être habitués (c'est déjà arrivé à une chiée de sites de réseaux sociaux). Par contre les données bancaires...sachant que les security numbers (le truc à l'arrière de la carte) sont stockés (pour éviter à Jean-Kevin de demander les données bancaires de la CB de ses parents chaque fois qu'il veut acheter du contenu pour ses jeux PS3 - les achats en "1 clic"), donc il y a là potentiellement du danger. Certaines banques demandent par exemple la date de naissance de l'utilisateur avant de valider un achat en ligne. Ici elle a juste pu fuiter.
Dans un sens, il y a quelques mois, Sony disait qu'il fallait choisir entre garder le support de Linux sur PS3, ou faire une mise à jour pour pouvoir continuer à jouer en ligne (et donc, perdre Linux). Ceux qui ont choisi la mise à jour ont donc en effet "tout" perdu: support Linux via OtherOS, et jeu en ligne :-)

Fail by design

J'ai craqué, j'ai fini par prendre un iPhone (tout en conservant mon autre téléphone). Passée la phase de découverte de l'appareil, ainsi que son jailbreak, je me suis rendu compte qu'une fonctionnalité assez utile présente sur mon blackberry, est mal implémentée sur iPhone: il s'agit du (non) chargement des images distantes dans les e-mails, avec les risques que ces images engendrent (Sid parlait de ce genre de choses dans un billet, il y a longtemps)
En effet, alors que sur blackberry, il est possible de désactiver le téléchargement automatique de ces images, et les télécharger ensuite à la demande (en un bref appui sur la touche de menu, puis un petit "load images") pour un mail donné, sur iPhone, cela n'a pas l'air possible; soit le téléchargement des images est désactivé pour tous les mails, soit il est activé, mais il n'est pas possible de télécharger les images d'un unique mail.
Une fonctionnalité que j'aimerais bien voir implémentée, même si les mails HTML c'est le mal (puis c'est pas très pgp compliant selon le client mail utilisé)

Un NAS que je déconseille: Freecom Network Media Center

Je me suis enfin décidé à acheter un NAS, pour diverses raisons pratiques. Dès le début je m'étais donné le ton: je ne conserverai pas ce NAS très longtemps (maximum 1 an, pour un peu évaluer mon activité dessus), donc je n'envisageais pas d'y mettre un prix trop élevé.

Direction Grosbill, pour prendre le moins cher: un Freecom.

Les specs ont l'air raisonnables, pour un appareil de ce prix là (150 euros). Mais je pense que la majorité de mes lecteurs savent tout à fait que des specs restent des specs...

L'interface de configuration, via des CGI en Perl, est relativement lente pour une raison encore inexpliquée (ça sent le truc codé par un goret derrière).

On nous vante un système de refroidissement ultra silencieux, mais qui en réalité fait plus de bruit que mon (vieux) PC de bureau: il devrait pouvoir finir aux côtés de mon Cobalt Qube en terme de nuisance sonore (donc dans le couloir ! :))

Au niveau "media center", je n'ai pas encore eu le temps de trop expérimenter: j'ai juste pu constater que ma console de salon (PS3) parvient à jouer les fichiers, mais je n'ai pas poussé le test plus loin.

Devenons un peu vulgaires: le client bit-torrent est complètement fini à la pisse. Lorsqu'un fichier est téléchargé par le client bittorrent du NAS, il est déposé dans /public/torrents/. Jusque là tout va bien. Le problème, c'est qu'il est alors tout simplement impossible de supprimer le fichier. Aussi bien via FTP (en tant qu'utilisateur "normal", ou "admin"), que via le partage samba (de toutes façons, je n'ai même pas réussi à me connecter en tant qu'admin sur le partage samba, ça n'a pas du être activé). Ca sent bien le client bittorrent qui s'exécute avec des permissions un peu spéciales (root ?) et qui n'a pas été testé.

Un tour sur les forums de Freecom a répondu à ma question (en néerlandais, merci Google Translation), en gros c'est juste impossible de supprimer ces fichiers. On ne peut y accéder qu'en lecture seule. Le seul moyen de s'en débarasser, c'est soit de renvoyer le disque au SAV de Freecom (ben voyons), ou alors de formater (trop pratique).

En espérant que d'autres ne feront pas la même erreur que moi :-)

Fedora 12 et séparation des privilèges

Un bien bel exemple, assez représentatif du concept de "en voulant simplifier la vie à l'utilisateur, on réduit le niveau global de sécurité d'un système".

En gros, sans entrer trop dans les détails (les posts sur la mailing list, et la "wave" sur Google Wave, liés à ce problème, seront plus précis et plus instructifs), tout utilisateur sur le système peut installer n'importe quel package signé sans avoir à donner de mot de passe root (bon, après tout, sur une distribution Ubuntu, on utilise sudo et on donne le mot de passe de l'utilisateur connecté pour installer des packages). Certains peuvent se demander où est le problème. Il est là:

The default configuration of PackageKitinFedora 12 permits non-root users to install signed rpm packages from configured yum repositories. This creates a number of potential security problems including the possibility to:

1) Execute a remote-root exploit by exploiting a networked client such as firefox, Adobe flash, pidgin, xchat, etc. to obtain a remote user shell, and then installing a signed package from a configured repository which contains a local-user to root privilegeescalation vulnerability to gain root.

2) Similar to #1 above, but downloading a signed rpm from a previous OS release that has a known user-to-root shell vulnerability, and doing a local install.

3) Similar to #1 above, only doing a denial of service attack by installing a massive number of applications (in one massive transaction, or many smaller ones), and possibly tying up a large amount of network bandwidth, spiking the system CPU load, causing an out of memory condition, etc.

Au final, après un long troll (dont j'ai pris connaissance en lisant dailydave), une décision importante a été prise et annoncée par le type qui maintient le package responsable de ce léger défaut:

"After more discussion and thought, though, the package maintainers have posted to the fedora-devel-list mailing list agreeing to provide an update to Fedora 12's PackageKit. The update will require local console users to enter the root password to install new software packages."

A part ça, sans transition, Google Wave c'est rigolo 5 minutes, mais je pense qu'une majorité de gens ne savent pas encore trop à quoi ça peut leur servir. J'aurai peut-être quelques invitations à refiler d'ici quelque temps. Pour le moment, à part ce qui peut s'apparenter à un échange de "mails" (qui s'appellent des "waves" là dedans), et un test de twitter-via-gwave, je n'ai pas fait grand chose. Par contre, il faudra envisager les plugins permettant de chiffrer/déchiffrer ce qu'on envoie sur wave :-)

Quand même les auteurs ne se respectent pas entre eux

Yesterday it was revealed that, despite her calls for tougher anti-piracy legislation, Lily Allen herself created illicit mixtapes full of copyrighted music and made them available to the public. Today, after having rationalized why it is okay for her to pirate music, she killed her pro-copyright blog because “the abuse was getting too much.”

FAIL.

Se justifier en disant qu'elle a fait ça avant que ses revenus ne dépendent de l'industrie musicale est un peu débile de sa part, dans la mesure où plus récemment que ça, ce mois-ci en fait, elle était encore à pomper du contenu ne lui appartenant pas.

Comme dit dans l'article, il y a 5 ans, elle n'était guère différente des gens qui téléchargent "illégalement" de la musique de nos jours.

Un site presque à jour

Ma curiosité m'a poussé sur le site du "ministère de la culture et de la communication", et j'ai pu remarquer quelques trucs amusants (non, rassurez vous, rien d'illégal ici, juste un site extrèmement mal fait et pas totalement à jour). Je précise que tout cela est constaté avec Firefox. ET Google Chrome (dev-build) Je n'ai pas vérifié avec Internet Explorer, je ne l'ai pas sous la main, je suis sous Linux. Alors on me dira peut-être que c'est à cause des logiciels libres, ou parce que je n'ai pas le parefeu offert par OpenOffice.

- Je me rends sur http://www.culture.gouv.fr et je souhaite voir les dossiers de presse (on sait jamais, ils sont remplis de LULZ). Je clique donc sur "Espace presse" dans le menu de gauche qui me mène à la bonne page. Jusque là, tout va bien. Je souhaite ensuite voir les dossiers thématiques: je clique donc sur "Dossiers thématiques". Là encore, la bonne page s'ouvre. Alors je vous entends d'ici, et vous vous demandez là où je veux en venir. Supposons que je veuille retourner sur "espace presse", je re-clique donc dessus. Et là, c'est le drame: on reste sur "dossiers thématiques".

Premier FAIL.

- Maintenant, je clique sur "Développement culturel", et là le site part totalement en couille:

Second FAIL.

- Je me rends donc sur la page "contact" du bas de page, parce que je me sens obligé de faire remonter cette information capitale, y compris à monsieur le ministre, Frédéric Mitterand. Et là, erreur fatale encore une fois:

Si vous regardez le titre de la fenêtre Firefox (le truc entre les balises TITLE si vous préférez), vous constaterez qu'il y a marqué: "Ecrire à Madame Albanel, Ministre de la Culture et de la Communication - 2008"; poste que cette Madame Albanel n'occupe plus depuis la fin juin 2009, pour être remplacée par Monsieur Frederic Mitterand.

Troisième FAIL.
C'est tout pour aujourd'hui.

Mais arrêtez avec ça

Voilà, je l'attendais avec impatience:

Zataz qui raconte - encore - des âneries (bon, en même temps ça fait 15 ans qu'il le fait, donc ça ne devrait plus choquer grand monde). Il pousse le vice jusqu'à la mise à disposition d'un lien vers le document qu'il cite, alors qu'il n'a pas du bien le comprendre...ou même le lire en fait (en faisant comme beaucoup de gens: s'arrêter sur le gros titre et éventuellement un résumé de 3 lignes, pas forcément compréhensible pour quelqu'un qui n'a aucune notion technique - comme zataz - et faire du sensationnel).
Alors bien sûr, WPA ne devrait plus être utilisé par les gens qui ont du WPA2 à disposition (pourquoi prendre un niveau de protection plus faible, quand on peut utiliser un truc solide ?), mais cette attaque n'a pas non plus, pour le moment, la même incidence, et la même facilité d'utilisation, qu'une attaque via airmon/aircrack utilisable par à peu près n'importe qui.
Quand je parle de l'incidence, je veux dire par là qu'on ne peut pas récupérer la clé permettant de "se connecter" au point d'accès. On peut *juste* déchiffrer certains paquets (typiquement des paquets ARP, dont on connait une grande partie du contenu à l'avance). Dans la mesure où l'on effectue une attaque de type"man in the middle", il faut un petit peu plus de matériel "radio" que la moyenne (là ce n'est plus une attaque passive comme une capture airmon+cassage hors ligne avec aircrack, là il faut clairement patater plus fort que l'accesspoint). Non, vraiment, d'un point de vue théorique ça met bien à mal la sécurité offerte par WPA/TKIP (dans la mesure ou WPA/AES n'est pas affecté), mais dans la pratique, on peut encore l'utiliser un petit moment, sa plus grosse faiblesse dans la vie de tous les jours étant l'utilisation d'une passphrase simple ("qui figure dans toute bonne wordlist"), et ça, malheureusement ça arrivera même à ceux qui utiliseront WPA42 dans quelques années (je me rappelle encore l'accesspoint d'un(e) voisin(e) quand j'ai emmenagé [pas encore d'acces internet personnel], avec une clé WEP, assez triviale à deviner qui aurait pu m'éviter de lancer airmon)
Pour finir, as usual, ceux qui voudraient des infos bien plus complètes et pertinentes, ainsi qu'une très bonne analyse, devraient se ruer sur cet article du blog de sid.

cryptophail

Korben (le fameux) a balancé dans la matinée un lien vers une sorte de lib permettant de réaliser des formulaires web dont le contenu est chiffré (par le browser, en javascript) avant d'être envoyé sur le réseau, puis déchiffré côté serveur et ensuite utilisé.
En lisant la FAQ, un truc m'a quelque peu ennuyé:

* How secure is jCryption ?
Well that’s not easy to say, the RSA public key encryption algorithm is one of the strongest and most secure in the world. It has survived over 20 years although it has some disadvantages/weaknesses. For example if you use a keylength +512bit. Like I mentioned before, everytime you submit a form the keypair will be newly generated, because of this fact jCryption, with it’s functions, is immune to some attacks. But I think in most cases it should be enough using a 512bit key because it’s not that easy to factorize a 512bit prime. But you can adjust the security level of jCryption very easy in PHP (see documentation page). But remeber the higher the security, the longer it takes to generate the keypair. Although jCryption offers some nice ways to bypass the waiting time of the key generation (see the full featured example).

* Why should I use jCryption instead of SSL ?
In my opinion jCryption is much easier to install and configure. Although I don’t think that jCryption is a replacement for SSL. It could be a nice addtion for your contact form or login page to simply make it more secure. If you need highest security you have to use SSL, because jCryption offers no way of authentication.

Et c'est là que vous réalisez à quel point des années de sécurité informatique tombent aux oubliettes. Parce que bon, les attaques Man in the Middle ça n'existe pas, c'est bien connu; donc on peut utiliser une clé de 512 bits (trop la classe, quand on lit que RSA 1024 bits ne doit plus être utilisé d'ici quelques années, même si ce n'est pas pour tout de suite) sans avoir peur que, au hasard, quelqu'un détourne le flux, et se fasse passer pour le véritable correspondant sans le prouver (car vous l'avez bien lu, "jCryption offers no way of authentication"), et puisse déchiffrer les données chiffrées et/ou les modifier (et ça, que ça soit 512 bits ou 4096).
Bon, au moins ils disent que ça ne remplace pas SSL. C'est déjà ça.

Le buzz OpenSSH du moment

Bon c'était le buzz de ces deux derniers jours, "y-a-t'il un 0day dans OpenSSH massivement utilisé ?". Alors on a des forums géniaux (merci à la personne qui a balancé le lien sur twitter et qui se reconnaitra, j'ai bien ri :)).
Au final, ce soir on a pu lire ce qu'un dev OpenSSH a lancé, à savoir:

I don't have any non-public information. I have exchanged some emails with

one of the victims of the alleged sshd 0day, but he was not able to provide any

evidence that the attack was sshd-related. In particular, I spent some time

analysing a packet trace that he provided, but it seems to consist of simple

brute-force attacks.à croire que c'est un bête bruteforce. Pas trop de quoi s'affoler si on a pas de mot de passe débile (bon, d'accord...quand je vois mes logs ssh avec la quantité de tentatives de bruteforce, je me dis qu'il y a un paquet de machines qui se sont faites pwner par des wormn'exclut pas, bien sûr, la possibilité qu'il y ait une faille réellement exploitée, mais cela semble peu probable.

IRCFAIL

[mickou] hier je suis allé voir le film milenieum au ciné il est genial conseil allé le voir car la meuf qui joue le role de hackers pour un journaliste et tros baleze meme si sa reste qun film

Je pense que je vais grepper mes logs (quelle idée aussi d'idler sur ce chan irc) et faire un fichier de quotes de ce type.

Rapport d'étude, partie 1 (dessins et crypto)

Lors de mes aventures sur IRC, je suis tombé sur un lien qui, ma foi, semble poser quelques éléments de réponse quant à ce qui composera le futur « logiciel de sécurisation » dont l'installation sera très prochainement, vivement recommandée afin d'éviter de s'attirer les foudres de la toute-puissante HADOPI (et deviendra certainement obligatoire par la suite une fois que l'on nous aura inventé un nouveau délit, suivi d'une nouvelle loi et d'une nouvelle Haute Autorité (qui donc se placera plus Haut, en terme de puissance, qu'une autre Autorité existante))

Bref, ce lien, quel est-il ? Il s'agit d'un RAPPORT D'ETUDE des solutions de filtrage des échanges de musique sur Internet dans le domaine du peer to peer. Rien que ça.Il est disponible à cette adresse:

http://www.culture.gouv.fr/culture/actualites/rapports/filtrage/charte.pdf

S'il n'est plus disponible, mailez moi (n'oubliez pas PGP), je vous en enverrai une copie (pourquoi PGP/GPG ? Pour pas qu'en surveillant le trafic mail on puisse voir que je fais du recel de contrefaçon d'un document du ministère de la culture, tiens!)

Alors je me suis dit « Enfin! De la lecture intéressante et qui va me donner quelques éléments de réponse quant à ce qu'a prévu le ministère de la culture pour re-dynamiser le secteur de la culture en France, et permettre à nos artistes de pouvoir, enfin, manger à leur faim! »

Alors on nous balance des graphiques sur le trafic peer2peer pour nous montrer que c'est une proportion énorme du trafic Internet. Soit. Mais avant que bittorrent ou autres emule ne fassent leur apparition, des protocoles comme FTP devaient représenter une part non négligeable de la bande passante globale, et ça n'en faisait pas pour autant un fléau; et pourtant, ça servait aussi au partage de données copyright-ées de manière illégale, mais pas seulement (la vieille époque des /pub en +rw accessibles en anonymous (ce même anonymous qui menace nos élus)...souvenirs). Mais j'imagine bien une réunion dans un bureau, style salle de réunion immense, réunissant tout ce beau peuple qui nous a pondu HADOPI (enfin, la loi création et internet), avec un powerpoint bourré de camemberts comme ceux du rapport (dont le temps de calcul dans excel est très certainement supérieur au temps passé pour faire l'étude dont il est question dans ce rapport)

Puis, la partie qui m'a fait le plus frémir (de rage), c'est à la page 11, la partie qui nous parle de crypto. Alors déjà, je vois venir les plus puristes d'entre vous, et rassurez vous, c'est la même chose qui m'a fait tiquer: l'usage de mots tels que « encryptage », « cryptage ». Quelqu'un qui se veut un minimum sérieux ne devrait pas utiliser ces termes. Je pense. Bon puis on nous dit que SSL, SSH et Freenet sont utilisés par ces outils illégaux pour masquer leur trafic. Vlà-t'y pas qu'on va nous rendre SSH illégal (je me rappelle l'époque où, plus jeune, j'avais acheté un magazine sur GNU/Linux, dont le CD-ROM contenait SSF, la version french-crypto-law-compliant de SSH) à ce rythme là. On voit qu'un outil de « peer to peer » comme soft-ether utilise à la fois SSH et SSL pour ça. J'avoue ne pas avoir trouvé quoi que ce soit à propos d'un outil de peer to peer nommé SoftEther. Si quelqu'un a des infos à ce sujet, ça m'intéresse (j'ai surtout trouvé des infos à propos d'un malware nommé comme ça en fait). Puis surtout, on nous dit que les logiciels peer2peer opensource, on peut plonger dans leur code (puisque disponible) pour comprendre comment fonctionne le protocole afin de mieux le filtrer, même si chiffré (crypté, dans leur dialecte). On sait déjà pas vraiment (enfin, uniquement dans certaines conditions qui relèvent du rêve) détecter du trafic HTTP dans un tunnel SSH (voir http://coderrr.wordpress.com/2008/06/28/detecting-ssh-tunnels/ ) et là on nous sort qu'une boite sait détecter du trafic p2p circulant dans un tunnel chiffré. Pas mal. Bon, il s'agit de protocoles absolument pas connus (perso je connais pas filetopia et le reste).

Bref, à ce stade là du document, je reste sur le cul, et je me dis que la partie suivante sur Ipv6 va me faire rire encore un peu avant d'aller manger. En fait, ça me fait juste sourire:

L’évolution du protocole Internet vers IP V6 va apporter, outre l’extension des plages d’adressage IP disponibles, des évolutions sur les fonctions d'authentification et de sécurité de TCP/IP, avec notamment la généralisation du protocole IPSec et des fonctions de chiffrement DES.

Les fonctions de chiffrement DES. On sent là encore l'étude très poussée. Genre on va généraliser l'adoption d'un algorithme de chiffrement obsolète depuis pas mal de temps déjà (ça va faire 10 ans quand même qu'AES remplace DES). Avec un peu de chance, ça fera passer Ipv6 pour une suite de protocoles permettant ou facilitant la mise à disposition de contrefaçon.

La suite, très bientôt (et désolé pour le formatage à chier). Je rajouterai des liens vers des sources très prochainement aussi.

And remember...

On a beau utiliser du SSL de la mort qui tue, si le noeud final du lien sécurisé est compromis (même que partiellement, sachant que lors d'un pentest, un lien partiellement compromis finit par l'être totalement, ce n'est qu'une question de temps), les données qui ont transité seront tout de même accessible (autant avoir des convoyeurs de fonds ultra armés qui déposent l'argent à un endroit en libre accès et sans gardiens, sur une table).
Une possibilité étant de chiffrer les données avant de les envoyer (via un lien sécurisé (ssl par exemple), ou non), comme ça, une personne "malveillante" aura plus de mal à en faire quelque chose si elle parvient à s'en emparer.
L'insécurité informatique a encore de beaux jours devant elle.