Écriture inclusive et risques de sécurité

Je ne vais pas rentrer dans le débat du pour ou contre l’écriture inclusive. Mon propos est ici d’étudier l’impact d’une forme de graphie utilisée dans le cadre de l’écriture inclusive française sur la sécurité des systèmes d’information.

Il existe différentes formes ou manière de faire de l’écriture inclusive, utilisant différents artifices typographiques. Malheureusement, une des formes les plus élémentaires - celle qui utilise le point de ponctuation pour séparer les blocs - crée parfois des noms de domaines, comme par exemple : enseignant.es, doctorant.es, etc.

L’auteur d’un texte rédigé avec cette forme d’écriture inclusive peut donc se trouver rapidement à truffer sa prose de noms de domaine espagnols. Dans le cas d’un support totalement maîtrisé comme le papier ou l’image, l’impact est faible car le texte n’est pas immédiatement accessible à la machine. Il faudrait opérer une reconnaissance optique de caractère pour retrouver un texte électronique exploitable.

Malheureusement pour cette forme d’écriture, les supports numériques prévalent de plus en plus, et la maîtrise du support disparaît presque totalement au profit d’intermédiaires, de médias, qui peuvent décider d’améliorer l’expérience utilisateur sans demander son avis à l’auteur initial. Que cet intermédiaire soit un logiciel bureautique, un CMS, une plateforme de réseau social, une application de SMS, une messagerie instantanée, etc. nombreux sont ceux qui vont s’arroger le droit d’activer les URL qu’ils détectent dans les contenus soumis. Ainsi, quand un auteur écrit que « les étudiant.es peuvent se porter candidat.es au concours d’infirmier.es », il est bien possible que le média de publication informe les lecteurs que « les étudiant.es peuvent se porter candidat.es au concours d’infirmier.es ». La différence est de taille : les mots suffixés en .es sont devenus des URL actives.

Qui dit URL actives dit aussi : téléchargement d’un aperçu, possibilité de clic volontaire ou non sur une de ces URL, et dans des cas rares de vulnérabilité logicielle, possibilité de téléchargement de l’URL sans clic de la part du lecteur.

À titre de démonstration et d'expérience j'ai personnellement enregistré les noms étudiant.es et enseignant.es, puis je les ai faits pointer sur une page web que je maîtrise pour mesurer le comportement des utilisateurs en présence de ces noms de domaines. Sur une période de 31 jours, je mesure 5265 requêtes GET tous visiteurs confondus (avec une majorité de robots donc). Sur la même période, je mesure environ 350 visiteurs réels, soit plus de 10 par jour en moyenne, et avec un pic à 54 visiteurs un jour particulier.

Nombre de "GET" par jour sur étudiant.es et enseignant.es

Nombre de "GET" par jour sur étudiant.es et enseignant.es


Estimation du nombre de "vrais visiteurs" par jour sur étudiant.es et enseignant.es


Les traces sur le serveur web montrent aussi qu'un grand nombre des requêtes de robots sont faites par des plateformes de réseau social, au moment où ces plateformes analysent le lien posté par l'utilisateur (création de l'aperçu, de l'URL raccourcie, détection de malware, analyse du contenu promu par l'utilisateur, etc.). Par exemple : Twitterbot, Facebookbot, EveryoneSocialBot, et autres.

L’URL ainsi activée va en général se retrouver sur des supports largement diffusés. On peut penser notamment à un CMS d’institution, mais aussi à des documents PDF, des emails, des messages diffusés sur des plateformes de réseau social comme Facebook, Twitter, Linked’In. Dans une grande université française, un seul auteur peut ainsi toucher directement 20000 à 60000 individus, et indirectement bien plus.

Il est donc normal dans un tel contexte d’envisager ce qu’il se passerait si par exemple quelqu’un décidait d’enregistrer tout ou partie de ces noms de domaines espagnols pour faire des choses avec :

  • Faire du profit (affichage de publicité, vente de contrefaçon, pornographie, etc.)
  • Attaquer les lecteurs de certains contenus en distribuant des malwares
  • Lancer une campagne de phishing contre les lecteurs de ces contenus
  • Porter atteinte à l’image de l’auteur (incitation à la haine, diffamation, etc.)

L’attaque en elle-même est extrêmement simple et économique. La location d’un nom de domaine à l’année coûte une poignée d’euros, et la plupart de ces mots français sont disponibles en .es. Par ailleurs, elle peut se produire à tout moment, et le plus tard est même le mieux : plus le nom de domaine est répandu, plus il est diffusé largement et dans un grand nombre de documents et supports, plus son exploitation devient intéressante.

Comme évoqué ci-dessus, les motivations de l’attaquant peuvent être diverses, néanmoins les effets de l’attaque sur l’auteur ou sur son entreprise/institution sont toujours les mêmes. Inévitablement il se produit un dégât d’image : personne ne trouverait normal en cliquant sur le mot canditat.es dans une communication officielle d’entreprise d’arriver sur un site pornographique (sauf bien évidemment si cette entreprise gère le site en question). Idem si le lecteur voit son antivirus passer au rouge suite à un clic sur infirmier.es.

Ensuite, il peut se produire une perte pour l’entreprise ou pour l’auteur : perte de temps et d’argent car il faut rapidement neutraliser les documents ou les URL dans les documents publiés. Cette opération curative est indispensable, mais impossible en pratique à faire en totalité : en effet il est impossible d’aller modifier les emails déjà envoyés, les documents PDF ou bureautique déjà téléchargés par le public, les SMS, etc.

Si l’attaquant a choisi une posture très offensive en faisant pointer les URL vers des malwares, alors l’auteur des contenus entre dans un nouveau cercle des Enfers : il pourra être amené à découvrir ce qu’il se produit lorsque Google décide de faire disparaître son site web des résultats de recherche, ce qu’il se produit quand tous les antispam de la planète décident de bloquer les emails qu’il envoie. Le blocage ne sera pas immédiat bien sûr, laissant à l’attaquant une fenêtre de tir pendant laquelle il pourra infecter d’innocents lecteurs. D’une pierre deux coups, en quelques sortes. Je n’ai pas de certitude sur le comportement des réseaux sociaux dans ce cas de figure, mais il est possible que certains décident de supprimer les messages contenant des liens vers des malwares, que d'autres suspende le compte de l'auteur. Autant dire que tout à coup, les choses vont devenir très compliquées pour l’auteur.

À mon avis, il y a ici un risque qui vaut la peine d'être pris en compte. Même si on constate que le nombre de clics volontaires ou non sur ces liens automatiques est relativement faible, il reste très largement supérieur au "taux de conversion" habituel d'une campagne de phishing par email. Et nous protégeons tous nos utilisateurs contre le phishing, n'est-ce pas ?
Ici l'attaque part d'un support légitime, réellement écrit par son auteur : il ne s'agit pas d'un faux message de votre Support utilisateur écrit dans un français approximatif. Non, il s'agit de transformer des contenus légitimes en vecteur d'attaque sans même avoir besoin de modifier ces contenus.

À méditer.

Data leak at Elinchrom

As I'm paranoid, I create a brand new email address each time I've got to register on a web site. It's easy enough and allows me to partition usages and detect abuse. If one of those dedicated addresses ends up in the wild (spammers for example), I just destroy it.

CCBY ©Yuri Samoilov via Flickr

CCBY ©Yuri Samoilov via Flickr


So, in 2010 I registered a support account on Elinchrom's web site with a tailored address : elinchrom (@patpro.net of course). Later, during September 2014, I've received a big spam at that address, neither from Elinchrom nor from one of their partner. After a quick search I've found many other spams blocked by my server. The earlier arrived in 2013.
I've contacted the company, explained the problem, and sent extracts from my mail server logs. After few days, they could find no evidence of a compromise or a data leak on their side. Fair enough, that's not the kind of things you can detect easily, especially if it's years old. On a side note: it's not impossible that I've used the same email address for a contest or event registration affiliated with Elinchrom but not run by them. My bad. At least, this time they deserved the benefit of the doubt.
Following this leak, I've changed the address email to elinchrom2014 (still @patpro.net) and changed the associated password.
The 31th of December 2015 I've received my very first email at this new address: a Paypal phishing attempt, out of a hacked web server somewhere…
Fine.

As I'm super-vigilant since 2014 not to use this address anywhere, the only possible scenario is a data leak at Elinchrom. Going back into my logs, I've found the earliest spam blocked dated from the 24th of October:

Oct 24 17:17:50 postfix/smtpd[84170]: NOQUEUE: reject: RCPT from unknown[202.71.131.54]: 550 5.7.1 Client host rejected: cannot find your hostname, [202.71.131.54]; from=<apache@corp17.net4india.com> to=<elinchrom2014@...> proto=ESMTP helo=<smtp.net4india.com>

I've immediately destroyed this email address, created a new one (longer, with random characters), changed the password again.

Elinchrom: seriously, that's ridiculous, do something. Even the user authentication does not use HTTPS. WAKE UP, it's 2016.

Firefox mange mon CPU

Comme je suis vieux et extrémiste, j'ai décidé de ne pas adhérer aux mises à jour continuelles des systèmes d'exploitation Apple. Ce que proposent les nouvelles versions est rarement intéressant (cloud, flicage des utilisateurs, baisse des performances, App Store, etc.).
Le souci avec les vieux logiciels, c'est le manque de sécurité qu'ils offrent. Les nouveaux ne valent guère mieux, mais la mesure du risque se fait sur le nombre de failles connues, et donc à ce compte là, les anciennes versions sont toujours perdantes. Ne faisant plus évoluer mon système, mais passant mon temps sur internet, j'ai donc du m'adapter : virer mon Safari préhistorique, et installer un navigateur bien à jour, au taquet, fourni par un éditeur qui lui ne se fout pas de ma gueule (comprendre qu'il n'oblige pas les gens à acheter un nouveau Mac pour bénéficier d'un navigateur web à jour).

Bref, j'utilise Firefox.

J'en étais content, jusqu'au moment où j'ai trouvé qu'il était relativement lent, puis lent, puis très lent, puis très très lent. En fait, ce navigateur mange mon CPU. Petit à petit. Si vous êtes le genre d'utilisateur qui allume/éteint sa machine tous les jours, vous n'avez pas ce problème. Mais si vous laissez le chauffage d'appoint allumé 24/7/365, alors vous pourriez constater ce genre de chose :

firefox_cpu-580

Avec le temps qui passe Firefox consomme de plus en plus de cycles de processeur. Après une poignée d'heures, il est environ à 18%. Sans rien faire avec, 200 minutes plus tard il consomme 21% du CPU. Après 1000 minutes, il oscille entre 33 et 35% CPU.
On constate aussi que le nombre de threads de l'application gonfle tranquillement.

J'ai tenté d'accuser les extensions, mais je n'en utilise que 2 et une fois désactivées Firefox avait le même comportement. J'ai aussi tenté d'analyser le comportement du navigateur avec Instruments, sans succès. Je ne comprends pas d'où vient le souci. Peut être d'une des pages web que je garde ouvertes en permanence… Quoi qu'il en soit, c'est un peu dommage, je vais devoir programmer un redémarrage de Firefox toutes les nuits

Le racket des certificats SSL

Autrefois, Internet était un peu open bar. C'était un lieu de partage où tout le monde pouvait publier, échanger, créer librement. C'était l'insouciance. Puis il y a eu l'arrivée du commerce en ligne, avec des échanges d'argent numérique. Il a alors fallu créer la confiance, car dans nos vies pressées il n'est plus question de l'acquérir sur le long terme, non, il faut la créer de toute pièce pour en disposer immédiatement.
Sont alors arrivés en masse les sites marchands (ou non) proposant des connexions sécurisées "https". Plus récemment, l'usage des connexions sécurisées par SSL/TLS s'est beaucoup élargi, non plus pour protéger vos données bancaires d'une interception mais pour protéger votre vie privée. Il est en effet primordial de pouvoir publier sa vie sur facebook ou twitter sans qu'un méchant pirate puisse espionner directement sur votre connexion ce que vous écrivez sur ces sites.

C'est bien de promouvoir la sécurité des échanges sur internet, d'encourager les gens à proposer des services chiffrés, et les initiatives ce multiplient dans ce sens, avec par exemple des navigateurs qui vont tenter de se connecter à la version https d'un site web par défaut, et se rabattre sur la version http seulement quand la version sécurisée n'existe pas.

Pour transformer un service http classique en service sécurisé https, il faut disposer d'un certificat SSL/TLS. Malheureusement seuls les gens riches peuvent proposer des services sécurisés "de confiance". En effet il existe globalement trois manières de se procurer un certificat SSL. Vous pouvez le fabriquer vous même, c'est assez simple, cela prend quelques minutes et c'est totalement gratuit. Vous pouvez demander à un opérateur libre et gratuit comme CaCert.org de vous le proposer, c'est à peine plus long et toujours gratuit. Ou alors, vous avez de l'argent (beaucoup), et vous l'achetez chez un prestataire.
Et là, nous sommes face à trois obstacles majeurs, qui sont le Certification Authority Browser Forum, les moteurs de recherche, et le prix.

Chrome vous ment, ce qui ne profite qu'aux grosses entreprises

Chrome vous ment, ce qui ne profite qu'aux grosses entreprises

Le Certification Authority Browser Forum est un lieu d'échange entre les développeurs de navigateur d'une part et les autorités de certification d'autre part. Ces gens se mettent d'accord sur plein de détails techniques autour de l'implémentation de la sécurité des certificats dans les navigateurs. Notamment, c'est en partie là-bas qu'ils se mettent d'accord sur quelle autorité de certification (CA) va se trouvée incluse d'office dans la liste des CA valides des navigateurs. En effet, quand vous ouvrez une page web en https, le serveur présente son certificat. Ce dernier indique par quelle CA il a été signé. Si la CA est reconnue par le navigateur tout va bien, sinon l'utilisateur reçoit une alerte indiquant que la connexion n'est pas sécurisée, qu'on ne peut pas lui faire confiance, etc. Ces messages d'alerte ont d'ailleurs beaucoup évolué depuis quelques années. Actuellement, ils sont juste mensongers. Ils induisent pour son bien l'utilisateur en erreur allant jusqu'à prétendre à tort que la connexion n'est pas sécurisée. Ce mécanisme induit chez les utilisateurs une confusion (criminelle oserais-je dire) entre sécurité et confiance, en faisant passer "une confiance que l'outil ne peut vérifier" pour une "sécurité qui n'existe pas".

Confusion sécurité confiance

Confusion sécurité confiance

Les moteurs de recherche ne sont plus ce qu'ils étaient à leurs balbutiements dans les années 90. Ils intègrent désormais des algorithmes extrêmement complexes de classement (ranking) autorisant des recherches personnalisées et un placement de produits optimisé. En parallèle ils se sont arrogés le droit de surclasser ou de déclasser des résultats de recherche selon des critères tout à fait critiquables. Google a notamment décidé d'améliorer la visibilité des sites qui répondent à des critères de sécurité arbitraires. Essentiellement cela revient à surclasser les sites internet disposant d'un certificat SSL EV (extended validation, les plus chers).
Ainsi, si vous n'êtes pas en mesure de proposer votre site web en https, avec un certificat valide et de préférence un certificat EV, vous êtes déclassés au profit de la concurrence.

Comme vous l'avez compris, la seule planche de salut pour obtenir la confiance des navigateurs et donc des utilisateurs qui sont derrière est de proposer une connexion https avec un certificat acheté chez un fournisseur du commerce. Ces certificats sont excessivement chers. Et ce tarif ne permet simplement pas, même à des individus passionnés, de proposer une connexion https qui aurait les faveurs de Mozilla ou Google.
J'utilise sur ce serveur un certificat SSL de CaCert qui contient 20 noms différents (patpro.net, www.patpro.net, patpro.fr, etc.). Ce certificat ne me coûte rien, il me permet de proposer le chiffrement SSL/TLS pour mon serveur web et pour mon serveur de mail. Si je veux obtenir un certificat comparable chez les autorités de certification du commerce, il m'en coûtera 2582 euros chez Thawte ou 6280 dollars chez Verisign/Symantec, pour un certificat valide pendant une année. À ce tarif là, c'est un certificat d'entrée de gamme, qui sera reconnu dans votre navigateur, mais ne disposera pas de la belle "barre-verte-qui-stimule-la-confiance-du-visiteur-et-améliore-le-référencement".

La fameuse barre verte qui doit donner confiance aux utilisateurs

La fameuse barre verte qui doit donner confiance aux utilisateurs


Pour disposer d'une telle parure il me faut être une entreprise, montrer patte blanche, et débourser 18200 dollars chez Verisign, toujours pour 1 an et mes 20 noms de domaines.
Heureusement il existe des alternatives un peu moins coûteuses, comme chez Gandi par exemple, où je pourrai trouver un certificat répondant à mes besoins pour 210 euros par an, ou 1900 euros en version EV. C'est toujours un coût sérieux pour un individu.

Donc la situation actuelle se résume assez simplement : les gros acteurs du web, Google en tête, poussent très fort pour que les utilisateurs ne fassent pas confiance à des certificats autosignés, ou gratuits. Ils utilisent un discours tellement simpliste qu'il en devient mensonger. En trompant l'utilisateur, ils favorisent la visibilité sur internet des gens riches, au dépend de ceux qui n'ont pas les mêmes moyens. En diffusant des messages anxiogènes aux utilisateurs, ils dévoient la sécurité réelle proposée par des certificats SSL légitimes.

Une adresse email pour chaque contact ?

Depuis de nombreuses années j'ai pris l'habitude de créer une adresse email spéciale pour (presque) chaque site web sur le quel je m'inscris. D'une part cela apporte un bénéfice de sécurité immédiat car il est courant que l'adresse email soit aussi le login pour un système d'authentification sur le site en question. Donc ce login est différent pour chaque site.
D'autre part, cela me permet de cloisonner le spam, et de détruire sans aucun état d'âme toute adresse email qui serait un peu trop "publique". Au quotidien, c'est aussi un excellent moyen de savoir qui distribue votre adresse email, et qui la garde pour lui comme promis.

Le cas s'est présenté précédemment avec l'adresse email que j'utilisais pour l'association des anciens de mon école d'ingénieurs. Quand j'ai commencé à recevoir de la publicité pour du vin, j'ai détruit l'adresse. Maintenant il ne leur reste que mon adresse postale, ce qui leur pose quelques soucis. Il fallait y penser avant de faire n'importe quoi avec l'annuaire.
Le cas que je souhaite évoquer ici est un peu plus grave. Il s'agit du photographe Zack Arias et de sa liste OnelightWorkshop.
Il a créé sa liste de diffusion d'information au sujet de ses ateliers fin 2009 ou début 2010. Et je m'y suis inscrit presque aussitôt. Il annonce d'ailleurs sur son site :

Sign up on our email list for news about the workshop. We promise not to spam you or pass your information on to any third party. You can expect about 4 emails a year from us… at most.

4 emails par an, c'est à peu prêt vrai, si on s'en tient aux messages légitimes. Par contre, pour le reste, il y a comme un souci. J'hésite entre négligence criminelle, "je-m'en-foutisme", ou grossière escroquerie. Quoi qu'il en soit, moins de 15 jours après le premier message légitime, le spam a commencé à arriver. Les chiffres sont, ces derniers temps, plutôt alarmants :

spam volume per month

Le nombre de messages légitimes est juste invisible sur ce graphique, tellement la masse de spam est importante. Je ne m'en suis aperçu que très tardivement, car mon antispam fait très bien son travail, mais je vais de ce pas détruire cette adresse email.

Maintenant on peut se demander comment ce photographe protège ses clients, leurs données personnelles bien sûr, mais aussi les travaux en cours, les photo confidentielles ou qui devraient rester à jamais privées. Savoir gérer un business de nos jours, c'est aussi savoir répondre efficacement à toutes ces problématiques de sécurité des informations, de protection des données personnelles.
Je suis sûr d'une chose : je ne fournirai plus aucune donnée personnelle à M. Arias.

Collecte en aveugle

Elle est belle celle-là :

213.61.149.100 […20:00:26 +0100] "GET / HTTP/1.0" 301 235 
213.61.149.100 […20:00:27 +0100] "GET /blog/ HTTP/1.0" 200 63772 
213.61.149.100 […20:00:28 +0100] "GET /www.patpro.net.tar.gz HTTP/1.0" 404 493 
213.61.149.100 […20:00:28 +0100] "GET /www.patpro.net.tgz HTTP/1.0" 404 493 
213.61.149.100 […20:00:29 +0100] "GET /www.patpro.net.zip HTTP/1.0" 404 493 
213.61.149.100 […20:00:29 +0100] "GET /www.patpro.net.sql HTTP/1.0" 404 493 
213.61.149.100 […20:00:30 +0100] "GET /patpro.tar.gz HTTP/1.0" 404 493 
213.61.149.100 […20:00:30 +0100] "GET /patpro.tgz HTTP/1.0" 404 493 
213.61.149.100 […20:00:31 +0100] "GET /patpro.zip HTTP/1.0" 404 493 
213.61.149.100 […20:00:31 +0100] "GET /patpro.sql HTTP/1.0" 404 493 

Et particulièrement astucieuse, je suis persuadé qu'elle permet de ramasser des tonnes de trucs très intéressants.

Message personnel à Mme Filippetti

Bonjour Madame Filippetti,

Votre entrevue récente avec Libération m'interpelle. Vous y déclarez ceci :

Vous avez aujourd’hui des outils qui permettent d’accéder à de la musique, du cinéma, des contenus audiovisuels, mais qui ne participent pas du tout au financement de la création. Ce n’est pas normal.

Allez-vous taxer les lunettes, lentilles correctrices, et appareils auditifs ? En toute logique, nous sommes nombreux à ne "consommer" de la culture qu'au travers de ce type d'appareil, il serait donc judicieux de les taxer rapidement.

On n'est pas loin du monde idéal rêvé par les gros portefeuilles de l'entertainment : un monde où la simple possibilité d'accéder à du contenu devient payante, qu'on y accède ou pas. Ça évite d'avoir à courtiser les clients avec des contenus de qualité, bien trop compliqués et coûteux à produire. Il vaut mieux comme toujours prendre un peu à tout le monde que beaucoup à une minorité.

Bref, raz le bol quoi.

Pas tous égaux devant le spam

Là où je travaille, une partie de la population ne reçoit pas de spam, ou presque. L'autre partie reçoit une grosse quantité de spam. La raison est simple : les utilisateurs du second groupe ont leur adresse email publiée sur le portail web de l'université.
Alors bien sûr, c'est une évidence. On le sait tous depuis longtemps : une adresse email publiée sur un site web devient immanquablement, et en l'espace de quelques jours, une cible privilégiée pour le spam. Oui, on le sait. Mais est-ce qu'on le mesure ?
Comme mes serveurs MX brassent des millions de messages par mois, je peux faire des statistiques assez simplement (moyennant de longues heures de traitement sur des giga octets de logs). J'ai donc compté le spam visant les deux groupes, ainsi que les volumes de phishing relevés lors de 4 "attaques" facilement traçables. Le constat est sans équivoque :

Une adresse email publiée sur le portail web de l'université reçoit 31,2 fois plus de spam qu'une adresse non publiée.

Une adresse email publiée sur le portail web de l'université a 59 fois plus de risque d'être la cible d'un phishing qu'une adresse non publiée.

À bon entendeur...