vendredi 23 mai 2014

Pidgin & Forensics

/!\ Attention, article foireux. /!\

Dans un post précédent qui critiquait une non-info comme quoi Skype gardait en local des données personnelles en clair, je faisais allusion à des données similaires stockées par un autre produit de messagerie instantanée : Pidgin (attention, je ne compare pas les deux non plus).

Je ne vais pas faire un historique du projet, Wikipedia fait très bien l'affaire, mais en gros, Pidgin utilise la bibliothèque "libpurple", qui permet de gérer tout un tas de protocoles de messagerie, allant d'IRC à ICQ en passant par XMPP (ouais, Pidgin c'est juste un gros front-end en fait...). C'est donc pour cette raison qu'on ne trouvera pas de dossier .pidgin dans le "home" d'un utilisateur de pidgin. En revanche, on trouvera un ".purple", qui contient plus ou moins ces entrées :

meik@blabla:~/.purple$ ls -l
total 132
-rw-r--r-- 1 meik meik  6175 mai    7 21:20 accels
-rw------- 1 meik meik 12145 mai    7 20:06 accounts.xml
-rw------- 1 meik meik 47114 mai    7 21:46 blist.xml
drwx------ 3 meik meik  4096 juil.  1  2013 certificates
drwx------ 2 meik meik  4096 mai    7 21:43 icons
drwx------ 3 meik meik  4096 juil.  1  2013 logs
-rw------- 1 meik meik 26384 mai    7 21:00 prefs.xml
drwx------ 2 meik meik  4096 juil.  1  2013 smileys
-rw------- 1 meik meik   401 juil.  1  2013 status.xml
-rw------- 1 meik meik 14581 avril  2 11:33 xmpp-caps.xml

Je ne me suis pas attardé trop longtemps sur Skype (je sais juste que sur une session Skype ouverte depuis plusieurs mois sur un PC dont l'uptime est de 297 jours, et qui a été déconnecté d'Internet un certain nombre de fois, et dont le mot de passe de mon nom d'utilisateur Skype a été changé sans que ce changement ne soit répercuté sur le PC en question, Skype arrive toujours à s'authentifier...), mais il ne me semble pas que ce dernier stocke un quelconque mot de passe quelque part, ou du moins, pas en clair (ensuite, si quelqu'un sait, ça m'intéresse). Je suppose qu'il stocke plutot un token quelque part dans ~/.Skype (ensuite, en cas de changement du mot de passe, ce dernier devrait alors être révoqué côté serveur, afin d'empêcher qu'une session authentifiée avant changement de mot de passe ne puisse se réauthentifier avec le même token sans avoir à fournir une preuve de la connaissance du nouveau mot de passe...m'enfin un truc m'échappe peut-être). Bon, avec toutes ces conneries je me perds, je voulais juste dire que le fichier "accounts.xml" de Pidgin contient...des identifiants...en clair !

<account version='1.0'>
<account>
<protocol>prpl-jabber</protocol>
<name>moi@server/</name>
<password>[censuré]</password>

On peut ensuite s'amuser à consulter le contenu du dossier ~/.purple/logs/ qui contient un sous-dossier par type de compte (jabber, irc, etc), et encore une sous-arborescence par compte et ensuite par contact à qui l'on a parlé. Je ne vais pas reproduire ici d'extrait de conversation, mais voilà donc le genre d'infos qu'il est possible de récupérer.

Alors ensuite je veux bien que Skype ça soit le mal, mais si les logiciels libres font pareil, il y a bien une raison (c'est ce que je disais dans le post précédent : si un pirate prend le contrôle du PC de sa victime, il peut faire la même chose que lui, y compris lire ses logs; car même si ce dernier les chiffre, lorsqu'il souhaitera y accéder pour retrouver un numéro de téléphone super important, les données seront en clair à un endroit dans la mémoire de la machine, accessible par l'utilisateur ET le pirate).

Protip: Nokia N900 et kb_lock défectueux (écran qui clignote)

Il y a quelques semaines, mon bon vieux Nokia n900 (recyclé en "pwnphone") a commencé à défaillir. En gros, après un délai variable écoulé après le démarrage du téléphone, l'écran se mettait à "clignoter" (comprendre: s'allumer et s'éteindre plusieurs fois), et évidemment, le clavier semblait ne plus trop réagir au moment où l'écran s'éteignait. Ce qui est assez ennuyeux, vous en conviendrez aisément, lorsqu'on est dans un terminal pour geeker.

Fort heureusement, l'OS tournant sur ce téléphone (qui n'a pas été mis à jour depuis super longtemps) est un Linux (la distribution est Maemo), ce qui facilite un peu la tache pour essayer de comprendre ce qui se passe, et éventuellement régler le problème. La commande dmesg m'a aidé. En effet, entre deux blinks de mon écran, j'ai pu afficher le contenu du dmesg pour me rendre compte qu'il était rempli d'événements de ce type :
"kb_lock (GPIO 113) is now open"
"kb_lock (GPIO 113) is now closed"
[...]
En tout, une bonne dizaine par seconde. Une mauvaise impression m'a mené à penser que c'était l'écran coulissant qui était à l'origine de ce problème (me menant à démonter l'écran et son connecteur, résolvant le problème le temps d'une soirée ...), mais il s'agit de la GPIO 71 !
Quelques recherches m'ont mené au switch de verrouillage clavier situé sur le côté droit. C'est l'activation de ce dernier qui génère des événements sur la GPIO 113. Dans la mesure où je n'utilise pas ce switch lorsque l'écran clignote (faudrait être sacrément rapide pour l'activer une dizaine de fois en une poignée de secondes...), j'en déduis qu'il est défectueux (le n900 n'est plus produit par Nokia depuis 2009, je vous laisse faire le calcul de l'age minimum du téléphone...).

Fort heureusement, il est possible de désactiver, au niveau de l'OS, la prise en compte des événements générés par ce switch (le kb_lock). Il suffit de positionner à 1 le fichier déterminant la désactivation du kb_lock : /sys/devices/platform/gpio-switch/kb_lock/disable

# echo 1 > /sys/devices/platform/gpio-switch/kb_lock/disable

Evidemment, pour rendre cette manipulation persistante, il est nécessaire d'ajouter cette ligne dans un script qui sera exécuté au démarrage...

jeudi 1 mai 2014

Skype et les données personnelles en clair

Ces derniers jours j'ai vu passer un certain nombre de fois un article parlant des données personnelles des utilisateurs de Skype qui sont stockées en clair sur les machines de ces derniers, comme quoi ça serait un scandale; par exemple, je lis sur PCInpact (excusez la référence...) "il s’agit d’une porte ouverte aux pirates en cas d’accès à la machine."
Le problème, si le contenu est chiffré, c'est que si la machine est compromise, rien n'interdit au vilain pirate d'accéder au contenu "protégé", ce dernier étant chiffré avec une clé stockée à un endroit accessible par l'application pour utilisation "user-friendly", et si l'application peut y accéder (car elle aura besoin de ce contenu), un pirate aussi (je me comprends).
Il s'agit d'une problématique qui a déjà été "abordée" (si on veut) par les développeurs de Google Chrome, en expliquant pourquoi, d'après eux, il est limite absurde d'implémenter un système de "master password" pour déverrouiller les accès aux mots de passe enregistrés dans le navigateur :
I'm the Chrome browser security tech lead, so it might help if I explain our reasoning here. The only strong permission boundary for your password storage is the OS user account. So, Chrome uses whatever encrypted storage the system provides to keep your passwords safe for a locked account. Beyond that, however, we've found that boundaries within the OS user account just aren't reliable, and are mostly just theater.

Consider the case of someone malicious getting access to your account. Said bad guy can dump all your session cookies, grab your history, install malicious extension to intercept all your browsing activity, or install OS user account level monitoring software. My point is that once the bad guy got access to your account the game was lost, because there are just too many vectors for him to get what he wants.
We've also been repeatedly asked why we don't just support a master password or something similar, even if we don't believe it works. We've debated it over and over again, but the conclusion we always come to is that we don't want to provide users with a false sense of security, and encourage risky behavior. We want to be very clear that when you grant someone access to your OS user account, that they can get at everything. Because in effect, that's really what they get.

On s'y retrouve.
Ensuite, j'ai limite envie de dire "ooooold" quand je vois cette "news" sur Skype. En fait, déjà dans le bouquin "Violent Python" sorti fin 2012 l'auteur explique comment développer un parser de logs Skype en Python (assez obvious vu le titre du livre). A titre personnel, je me suis fait un bête "parser" de logs Skype en Perl il y a quelques mois, histoire d'avoir un formatage personnalisé ("parser" est un bien grand mot, surtout quand on voit que le script se contente de faire un SELECT sur une base sqlite3 ...), et pour finir, j'ai vu passer début Avril un script (linké via les liens de LOTFREE) faisant la même chose.

Et si on va par là, on peut s'intéresser au dossier "~/.purple" des utilisateurs de Pidgin sous Linux, histoire de ne pas cracher que sur Skype.