L’Agence Nationale de la Sécurité des Systèmes d’Information offre une formation sécurité en ligne

Voilà comment poser de bonnes bases avec une formation à la cyber sécurité, sur le MOOC de l’ANSSI.

C’est gratuit, instructif (ou de bon rappel), et ça vous concerne sur plusieurs plans que vous ne soupçonnez peut être pas. Donc ne vous laissez pas rebuter par le sujet lui même ou le style institutionnel.

Là personne ne vous oblige à quoi que ce soit, et vous avez tout votre temps. Pas besoin de laisser tourner la vidéo dans un coin de l’écran et de sauter sur le QCM 😉 Profitez d’un moment de calme pour un peu de culture cyber, à votre rythme.

J’ai entamé la formation, de toute évidence c’est bien construit, agréable à suivre et interactif. De plus il est rare d’avoir du contenu de qualité, les e-learning cyber sécurité c’est plutôt quelques centaines d’euros le module et in English habituellement…!

Est-ce que cette formation est pour vous ?

Deux réponses possibles:

• OUI: Tout professionnel de la donnée, développeur, de la sécurité ou de l’informatique en général se doit de suivre cette formation.
• OUI: Tout utilisateur d’un Système d’Information, ou de quoi que ce soit qui s’allume avec un tant soit peu d’électronique à l’intérieur.

Ce qui veut dire, vous l’aurez deviné: quasiment tout le monde.

Si vous craignez d’être un peu perdu dans trop de technique, ou d’avoir trop d’informations à la fois, il y a dans chaque module une rubrique « pour en savoir plus », et toujours wikipédia…

Pour commencer la formation c’est ici  https://secnumacademie.gouv.fr/

 

Mastodon fossilise les données, et dynamise le modèle établi des réseaux sociaux

Avant propos: une courte présentation

Mastodon est une nouvelle tentative de réinventer Twitter et les réseaux sociaux, les sites de micro blogging « commerciaux »,  à base de composants open source construits sur une infrastructure ouverte et décentralisée.

Je vous confie ce billet du blog Framasoft pour une bien meilleure description si vous voulez en savoir plus, car ce n’est pas directement le sujet ici.

Le code est libre, les données le sont un peu moins

La nature distribuée de l’infrastructure constituant le reseau mastodon fait que les données sont éparpillées sur divers serveurs, donc partout sur la planète et avec un administrateur et un hébergeur différent à chaque fois.

Voyons le bon côté des choses en matière de libertés : difficile de censurer ou de faire fermer un tel réseau. Plus d’autorité centrale, pas de de siège social dans la silicon valey qu’elle soit americaine, russe ou chinoise (à chacun ses reseaux sociaux et ses règles du jeu).

De plus côté utilisateur la visibilité des messages et le contrôle du contenu affiché à été plutôt bien pensée par l’auteur.

Ensuite ça se complique un peu… L’intégrité, et j’ajouterai aussi la neutralité du trio administrateur-hébergeur-operateur est critique. Il est commun de considérer que « big brother » vous observe sur les réseaux sociaux majeurs. 

Mais soyons réaliste, big brother, c’est l’automate qui lit, enfin qui parse vos messages, fait du big data pour se rémunérer et offrir un service en apparence gratuit. Jusqu’à présent, beaucoup s’en acomodent n’est-ce pas ?

Dans le cas d’un serveur mastodon, on est généralement face à une instance administrée bénévolement, avec un  panorama de tout ce qui se fait en matière d’hébergement.

C’est bien, très bien même, et je salue le temps et les moyens que les administrateurs y consacrent. D’autant que c’est un peu délicat pour la montée en charge quand le succès arrive par surprise.
Du coup la notion de confidentialité des messages (« toot », ou en français « pouet ») est celle qui correspond à la sensibilité de l’administrateur local, ou aux moyens investis dans l’administration/hébergement/sécurité. Idem pour la sécurité intrinsèque des développements, et la disponibilité du service. L’emploi de chiffrement est prévu (communications, basée de données, webservices), mais pas obligatoire.

Le recours au stockage cloud d’Amazon S3 est recommandé, à moins de vouloir gérer soi même la pérennité des données… Même chose pour l’envoi des e-mails aux abonnés.  C’est un peu déroutant tout ça, ce réseau social vise à éviter les réseaux commerciaux, tout en conseillant aux administrateurs un stockage et une messagerie dans le cloud commercial ? J’imagine que c’est pour faciliter les choses, mais heureusement les administrateurs restent plutôt concentrés sur les ressources dont ils disposent localement… Et oui, S3 ce n’est pas gratuit.

Au passage, merci pour la transparence avec le up/down et taux de disponibilité des instances visibles ici https://instances.mastodon.xyz.

Dura lex, sed lex

Pour le moment, la réglementation en matière de protection des données, le droit à l’oubli, la CNIL, la portabilié… C’est un peu le désert. Comme dans tout bon concept lancé avec les méthodes d’ingénierie logicielle à la mode, on se concentre sur ce qui fait le succès, les contraintes et le reste on verra après. En général une fois arrivé à maturité, ça s’améliore, et il y à déjà pas mal de questions et requêtes qui remontent de la communauté.

En fait je me demande un peu si tous les administrateurs d’instances sont bien conscient des responsabilités (au moins morales) associées à ce réseau social. Car c’est bien à eux que sont déléguées ces contraintes et ces risques.

Autre point, techniquement il n’est pas prévu, donc pas possible simplement d’effacer soi même un compte utilisateur ou ses données.

Espérons que l’ordre 109 sera bientôt exécuté pour y remédier.

La nature même du réseau maillé d’instances sous une autorité indépendante ne facilite pas la tache : effacer en local, ok c’est un minimum, et envoyer une commande d’effacement à distance sur les centaines d’autres instances ? Il faudrait  un mécanisme de relations d’approbation, une administration fédérale… Entre entités étrangères, c’est un challenge intéressant, ou plutôt un non sens.

Ce type de difficulté ne peux se résoudre que si c’est l’utilisateur et lui seul qui contrôle son compte et ses données. Chiffrement, PKI, blockchain… Il y a des pistes, mais ce n’est pas facile à implémenter dans un réseau social qui se met à jour, diffuse et synchronise en temps réel.

Donc en attendant, ce qui est publié est conservé, fossilisé dans les strates d’une infrastructure décentralisée. L’utilisateur lui aussi participe à ce phénomène à chaque changement d’instance. Ce qui ferait le bonheur d’un archéologue numérique.

Peut-on vraiment le reprocher ? Quand c’est publié sur internet…

L’identité n’est pas un concept fixe

Là aussi de part la conception distribuée de mastodon, l’unicité d’un compte, et donc l’identité d’un utilisateur n’est vraie que localement au sein d’une instance.

 

Il n’y a pas de solution native pour authentifier un compte (comme les comptes officiels, validés sur les réseaux sociaux majeurs).

Donc soit vous bricolez (un tweet pour confirmer un toot, un référencement croisé entre réseaux sociaux ou site web), soit vous créez votre propre instance (mauvaise réponse à une bonne question). Autre piste : https://keybase.io.

Au final

Un réseau social et les données de centaines de milliers d’utilisateurs, c’est compliqué. Surprenant ? Non pas vraiment puisque ça fait partie du jeu. Simplement mastodon propose un autre mode de fonctionnement, alternatif, de peu comme l’internet à ses débuts pour ceux qui l’ont connu avant les GAFAs.

A ce stade rien n’est vraiment garanti, c’est une somme de bonnes volontés plus un soupçon d’idéalisme qui le font fonctionner, pourvu que ça dure.

Enfin à lui seul le principe même de mastodon est une invitation à l’essayer… Vous avez toute liberté sur ce réseau, y compris ne de pas le rejoindre, c’est bien ça l’essentiel.

Voilà c’est toot: https://mamot.fr/@mathieu_lubrano

250 millions de comptes iCloud mis en doute, le cyber chantage a de l’avenir

La bourse ou la vie…

Quand ce n’est pas un ransomware qui chiffre vos fichiers, ou récemment des bases de données en échange d’une rançon, quand ce n’est ni votre compte mail ou votre webcam qui sont détournées, c’est encore mieux : les pirates se servent de vous et moi comme de vrais otages, et s’adressent à ceux qui on beaucoup à perdre (l’argent et le pouvoir)…

Car c’est finalement ce que fait le groupe Turkish Crime Family en demandant directement à Apple une rançon en échange de votre vie numérique (iCloud = iPhone, photothèque, contacts, notes où vous stockez peut-être vos autres mots de passe ? … etc).

Au lieu de réclamer 1 Bitcoin à chacun, pour un paiement hypothétique au bout d’un long travail fastidieux, mieux vaut braquer la banque et faire un seul gros coup.

Bluff ou un coup de génie ?

Un échantillon de comptes à été fourni comme on libère un otage pendant la négociation. Donc le scénario est en place, on le saura bientôt après l’ultimatum, le 7 avril.

Si il est assez peu probable que ce soit Apple qui ait été visé directement pour le détournement des comptes, les fuites massives des données ces derniers temps peuvent effectivement permettre de remonter d’un service de messagerie par exemple Yahoo! Mail, jusqu’à iCloud, via la réutilisation du mot de passe. Notez que si c’est vrai pour iCloud, c’est aussi applicable à GMail/Google, la banque en ligne, Linkedin, Facebook & cie.

Pour éviter que ce soit vous qui serviez d’exemple pour prouver la détermination et la réalité de l’attaque… Rdv sur iCloud pour renouveler votre mot de passe, ou mieux activer l’authentification en deux étapes…

(au fait, à quand remonte votre dernier changement déjà ? Et profitez-en pour changer le mot de passe des autres comptes importants)

Triple exploit au Pwn2Own 2017 pour s’échapper d’une machine virtuelle et atteindre l’hyperviseur

VM escape … oui, mais encore ?

Le groupe chinois Qihoo 360, coutumier des exploits (bien préparés) dans les concours de sécurité, à touché 105.000 dollars pour un triple exploit… chapeau !

Le scénario: un poste de travail virtualisé innocent visite un site internet au contenu malveillant (en javascript).

En trois coups, l’équipe de Qihoo à réussi à traverser les mécanismes d’isolement du navigateur, du système d’exploitation et à remonter jusqu’à l’hyperviseur.

Pourtant, tout avait l’air OK et ressemble à ce qui se fait couramment en entreprise, avec toutes les garanties apportées par les éditeurs sur la robustesse des produits…

Les mesures mises en place

√   Contre les sites internet malveillants ou possédés : bac à sable et navigateur moderne

√   Contre les menaces: des solutions professionnelles et un système d’exploitation récent

√   Pour optimiser les ressources / réduire les coûts / aller dans le cloud : virtualisation

Les failles exploitées

⊗   Bac à sable (Edge) : KO via un débordement de la pile

⊗   Système d’exploitation (Windows 10) : KO via une faille noyau (UAF)

⊗   Virtualisation (VMWare) : KO via une faille exploitant un buffer non initialisé

Donc, quand un internaute se promène sur un site malveillant, la ballade peut se terminer par une prise de contrôle de l’hyperviseur, puis de là potentiellement le cœur de l’infrastructure (les autres VM de cet hyperviseur et comme par exemple la VM firewall).

Cette démonstration de force, ou plutôt d’habileté à mettre en déroute la sécurité de toute la pile d’un datacenter virtuel,  rappelle que tout est piratable…

Inévitable, alors que faire ?

Pour éviter l’effet domino et une telle escalade, dans la mesure du possible il faut résister à la facilité, à la tentation de suivre la mode du tout virtualisé (y compris le réseau, la sécurité).

Les principes type KISS et de la séparation des fonctions ne sont pas incompatibles avec une infrastructure moderne et économique (cher ≠ meilleur), du moins pour le moment. Car les efforts des constructeurs-éditeurs pour du « software defined » (SDN, SDS, SDDC) conduiront bien à terme à l’effacement des limites.

Le problème de fond étant la maturité de l’offre -qui ne sera par définition jamais atteinte- et donc l’empilage des couches logicielles qui rendent possible un triple exploit comme celui ci.

Il reste donc les bonnes pratiques, déjà connues mais toujours valides. L’état de l’art et le bon sens lors de la conception de solutions, ensuite les tests, mises à jour, contrôles et corrections. Pour tout cela, il faut du temps, des compétences des ressources.

Comment ont ils fait ? Mes serveurs sont ils en risque ? Que faire pour éviter que ça se reproduise, est-ce vraiment inévitable…? Et si finalement la vraie question était : quels moyens accordez vous réellement à la sécurité ?

AWS : bonne nouvelle les datacenters d’Amazon bientôt en France

C’est une bonne nouvelle d’un point de vue utilisateurs, car le rapprochement en région parisienne plutôt que Dublin ou Francfort signifie moins de temps de transit, moins d’interconnexions d’opérateurs.
D’autant que de nombreuses offres et sites Web sont hébergés dans les datacenters historiques Américains. 

Ceci dit, le cloud d’Amazon, AWS, appartient toujours à une société Américaine, donc patriot act et access possible pour les autorités US.

Reste à voir à quel tarif Amazon placera les datacenters Français (plus ou moins cher que l’Irlande ?)

Ça fait quand même d’AWS, leader du cloud public, une option de plus dans le portefeuille de solutions.
Et, c’est aussi un plus car il sera alors possible d’exiger de vos fournisseurs hébergeant leur plate-forme dans AWS de localiser votre instance en France…

AccessURL.com un nouveau moyen de partager ses identifiants : bien ou mal ?

Dans la série faites ce que je dit, pas ce que je fais, bienvenu à AccessURL !

Ce service, qui repose sur un plugin Chrome (uniquement), propose de partager en toute sécurité votre accès à des sites web privés.

Exemples : Votre abonnement sur LeMonde.fr, l’extranet de votre fournisseur que tous vos collègues voudraient utiliser, Netflix ou autres services de streaming vidéo servis chauds.

 

Un site protégé, un service de partage gratuit, un tiers… Qu’est-ce qui pourrait mal de passer ?

En entreprise déjà c’est une faute, vous avez signé un règlement intérieur ou la charte informatique, et il est bien possible la nature même de votre métier fasse de vous un collaborateur informé, qui a le devoir de protéger les données et les accès. Donc au mieux ça passe inaperçu, l’IT vous fait passer un message bienveillant, ou un incident se produira et…

À titre personnel « je fait ce qui me plaît », et il est bien possible que vous ayez raison car le site que vous détournez commencera probablement par un avertissement de sécurité puis une suspension de compte (pour double connexion depuis plusieurs adresses IP publiques, pour activités suspectes) mais y réfléchira à ceux fois avant de vous résilier…  La mauvaise presse (plaintes sur les réseaux sociaux pour incompréhension), le coût de recrutement de nouveaux clients, la concurrence : pas simple à gérer comme situation. De plus, vous n’avez pas à vous préoccuper d’Hadopi, ça ne les intéresse pas.

Car si le prêt de compte personnel est interdit dans les petites lignes du contrat, vous ne l’avez pas lu d’une part, et d’autre part AccessURL fait tout pour que cela ait l’air tout à fait naturel et facile à faire. Donc autorisé, donc légal en apparence, puisque aujourd’hui on s’en tient souvent aux apparences.

Les choses pourraient s’aggraver, si à la manière des forums de partage et téléchargement qui font payer à l’acte avec du micro-paiement, vous sous-louez l’accès à un abonnement ou à du contenu protégé.

Ceci dit, dans les conditions d’utilisation, AccessURL indique clairement collecter des informations personnelles, et se dégage de toute responsabilité en cas d’utilisation inappropriée de ce service, ou de violation de droits d’auteurs. De même qu’en cas de perte financière ou de fuite de données, y compris si le propriétaire d’AccessURL est prévenu d’un incident ou d’une procédure, vous n’êtes pas couvert.

 

Regardons AccessURL.com d’un peu plus près

D’après de simples informations publiques (aucun site web n’a été maltraité pendant la rédaction de cet article)…

• Le site est chez un hébergeur qui à plutôt bonne réputation : Digital Ocean, à San-Francisco visiblement.

« 11 DIGITAL-OCE.bar2.SanFrancisco1.Level3.net (4.14.106.166)  288.779 ms »

 

 

• Le service (ou du moins le frontal web) tourne sur un VPS, donc le trafic est capé à quelques To. Attention, « quelques To » ça fait déjà beaucoup de volume quand même, ça n’est pas ridicule, mais c’est une limitation et un choix économique.

Site	http://www.accessurl.com	Netblock Owner	Digital Ocean, Inc.
Domain	accessurl.com	Nameserver	ns-cloud-e1.googledomains.com
IP address	45.55.24.192	DNS admin	cloud-dns-hostmaster@google.com
IPv6 address	Not Present	Reverse DNS	unknown

 

• Pour un site qui met en avant un haut niveau de sécurité et de confidentialité, il aurait été préférable de masquer la version du serveur web, et le système d’exploitation. A moins bien sur que ces informations soient forgées pour induire en erreur.

Netblock owner	IP address	OS	Web server	Last seenRefresh
Digital Ocean, Inc. 101 Ave of the Americas 10th Floor New York NY US 10013	45.55.24.192	Linux	nginx/1.10.0 Ubuntu	27-Sep-2016

• Et il serait utile d’affiner les configuration d’ngnix… car tel quel le site emploie un algorithme d’échange de clés permettant l’interception des communications (man in the middle) type Logjam. Plutôt gênant en environnement hostile, mais bon, vous êtres en train de donner volontairement vos codes d’accès à un correspondant, donc pourquoi pas votre voisin de hotspot wifi aussi ?

« This server supports weak Diffie-Hellman (DH) key exchange parameters. Grade capped to B. »

 

• Le certificat SSL du site est bien sur émis par Let’s Encrypt. Donc gratuit, et d’une durée de vie courte (renouvelé automatiquement par un automate). Ça n’est pas un problème en soit, mais ça donne une idée des moyens investis sur la sécurité.

 

• Les informations sur le propriétaire du domaine accessurl.com sont masquées, impossible donc d’entrer en contact « directement » avec le propriétaire en dehors de l’adresse email de support indiquée sur le site lui même.

Administrative Contact Information:

Name Contact Privacy Inc. Customer 124788088

Organization Contact Privacy Inc. Customer 124788088

Address 96 Mowat Ave

City Toronto

State / Province ON

Postal Code M4K 3K1

Country CA

Phone +1.4165385487

Email seis1ecfm@contactprivacy.email

Tout ça n’est pas très rassurant, mais dans l’absolu il n’y a rien de bien extraordinaire ou absolument critique qui ressorte (à cette profondeur d’analyse).

 

Quelques questions à se poser

Comment AccessURL gagne-t-il sa vie ?

• De la publicité ? à priori non.
• En revendant des informations personnelles ? peut-être.
• En revendant vos comptes privés ? ça serait suicidaire, mais pas impossible.
• Rien en attendant d’avoir atteint une masse critique, puis passage en mode « régie publicitaire » comme beaucoup de services gratuits ?
• Rien en attendant une proposition de rachat par un plus grand éditeur ? possible.

La réponse est importante, car elle conditionne la viabilité de ce service tout autant que sa confidentialité.

Comment ça marche ?

Voilà une tentative d’explication et de déduction, sans avoir fait de reverse engineering (à peine surveillé les flux), en sachant qu’AccessURL déclare se baser sur les cookies de session, et ne pas fonctionner en mode navigation incognito… cf. son site web.

On peut imaginer que quand vous êtes connecté à votre site privé, et que vous demandez la création d’un lien de partage au plugin, le cookie de session que vous avez (et qui est légitime) est chiffré et envoyé chez accessurl.com. Le chiffrement étant déclaré être de l’AES, c’est un algorithme symétrique donc une « clé » (mot de passe) seule permet à la fois de chiffrer et déchiffrer les données. Simple et efficace pour ce niveau de besoin de protection des données.

La clé de chiffrement est encodée dans l’URL généré pour le partage de l’accès, ainsi que l’identifiant du cookie chiffré à récupérer sur accessurl.com. Puisque AccessURL déclare ne pas avoir connaissance de la clé, ça doit vouloir dire qu’elle n’est pas envoyée sur leur serveur mais reste côté clients.

Comme c’est cet URL de partage que vous transmettez à votre correspondant (toujours côté client donc), son plugin Chrome AccessURL n’a plus qu’à intercepter cet URL télécharger le cookie chiffré, puis le déchiffrer en déduisant la clé de l’URL de partage, et ré-ouvrir une session authentifiée sur le site d’origine.

Donc le plugin doit être activé dès que le site que vous entrez dans la barre d’URL matche accessurl.com… D’après ceci je dirais que c’est Chrome qui se charge d’appeler le plugin, et pas le plugin qui traite tous les URLs que vous entrez et y recherche accessurl.com, à condition que ce soit bien implémenté par l’auteur. La différence tiens à la protection de votre vie privée, en évitant entre autres que ce plugin ne collecte tous les sites que vous visitez par exemple…

Les URLs partagés sont de cette forme :

https://accessurl.com/POrK#nq5dqb

https://accessurl.com/BMk6#io6mm7

https://accessurl.com/4WDZ#erveqy

Ce qui laisse à penser qu’ils sont formatés et découpés en deux sous chaines:

https://accessurl.com/ AAAA # BBBBBB avec AAAA un pointeur vers le cookie chiffré transmis via accessurl.com, et BBBBBB la clé de chiffrement.

 

4 et 6 caractères c’est très peu, le pointeur AAAA n’est donc peut-être pas direct (lookup, 2-3 tree), et la clé BBBBBB je crains qu’elle soit tout simplement « BBBBBB » sans artifice.

Note : un mot de passe sur 6 caractères, avec le jeu de caractères présent dans ces exemples, prends 56 millisecondes à deviner en brute-force aujourd’hui. Donc encore moins demain avec les gains en puissance de traitement.

 

Alors AccessURL.com : bien ou mal ?

C’est bien de constater qu’il y a toujours de la place pour l’innovation en matière de sécurité, et à voir la couverture médiatique accordée à AccessURL les internautes utilisateurs sont toujours friands de solution qui simplifient la vie, et simplifient la sécurité. Ce qui veut dire que les acteurs du web et de la cyber sécurité ont encore une bonne marge de progression, pour arriver à éradiquer le mot de passe comme moyen d’authentification, et passer à quelque chose de mieux. Le plus rapidement possible SVP…!

C’est bien aussi, car ça évite de donner par email, fichier word ou post-it ses identifiants et mots de passe à un correspondant (niveau zéro de l’échange sécurisé). Tout du moins dans un monde idéal qui ne prête pas de mauvaises intentions, ou d’implémentation fragile à AccessURL.

AccessURL est très probablement le fruit d’un one man show. Qu’il convient de saluer pour l’idée et l’implémentation car il y a un produit réel et qui fonctionne (actuellement à peu près bien, et l’intention de cet article n’est pas de descendre AccessURL).

Mais en même temps, c’est mal. Car d’après le peu d’information disponibles, on ne peut avoir aucune garantie sur la pérennité du service, sont évolution ou sa maintenance (disponibilité, sécurité opérationnelle etc), d’autant que le modèle de revenus est inconnu.

En réfléchissant aux pistes menant à des problèmes de sécurité ou des dérives d’utilisation des sites privés, j’aurai tendance à déconseiller d’utiliser AccessURL pour quoi que ce soit qui puisse vous mettre en difficulté financière ou juridique.

Il existe d’autre moyens de partager des comptes privés, notamment chez les gestionnaires de mots de passes, qui ne font pas l’économie des écarts aux conditions d’utilisation des sites privés, mais ont pignon sur rue et affichent un niveau de confiance bien supérieur…