Archives de catégorie : Concepts

La catégorie concepts regroupe les généralités utiles en sécurité des SI et parfois d’autres plus globales à l’informatique, mais ayant un sens ou un intérêt particuliers en SSI.

Intelligence artificielle

L’intelligence artificielle est un concept nouveau depuis 30 50 ans (mince, c’est encore plus vieux que je ne le pense). Quand j’ai commencé l’informatique, on parlait déjà d’intelligence artificielle, et déjà on était déçu des résultats, au point que l’acronyme IA se trouvait souvent remplacé par Informatique Avancée qui correspondait mieux à la nature profonde du sujet. Le marketing ou nos peurs primaires nous empêchent souvent de bien comprendre ce que recoupe cette notion d’intelligence artificielle. Mais parler d’intelligence artificielle est nettement plus vendeur que de parler de classification automatique de motifs complexes1.

Continuer la lecture →

FIDO

FIDO est une alliance créée (en 2012) à l’origine par PayPal et quelques autres acteurs afin d’essayer d’établir un protocole d’authentification sans mot de passe.

Dès 2013, Google, Yubico et NXP1 s’y joignent pour répondre à une problématique forte chez Google de lutte contre le phishing. Pour cela, l’industrie avait besoin d’un standard pour une authentification « forte », et très vite l’idée d’un facteur matériel a été présentée par ces acteurs, avec un protocole ouvert et donc utilisable par tous.

L’acronyme FIDO correspond à Fast IDentity Online, ce qui souligne bien l’orientation web des protocoles. Les grandes étapes historiques de cette alliance sont ici.

FIDO « 1 »

Le besoin initial était de renforcer l’authentification sur des services web ; il était donc naturel d’introduire un second facteur en complément du mot de passe. Fin 2014, les normes FIDO UAF et FIDO U2F sont publiées simultanément.

Premiers protocoles

UAF

UAF correspond à Universal Authentication Framework, qui propose un protocole d’authentification sans mot de passe, à base de cryptographie.

U2F

U2F est la norme concernant le second facteur d’authentification, ou Universal 2nd Factor en anglais, également à base de cryptographie.

A quoi ça sert ?

Grâce à ces normes, on garantit la valeur de l’authentification puisqu’on sait comment cette dernière est établie. Garantir ne signifie pas que l’authentification est parfaite mais qu’on en connaît les mécanismes, et qu’on peut ainsi gérer correctement le risque associé.

Certification

En bonus, une certification peut ainsi être réalisée sur les dispositifs concernés : en utilisant un dispositif FIDO, on sait donc parfaitement comment ce dernier fonctionne. Par la suite, les travaux concernant la certification vont continuer pour suivre l’évolution des technologies et l’accompagner.

La suite

Des travaux viendront compléter ces premières normes, en standardisant les échanges via Bluetooth et NFC, en incluant la biométrie, etc.

FIDO2

En 2016, l’alliance poursuit son travail avec un objectif ambitieux, à savoir créer une norme reconnue pour l’authentification forte sur internet (sur le web).

Pour cela, l’alliance pouvait se baser sur les travaux de la première norme et en 2018 le protocole fut intégré comme candidate recommandation par le W3C, ouvrant la porte à la reconnaissance en tant que standard international de ce qui était en train de devenir FIDO2.

FIDO2 vs. webAuthn

FIDO2 est un ensemble de spécifications, comprenant deux parties :

  • webAuthn qui est une ensemble de spécifications du W3C, dont le but est d’établir des standards pour le Web ;
  • CATP qui est un ensemble de spécifications de l’alliance FIDO décrivant un protocole d’authentification entre un client et un dispositif d’authentification communiquant via USB, Bluetooth ou NFC.
fido2_building_blocks.png
Source : Overview (yubico.com)
fido2_app_architecture.png
Source : Overview (yubico.com)

Les avantages selon FIDO

Sécurité

Sécurité

FIDO utilise un mécanisme cryptographique pour assurer l’authentification à un site. Chaque authentifiant est unique pour chaque site, le secret ne quittant jamais le dispositif FIDO.

Facilité d’utilisation

Facilité d’utilisation

La facilité d’utilisation provient du dispositif FIDO lui-même, qui gère la partie cryptographique avec le site web. L’authentification sur le dispositif lui-même peut être celui que le client désire (parmi ce qui existe), et est réalisée localement, sans échange avec le serveur web.

Types d’authentification pris en charge

FIDO versions 1 et 2 permettent plusieurs types d’authentification, en combinant les différentes possibilités. En ce ce qui concerne FIDO2 :

  • Un seul facteur : identité + identifiant (« credential ») FIDO2
  • Second facteur (complément du 1er) : identité + mot de passe + identifiant FIDO2
  • Un seul facteur, sans mot de passe : clé cryptographique (« resident key ») FIDO2 stockée sur le dispositif FIDO2
  • Deux facteurs (MFA) « sans mot de passe » : clé cryptographique FIDO2 + code PIN

Les dispositifs FIDO2 sont également rétro-compatibles avec l’authentification FIDO U2F :

  • Un seul facteur : identité + identifiant FIDO U2F
  • Second facteur: identité + mot de passe + identifiant FIDO2 U2F

Points clés

  • Les identifiants FIDO2 sont basés sur une paire de clé cryptographique de type asymétrique.
  • Le fournisseur d’identité (« identity provider », ou IdP) valide l’identité de l’utilisateur et associe une clé publique FIDO2 à un compte utilisateur (phase d’enregistrement, souvent appelée improprement enrolement en français).
  • L’identifiant (« credential ») FIDO2 peut être généré sur un support matériel (clé physique, smartphone, PC portable…) ou par logiciel, selon la politique choisie.
  • L’authentification utilise une clé cryptographique liée au dispositif d’authentification et, en option, un autre facteur qui peut être de type « ce que je sais » (code PIN) ou « ce que je suis » (biométrie). Cet identifiant complémentaire (PIN ou biométrie) n’est pas diffusé entre les dispositifs d’authentification et n’est pas partagé avec aucun serveur. Il est stocké uniquement sur le dispositif d’authentification.
  • La clé privée de l’utilisateur (de la paire de clé asymétrique) ne quitte jamais le dispositif d’authentification. Le serveur d’authentification ne conserve que la clé publique associée au compte de l’utilisateur durant la phase d’enregistrement.
  • La saisie du code PIN, la présentation de la biométrie, ou l’appui sur le bouton présent sur le dispositif sert à débloquer la clé privée afin de signer cryptographiquement les données envoyées au fournisseur d’identité dans l’assertion. Les données signées contiennent également l’indication d’utilisation ou non d’un code PIN ou de la biométrie. La demande d’authentification se poursuit à partir du moment que le fournisseur d’identité a vérifié l’assertion d’authentification.

Hello ?

Sources

Sujets connexes

Authentification web

A regarder :

  1. La théorie, l’alliance
  2. Principes, programmes, working Groups
  3. L’architecture
  4. Sécurité du stockage
  5. Versus biométrie
  6. Inter-opérabilité
  7. Développements, API

Attaques 2FA

Autres ressources

Serverless functions

Principe

Les principe des serverless functions (fonctions sans serveur) consiste à mettre à disposition, pour un client, un environnement d’exécution géré par l’hébergeur (et non par le client) permettant de faire tourner un script ou programme ayant une durée de vie assez courte, par exemple en réponse à un événement quelconque.

Continuer la lecture →

Mot de passe

Le mot de passe est un élément extrêmement sensible dans la chaîne de la sécurité. C’est le point faible le plus souvent rencontré et, forcément, le plus souvent utilisé pour les piratages et les actes malveillants. Il ne sert à rien de sécuriser sa connexion SSH si vous laissez un mot de passe faible…

Continuer la lecture →

Villes connectées

Le concept de villes connectées (ou Smart Cities) est un des nébuleux concepts issus de l’imagination débridée de nos têtes plus ou moins pensantes. Elles seront alimentées par nos équipements informatiques et par une foultitude de capteurs qui seront inévitablement disseminés dans notre environnement urbain (mais pourquoi pas aussi dans des zones moins denses) : des objets connectés dédiés au fonctionnement de la ville.

Or nos brillants techniciens sont plus enclins à étudier comment réaliser et rendre possible cette idée plutôt que de penser aux conséquences de cette utilisation ultra-intrusive de données récoltées1, lesquelles échapperont probablement au contrôle des citoyens.

On part de loin

De très loin, même. Sans refaire l’historique des vulnérabilités, on remarque que les chercheurs (comme ceux d’IBM2)relèvent que les plus basiques sont présentes quasiment partout, aussi bien dans des capteurs météo que dans des feux tricolores de signalisation !

Et je te mets un mot de passe administrateur codé en dur (et facilement devinable), que je ne sécurise pas ma couche d’authentification, que je laisse passer les injections SQL (voir ce que ça donne pour les machines à voter électroniques) ou le XSS.

Les scénarios de risque ressemblent à ce qu’on trouve dans les films3 : on détourne l’usage des feux rouges pour bloquer la circulation et échapper aux flics, on fausse les mesures d’éléments critiques comme la niveau des eaux ou le taux de radioactivité, pour causer des dégâts ou désorganiser les activités humaines.

Voir aussi

Sources

  • https://www.lemonde.fr/smart-cities/article/2017/10/13/les-libertes-individuelles-oubliees-de-la-smart-city_5200742_4811534.html
  • https://www.cnil.fr/fr/smart-city-et-donnees-personnelles-quels-enjeux-de-politiques-publiques-et-de-vie-privee
  • https://public.dhe.ibm.com/common/ssi/ecm/75/en/75018475usen/final-smart-cities-whitepaper_75018475USEN.pdf

Lien interne

Smartphones

Nos smartphones sont-ils sûrs ? Je suis persuadé que la plupart des utilisateurs pensent que oui, particulièrement les afficionados d’Apple qui ont entendu dire (et donc sont persuadés) qu’iOS et Mac OS sont insensibles voire invulnérables aux virus et autres malwares.

Or malheureusement il n’en est rien, je renvoie iOS et Android dos-à-dos, surtout lorsque les utilisateurs débrident (débloquent) leur téléphone à des fins de personnalisation. A ce titre voici les principales, recensées par l’éditeur Checkpoint.

Je ne regarderai ici que le point de vue technique, et non fonctionnel, car nos smartphones sont nos pires ennemis au sujet de notre vie privée (et même professionnelle), en dévoilant par le biais de notre usage une énorme partie de notre vie.

Les menaces directes

Le jailbreak (ou débridage)

Cette opération consiste à faire sauter les contrôles de votre téléphone et de vous donner, consciemment ou non, un accès complet à celui-ci. Avec un niveau élevé de privilèges, vous pouvez devenir administrateur (= grand chef) de votre machine et y faire ce que vous voulez. En bien ou en mal. C’est amusant pour installer des applications qu’Apple a refusé. Donc ok vous pourrez personnaliser votre écran d’accueil et télécharger toutes les applications pornos que vous souhaitez (par exemple sur Cydia), mais rien n’arrêtera les programmes malveillants qui n’en demandent pas tant… D’abord ils pourront s’installer facilement, mais en plus ils pourront ensuite faire ce qu’ils veulent. Exemple : installer un RAT ou un outil cherchant à cacher que votre téléphone est jailbreaké…

La prise de contrôle

Votre iPhone peut être totalement contrôlé par un inconnu, sans que vous ne le sachiez. Le principe est qu’une fois un iPhone jailbreaké, il devient possible d’installer tout et n’importe quoi dessus, et donc pas seulement les applications vérifiées par Apple sur son store. L’attaquant se débrouille pour installer son malware ou son RAT .

Les faux certificats

A quoi bon faire de faux certificats ? Pour tromper son monde ! Si un petit malin arrive à se faire passer pour une entreprise réputée qui publie de nombreuses applications légitimes sur le store d’Apple, il arrivera alors facilement à faire passer son programme à lui, voire à l’intégrer dans un programme légitime.
D’où l’importance de vérifier correctement les certificats, afin d’être sûr de qui les publie et les utilise. Cela peut représenter une somme de travail importante dans le cas des magasins d’applications, où des centaines d’applications sont publiées.

Les profils iOS malicieux

Le MITM du Wifi

Pfou, un titre incompréhensible au premier abord. Les attaques MITM consistent à ce qu’un tiers vienne se placer au milieu d’une conversation en principe sécurisée. Ce type d’attaque se voit sur les réseaux Wifi mal sécurisés (ou non sécurisés). On peut théoriquement éviter cela avec un utilisateur au faîte du sujet et très vigilant. Et disposant d’un smartphone qui lui permette de contrôler visuellement certains éléments (comme les certificats).

Les webkits

Les webkits ne sont pas de méchants programmes : ce sont des outils que les navigateurs internet utilisent pour construire visuellement le résultat de votre navigation (afficher et positionner le texte, les images, etc.). Très utilisés, la moindre faille est critique. Une d’entre elles permettait, par exemple, d’effectuer le jailbreak de son iPhone rien qu’en visitant une page web spécialement construite à cet effet.

Attaques 0-day

Pour moi, un 0-day (ou faille 0-day) est une faille non corrigée dans une application. Qu’elle soit connue ou pas importe peu.
Une attaque 0-day est une attaque utilisant… une faille 0-day. Pourquoi est-grave ? Voir ci-dessus : parce qu’elle est non corrigée. Donc un petit malin se sert de cette faille, et personne ne peut l’arrêter. Il existe un commerce de ces failles : la cybercriminalité est devenue une industrie.

Les risques indirects

La plupart des fabricants de smartphones proposent des services de stockage en ligne. Il faut garder à l’esprit qu’ils sont souvent opérés par des tiers, et que leur mise en œuvre peut être plus ou moins bien faite, sans compter les risques inhérents à l’usage de services en ligne. Savez-vous par exemple qu’Apple utilise Amazon (AWS), Microsoft (Azure) ou Google (GCP) pour son service iCloud1 ?

Qui qui est le mieux ? iOS ou Android ?

Checkpoint ne mentionne pas pour Android les webkits (je ne vois pas pourquoi) ni les profils iOS malicieux (là j’ai une petite idée). Sinon, à défaut d’être identiquement exploitées (d’un point de vue purement technique), les menaces sont très similaires d’un point de vue conceptuel. La pomme n’est pas plus sûre que les bonbons.

Toutefois, certaines caractéristiques desservent Android, comme par exemple le nombre d’applications publiées (supérieur à iOS2), le fractionnement des versions du système d’exploitation et l’ouverture complète du système qui permet aux constructeurs et opérateurs de proposer des services et des programmes dont le niveau de sécurité peut être très hétérogène. Quand à la maintenance des programmes et versions d’OS, elle est à la main des mêmes constructeurs et opérateurs, donc la rigueur de gestion diffère (quand il n’y a pas carrément d’impossibilité technique à prendre en compte certains correctifs de sécurité).

Enfin, il est très facile sous Android de se connecter à des magasins d’applications non contrôlés, portes ouvertes aux programmes malveillants.

Les menaces sur Android

Liens utiles et articles liés

CNIL

Sujet intéressant ! Les mentions légales de ce site sont ici.

Charte des contrôles de la CNIL

Les mentions légales

https://www.service-public.fr/professionnels-entreprises/vosdroits/F31228

Les cookies traceurs

Que dit la loi ? https://www.cnil.fr/fr/cookies-traceurs-que-dit-la-loi

Voir aussi https://github.com/LINCnil/CookieViz/releases pour les cookies !

Liens utiles

https://www.cnil.fr/fr/modeles/courrier

Objets connectés

Le terme objets connectés me semble plus approprié que l‘internet des objets, qui prend les choses dans le mauvais sens en partant d’internet pour arriver aux objets, et qui est également trop limitatif car le vrai enjeu n’est pas tant d’être sur internet que d’être relié à d’autres objets.

Le ‘S’ dans IOT c’est pour « Sécurité ».

Blague anonyme

Les objets connectés existent depuis longtemps, sur l’échelle de temps informatique. Un ordinateur ou un serveur informatique étant des objets, il y a belle lurette que la connexion est faite. Le vrai changement est qu’en suivant la vague de miniaturisation et de banalisation des composants informatiques, on peut désormais coller partout ces composants, jusque dans votre pacemaker12, permettant notamment des fonctions évoluées mais aussi de la communication avec d’autres objets, sur internet ou pas.

Cela concourt selon moi à rendre ces objets menaçants, car comme souvent toujours en informatique, la sécurité n’a été abordée qu’après coup, car le bénéfice immédiat (réel) a souvent coupé court à toute autre réflexion.

Marchera pas

Difficile de penser qu’on arrivera facilement à un niveau de sécurité acceptable dans le monde des objets connectés, car la multiplicité des acteurs3 et leur féroce concurrence commerciale, le manque de culture sécurité et le coût nécessaires à cette sécurisation sont des freins puissants sur le chemin de cet objectif. Quant aux mauvaises habitudes, elles perdurent et les mots de passe par défaut continueront à nous jouer des tours, jusqu’à transformer un aspirateur45 en espion (puisque les aspirateurs automatiques ont des caméras pour se diriger).

Innovons

Que n’ai-je entendu que j’étais un râleur patenté, un pessimiste né, un rétrograde primaire, tout ça parce que je pestais (et peste encore) contre l’innovation bête et stupide, ainsi que sa glorification béate (toute comme pour les start-up) sans prise de conscience de l’ensemble des enjeux liés à ladite innovation.

Aspirateurs connectés

A partir du moment où votre aspirateur5 devient un objet connecté, attendez vous au pire. Toute caméra peut devenir un espion potentiel. Donc tout objet connecté, même anodin, peut recueillir (et donc transmettre) plein d’informations vous concernant, et à l’ère du big data, l’utilisation qu’on peut en faire est quasiment infinie.

Des chercheurs ont même réussi à transformer un aspirateur-robot en centre d’écoute : ils ont détourné l’usage du « lidar » (le radar dont se sert le robot pour se déplacer) pour capter les vibrations sonores sur les surfaces rencontrées6, et en déduire les conversations. Seul élément rassurant : vous parlez beaucoup, quand l’aspirateur marche ?

Avions connectés

Cela fait beaucoup moins rire de parler du danger des connexions dans les avions que pour les réfrigérateurs : autant un frigo qui envoie du spam ou qui commande une pizza, cela prête à sourire, autant la perspective d’un avion qui s’écrase fait froid dans le dos. Or dans objets connectés il y a aussi avions connectés. Et le département de la sécurité intérieure aux Etats-Unis nous dit que ce n’est qu’une question de temps7 avant qu’un avion ne soit piraté, avec les conséquences catastrophiques que l’on peut imaginer. Ils ont réussi à la faire avec un Boeing 737, on peut voir une analyse de risque ici.

Voitures et deux-roues connectés

Entre les scooters électriques (ou les vélos) en libre-service qu’il faut suivre pour leur entretien, ou les voitures se conduisant toutes seules, les interactions informatiques sont forcément très nombreuses. Donc récolte de données à gogo8 et réutilisation par toujours contrôlée, surtout en cas de faille.

Un autre exemple ? Volontiers : les trottinettes Xiami M365 peuvent être (au moins partiellement) contrôlées par un pirate9, qui peut agir sur le freinage ou l’accélération avec les conséquences qu’on peut imaginer.

N’importe quoi connecté

Parfois on trouve des failles non seulement dans les objets connectés, mais aussi dans les centrales électroniques censées les contrôler. En gros, si par extraordinaire vous utilisez un objet connecté non troué (= non vulnérable), alors il faudra vérifier que votre hub10 soit également bien protégé.

Menaces

DDoS et Botnets

Puisqu’il est si facile de prendre le contrôle d’un grand nombre de machines informatiques reliées à internet, les objets connectés sont tout naturellement d’excellents candidats pour construire un réseau de machines zombies (botnet). Et les méchants ne s’en privent pas. Les objets connectés piratables, zombifiables et contrôlables à souhait sont du pain béni pour les attaques de type DDoS (déni de service) ; Mirai en a été le premier exemple marquant.

Conséquences juridiques

Les conséquences juridiques sont difficiles à appréhender à l’émergence d’une nouvelle technologie (ou de son expansion). Or, tout comme la sécurité, les aspects juridiques sont trop souvent négligés11, et ça n’est qu’au moment d’une catastrophe, d’une attaque ou d’un litige qu’on se rend compte qu’on ne maîtrise ni la situation technique ni les conséquences juridiques (et judiciaires) de cette technologie.

En 2019 : rien de nouveau

Étonnamment, malgré des alertes renouvelées et argumentées, malgré des compromissions, les fabricants d’objets connectés continuent leur déni12 et la situation ne s’améliore absolument pas. En cause, toujours les mêmes facteurs :

  • La course au prix le plus bas (la sécurité étant vue comme source de surcoût initial) ;
  • La course à la part de marché et le time-to-market : faut être le premier, et pas le meilleur. Or la sécurité demande de réfléchir, donc du temps que les industriels ne se donnent pas.

En 2020 : rien de nouveau

Une étude de Palo Alto Networks13 enfonce le clou : sur le million d’objets connectés étudiés, 98% des flux réseaux circulent en clair, avec les risques de fuite d’information et de détournement associés, 57% sont vulnérables à des attaques ayant des impacts moyens ou élevés, dans l’industrie et les milieux hospitaliers, les objets vulnérables sont sur les mêmes VLAN que les dispositifs traditionnels, les mots de passe sont majoritairement faibles voire encore triviaux, etc.

The Internet of Things is a security nightmare reveals latest real-world analysis: unencrypted traffic, network crossover, vulnerable OSes

Sources

theregister.co.uk

Une autre étude de Zscaler14 est moins pessimiste, mais pas plus rassurante pour autant : seules 17% des « transactions » sont chiffrées. Cela s’explique probablement par un panel d’étude différent, avec d’autres usages et donc d’autres types de machines, mais ça reste pas beaucoup…

Sources

Voir aussi

Attaque et défense

La défense semble une posture normale pour tout entité, vivante ou organisationnelle. Il va de soi qu’un Etat va chercher à se défendre et à défendre ses concitoyens, tout comme n’importe quel individu. L’attaque dépend d’autres facteurs, et cette capacité a longtemps eu une place à part en informatique, car cela a toujours été considéré comme l’apanage des méchants. L’informatique était considérée comme un outil de production, qu’il fallait protéger et garder en état de marche.

Continuer la lecture →

Android

Application, gestion des fichiers

Just like files that you save on the device’s internal storage, Android stores your database in private disk space that’s associated application. Your data is secure, because by default this area is not accessible to other applications.

Cependant, si on ne suit pas les bonnes pratiques, notamment lors du stockage de données sur des supports externes à l’OS (genre carte SD), les données deviennent vite accessibles pour des intrus1.

Lenteur des mises-à-jour

Une des choses que je reproche le plus à Android est la fragmentation des versions de l’OS, ce qui se comprend par la difficulté d’intégration de tous les acteurs (fabricants de composants et puces, fabricants de smartphones, opérateurs téléphoniques) qui devaient chacun revoir leur copie à chaque mise à jour d’Android, ce qui fait que beaucoup traînaient les pieds ou ne le faisaient carrément pas. Or un OS viable est un OS à jour !

Treble

Depuis Android 8.0, toutes les parties spécifiques que les acteurs précédents devaient modifier a été séparée (logiquement) de l’OS. L’avantage indéniable de la manœuvre est de laisser le code spécifique à part, sans avoir besoin de le retravailler2. Il « suffit » donc de mettre à jour l’OS, pour un téléphone donné, afin d’avoir les derniers correctifs : le travail est du côté de Google, pas des acteurs intervenant par la suite (fondeurs de puces, constructeurs de téléphone et opérateurs).

Android One

Une autre option pour avoir un système à jour est justement de n’utiliser aucune personnalisation du téléphone, en respectant certains critères documentés par Google3. Au final, on aura un téléphone moins personnalisé (personnellement ça m’importe peu) mais surtout suivant (ou plutôt : pouvant suivre) les mises-à-jour Android sans aucun souci.

Google propose même de labelliser les téléphones respectant les critères Android One ; et je ne vois pas l’intérêt qu’aurait un constructeur à s’embêter à être Android One pour ne pas suivre le train des mises-à-jour de l’OS !

Liens

Sources

Voir aussi

Darkweb

La récente salve de francisation de termes informatiques n’a pas fait que des heureux. Plusieurs voix se sont élevées contre l’institutionnalisation de fait de termes abscons, comme darkweb et deepweb dont l’existence même prête à polémique.

Autant un portail de messagerie (« webmail ») est un concept clair pour tous, autant les notions d’internet clandestin (« darkweb ») ou de toile profonde (« deepweb ») n’ont pas de réalité si tangible que ce qu’on veut bien nous faire croire.

Le cas des clandestins

Le Larousse nous apprend que clandestin peut signifier « qui se cache » mais aussi « qui contrevient à la loi ou qui se dérobe au contrôle ». Cela peut tout à fait s’appliquer à l’internet de Mme Michu, car nombre de sites web d’accès public contreviennent allègrement à plusieurs lois françaises : tel site d’un journal people qui reprend des clichés violant la vie privée de personnalités, tel autre qui diffuse de annonces liées à des escroqueries diverses (la bague qui guérit tout, le gain assuré au loto, l’augmentation de volume de [ce qu’on veut], la promesse de gains mirobolifiques sur des marchés financiers qu’on cache être extrêmement risqués), la vente d’armes sur Facebook ou Instagram, etc.

Par ailleurs, se dérober au contrôle est parfois une mesure salutaire notamment dans les pays (grands ou petits) où la censure sévit et où la clandestinité est la seule option permettant de vivre (ou survivre). Aller sur l’onionland ou utiliser des VPN est nécessaire à certains.

Sombre internet

D’après S. Bortzmeyer, la définition correcte de deepweb serait :

Concept débile, peu ou pas défini, flou, et qui ne sert qu’aux politiciens et journalistes sensationnalistes.

La définition officiellement retenue est :

Partie de la toile qui n’est pas accessible aux internautes au moyen des moteurs de recherche usuels.

Ce qui est sans aucun rapport avec la notion qu’on veut mettre dans ce deepweb peuplé uniquement de méchants qui se cachent pour comploter, car il y a un tas de raisons pour lesquelles les moteurs de recherche n’indexent pas : je prenais le cas d’un portail de messagerie, dont la quasi-totalité du contenu n’est accessible qu’à un utilisateur authentifié (et donc inaccessible aux moteurs de recherche). Ce portail de messagerie serait donc à classer dans le deepweb. Or consulter ce deepweb vous expose directement à l’excommunication ou à des poursuites pénales, bien entendu. Idem pour tous les sites utilisant un fichier robots.txt.

Deep ou dark ? Blanc ou noir ?

J’avoue moi-même ne plus bien réussir à faire la différence entre ces deux notions, tant elles sont floues. Une distinction plus simple et plus claire serait peut-être de parler d’activités légales ou d’activités illégales sur internet, quels que soient les moyens employés, puisqu’on peut vendre de la drogue sur l’internet « classique » et tenter de sauver sa famille sur l’internet « clandestin ». Toutefois, le darkweb désigne plus généralement :

Réseau accessible uniquement via des outils spécifiques, comme le navigateur Tor.

Après, Tor ou Freenet ne sont pas vraiment des réseaux séparés, puisqu’ils utilisent l’infrastructure d’internet. On parle de réseaux « overlays », qui se superposent sur des réseaux existants.

Internet n’est qu’une sorte de reflet des activités humaines : les truands se cachent, sauf parfois pour escroquer les gens ou faire leur business. Et les gens normaux sont parfois tentés d’être discrets pour de bonnes raisons. Le darkweb sera d’ailleurs peut-être la dernière solution pour tenter de garder un soupçon de vie privée.

The Dark Web Boundaries Are Not Always Clear, and Many Sites Fall in a Gray Area

Idan Aharoni on SecurityWeek.com

Sources

Articles externes

GnuPG

GnuPG est un système de chiffrement (ou cryptosystème) indépendant des grands acteurs de la sécurité et de la surveillance (lesquels se confondent parfois). Il se base sur l’utilisation de clés de chiffrement asymétriques, ce qui permet de les échanger plus facilement.

Principes

A quoi ça sert un crypto-machin ?

Ça sert à masquer vos très chères données à nos très chers GAFA et autres acteurs du web et de l’internet. Accessoirement, Mme Michu ne pourra pas non plus lire ce que vous échangez avec vos correspondants.

En gros, vous créez une paire de clés de chiffrement qui vous seront associée à vous personnellement. Un des clés sera publique, l’autre sera privée ; elles vous permettront de chiffrer vos données ou vos mails. La clé publique pourra et devra être diffusée partout, et la clé privée devra rester secrète et donc, au contraire, être la plus cachée possible. Le gros inconvénient est que lorsqu’on perd sa clé privée, et bien c’est foutu, ça marche plus ! Il n’y a plus qu’à en recréer une, et diffuser la nouvelle clé auprès de vos correspondants, car il n’existe aucun moyen de la récupérer.

Comment ça s’installe ?

Sur les systèmes Linux, les outils nécessaires sont généralement installés par défaut. Après, le plus important est de stocker la clé privée en lieu sûr. La première opération à réaliser est la génération d’une paire de clés avec la commande --gen-key :

gpg --gen-key

On aura besoin durant cette procédure de disposer d’une quantité d’aléa (ou entropie) suffisante. Afin de voir l’entropie disponible sur un système Linux, on peut utiliser la commande suivante1 :

watch cat /proc/sys/kernel/random/entropy_avail

S’il vous en manque, il peut être judicieux d’utiliser le package rng-tools (sur Ubuntu).

apt-get install -y rng-tools

Pour générer un peu d’entropie supplémentaire, on peut utiliser la commande suivante :

/usr/sbin/rngd -r /dev/urandom

La seconde mesure consiste à générer un certificat de révocation pour toute une nouvelle paire de clés. La raison de procéder ainsi est qu’il vous faut disposer de la clé privée pour générer son certificat de révocation. Générer le certificat de révocation le plus tôt possible vous met à l’abri de l’oubli de votre clef. Vous devrez bien sûr conserver ce certificat à l’abri. En outre, il doit rester facile et rapide de révoquer une clé, en cas de compromission.

Comment ça marche pour chiffrer/déchiffrer ?

Pour chiffrer :

gpg -e destinataire [message]

Pour déchiffrer :

gpg [-d] [message]

Et pour signer ?

Pour signer et chiffrer un message, la syntaxe complète est :

gpg [-u expéditeur] [-r destinataire] [--armor] --sign --encrypt [message]

On peut faire un chouïa plus simple, pour signer un message avec l’identité par défaut de votre trousseau de clé :

gpg --sign|--clearsign|--detach-sign [message]

L’option --sign vous construit un fichier .gpg illisible, --clearsign produit un fichier au format texte avec le contenu en clair suivi de la signature, et enfin --detach-sign ne fournit que la signature dans un fichier .sig. Ajoutez l’option --armor pour avoir un fichier signature en clair, suffixé par .asc. Si vous prenez l’option --clearsign, cela vous construira un fichier de type :

root@rasp-janiko:/jean/test# cat essai.txt.asc 
-----BEGIN PGP SIGNED MESSAGE----- 
Hash: SHA1 
Ceci est un test. 
-----BEGIN PGP SIGNATURE----- 
Version: GnuPG v1.4.12 (GNU/Linux) 
iQEcBAEBAgAGBQJV+WSgAAoJEN+s4kEe3i4xT6AH/RlkQZyQQ5XkdGmIQGgk8H6h 
C8zK7/RO1XzzP4xyqA59yHfgPgwGJ9PASaaUlOHgLcIbbiTRTrow8ZIPNhBdF4fC 
gEvZfu9p27X6SXXRa/94Lt1uIHDVFhtzWf9YNoytToxRSIf/CvPpTXcHPbnYP7YD 
Gwdz+Qxz8u2vhKJKLk4uXHgJb97IvsgoSfpb7e7TMMqCRIKV2S6T1LyouW+Tyy1Y 
ZerF5rGIWle2rYVQoM5ujuM77q/XaxAZyGQ7fp5rndBSVMBWptK5W9k8Ji4vhCqa 
FqhVdzTvq+DwmsjigCUtLk9uxSdqBhNQ+xb3sSRlyXG1PmnQtigXlUnUs/wBVds= 
=t6tc 
-----END PGP SIGNATURE-----

Pour vérifier la signature, il suffit de taper :

gpg --verify [message]

Si tout va bien, vous aurez :

root@rasp-janiko:/jean/test# gpg --verify essai.txt.asc 
gpg: Signature faite le mer. 16 sept. 2015 14:46:24 CEST avec la clef RSA d'identifiant 1EDE2E31 
gpg: Bonne signature de « Jean GEBAROWSKI (statodynamicien) <jean@geba.fr> » </jean@geba.fr>

Et si la signature est mauvaise ou que le fichier est modifié :

root@rasp-janiko:/jean/test# gpg --verify essai.txt.asc 
gpg: Signature faite le mer. 16 sept. 2015 14:46:24 CEST avec la clef RSA d'identifiant 1EDE2E31 
gpg: MAUVAISE signature de « Jean GEBAROWSKI (statodynamicien) <jean@geba.fr> » </jean@geba.fr>

Ce qu’il faut vérifier

Comme toujours, ça ne sert à rien d’utiliser des moyens sûrs si on ne vérifie pas leur validité. Quand on reçoit une alerte sur un certificat, il ne faut pas cliquer sur OK sans réfléchir. Pour les clés PGP, on a vu des tentatives d’usurpation reposant sur l’identifiant court (ou short id), qui peut parfois être dupliqué ! Donc en utilisant et/ou important des clés, il ne faut pas de limiter à cet identifiant mais aussi vérifier l’adresse mail23…

Où vérifier ?

Le réseau SKS Keyserver (Synchronizing Key Server) a été historiquement le principal système de distribution des clés publiques. Le réseau SKS est en déclin (relatif) car il est vulnérable à des attaques comme l’empoisonnement de clés (« key poisoning »). On a, par exemple :

Sinon vous pouvez vous tourner vers :

  • keys.openpgp.org qui s’est modernisé, et qui est intégré par défaut dans plusieurs outils GPG.

Pour importer une clé : 

gpg --keyserver hkps://keys.openpgp.org --recv-keys

Outils et sites utiles

Site officiel

Failles

Une faille a été découverte en mai 20184 dans de nombreux outils de messagerie ou dans leurs plugins mettant en oeuvre PGP et S/MIME. Il s’agirait plus d’une mauvaise implémentation de ces protocoles dans les clients de messagerie que d’autre chose, mais le résultat est le même : il y a danger, même sil l’exploitation n’est pas triviale5.

Le seul conseil pour l’instant est de désactiver le déchiffrement automatique des messages dans les clients de messagerie concernés (tels que Outlook, Thunderbird, Apple Mail, etc.) en supprimant les clés qui y sont stockés, et de désactiver l’affichage HTML. Le déchiffrement ne doit être effectué que dans une application tierce, jusqu’à production du correctif.

Une autre faille a été mise au jour en juin 20186 permettant d’usurper n’importe quelle signature, ce qui est gênant. La version 2.2.8 de GnuPG corrige le tir de cette anomalie qui existait depuis très longtemps, apparemment !

Scan SSL

La confiance n’exclut pas le contrôle, dit-on souvent. Il existe d’excellents outils pour évaluer la sécurité et la robustesse d’un serveur proposant une communication SSL.

Pour ma part, je recommande SSLScan, dont il existe plusieurs variantes. En fouillant un peu, celle qui me semble la plus pertinente est celle de rbsec, car elle est à peu près à jour (elle intègre les versions 1.1 et 1.2 de TLS), et ne mixe pas les technologies puisqu’il s’agit uniquement d’un programme en langage C. Ca permet d’éviter de trop nombreuses dépendances, et ça évite de cumuler les vulnérabilités de multiples technologies (bien que cet aspect puisse être débattu).

Continuer la lecture →

Kubernetes

Kubernetes, ou k8s pour les intimes, est un orchestrateur. On pourrait dire parmi tant d’autres, vus qu’ils fleurissent pour nous aider à tout faire, mais pas tant que ça : il tend de facto à devenir un standard, ou tout du moins l’outil le plus utilisé dans son genre.

Continuer la lecture →