« La cybersécurité de zéro » : venez participer et gagner un exemplaire !

Voici deux anecdotes.

Base64 en tant que cipher

Dans ma première entreprise, nous étions amenés à collaborer avec des équipes d’autres sociétés, avec lesquelles il fallait se mettre d’accord pour faire des API entre nous.

À cette époque, le mouvement du "HTTPS everywhere" n’était pas encore bien amorcé, on voyait encore hélas pas mal d’API en clair, comme les nôtres et celles de nos correspondants. Après tout, « c’était que pour de l’interne ».

Conscient de ce problème, notre interlocuteur nous propose d’échanger des messages JSON qui seraient d’abord encodés en Base64, car « c’est plus sûr ». Pour éviter de rentrer dans les jeux politique, nous avions accepté sa proposition, avec un beau face palm.

Réutiliser les nonces, c’est ok !

Exemple plus récent. Stocker des tokens client dans une base de données, mais chiffrés. Dit comme ça, ça a l’air simple. Mais il y a plus de pièges qu’on ne le pense.

• Quel algorithme utiliser ? Nous nous mettons d’accord sur ChaCha20.
• Utiliserons-nous une même clé pour chiffrer tous les tokens ? Oui (pas idéal sans mécanisme d’authentification avec associated data, mais soit)
• Utiliserons-nous le même nonce pour éviter de le stocker dans une nouvelle colonne ? Oui (!)

On peut déjà mettre en question le choix d’utiliser un mécanisme sans authentification (qui aurait été ChaCha20-Poly1305 pour garder le même cipher), mais à la limite, on peut toujours garantir la confidentialité des données.

Mais ré-utiliser le même couple (clé, nonce), c’est une grosse bêtise ! Un simple XOR suffit alors à ébranler la confidentialité d’un message chiffré si jamais on a connaissance d’un message en clair initial.

P.-S. : Je ne participe pas au concours, car j’ai déjà lu le livre

Ça me dit bien de participer tiens, ça ira bien à côté de mon exemplaire des réseaux de zero.

Je ne suis pas éligible, et pas dans l’informatique non plus, mais voici une petite anecdote.

Au travail, on développait un logiciel qu’on devait parfois envoyer à des clients ou partenaires. Pour s’assurer que le code arrivait tel qu’on l’envoyait, on faisait un md5sum sur les fichiers. Un des dév (pas de métier, par nécéssité) a suggéré d’intégrer le résultat directement au code source, pour faciliter la vérification…

Vous savez ce qui est vraiment dangereux ?

Les conneries créatives. Celles qui ne sont pas détectées par les outils de scans de vulnérabilité, parce que, eh bien personne ne fait ça. Concrètement, ça veut dire qu’à moins d’inspecter le code, aucun outil automatique ne lèvera d’alerte ; et ce même si la faille est béante, triviale à découvrir et à exploiter.

Dis-moi quel rôle tu veux avoir

Il était une fois une API ouverte sur Internet mais privée, sécurisée avec des JWT. Sauf que voilà : valider des JWT et en extraire le rôle, c’est chiant à faire. Ce qu’il est beaucoup plus simple de faire, c’est de prendre un query param en entrée qui demande le rôle.

Et donc, il suffisait d’ajouter ?role=admin à l’URL d’appel pour être admin.

Même sans fournir de JWT valide.
Même sur le tout premier appel à l’API, en étant un parfait inconnu pour le système.
En production.
Sur Internet.
Sur un projet qui passait les audits automatiques de sécurité.
Après 2010.

On est d’accord que ça n’aurais jamais dû passer les contrôles internes de qualité de code ; mais quand on rogne tellement sur les couts que plus personne dans l’équipe de développement ne comprends ce qu’il fait (dans le sens :  « aucun membre de cette équipe n’a les compétences réelles pour faire du développement logiciel, même en tant que débutant »), voilà le genre de chose qu’on obtient.

J’ai travaillé dans une petite PME à Marseille.

La zone industrielle était connectée à Internet via un ADSL au débit anémique et aucun plan pour le fibrer prochainement. Cela nous limitait grandement dans nos développements.

Le patron de la PME habitait non loin de là et son appartement était fibré. On a installé une antenne directionnelle pour établir un lien direct entre sa connexion privée depuis son balcon et l’entreprise afin d’avoir un débit acceptable. L’installation fonctionnait bien et c’était vraiment confortable au quotidien.

Puis un jour, je vais sur le site d’orange.fr pour vérifier quelque chose concernant l’abonnement chez moi. Et surprise, comme cette requête émanait du réseau de mon patron, la session était automatiquement associée à celle de mon patron sans introduire un quelconque mot de passe. Théoriquement on pouvait consulter les factures ou courriels associés à son compte auprès du FAI.

En dehors de prévenir le patron il n’y avait pas grand chose à faire de notre côté. Je crois qu’il y avait une parade pour éviter cet effet, et que depuis ce n’est plus d’actualité de toute façon, mais vaste blague de la part d’un FAI.

Et surprise, comme cette requête émanait du réseau de mon patron, la session était automatiquement associée à celle de mon patron sans introduire un quelconque mot de passe. Théoriquement on pouvait consulter les factures ou courriels associés à son compte auprès du FAI

Ça a été le cas sur l’espace Free Mobile pendant un moment. Si tu étais connecté en cellulaire, tu étais automatiquement connecté à ton espace client. Y compris en cas de partage de connexion.

Trop bien

Pas forcément anecdotes sur la cybersécurité, mais je fais un certain prosélytisme auprès de mes pairs pour l’utilisation de keepass et éviter les problèmes !

Un des 10 sites les plus fréquentés en France proposait une fonction pour contacter les autres membres pour des petites annonces : un champs message et un champs mail, pour que l’autre personne nous réponde.

Petit à petit ils ont voulu faire rester les gens sur la plateforme et faire une messagerie interne, sans les mails.

Pendant la période de transition, on avait la messagerie interne si on était connecté, où l’on voit le pseudo et le compte de notre interlocuteur. Si on était pas connecté, on pouvait toujours envoyer un message en rentrant notre mail, que l’on ait un compte…. ou pas.

Avec le mail de quelqu’un il suffisait de s’envoyer un message à soi même, puis de se connecter et de regarder le profil de la personne qui "venait de nous contacter" via la messagerie interne, pour avoir accès à son pseudo, parfois/souvent la possibilité d’avoir son numéro de téléphone et son adresse s’il avait des annonces  !

Pendant 9 mois je les ai harcelés par plusieurs moyens de contact avec que ça soit patché (en supprimant la possibilité de discuter sans compte ), impossible d’avoir un interlocuteur qui réalisait la gravité du problème…

Ce n’est pas un bon coin où aller.

J’ai eu l’occasion de travailler sur un des sites web d’une entreprise de sécurité informatique. Pour mettre en ligne les mises à jour, on devait s’authentifier sur un de leurs outils, et notre mot de passe (personnel, pas "d’entreprise"), devait être changé fréquemment, par nos soins.

Un beau matin de mise en production, voilà que je dois changer mon mot de passe. Je suis la procédure et en définis un qui remplit les (nouveaux) critères de sécurité. Mais au moment de me connecter, cela ne fonctionne pas. Je retente jusqu’à être bloqué, et je dois contacter le responsable, qui ne comprend pas la raison de l’échec. Il me réhabilite et me transmets un nouveau mot de passe généré par ses soins. Cela ne fonctionne pas non plus. Et à la dernière tentative avant d’être à nouveau bloqué, je note que le précédent contient un caractère bien précis. Et que le nouveau a ce même caractère au début. Bloqué pour bloqué, je tente de ne mettre aucun mot de passe. Le formulaire n’accepte pas cette possibilité, mais cela ne me bloque pas au niveau du système. Voulant tester jusqu’au bout, je tente avec un mot de passe complètement bidon, mais toujours avec ce caractère au début.

Ça fonctionne.

Toujours au téléphone avec le responsable, j’explique ce que j’imagine : le caractère en question fait que dès qu’il est rencontré au niveau du mot de passe, celui-ci et ce qui le suit est ignoré à un moment où un autre, similaire aux navigateurs qui n’envoient pas au serveur la partie #… de l’URL lors de la navigation. Le responsable effectue un test depuis une interface qui accepte que le champ de mot de passe soit vide, et le résultat semble montrer que dans toute la chaîne de validation, c’est un des derniers maillons qui pose problème.

Cela aurait été sans grande conséquence si ces derniers maillons n’avaient pas une place très importante dans les systèmes de sécurité du réseau et des infrastructures de ladite entreprise… et le portail auquel nous avions accès était destiné à tous les partenaires, et ils venaient d’avoir des problèmes avec l’un d’entre eux, d’où les nouvelles directives sur la composition du mot de passe.

Pour l’anecdote, ils ont après cela rapidement exprimé leur volonté d’internaliser le développement du site, et comme c’était ma mission principale, j’ai dû retrouver autre chose. Quelques temps plus tard, un homonyme me contacte par LinkedIn, notamment parce qu’en plus d’avoir les mêmes nom et prénom, on travaille dans le même domaine. En regardant son profil, je note qu’il a été embauché dans l’entreprise de sécurité un ou deux mois après mon départ de l’entreprise qui en gérait le site… 

Un ami à moi en stage dans un labo avait besoin de tester des trucs régulièrement, donc installer des bibliothèques etc, mais n’était pas admin de sa machine. Il devait aller chercher son encadrant à chaque fois, c’était super chiant. Pire, d’autres arrivés après lui l’était, parce que la politique interne sur le sujet changeait tout le temps.

Un jour, il a demandé à son encadrant de mettre à jour sa machine (sous linux, faut être admin). Il est passé par la ligne de commande avec un truc du genre "sudo apt update" au lieu de l’interface graphique. L’encadrant a juste dit qu’il avait plus l’habitude de l’UI, mais a entré son mot de passe. Ceci étant fait, il est parti. Le stagiaire a alors stoppé les mise à jour et profité que les droits sudo durent 5 minutes pour s’ajouter en sudoer (donc admin de fait) de sa machine.

Il n’a plus jamais embêté son encadrant avec les logiciels à installer ou les mises à jour.

Dans un ancien job, un collègue stockait sur son disque dur des dizaines de gigaoctets de résultats d’essais. C’était un statu quo lié à l’inadéquation du "cloud" sensé accueillir ces données face aux besoins pratiques. Le disque devenait trop petit pour continuer à stocker les nouveaux résultats d’essais, mais la demande d’avoir un disque plus grand a été refusée de manière repétée par le service info, vu que c’était le job de la plateforme cloud. Jusque là, ce n’est qu’une histoire de SI de grand groupe classique.

Il est venu un moment où ce disque dur était tellement plein que l’ordinateur ne pouvait plus faire les mises à jour Windows automatiques. Il a fallu purger des fichiers temporaires pour y arriver. Quelques semaines plus tard, l’ordinateur ne pouvait de nouveau plus être mis à jour, le disque étant plein à craquer. Au bout d’environ 6 mois, le service info a fini par traiter le problème : changement de l’ordinateur pour un avec un disque plus gros, et retour des mises à jours. On a donc eu un Windows non patché pendant des mois pour une bête histoire de disque dur à changer. Sachant que c’était aussi un des rares PC avec les ports USB débloqués, très utilisé en télétravail, et donc plus exposé.

Toutes les discussions, demandes et opérations liées à ce problème ont probablement coûté plus cher que l’achat et l’installation d’un deuxième disque dur dans le PC du collègue en premier lieu.

Vous connaissez le SIE ? C’est le Service Impots des Entreprise, qui permet de payer sa TVA, sa CFE et autres démarches qui concernent beaucoup d’entreprises. He bien figurez-vous qu’ils ont été récemment victime d’une fuite de données, par mesure de précaution ils ont alors invalidé les mots de passe et questions de sécurité de tous les comptes concernés (dont le mien vous imaginez bien). J’apprends donc que je dois prendre rendez vous pour aller a mon SIE pour définir un nouveau mot de passe (comme les milliers d’autres cas de cette affaire). Si je ne le fait pas je ne pourrais pas déclarer ma TVA en ligne, et par conséquent l’état me demandera des pénalités…

Rendu au SIE je monte dans le bon bureau et la personne m’explique la procédure. Sur son ordinateur je fait devoir tenter de me connecter à mon compte, mais en rentrant un mot de passe qu’elle va me dicter. Le mot de passe en question ? Une petite phrase rigolote facile a retenir qui leur a été communiqué par mail par le service informatique. Je rentre donc la phrase en mot de passe et cela me permet de définir un nouveau mot de passe et une nouvelle question de sécurité… que je dois aussi taper sur son poste (comme les 10 personnes avant moi). Le SIE : Un mot de passe pour les gouverner tous.

J’ai bien évidemment changé mes infos depuis, si jamais vous avez votre compte bloqué, faites moi signe

Comme promis, je participe

la petite anecdote rigolote

Il existe une administration française qui a un portail captif où ils rassemblent toutes les données BI. Ce portail permet de forcer l’authentification, avec MFA and co, et pour les parties les plus sensibles de la BI il me semble avoir même entrevu une authentification par smartcard (après, je sais plus trop, j’étais trop occupé à rire à cause de la chute). Bref, comme toujours avec ce genre de portail, la session saute au bout de x minutes, mais tu sais jamais combien vaut x car ça peut aussi bien être 2 que 200.

En tout cas le nom du portail captif c’est internal.{nom del'administration}.gouv.fr/sexy.

Alors quand tu es en call support avec un client qui t’annonce "attend, je dois aller sur sexy. tu as du mal. beaucoup de mal.

Ah je viens de me souvenir d’une anecdote d’il y a quelques années entre prestataires de paiements.

Une application A installée sur un terminal utilisateur appelait une API B en lui communiquant un jeton de paiement, pour que B débloque des actions auprès de l’utilisateur suite à ce paiement.
Mais B n’avait aucun moyen (ni signature, ni appel en retour) pour vérifier auprès de A que le jeton reçu était valide, la seule authentification étant une clé de l’utilisateur.

N’importe quel utilisateur pouvait alors utiliser sa clé pour appeler l’API B avec un faux jeton de paiement et déclencher les actions liées. Même après moult explications, A ne comprenait pas en quoi ça posait problème.

Il y a quelques années, un client se plaignait de mails de phishing d’un expéditeur usurpant des adresses internes à la société. En analysant les en-têtes, je me suis rendu compte que le test SPF, qui consiste à vérifier que le domaine de l’expéditeur corresponde au serveur qui envoie le message, était en échec mais que les e-mails frauduleux passaient quand même. En discutant avec d’autres équipes, j’ai appris que cette sécurité avait été désactivée pour permettre aux copieurs multifonctions d’envoyer par e-mail des copies numériques en utilisant une adresse interne. Au lieu de configurer correctement le service, quelqu’un a préféré désactiver une sécurité pour que ça fonctionne. Résultat, une vague de phishing qui a fait fuiter des informations comme les codes d’accès entreprise au compte Pôle Emploi de la société, et qui a laissé la possibilité à des tiers de créer de fausses offres d’emploi pour récupérer des données personnelles de candidats (je ne me souviens plus si ce dernier point avait effectivement eu lieu ou si le risque avait seulement été identifié).

C’est juste pour raconter l’anecdote, je ne participe pas au concours.

Il y a quelques années j’étais intervenu pour faire évoluer un site existant. Un bête WordPress pour un événement récurrent (appelons le "site A"), auquel des partenaires pouvaient se connecter, et de là accéder directement à un autre site (pour gérer des fournisseurs ou quelque chose du genre, de mémoire) qu’on appellera "site B".

Sauf que demander aux utilisateurs de se connecter aux deux sites de façon distincte était impensable : il fallait pouvoir se connecter sur le site B sans voir d’interface de connexion.

Alors la solution (créée par les développeurs avant mon arrivée, et dont je n’ai — heureusement pour eux — jamais connu l’identité) était simple :

• il y avait une nouvelle colonne dans la table users du site A (dans la structure utilisée nativement par WordPress, bonjour le risque de casse avec les mises à jour) pour stocker le mot de passe en clair de l’utilisateur
• le lien d’accès au site B passait l’email et le mot de passe (toujours en clair) dans l’URL vers une page de "connexion" qui s’occupait de créer la session et rediriger l’utilisateur au bon endroit (pratique pour copier le lien et permettre à n’importe qui d’autre d’être connecté à sa place sur le site B)
• comme cela ne suffisait pas, aucun des deux sites n’était passé à HTTPS
• et bien sûr, sinon c’est pas drôle, la base de donnée était accessible via un bon vieux phpMyAdmin (connu pour ses… quelques failles de sécurité) sans VPN avec des identifiants assez simples à deviner et eux-même communiqués en clair entre différentes équipes qui intervenaient sur ce site

Voilà-voilà

Autant vous dire que j’ai un peu remué les brancards dans l’agence qui m’avait sous-traité la mission (et qui me faisait souvent intervenir sur des bases techniques de niveaux similaires : un jour je vous raconterai comment j’ai fait tomber le site d’une grande marque de fringues française en faisant un bête SELECT pour trouver la liste des clients inscrits qui n’avaient jamais validé de commande sur le site parce qu’il y avait aucun index et des clés étrangères avec des types différents entre les colonnes).

J’ai du prendre la responsabilité de couper un serveur sur lequel je bossais en freelance parce que j’avais compris qu’il était compromis, et qu’il avait des données possiblement sensibles, et que je n’arrivais pas à joindre le patron pour savoir quoi faire.

Je n’ai pas grand chose qui me vient en tête sur le sujet (du moins qui ne sont pas confidentiel), mais je veux bien participer

Et bravo aux auteurs et validateurs pour cette nouvelle publication !

Quelques anecdotes perso :

• Quand j’étais stagiaire en SS2I, j’ai notamment travaillé en support pour un site d’un équipementier militaire. J’ai dû faire des petites interventions et vérifier en prod, on avait un compte de test là-bas. Le compte avait été peuplé avec de vrais documents, j’ai donc pu accéder sans même faire exprès à des documentations militaires, ma mémoire me joue des tours mais je suis à peu près sûr que c’était pas écrit "déclassifié" dessus.
• Toujours pendant le stage, en mission chez un client où un collègue se rend compte que les numéros de CB des clients étaient enregistrés dans les logs
• Premier boulot en 2017, dans une multinationale française avec beaucoup d’activités liées à la défense. J’ai entendu qu’ils avaient un contrat spécial avec Microsoft pour maintenir à flot des ordis qui tournaient encore sous Windows XP

Bon et du coup qui c’est qui a gagné, la date est passée les agrumes veulent savoir

Ce qui me fait penser que certaines stations des chemins de fer suisses avec au moins deux aiguillages utilisaient toujours Windows 95 début 2015. Et je pense qu’il subsiste encore de telles installations en service à l’heure actuelle. Service léger/de manœuvre, certes.

Bonjour,

Le jeu-concours est en effet terminé. Les trois gagnants sont :

• viki53 sur le billet ;
• Qwerty sur X ;
• Marius sur Mastodon.

Ils ont été contactés. Merci à tous les participants, et merci à Eyrolles pour les livres !

Ce qui me fait penser que certaines stations des chemins de fer suisses avec au moins deux aiguillages utilisaient toujours Windows 95 début 2015.

C’est trop tard pour le concours, mais ça me fait penser… je sais que les distributeurs de billets tournaient à une époque sous MS-DOS. Un jour de 2003, celui de mon village avait un papier "Hors service" collé sur l’écran. Sauf que le papier était mal posé, et par curiosité, je l’avais soulevé un peu pour voir…. et avais vu apparaître un bout d’écran noir avec un texte en gris: "C:\> _".

Je n’en ai jamais eu la preuve, mais on m’a aussi dit la même chose des selecta qu’on pouvait trouver dans à peu près toutes les gares (pour les non suisses: ce sont des automates à boisson/nourriture)

Il y a aussi encore de nombreux bancomats et de systèmes de caisse de supermarchés sur Windows XP voire pire… aujourd’hui…

Ca me fait aussi penser que, malheureusement je n’ai plus les sources, mais il semblerait que les systèmes dans certains avions se mettent toujours à jour via des disquettes.