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.

Microservices

L’architecture en microservices est une approche intéressante dans la construction de systèmes d’informations, en particulier sur des infrastructures cloud où ce type d’architecture s’adapte naturellement. Cependant, cela reste un choix d’architecture, dans la filiation du SOA, avec des cas d’usage plus ou moins adaptés1.

En premier lieu, construire une architecture en microservices implique de choisir un niveau de granularité (de finesse) des services, qui n’obéit à aucune règle prédéfinie : on propose généralement d’avoir un service par fonctionnalité, mais plus le service est gros, plus on se rapproche d’une application monolithique, et à l’inverse plus le service est fin, plus la complexité induite peut être importante. Il faut donc que le service (ou la fonctionnalité) soit suffisamment indépendante du reste mais pas trop complexe non plus.

La transition entre l’architecture monolithique des applications des années 90 et les applications à base de microservices actuelles. © PWC via JDN

Ensuite on les fait communiquer et interagir, soit par des API REST, soit par des échanges asynchrones. Ces derniers sont peu évoluées, mais robustes : leur but n’est pas d’ajouter des fonctionnalités mais uniquement d’assurer un échange fiable de messages et d’informations entre plusieurs services, justement en n’ayant que peu ou pas de couplage ou de friction.

Enfin, on orchestre ces services, en les déployant, en les monitorant, etc. Souvent, l’organisation DevOps est adaptée à cette architecture, en institutionnalisant l’indépendance des équipes et donc des services composants le système final. L’équipe DevOps doit en théorie être responsable de son service, y compris de son suivi en production, mais certains éléments comme la sécurité du service et la sécurité globale du système sont difficiles à positionner dans ce contexte.

Le passage à une architecture en microservices est l’occasion d’adopter une organisation de type DevOps. Ca manque toutefois un peu de sécurité, non ? © Adrian Cockcroft / Slideshare via JDN

Ingénierie sociale

L‘ingénierie sociale  est une forme de délinquance astucieuse consistant à manipuler une personne, en lui faisant croire qu’elle a affaire à un interlocuteur légitime,  pour qu’elle réalise une action ou divulgue une information.

Le phénomène est ancien mais il est en plein expansion, notamment contre les entreprises françaises (indépendamment de leur banque). Les scenarii utilisés sont de plus en plus perfectionnés et font appel aux moyens techniques modernes.

Les fraudes financières

Le but est généralement de faire réaliser un virement à son profit, d’obtenir de l’information confidentielle (bancaire, financière, technique, etc) ou de détourner des services à son profit (vol de session, de compte de réseaux sociaux).

L’escroc essaiera de se faire passer pour une personne légitime (usurpation d’identité), à distance et en utilisant tous les moyens possibles (fax, mail, et même lignes téléphoniques détournées). Il usera de menace ou d’empathie pour convaincre son interlocuteur, en montrant également assez souvent une bonne connaissance de l’entreprise et de ses processus afin de rendre son discours crédible. 

Toute demande inhabituelle dans son contenu ou dans sa forme doit être considérée comme suspecte :

  • Urgence ou confidentialité extrême ;
  • Demande de virement bancaire sortant du cadre normal (montant important, opération avec un pays ou un tiers inhabituel) ;
  • Demande de prise de contrôle du poste ;
  • Non respect des procédures internes (appel direct du président, d’un service technique).

La fraude au président

Forme élaborée d’ingénierie sociale, elle est précédée très souvent par une longue phase de reconnaissance de la part de l’attaquant (ou de l’équipe d’attaquants). Tous les moyens sont bons : registre de commerce, Kbis, sites web des entreprises, réseaux sociaux, appels téléphoniques, etc. Le coût reste très raisonnable pour une équipe motivée et organisée, et la dissimulation reste facile (cartes bancaires prépayées, standards téléphoniques IP, essais gratuits de produits comme des fax par internet ou des outils de prise de contrôle à distance d’ordinateurs, etc.).

Une fois les informations engrangées, un ou plusieurs scénarios d’attaques sont élaborés. L’attaque en elle-même consiste en un ou plusieurs coup de téléphone à une personne ciblée, afin de la pousser à réaliser un virement au profit des attaquants. Au total, le coût de l’attaque reste très faible par rapport au gain potentiel.

L’élément le plus délicat dans ce schéma de fraude est le circuit de transfert puis de blanchiment de l’argent : il doit partir au plus vite du compte bancaire de la société victime et doit être difficile à rapatrier en cas de contestation.

Les bons réflexes

En cas de sollicitation de ce type, la personne doit :

  • Ne pas céder à la pression et garder son sens critique ;
  • Continuer à respecter les processus internes ;
  • Vérifier la légitimité de la demande ;
  • Vérifier l’identité du demandeur (contre-appel sur un numéro d’appel validé, ou toute méthode validée à l’avance) ;
  • Ne pas se laisser isoler : faire appel à un collègue ou son responsable.

Tendance

Grace aux progrès de l’informatique, il ne faut désormais plus que 20 minutes d’écoute1 pour reproduire correctement la voix de quelqu’un.

Cela va grandement faciliter le travail de ces pauvres fraudeurs au président, qui avaient bien du mal avant à trouver une voix ressemblante.

Autres fraudes

La liste est infinie : escroquerie à la fausse facture, à la facture falsifiée, changement de RIB, intervention sur un système informatique de paiement ou de gestion de trésorerie pour voler une session utilisateur, etc.

Un schéma possible est que le fraudeur tente de contrôler la session utilisateur d’une victime (une personne ayant l’autorisation de faire des paiements), en prétextant être un service technique devant faire des manipulations sur l’ordinateur de la victime, à distance. Si la victime est abusée et qu’elle laisse l’accès au pirate (comme il le ferait à un helpdesk informatique, par exemple), ce dernier cherchera généralement à détourner l’attention de sa cible (en lui faisant envoyer un fax, ou poser une question à un autre collaborateur, etc) afin d’installer à demeure un moyen d’accès à l’ordinateur ciblé sans être vu.

Voir aussi

EBS

Elastic Bloc Store, ou EBS, est un service d’espace de stockage destiné à être utilisé par les machines virtuelles d’AWS (EC2).

Chiffrement

Un des principaux (seuls) moyens de protéger les informations stockées sur des volumes de données est de les chiffrer. Mais que peut-on chiffrer sur un volume EBS ? La règle fournie par Amazon est simple :

  1. Les volumes créés à partir d’images chiffrées sont chiffrées.
  2. Les volumes créés à partir d’images non chiffrées ne le sont pas.
  3. Les volumes crées vides peuvent être chiffrés.

Conséquence : le volume EBS sur lequel vous installez un système d’exploitation issu d’une image machine (« ami ») non chiffrées ne le sera pas. Or c’est le cas de toutes les images machines fournies par AWS, ce qui s’explique car sinon, pour créer une instance EC2, il faudrait fournir la clé à chacun des clients, ce qui serait totalement contreproductif, vu que d’une part un chiffrement n’est utile que si la clé de chiffrement est secrète, et que d’autre part les clients d’AWS ne pourraient créer aucun instance sans disposer de cette clé, ce qui rend le processus très lourd.

Comment chiffrer les volumes de données

Il n’y a aucune astuce ni piège : il suffit de cocher la case « Chiffrement » puis de choisir la clé de chiffrement désirée en dessous. Cette clé peut être n’importe quelle clé à laquelle l’utilisateur a accès.

center

Comment chiffrer un volume EBS système ?

Il faut d’abord créer une ami non chiffrée à partir de la machine « modèle », puis faire une copie de l’ami ainsi produite et la chiffrer (je n’ai pas trouvé d’autre méthode).

center

Sources

  • https://d0.awsstatic.com/whitepapers/KMS-Cryptographic-Details.pdf

Certificat

Un certificat (en réalité un certificat numérique, mais je simplifie la terminologie car je ne parle que de sécurité informatique) est un document informatique permettant de prouver l’authenticité et l’intégrité d’un élément (une clé) de chiffrement public.

Il existe plusieurs types de certificats, ayant des caractéristiques et des niveaux de garantie assez différents.

Caractéristiques principales

Classes de certificats

Bien qu’il n’y ait pas de standard en la matière, les autorités de confiance délivrant les certificats proposent différents niveaux de garanties, déclinées souvent en classes.

Etendue de la validation

Il y a trois grand types de validation :

Domain Validation (DV)

C’est le type le plus simple de validation pour un certificat. L’autorité de certification (AC) émettra un certificat de validation de domaine à toute personne apparaissant comme contact administratif dans le registre public associé à chaque nom de domaine (ou suivant des contrôles assez simples se basant sur une adresse mail). La seule garantie obtenue est que le nom de domaine est bien celui qui apparaît, ce qui peut suffire à certains usages. Cela permet toutefois de chiffrer le trafic entre l’internaute et le site en question, et d’établir un minimum de confiance de façon assez rapide (pour le propriétaire du site).

Organization Validation (OV)

Ici, l’Autorité de Certification contrôle également l’identité de l’entreprise et de la personne formulant la demande de certificat. C’est un niveau supérieur, qui permet d’associer une identité à un nom de domaine, ce qui peut trouver son utilité quand des noms de domaines peuvent être ambigus.

Extended Validation (EV)

Édictées par le CA Browser Forum1, les directives EV2 obligent l’Autorité de Certification à effectuer une vérification beaucoup plus poussée de l’identité de l’entreprise ou de la personne demandant le certificat. Le niveau de garantie est supérieur à un certificat OV, ce qui est attesté par une barre verte contenant le nom de l’organisation dans certains navigateurs. En général, ils ne permettent pas le multi-domaine (SAN) ni le wildcard.

Type de certificat

Wildcard

Multi-domaine (SAN)

Usage

Validité d’un certificat

Que doit-on vérifier pour pouvoir dire qu’un certificat est valide ?

  1. Le certificat doit avoir un format valide ;
  2. le certificat doit être valide au moment de son utilisation (date de fin mais aussi date de début) ;
  3. il doit être issu d’une autorité de confiance (CA) reconnue et fiable ;
  4. le nom du service correspond bien à celui que l’on veut (champ CN du sujet) ;
  5. l’usage du certificat est conforme à celui qu’on veut en faire, en vérifiant :
    1. Basic constraints : indique notamment s’il s’agit d’un certificat racine ou non (CA:FALSE par exemple)
    2. Key Usage : signature, chiffrement, etc.
    3. Extended Key Usage : authentification du site web, par exemple ;
  6. le certificat ne doit pas avoir été révoqué (mais c’est bien rare que cette vérification soit faite…).

Applications

DMZ

J’ai toujours eu du mal à cerner la notion de DMZ. Pour moi, il s’agit d’une zone sans arme, et je vois difficilement aller au combat (à savoir : se connecter à internet) sans être un minimum équipé.

Pour la clarté de l’explication, le local sera le gentil, l’extérieur sera le méchant, et le gentil cherche à se protéger du méchant.

Dans ce contexte, une DMZ est bien une zone réseau à part, servant de tampon entre les deux zones de conflit (le réseau local et le réseau extérieur, qui est en général internet). Son rôle est bien d’éviter une propagation des menaces de part et d’autre, mais les moyens employés sont bien plus coercitifs qu’un gentleman agreement, avec la différence notable qu’une des parties (le gentil) s’autorise à militariser tout ce qu’il veut, et que le but d’une DMZ réseau est de désarmer uniquement l’attaquant, et non les deux parties simultanément.

DMZ avec un seul pare-feu

Source : wikimedia.org.

Cette solution est simple à mettre en place, mais elle est moins sûre dans l’absolu, car tout repose sur une seule brique : le pare-feu. Cela suffit si la zone à protéger n’est pas trop critique, mais tout problème sur le pare-feu impacte l’efficacité de ce type de DMZ. C’est ce qu’on appelle une SPOF (Single Point Of Failure).

De plus, l’équipement utilisé pour le pare-feu doit savoir gérer tous les types de flux, ainsi que le cloisonnement demandé, ce qui en fait un équipement complexe.

DMZ avec deux pare-feu

Cette architecture est la plus sécurisée, car même si un des pare-feu est attaqué, l’autre reste disponible.

Source : wikimedia.org.

Ici, tout flux provenant d’internet arrive sur le 1er pare-feu, et il est redirigé vers la DMZ : il est donc impossbile d’aller dans le réseau local.

A l’inverse, un utilisateur du réseau local (LAN) peut accéder à la DMZ pour aller chercher ce dont il a besoin. Il peut aussi éventuellement accéder à internet, si on lui en donne l’autorisation (c’est un choix qui n’influe pas directement sur le niveau de sécurité de la DMZ).

Enfin, un équipement se trouvant à l’intérieur de la DMZ n’a accès… à rien : il est bloqué par les deux pare-feu. Il peut y avoir des exceptions, par exemple pour des mises-à-jour logicielles des équipements de la DMZ.

Sources

http://www.commentcamarche.net/contents/995-protection-introduction-a-la-securite-des-reseaux
https://www.1and1.fr/digitalguide/serveur/securite/quest-ce-quune-zone-demilitarisee-dmz/

NSA

La NSA n’est plus à présenter, puisque c’est le plus gros employeur au monde dans le domaine de la sécurité informatique. Rien que l’équipe dont le seul objectif est de pénétrer dans n’importe quel système informatique compte plus d’un millier de personnes, qui n’ont pas l’air d’être des manchots (à part celui qui est à l’origine de fuites d’informations retrouvées « par hasard » par Kaspersky).

Non, ce qui m’intéresse est d’observer les implications, les ramifications et les relations entre différentes affaires, ainsi que les forces et les faiblesses de cette organisation déjà tout puissante avant l’avènement de l’informatique grand public.

Evolution tardive

Un des grands reproches fait à la NSA est que l’agence est exclusivement orientée vers l’attaque, ce qui correspond à la doctrine de défense des Etats-Unis qui ont longtemps pensé qu’ils ne seraient jamais attaqués sur leur territoire national, et que toute posture de défense serait superflue.

Or dans le monde cyber, comme dans le monde physique, les Etats-Unis sont comme les autres, vulnérables et attaqués. Et ce n’est qu’en 2019 qu’est structuré une organisation en charge de la défense informatique dont l’objectif est de protéger les infrastructures du pays ainsi que les prestataires de défense.

  • Voir plus d’infos sur le site de la NSA.

Sources

L’informatique, c’est physique

Je suis un des premiers à le reconnaître, mais j’avais oublié que l’informatique était un objet éminemment physique. A l’ère du tout numérique et de la dématérialisation à tout va, à une époque où on se demande où sont stockées nos données (car bien souvent on ne le sait pas), j’ai suivi une présentation très intéressante au cours du FIC 2018 faite par un géographe, chercheur à l’université (ref), qui nous a remis à l’esprit que derrière l’immatérialité apparente de l’informatique il y avait une réalité bien tangible.

Cette réalité prenait forme d’une très éclairante approche cartographique du cyberespace, au sens très large.

Réalité contre projection

Le cyberespace est d’abord une construction physique, informatique, faite de machines et de câbles désormais répartis partout tout le monde réel.

Ensuite, ce cyberespace sert bien à quelque chose : tout comme l’informatique, il sert à manipuler et interagir sur une projection (une représentation) d’idées et de concepts, dont la plupart sont liés à notre monde réel (mais pas forcément). Si l’informatique a servi dans un premier temps à nous aider à accomplir ou accompagner des tâches réelles (techniques, scientifiques, professionnelles), son évolution a conduit à être utilisée pour interagir avec des objets chimériques ou imaginaires. Un exemple simple de cela est ce que peut représenter un jeu vidéo, qui représente un univers purement imaginaire.

L’idée n’est pas ici de différencier l’usage de l’informatique et du cyberespace en réel ou imaginaire, le fait est qu’on utilise l’informatique et que le contenu traité nous importe. Or comme il nous importe, il est également important d’examiner cet outil qui, bien que traitant d’immatériel (une projection de notre monde ou des concepts), il s’appuie sur des équipements physiques dont l’usage, la géographie et le contrôle sont des enjeux désormais stratégiques, au niveau des Etats.

Exemple de la Géorgie (guerre 2008, rachat d’un opérateur câble).

Cartographie du passage des flux. Tbilissi est plus proche de Sofia que de l’Abkhazie.

Importance militaire et stratégique (coupure en Géorgie et en Crimée).

SSL/TLS

SSL et TLS sont deux noms différents pour la même chose. Enfin presque : il y a eu plusieurs versions de SSL (notamment v2 et v3) puis l’appellation TLS a remplacé SSL. Nous avons donc eu TLS 1.0, puis TLS 1.1 et maintenant TLS 1.2.

SSL est un protocole permettant de sécuriser des échanges de flux réseaux. Comme tout protocole, il n’est constitué que de spécifications : on dit quoi faire et comment. Après, ce sont des programmes (des librairies…) qui implémentent (mettent en oeuvre en pratique) ce protocole.

SuperFish

Etablissement d’une session TLS

Avant d’échanger des messages de façon sécurisée, il faut commencer par se mettre d’accord sur la façon de faire.

Hello client (ClientHello)

Le 1er message est envoyé par le client au serveur. Ce message contient :

  • Le numéro de version de la version TLS la plus récente supportée par le client ;
  • la date et heure client ;
  • 28 octets aléatoires ;
  • un numéro de session (en cas de reprise de session) ;
  • la liste des méthodes cryptographiques supportées par le client ;
  • la liste des méthode de compression supportées ;
  • certaines valeurs spécifiques comme le nom du service demandé (Server Name Indication).

Premier retour serveur

Le serveur va ensuite envoyer un paquet de messages pour avancer dans le dialogue.

Hello serveur (ServerHello)

Le serveur va d’abord poliment renvoyer son bonjour. Il va indiquer :

  • La version du protocole SSL/TLS qu’il souhaite utiliser ;
  • la date et heure côté serveur ;
  • 28 octets aléatoires ;
  • un numéro de session si besoin ;
  • l’algorithme cryptographique et l’algorithme de compression retenus pour cette session, en fonction de ce que supporte le client.

Présentation des certificats du serveur (Certificate)

Le serveur envoie ensuite ses certificats.

à approfondir

Echange de clé serveur (ServerKeyExchange)

Le contenu de cette partie est variable. Elle est fonction de ce qui a été négocié auparavant, principalement des algorithmes cryptographiques retenus.

  • Dans le cas d’un échange de type Diffie-Hellman, ce message contient les paramètres de cet échange. Ils sont générés aléatoirement par le serveur et signés par la clé privée du serveur (sauf dans le cas d’un échangé DH/ECDH anonyme).
  • Dans les autres cas, ce message n’existe pas car les informations nécessaires sont dans le certificat.

Fin du bonjour (HelloDone)

Ce message marque la fin de cette étape. Mais ça n’est pas fini pour autant.

Pre-master secret

Voici maintenant une étape tout aussi importante dans l’établissement de l’échange : l’échange d’un pre-master secret, valeur essentielle pour la connexion, et qui ne doit être connue que des deux parties (Alice et Bob). Il existe plusieurs méthodes pour cela :

  • RSA : la valeur secrète est générée par le client, aléatoirement, et elle est envoyée au serveur chiffrée avec la clé publique du serveur (donc seul le serveur peut la déchiffrer), dans un message ClientKeyExchange.
  • Diffie-Hellman ou Elliptic Curve Diffie-Hellman (DH ou ECDH) : la valeur secrète est négociée via l’algorithme de Diffie-Hellman. Il en existe une variante basée sur les courbes elliptiques. Les paramètres côté serveur sont inclus dans le certificat ; côté client, c’est également dans le certificat si le client en présente un, sinon il doit en générer aléatoirement.
  • Diffie-Hellman Ephemeral (DHE) avec également une variante basée sur les courbes elliptiques (ECDHE) : les valeurs secrètes sont générées aléatoirement, dans tous les cas, et de façon unique pour chaque transaction. Côté serveur, les paramètres sont signés avec sa clé privée.
  • Diffie-Hellman anonyme, avec variante EC : C’est du DHE mais sans chiffrement côté serveur. En conséquence, cette négociation est vulnérable aux attaques MITM.

On en parle, hélas

Oui, on parle de SSL malheureusement, car on se rend compte de son importance et de la menace représentée par les failles du protocole ou de son implémentations. Freak, Poodle ou Heartbleed sont des exemples de failles ayant fortement impacté le monde informatique mais aussi, indirectement, les utilisateurs.

Quelles versions utiliser ?

Le conseil général est le suivant : toujours utiliser la dernièr version quand c’est possible.

Est-ce toujours possible ?

Comme le titre le laisse entendre : non. Comme vu plus haut, la connexion en SSL/TLS se fait sur la base d’une négociation entre le serveur (le site internet) et le client (le navigateur web). Les deux essayent généralement d’utiliser les versions les plus récentes et les plus sécurisées, mais il arrive souvent que les navigateurs ne soient pas à jour et ne connaissent tout simplement pas les versions récentes de TLS.

Y a-t-il des versions à éviter ?

Oui, car certaines versions contiennent des failles intrinsèques (par exemple Poodle). Par ailleurs, avec le temps, certaines attaquent deviennent plus faciles : soit parce qu’elles sont mieux connues, soit parce que la puissance de calcul nécessaire est plus facilement accessible. A fin juin 2015, on considère que SSL v2 et SSL v31 ne doivent plus être utilisées.

Liens

Liens internes

Liens externes