Petite introduction à l’auto-défense numérique

Présentation effectuée pour la première fois samedi 5 novembre pour la CNT Lille :

Services de renseignement des États, multinationales du web (GAFAM), employeurs voir proches indiscrets… à l’heure de l’omniprésence du web dans nos vies, nous sommes tous fichés et surveillés. Cependant, il existe des méthodes (plus ou moins efficaces) qui permettent de limiter les dégâts.
Au cours d’un atelier pratique destiné aux débutants, nous découvrirons les principes généraux des techniques de fichage et de surveillance puis manipulerons quelques outils permettant de s’en protéger sur ordinateur et sur téléphone mobile.

 

Fuite de données personnelles à Pôle emploi ? Revente d’informations ? Piratage ?

Pôle Emploi

Voici la première contribution externe de ce blog, un article écrit par une amie qui révèle un problème de confidentialité important chez Pôle emploi : les données personnelles des usagers seraient dans la nature, utilisées pour envoyer du spam et probablement pour tenter des usurpations d’identité.

Après une rapide analyse des en-têtes de l’email en question, la piste Pôle emploi se confirme : l’adresse mail du destinataire est écrite entièrement en majuscule, ce qui est un usage peu courant… sauf dans l’interface de gestion des cordonnées du site de Pôle emploi.

Ce sont potentiellement des dizaines de milliers de noms, d’adresses postales et d’adresses emails qui sont dans la nature. Les plaintes d’usagers commencent à se répandre sur la toile, gageons que Pôle emploi aura une réaction adapté à l’ampleur du problème.

Cela fait plusieurs jours que des demandeurs d’emploi reçoivent des mails plutôt louches. Un blog alerte de ces faux entretiens d’embauche, et à voir le nombre de commentaires, on peut penser que de nombreux demandeurs d’emploi sont concernés.

Et j’en fais moi-même partie…

J’ai reçu un mail étrange hier. Il m’indique que suite à ma réponse à une annonce, je suis convoquée à un entretien pour un poste de chargée de clientèle. Le hic, c’est que je n’ai répondu à aucune annonce et qu’en plus je ne cherche absolument pas un poste de chargée de clientèle ! Passée ma surprise, je regarde avec un peu plus d’attention ce mail et plusieurs détails me sautent aux yeux : les tournures de phrase ne sont pas adaptées à ce type de démarche ; les fonctions de la personne que je dois rencontrer et de la personne qui m’envoie le mail ne sont pas précisées ; le mail d’envoi est un mail SFR… et surtout, le cabinet de recrutement qui me contacte n’existe pas, pas plus que l’entreprise qui souhaite si promptement me recruter.

Après m’être beaucoup interrogée sur le pourquoi d’une telle démarche et avoir parcouru les commentaires sur le blog cité ci-dessus, je me dis que l’hypothèse de l’usurpation d’identité est probable. Faire venir des individus en galère à un entretien, leur demander leur carte d’identité pour préparer le contrat qu’il reviendront signer le lendemain et ne jamais les revoir… bref profiter de la situation de galère des chômeurs. Même si ça me paraît quand même carrément tordu…

De toute façon, je n’avais pas prévu d’y aller. En fait, ce qui m’inquiète surtout c’est comment nos données personnelles ont été récupérées. En effet, nos nom, prénom, adresse mail, numéro de téléphone (pour certains), lieu d’habitation (habitant à Lille, je suis convoquée à Roubaix et non à Paris) et situation de chômage sont associés.
A part Pôle Emploi, aucun autre organisme ne dispose de l’ensemble de ces informations (pas la peine de me contredire, j’ai bien réfléchi à la question et, disposant de plusieurs adresses mail, il ne m’est pas difficile de savoir quels organismes disposent de quelles informations).

Alors fuites de la part de Pôle emploi ? Piratage de leur système informatique (suite aux différentes “affaires” qui ont mis en question sa fiabilité, on peut se poser très sérieusement la question) ? Ou même revente de données ?
D’après les témoignages des demandeurs d’emploi concernés par ces démarches, il semblerait que ni Pôle emploi, ni les flics ne s’intéressent au problème… Moi ça m’inquiète, ça m’inquiète que des données personnelles me concernant soient utilisées de manière frauduleuse, surtout quand ces données viennent d’une administration comme Pôle emploi.
Alors quoi ?

En dessous le fameux mail.

De : <annie.afchain@sfr.fr>
Date : 21 mars 2014 14:24
Objet : Proposition d’entretien chez f 2f, Roubaix
À : xxx@xxx.com

UTF-8
Convocation: xxx xxx
Bonjour,

Suite à votre réponse à l’annonce, nous vous demandons de bien vouloir vous présenter chez f 2f pour rencontrer Mr Hurand au 35, Avenue Jean Baptiste Lebas,2ème étage (entre gare SNCF et Mairie), 59100 Roubaix.

Nous fixons donc un rendez-vous de principe pour mercredi 26 mars 2014 à 16h15, mais vous avez la possibilité bien évidemment de le fixer avant Vendredi 28 mars , dernier jour d’entretien pour ce poste de chargé de clientèle, en répondant à mon email.

Nous comptons vivement sur votre présence à l’heure prévue avec votre CV imprimé pour cet entretien individuel.

A. AFCHAIN
SH recrutement

Courriel transmis par le logiciel EMA http://www.emamailing.com
EMA est gratuit pour une utilisation non commerciale

Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection Antivirus avast! est active.

De l’inutilité de la fonction PHP sleep pour protéger des attaques brute force (exemple avec Prestahop)

Le couple adresse email / mot de passe est le sésame permettant d’accéder à presque l’ensemble des activités numériques d’un individu : messagerie, réseaux sociaux, documents, extranets, interface client des boutiques en-ligne…

Les applications web se doivent de garantir la sécurité de leurs utilisateurs. En plus du minimum exigible (hachage et salage des mots de passe en base de données, protections contre les injections SQL, les attaques de type XSS et CSRF…), les développeurs tentent souvent de trouver des astuces permettant de protéger mieux les utilisateurs de leurs programmes.

Tenter de se protéger des attaque par force brute…

Ainsi, on trouve le code suivant dans le système de connexion à l’interface client de Prestashop, la très populaire plateforme e-commerce open-source :

Comme le commentaire l’indique, les développeurs de Prestashop tentent de protéger leurs utilisateurs d’une attaque par force brute.
L’idée est que pour obtenir un accès à l’interface client, le pirate va utiliser un robot qui va tester méthodiquement et à très grande vitesse tous les mots de passe possibles (dans les faits, ce types de robots testent dans un premier temps les mot de passe les plus communs grâce à des listes pré-établies).
Bien que le concept soit bon, l’appel à sleep est inutile. Les serveurs web sont multithreads et les robots d’attaque le sont aussi. Ces derniers lanceront de nombreuses connexions parallèles et n’attendront pas de savoir si le mot de passe est correct ou non pour en tester un nouveau.

Pire cette implémentation est dangereuse car, en plus de ralentir l’affichage de la page indiquant une erreur de saisie aux utilisateurs légitimes, elle bloquera le thread le temps du sleep (ici une seconde) et favorisera ainsi les attaques par déni de service. Un attaquant souhaitant engorger le site (ce qui aura pour conséquence de le ralentir voir de le rendre inaccessible) lancera de très nombreuses requêtes de connexion avec un mauvais mot de passe. L’effet sera plus important et l’attaque d’autant plus efficace sur cette page grâce au blocage du à l’appel à la fonction sleep.

Se protéger efficacement

Commençons par supprimer de nos codes sources ces appels à sleep aussi inutiles que dangereux. Les développeurs de Prestashop ont pris les devants et à l’heure ou j’écris ces lignes la version de développement de la plateforme e-commerce ne contient plus le code incriminé.

Adaptons maintenant l’idée d’empêcher les tentatives de connexion trop fréquentes à l’environnement multithreads des serveurs web. Commençons par stocker chaque erreur de connexion ainsi que la date à laquelle elle se produit et l’utilisateur qu’elle concerne dans une base de données ou mieux avec memcached. Si pour un même utilisateur une tentative de connexion arrive trop rapidement après l’une ayant échouée, disons au bout d’une seconde après le premier échec, de 5 après le deuxième, de 10 après le troisième…, exigeons que l’utilisateur prouve qu’il est bien humain (ex. : en ajoutant un CAPTCHA en plus des champs login et password). Si les echecs provenant d’une même adresse IP sont systématiques, on peut blacklister cette adresse car elle est probablement utilisée par un assaillant.

Dernier point, inciter voir exiger que vos utilisateurs optent pour un mot de passe fort diminue drastiquement les risques de compromission par force brute. N’hésitez pas à afficher des jauges de sûretés auprès du champ de saisie de mot de passe du formulaire d’inscription.

La faille de sécurité touchant MessengerFX semble corrigée

Il y’a quelques temps, j’avais découvert une vulnérabilité de type Cross Site Scripting dans MessengerFX, un client web populaire pour le réseau Windows Live Messenger, qui pouvait avoir de fâcheuses conséquences : en plus de pouvoir faire planter le navigateur de n’importe quel utilisateur du service, elle permet d’accéder à toutes les fonctionnalités implémentées par Messenger FX ce qui signifie entre autre : récupérer la liste de contact de l’utilisateur, envoyer des messages en son nom, supprimer, bloquer et débloquer des personnes de sa liste de contact et lui en ajouter, lire les messages, bref : de prendre le contrôle complet du compte MSN de la victime.

Vendredi, j’ai reçu un email de l’équipe MessengerFX m’indiquant que le problème est corrigé :

Hi Kevin,
First of all i want to thank you for your warn. We fixed that problem and
now its working correctly.
[…]

La correction actuelle ne permet plus d’envoyer de code Javascript via MessengerFX à un ami et éxecute toujours le dis code en local (sur l’ordinateur de celui qui l’envoi). L’équipe indique que la prochaine version, bientôt disponible, inclura une meilleure gestion de l’envoi de code via l’application internet.

Faire fonctionner Google Notifier pour Mac en mode sécurisé

Peut-être utilisez-vous Google Notifier pour OS X ? Cet un utilitaire permet d’avertir en temps réel lors de la réception d’un messages sur Gmail, de rappeler les rendez-vous Calendar et d’intégrer ces services au système d’Apple.

Le problème, c’est que par défaut il fait transiter vos identifiants en clair sur le réseau. Si vous vous connectez à un réseau sans fil partagé tel que le réseau Wi-Fi de votre université ou d’une gare, c’est le vol de compte assuré.

Heureusement, une option cachée permet de forcer l’utilisation d’une connexion sécurisée via HTTPS, pour l’activer déployer le menu déroulant en cliquant sur l’icône de Google Notifier, appuyez simultanément sur commande (Pomme) et option (alt) puis sélectionnez l’entrée Preferences....

Dans la fenêtre qui apparait entrez SecureAlways pour Key et 1 pour Value.

Cliquez sur Set pour valider et fermez la fenêtre. C’est fait !

Que vous utilisiez un Mac ou non, c’est toujours une bonne idée de vous connecter à Gmail via https://gmail.com afin de ne pas vous faire voler vos mots de passe. Pour éviter les dangereux oublis il existe une option intitulée Toujours utiliser le protocole https activable depuis les paramètres de l’application web.

Astuce originalement trouvée par Highplace.

Nouvelle offre d’hébergement à bas prix chez Gandi : installez votre serveur web

Gandi m’a gentiment fourni une invitation à la bêta de leur service d’hébergement. Je compte y passer ce blog et voir comment se comportent les frameworks Symfony et Django sur ces serveurs virtualisés et scalable.

J’ai donc pris une part (6€ HT/mois) afin d’y installer un serveur web composé d’Apache, de PHP, de MySQL et géré par hosting.py.

Première opération, créer le serveur. J’ai choisi le mode expert et Ubuntu comme distribution (c’est le choix par défaut). Tout ce fait très simplement via le site internet de Gandi. Quelques minutes après la création du serveur via l’interface un mail arrive vous indiquant l’adresse IP de votre serveur tout neuf.

C’est une version personnalisée par Gandi de Gutsy qui est installée, un peu vieille mais très stable, cela me convient parfaitement.

Première opération : mettre à jour la distribution.

Connectez vous via SSH puis passez en root en tapant su (un peu perturbant pour une Ubuntu n’est-ce pas :P) puis tapez la classique commande apt-get update && apt-get dist-upgrade. Cette mise à jour est importante car elle corrige certaines failles de sécurité critiques dont celle désormais célèbre touchant le protocole DNS.

Installer Apache, PHP et MySQL

La commande magique pour installer le tout : apt-get install apache2 mysql-server php5 libapache2-mod-php5 php5-mysql phpmyadmin.

L’utilitaire d’installation vous demandera d’abord de choisir un mot de passe pour le compte root du serveur MySQL puis de sélectionner quel version d’Apache doit être configurée pour être utiliser avec phpMyAdmin : choisissez apache2.

Vous pouvez taper l’adresse IP de votre serveur dans votre navigateur préféré afin de vérifier que tout fonctionne bien. phpMyAdmin est accessible depuis http://<votre_ip>/phpmyadmin/.

Une petite amélioration afin d’augmenter les performances : installons xcache. Comme son nom l’indique, xcache permet de mettre en cache les versions “compilées” des scripts PHP (opcode) et ainsi d’améliorer grandement les performances du langage le plus populaire du web.

Rien de plus facile : apt-get install php5-xcache. La commande /etc/init.d/apache2 restart vous permettra de rendre effective la mise en cache.

Sécurisons tout ça

Très bien, notre serveur fonctionne. Mais ce n’est pas encore la panacée. Une simple requête HTTP GET nous renvoi comme en-têtes :

Les en-têtes HTTP sont riches, trop riches : on y apprend que le serveur fonctionne sous la distribution Ubuntu Linux, que le serveur web est Apache en version 2.2.4, que le langage de script PHP en version 5.2.3 est disponible et que les versions installées sont celles pacagées par la distribution (ce qui donne des indices supplémentaires sur la configuration utilisée). Ces informations sont en partie reprises dans les pages d’erreurs et les index générés automatiquement du serveur web.

Même si cacher les noms et numéros de versions des logiciels installés n’améliore pas la sécurité réelle de votre serveur elle le rend moins visible des pirates en herbe et autres robots des amateurs de warez.

Pour masquer les informations distillées par Apache éditons le fichier /etc/apache2/apache2.conf, remplaçons la ligne ServerTokens Full par ServerTokens Prod puis ServerSignature On par ServerSignature Off.

Pour celles que fourni PHP c’est dans /etc/php5/apache2/php.ini que ça se passe. Remplacez expose_php = On par expose_php = Off. Même si cela n’a rien à voir avec les numéros de versions, ça peut être une bonne idée de désactiver églament les magic quotes en remplaçant magic_quotes_gpc = On par magic_quotes_gpc = Off.

Relançons encore une fois Apache /etc/init.d/apache2 restart afin de faire prendre en compte nos modifications, c’est mieux.

Reste MySQL. Nous avons défini un mot de passe pour le compte root lors de l’installation mais il reste quelques brèches importantes comme la possibilité de se connecter sans compte ou celle d’utiliser le compte root depuis l’extérieur (sans passer par une console SSH ou phpMyAdmin – ce qui facilite les attaques par force brute).
Un script fourni nommé mysql_secure_installation permet de remédier à tous ces problèmes. Lancez-le. Excepté pour le changement de mot de passe root que nous venons de définir lors de l’installation je vous conseil de répondre par le choix proposé par défaut à toutes les questions.

Notre serveur est un peu mieux préparé à survivre dans la jungle qu’est le web.

Note : nous n’abordons ici que la sécurisation des composants LAMP de notre serveur. C’est un bon début mais c’est loin d’être une protection absolue ou suffisante.

Installer hosting.py

hosting.py est un petit logiciel que j’ai développé qui permet de gérer de manière très simple des comptes web. Il se base sur le système de gestion des utilisateurs UNIX et automatise les tâches les plus courantes lors de l’administration d’un petit serveur web mutualisé à savoir la mise en place et la modification de compte comprenant un utilisateur UNIX (accès SSH, FTP, …), un hôte virtuel apache, un compte et une base de données MySQL.

Il est conçu pour fonctionner avec les distributions basées sur Debian, Ubuntu en particulier. Il permet de simplement séparer les comptes des différents sites qu’hébergera votre serveur, ce qui n’est pas un mal question sécurité.

Commençons par installer les dépendances nécessaires à la récupération et à l’utilisation de mon script : apt-get install subversion python-mysqldb

Créons maintenant le squelette du répertoire de base des comptes web :

  • mkdir /etc/skel-www
  • mkdir /etc/skel-www/logs
  • mkdir /etc/skel-www/public_html

Comme son nom l’indique, logs accueillera les logs de connexion d’Apache (on pourra plus tard configurer AWstats pour générer des statistiques) et public_html sera le répertoire web de nos utilisateurs.

Récupérons la dernière version de hosting.py via Subversion : svn checkout http://debian-hosting.googlecode.com/svn/trunk/ debian-hosting-read-only

Éditez la variable MYSQL_PASSWD du fichier debian-hosting/hosting.py pour qu’elle contienne le mot de passe MySQL de l’utilisateur root puis donnez les droits en exécution sur ce même fichier en tapant chmod a+x debian-hosting/hosting.py.

Pour créer un compte utilisateur, passez en root avec la commande su puis tapez debian-hosting/hosting.py add monsite.com. Vous pouvez voir les informations de connexion s’afficher, notez les 🙂

Un sous domaine du type monsite.com.dunglas.fr est automatiquement créé (pour être effectif, il nécessite que dunglas.fr, notre domaine de test, dispose d’un wildcard dans ses entrées DNS).

Je vous conseil de le laisser à des fins de test et de debug, néanmoins un vrai nom de domaine c’est mieux. Toujours en tant que root éditez le fichier généré automatiquement nommé /etc/apache2/sites-available/monsite.com et transformez la ligne ServerName monsite.com.dunglas.fr en ServerAlias monsite.com.dunglas.fr. Ajoutez au dessus de celle-ci ServerName monsite.com.

Rechargez Apache (toujours en root) : /etc/init.d/apache2 reload

Votre serveur web est le site que vous avez créé sont fonctionnels si vos entrées DNS sont bien configurées. Placez vos fichiers web dans /home/monsite.com/public_html/ pour qu’ils soient visibles sur http://monsite.com 🙂

Vulnérabilité critique dans MessengerFX

MessengerFX est un client populaire pour Windows Live Messenger (anciennement MSN Messenger) écrit en AJAX. Sa spécificité et de permettre de se connecter au réseau via un simple navigateur web.

En voulant coller du code HTML à Edouard, je me suis rendu compte qu’il était interprété par le navigateur. Faille de type XSS ? Effectivement ! Sauf que celle-ci n’est pas bénigne : en plus de pouvoir faire planter le navigateur de n’importe quel utilisateur du service, elle permet d’accéder à toutes les fonctionnalités implémentées par Messenger FX ce qui signifie entre autre : récupérer la liste de contact de l’utilisateur, envoyer des messages en son nom, supprimer, bloquer et débloquer des personnes de sa liste de contact et lui en ajouter, lire les messages, bref : de prendre le contrôle complet du compte MSN de la victime.

Faille de Cross Site Scripting dans MessengerFX

Pire, il est tout à fait possible d’écrire un vers en utilisant les fonctions d’envoi de message. Ce vers pourrait par exemple supprimer tous les contacts de toutes les personnes connectées à Messenger FX… voir faire tomber le réseau MSN dans son ensemble par une attaque de type DDOS.

J’ai envoyé un email au propriétaire du service qui reste à ce jour sans réponse. En attendant une correction, simple comme un htmlspecialchars(), abstenez-vous d’utiliser Messenger FX et préférez-y Meebo ou le client officiel de Microsoft version web !

Edit du 6 octobre 2008 : la faille semble maintenant corrigée.

Sécurisez votre blog WordPress !

L’installation par défaut de WordPress pose quelques gênants problèmes de sécurité. Nous allons nous employer à les corriger.

Cachez le contenu des répertoires internes

Par défaut, WordPress ne bloque pas l’accès à tous les répertoires nécessaires à son fonctionnement que le public ne devrait pas pouvoir consulter. C’est le cas du très sensible répertoire wp-content/plugins. Les plugins que vous installez peuvent avoir étaient développés par des programmeurs novices ou ne pas avoir été correctement audités et contenir des failles de sécurité. Par défaut, WordPress permet à n’importe qui de lister les plugins que vous avez installé. Pour y remédier, entrez la ligne suivante dans votre fichier .htaccess, à la racine de votre répertoire :
Options -Indexes
Désormais, si un curieux tente d’accéder à des répertoires sensibles, il ne verra qu’une erreur 403.

Supprimez le numéro de version des meta-tags

De nombreux thèmes WordPress dont celui par défaut affichent un vilain meta-tag :
<meta name="generator" content="WordPress 2.3.3" /> <!-- leave this for stats please -->
Le petit commentaire associé ni changera rien, ce meta-tag est une très mauvaise idée ! Il permet aux pirates de connaitre instantanément quelle version du logiciel vous utilisez et quelles sont les failles de sécurité qui la touchent. Il pourrait même permettre à un robot d’attaquer massivement les sites utilisant des WordPress non mis-à-jour.

La aussi, la correction est simple, ouvrez le fichier header.php de votre thème (dans le répertoire wp-content/themes/default/ pour le thème par défaut) et cherchez :
<meta name="generator" content="WordPress <?php bloginfo('version'); ?>" /> <!-- leave this for stats -->
Si vous êtes sans états d’âmes pour les statistiques de WordPress supprimez simplement la ligne, sinon remplacez-la par :
<meta name="generator" content="WordPress" /> <!-- leave this for stats -->
Espérons que WordPress 2.5 corrigera ces problèmes.

Pour finir, quelques conseils en vrac

  • Bien-entendu, veillez à toujours tenir à jour votre WordPress et tous ses plugins.
  • Désactivez et supprimez les plugins que vous n’utilisez pas.
  • N’hésitez pas à renforcer la protection du dossier wp-admin/ par un fichier .htaccess.
  • Masquez également la version d’Apache et de PHP utilisée en mettant ServerTokens à Prod.

De jolies URLs pour optimiser votre référencement

Je vais vous présenter ici une technique de ré-écriture d’URL en PHP. Nous l’appellerons URL Rewriting via PATH_INFO. Celle-ci est un peu particulière, elle est indépendante d’Apache. Elle fonctionnera même si votre hébergeur désactive le ModRewrite ou si vous utilisez un serveur web alternatif.

Prenons une page imaginaire nommée http://monsite.com/recette.php?cat=tomate&id=2 et intitulée Mon plat secret qui détaillera notre succulente recette de pâtes à la tomate.
L’URL que nous souhaitons obtenir est http://monsite.com/recette/tomate/2-plat-secret.

Mais un exemple vaut mieux qu’un long discours… Rendez-vous sur le catalogue de l’Âne qui butine pour une démonstration.

Cette adresse présente trois avantages face à la première :

  • Elle ne contient pas de paramètres (?cat=tomate&id=2), et c’est tant mieux. Les pages accessibles de cette manières, si elles ne sont pas tout simplement ignorées, ne seront que faiblement pris en compte par les moteurs de recherche.
  • Des mots-clefs apparaissent dans l’adresse (plat-secret). Ils peuvent être simplement générés à partir du titre de la page (peut-être y reviendront nous dans un prochain article) et auront un puissant impact sur votre positionnement.
  • L’extension de la page n’apparait plus. Vos adresses n’en seront que plus simples à mémoriser et les pirates de découvrirons pas du premier coup d’œil quelle technologie vous utilisez (ici PHP).

Ceci est un exemple de code que vous allons ensuite modifier :

(Note : même en conservant l’extension la technique présentée ci-dessous fonctionnera.)Première opération, supprimer l’extension de la page. Si vous utilisez la configuration par défaut d’Apache c’est très facile, il n’y a rien à faire ! Si http://monsite.com/recette?cat=tomate&id=2 ne fonctionne pas il va falloir activer l’option MultiViews d’Apache. Il vous faudra ajouter à votre fichier .htaccess :
Options +MultiViews
Entrons dans le vif du sujet, la ré-écriture d’URL en PHP ! Pour ce faire nous utiliserons la variable d’environnement CGI nommée PATH_INFO. Cette variable contient tout ce qui est contenu dans l’adresse après le nom du fichier, y compris le “/” initial. Avec notre adresse http://monsite.com/recette.php/tomate/2-plat-secret, PATH_INFO contiendra /2-plat-secret. Nous y accèderons via le tableau super-global $_SERVER et en extrairons l’identifiant qui est séparé des mots clefs par le caractère “-“. Et maintenant, le code !

Et nous voici avec notre jolie URL qui se référencera très bien dans les moteurs de recherche !