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.

Logjam

Logjam est une nouvelle faille dans le désormais périlleux chemin de la cryptographie, touchant une étape de négociation lors d’une connexion [[TLS|SSL/TLS]]. Même si, comme Freak, son exploitation n’est pas forcément facile, cela va imposer à moyen terme l’augmentation de la longueur de certaines clés, ou l’utilisation de certains algorithmes à la place de certains jugés trop faibles, ce qui aura surtout pour effet de compliquer encore la vie des webmasters (et des navigateurs web).

En effet, à force d’augmenter la solidité des mécanismes de sécurité, on finit par demander beaucoup de calculs à la fois au serveur et au navigateur ; or tout le monde n’est pas obligatoirement à niveau, et on pourrait finir (par exemple) par rendre certains sites inaccessibles aux utilisateurs dont les ordinateurs (ou les navigateurs web) ne sauraient pas composer avec cette complexité croissante.

Une synthèse, avec un outil de test ainsi que les recommandations à suivre sont ici : weakdh.org.

Désactivation sur Plesk

Sur Plesk, si vous avez une version 2.2 d’Apache couplé à nginx, il faudra un peu ruser pour ne plus être exposé à Logjam. pour plus d »infos, allez voir le forum.

Il faut en premier lieu créer un fichier DH personnalisé, de complexité (longueur) suffisante :

openssl dhparam -out dhparams.pem 2048

Ensuite, il faut un template personnalisé pour ses sites web, dans /usr/local/psa/admin/conf/templates/custom/domain. Le fichier à modifier est nginxDomainVirtualHost.php. Il faut ajouter l’option ssl_dhparam en lui mettant le fichier que l’on vient de créer.

ssl_ciphers                 HIGH:!aNULL:!MD5;

ssl_prefer_server_ciphers   on;

ssl_dhparam             /dhparams.pem;

Ensuite on reconfigure et ça devrait aller.

# /usr/local/psa/admin/bin/httpdmng --reconfigure-all

Pour vérifier, tapez :

# cat /var/www/vhosts/system/*/conf/last_nginx.conf | grep dh_param

Liens externes

  • http://www.nextinpact.com/news/94144-logjam-apres-freak-nouvelle-faille-dans-chiffrement-connexions.htm
  • http://forum.odin.com/threads/ssl-poodle-sslv3-bug.323338/#post-761018
  • https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf

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.

Continuer la lecture

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.
Continuer la lecture

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. FreakPoodle 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

En cas d’incident

Difficile de donner des consignes générales en cas d’incident. Le CERT-FR a tenté l’exercice avec une infographie assez générique, plutôt destinée aux petites structures1.

Toutefois, dans le cas d’un ransomware, la meilleure solution est d’éteindre immédiatement la machine.

En cas de découverte d’une faille, il est normalement obligatoire de le déclarer en bonne et due forme.2.

Registre distribué

La technologie de registre distribué a le vent en poupe depuis quelques années (depuis la popularisation des cryptomonnaies telles que le bitcoin). On appelle aussi ça « chaîne de blocs », traduction plus littérale mais technique : ça dit ce que c’est, mais pas ce que ça fait, à l’inverse de « registre distribué ».

Continuer la lecture

NFC

NFC est un acronyme pour Near Field Communication, dont je laisse la description aux spécialistes (ou aux amateurs, selon les points de vue) de wikipedia. Il s’agit d’une technologie radio qui peut être utilisée pour l’échange de données informatiques sans contact, à courte distance.

Dans le milieu où j’évolue (la banque), on redoute les concurrents de type fintechs tout en cherchant à rester en tête de l’innovation. Le NFC a évidemment alimenté les discussions, pour ne pas rater le coche, mais il est souvent judicieux d’attendre un peu avant de se lancer tête baissée dans une technologie, surtout quand elle peine à décoller : les nombreuses expérimentations menées en France ne sont guère convaincantes, et même Gartner qui fait souvent montre d’optimisme, a un avis très mesuré sur cette technologie1.

Pire : fin 2015, un an après le lancement d’un service basé sur le NFC, Apple lui-même semble échouer à faire adopter cette technologie2, principalement en raison de l’usage peu naturel pour les utilisateurs d’un téléphone comme moyen de paiement. Les banques, pourtant, ont tendance à considérer les smartphones comme le Graal des futurs moyens de paiement. Graal ? Peut-être. Mais pas tout de suite. Un autre frein à l’adoption, probablement moins important mais sans doute assez présent, est le niveau de sécurité de la technologie.

NFC : est-ce sûr ou pas ?

Comme souvent, ce n’est pas la technologie en elle-même qui possède des faiblesses (bien que cela puisse arriver), c’est plutôt la manière dont on l’utilise et dont on la met en œuvre qui est perfectible. Or pour le NFC, comme pour l’internet des objets, tout le monde ne jure que par l’usage et l’adoption, sans penser sécurité, alors que pourtant ce point est crucial pour l’adoption d’un moyen de paiement. Et tôt ou tard on s’en mordra les doigts… Or même les grands opérateurs sont parfois légers sur le sujet3. Les premières attaques seraient déjà en cours (attaque réelle ou proof-of-concept sur un utilisateur ciblé ?)4.

Références

  • http://www.zdnet.fr/actualites/apple-pay-aurait-deja-vecu-son-age-d-or-39824616.htm
  • http://www.gartner.com/newsroom/id/2846017

TrueCrypt

Que penser de TrueCrypt ? C’est l’un des plus étonnants mystères de ces dernières années dans le petit monde de l’informatique.

TrueCrypt est un utilitaire permettant de chiffrer ses documents, voire des volumes entiers sur vos disques plus ou moins durs. Très utilisé, et même recommandé par des personnes de confiance, l’utilitaire a disparu du jour au lendemain (littéralement), sans donner d’explication convaincante1. D’autant plus étonnant que des initiatives avaient abouti à la réalisation d’un audit du code (qui est à peu près en open source), sans que l’on trouve en première approche de grosse faille ou de faiblesse particulière, à peine un mois plus tôt. Par ailleurs, en 2013, l’ANSSI avait fait réaliser une certification de premier niveau (CSPN), c’est-à-dire que fonctionnellement il répond bien à la cible de sécurité choisie.

Continuer la lecture

Botnet

Un botnet est un ensemble de bots informatiques qui sont reliés entre eux. Historiquement, ce terme s’est d’abord confondu avec des robots IRC (bien que le terme ne se limitait pas à cet usage spécifique), qui était un type de botnet particulier servant sur les canaux IRC.

Usage légitime

Sur IRC, leur usage est de gérer des canaux de discussions, ou de proposer aux utilisateurs des services variés, tels que des jeux, des statistiques sur le canal, etc. Être connectés en réseau leur permet de se donner mutuellement le statut d’opérateur de canal de manière sécurisée, de contrôler de manière efficace les attaques par flood ou autres. Le partage des listes d’utilisateurs, de bans, ainsi que de toute sorte d’informations, rend leur utilisation plus efficace.

Il existe d’autres usages légitimes de botnets, comme l’indexation web : le volume des données à explorer et le nécessaire usage de parallélisation impose l’usage de réseaux de bots.

Dérives et usages malveillants

Les premières dérives sont apparues sur les réseaux IRC1 : des botnets IRC (Eggdrop en décembre 1993, puis GTbot en avril 1998) furent utilisés lors d’affrontements pour prendre le contrôle du canal.

Aujourd’hui, ce terme est très souvent utilisé pour désigner un réseau de machines zombies, car l’IRC fut un des premiers moyens utilisés par des réseaux malveillants pour communiquer entre eux, en détournant l’usage premier de l’IRC. Le premier d’entre eux qui fut référencé a été W32/Pretty.worm2, appelé aussi PrettyPark, ciblant les environnements Windows 32 bits, et reprenant les idées d’Eggdrop et de GTbot. A l’époque, ils ne furent pas considérés comme très dangereux, et ce n’est qu’à partir de 2002 que plusieurs botnets malveillants (Agobot, SDBot puis SpyBot en 2003) firent parler d’eux et que la menace prit de l’ampleur.

Toute machine connectée à internet est susceptible d’être une cible pour devenir une machine zombie : des réseaux de botnets ont été découverts sur des machines Windows, Linux, mais également sur des Macintosh, voire consoles de jeu3 ou des routeurs4.

Usages principaux des botnets malveillants

La caractéristique principale des botnets est la mise en commun de plusieurs machines distinctes, parfois très nombreuses, ce qui rend l’activité souhaitée plus efficace (puisqu’on a la possibilité d’utiliser beaucoup de ressources) mais également plus difficile à stopper.

Usages des botnets

Les botnets malveillants servent principalement à :

  • Relayer du spam pour du commerce illégal ou pour de la manipulation d’information (par exemple des cours de bourse) ;
  • Réaliser des opérations de phishing ;
  • Identifier et infecter d’autres machines par diffusion de virus et de programmes malveillants (malwares) ;
  • Participer à des attaques groupées (DDoS)5 ;
  • Générer de façon abusive des clics sur un lien publicitaire au sein d’une page web (fraude au clic) ;
  • Capturer de l’information sur les machines compromises (vol puis revente d’information) ;
  • Exploiter la puissance de calcul des machines ou effectuer des opérations de calcul distribué notamment pour cassage de mots de passe ;
  • Servir à mener des opérations de commerce illicite en gérant l’accès à des sites de ventes de produits interdits ou de contrefaçons via des techniques de fast-flux, single ou double-flux ou RockPhish6 ;
  • Miner de la cryptomonnaie ;
  • Voler des sessions par credential stuffing.

Motivation des pirates

Motivation économique

L’aspect économique est primordial : la taille du botnet ainsi que la capacité d’être facilement contrôlé sont des éléments qui concourent à attirer l’activité criminelle, à la fois pour le propriétaire de botnet (parfois appelé « botherder » ou « botmaster ») que pour les utilisateurs, qui la plupart du temps louent les services d’un botnet pour l’accomplissement d’une tâche déterminée (envoi de pourriel, attaque informatique, déni de service5, vol d’information, etc). En avril 2009, un botnet de 1 900 000 machines7 mis au jour par la société Finjian engendrait un revenu estimé à {{formatnum:190000}} dollars par jour à ses « botmasters »8.

Motivation idéologique

En dehors de l’aspect économique, les attaques informatiques peuvent devenir une arme de propagande ou de rétorsion, notamment lors de conflits armés ou lors d’événements symboliques. Par exemple, lors du conflit entre la Russie et la Géorgie en 2008, le réseau géorgien a été attaqué sous de multiples formes (pour le rendre indisponible ou pour opérer à des défacements des sites officiels)9. En 2007, une attaque d’importance contre l’Estonie a également eu lieu10 : la motivation des pirates serait le déplacement d’un monument en hommage aux soldats russes du centre de la capitale estonienne11.

Motivation personnelle

La vengeance ou le chantage peuvent également faire partie des motivations des attaquants, sans forcément que l’aspect financier soit primordial : un employé mal payé12 ou des joueurs en ligne défaits3 peuvent chercher à se venger de l’employeur ou du vainqueur du jeu.

Architecture d’un botnet

Mode actuel de communication des botnets

Via canal un canal de commande et contrôle (C&C)

  • Canaux IRC13 (le premier historiquement), souvent sur un canal privé.

Via des canaux décentralisés

  • P2P61413, pour ne plus dépendre d’un nœud central ;
  • HTTP613 (parfois via des canaux cachés15), ce qui a pour principal avantage de ne plus exiger de connexion permanente comme pour les canaux IRC ou le P2P mais de se fondre dans le trafic web traditionnel ;
  • Fonctions du Web 2.013, en faisant une simple recherche sur certains mots-clés afin d’identifier les ordres ou les centres de commandes auxquels le réseau doit se connecter16.

Cycle de vie

Un botnet comporte plusieurs phases de vie117. Une conception modulaire lui permet de gérer ces plusieurs phases avec une efficacité redoutable, surtout dès que la machine ciblée est compromise. La phase d’infection est bien évidemment toujours la première, mais l’enchaînement de ces phases n’est pas toujours linéaire, et dépendent de la conception du botnet.

Infection de la machine

C’est logiquement la phase initiale. La contamination passe souvent par l’installation d’un outil logiciel primaire, qui n’est pas forcément l’outil final. Cette contamination de la machine utilise les mécanismes classiques d’infection :

Activation

Une fois installée, cette base logicielle peut déclarer la machine à un centre de contrôle, qui la considèrera alors comme active. C’est une des clés du concept de botnet, à savoir que la machine infectée peut désormais être contrôlée à distance par une (ou plusieurs) machine tierce. Dans certains cas, d’autres phases sont nécessaires (auto-protection, mise-à-jour, etc) pour passer en phase opérationnelle.

Mise-à-jour

Une fois la machine infectée et l’activation réalisée, le botnet peut se mettre-à-jour, s’auto-modifier, ajouter des fonctionnalités, etc. Cela a des impacts importants sur la dangerosité du botnet, et sur la capacité des outils de lutte à enrayer celui-ci, car un botnet peut ainsi modifier sa signature virale et d’autres caractéristiques pouvant l’amener à être découvert et identifié.

Auto-protection

D’origine, ou après une phase de mise-à-jour, le botnet va chercher à s’octroyer les moyens de continuer son action ainsi que des moyens de dissimulation. Cela peut comporter :

  • Installation de rootkits ;
  • Modification du système (changement des règles de filtrage réseau, désactivation d’outils de sécurité, etc) ;
  • Auto-modification (pour modifier sa signature) ;
  • Exploitation de failles du système hôte, etc.

Propagation

La taille d’un botnet est à la fois gage d’efficacité et de valeur supplémentaire pour les commanditaires et les utilisateurs du botnet. Il est donc fréquent qu’après installation, la machine zombie va chercher à étendre le botnet :

  • Par diffusion virale, souvent au cours d’une campagne de spam (liens web, logiciel malveillant en PJ, etc)
  • Par scan :
    •  Pour exploiter des failles qu’il saura reconnaître ;
    • Pour utiliser des backdoors connues ou déjà installées ;
    • Par réaliser des attaques par force brute, etc.

Phase opérationnelle

Une fois installé, et déclaré, la machine zombie peut obéir aux ordres qui lui sont donnés pour accomplir les actions voulues par l’attaquant (avec, au besoin, installation d’outils complémentaires via une mise-à-jour distante) :

  • Envoi de spam;
  • Attaques réseau ;
  • Participation au service de serveur DNS dynamique, ou DDNS (fast flux) ;
  • Utilisation des ressources systèmes pour du calcul distribué (cassage de mot de passe), etc

Illustration d’un exemple de botnet

Voici le principe de fonctionnement d’un botnet servant à envoyer du pourriel :

  1. Le pirate tente de prendre le contrôle de machines distantes, par exemple avec un virus, en exploitant une faille ou en utilisant un cheval de Troie.
  2. Une fois infectées, les machines vont terminer l’installation ou prendre des ordres auprès d’un centre de commande, contrôlé par le pirate, qui prend donc ainsi la main par rebond sur les machines contaminées (qui deviennent des machines zombies).
  3. Une personne malveillante loue un service auprès du pirate.
  4. Le pirate envoie la commande aux machines infectées (ou poste un message à récupérer, selon le mode de communication utilisé). Celles-ci envoient alors des courriers électroniques en masse.

Taille des botnets

Il est extrêmement difficile d’avoir des chiffres fiables et précis, puisque la plupart des botnets ne peuvent être détectés qu’indirectement. Certains organismes comme shadowserver.org tentent d’établir des chiffres à partir de l’activité réseau, de la détection des centres de commandes (C&C), etc.

Nombre de réseaux (botnets)

Au mois de février 2010, on estimait qu’il existait entre {{formatnum:4000}} et {{formatnum:5000}} botnets actifs18. Ce chiffre est à considérer comme une fourchette basse, puisque les botnets gagnent en furtivité et que la surveillance de tout le réseau internet est impossible.

Taille d’un réseau

La taille d’un botnet varie mais il devient courant qu’un réseau puisse comprendre des milliers de machines zombies. En 2008, lors de la conférence RSA, le top 10 des réseaux comprenait de 10 000 à 315 000 machines, avec une capacité d’envoi de mail allant de 300 millions à 60 milliards par jour (pour Srizbi, le plus important botnet à cette date)1920.

En 2018, l’activité des botnets se concentrait sur deux grands réseaux : Necurs et Gatmut. Pour McAfee, ils sont à eux seuls responsables de 97 % du trafic des réseaux de robots (botnets) de spam21 au 4e trimestre 2018.

Nombre total de machines infectées

Dans son rapport de 2009, la société MessageLabs estime également que 5 millions de machines20 sont compromises dans un réseau de botnets destiné au spam.

Botnets de tous pays, unissez-vous !

La dernière mode dans le monde des botnets est de s »unir, car il est bien connu que l’union fait la force. La difficulté croissante pour effectuer des fraudes bancaires pousserait les criminels à combiner leurs forces22 afin de disposer de plusieurs méthodes de capture de données, ainsi que pour compromettre de façon plus efficace les cibles.

Lutte contre l’action des botnets

La constitution même d’un botnet, formé parfois de très nombreuses machines, rend la traçabilité des actions et des sources délicate. Plus le botnet est grand, plus il devient également difficile de l’enrayer et de l’arrêter puisqu’il faut à la fois stopper la propagation des agents activant le botnet et nettoyer les machines compromises.

Les anciennes générations s’appuyaient souvent sur un centre de contrôle centralisé ou facilement désactivable (adresse IP fixe pouvant être bannie, canal IRC pouvant être fermé, etc). Désormais, le pair à pair permet une résilience du système de communication, et les fonctions Web 2.0 détournées rendent l’interception très complexe : le botnet recherche un mot clé sur le web et l’utilise pour déterminer l’emplacement du centre de contrôle auprès duquel il doit recevoir ses ordres.

Détection

  • Empreintes
  • Observation du trafic
  • Analyse de logs

Prévention

  • Liste noires
    • RBL
    • DNSBL
  • Mesures habituelles de protection du réseau (cloisonnement, restrictions, etc)
  • Mesures habituelles de protection des machines (anti-virus, HIDS/HIPS, mot de passe, gestion des droits utilisateurs, anti-spam, gestion des mises-à-jour, etc)

Examples

L’évolution probable des botnets

BITB (Botnet In The Browser)

Les futurs botnets pourraient évoluer dans leur architecture avec l’arrivée d’HTML5 : les nouvelles fonctionnalités offertes par la nouvelle spécification HTML pourrait permettre de réaliser des botnets d’une nouvelle nature, à l’intérieur même d’un navigateur web (et non plus codé en dur et installé sur une machine)23.

Il est également fort probable de les voir continuer à exister, persistants en dépit de efforts réalisés pour les éradiquer (comme le botnet Satori)24 : ils exploiteront toute faille pouvant être exploitée à grande échelle, dans les réseaux traditionnels mais aussi les smartphones ou les objets connectés.

Les objets connectés

Merci à eux, objets si nombreux, et si peu sécurisés. On a trouvé traces d’objets connectés dans des botnets dès 201325, mais depuis 2016, ils ont commencé à représenter une véritable menace en raison de la facilité de leur prise de contrôle, alors que leurs capacités suffisaient pour construire une attaque réseau puissante, les attaques DDoS dont l’origine était un botnet d’objets connectés pouvant atteindre le Tb/s, c’est-à-dire la limite technique des structures d’absorption à la même époque. L’hébergeur OVH en a subi les conséquences et a communiqué26 sur le sujet afin d’alerter les spécialistes sur ce risque. En 2018, la chasse au botnet représentait toujours un travail conséquent27 pour l’hébergeur.

Conférences et action coordonnée

A vue de l’importance des dégâts des botnets, et de leur répartition autour du globe, une action coordonnée est souvent le seul moyen de diminuer significativement l’activité d’un botnet. Le sujet a également pris suffisamment d’ampleur et d’importance que des conférences sont dédiées à ce problème, telle que la BotConf qui existe depuis 2013.

Voir aussi

Articles connexes

Liens externes

Clé SSH

Une clé SSH est en réalité une bi-clé (un couple clé publique et clé privée) permettant de renforcer la sécurité d’une connexion utilisant le protocole SSH (à condition bien sûr de respecter quelques règles de base).

L’idée de base est qu’on chiffre la connexion à l’aide de la bi-clé, la clé publique étant sur la machine cible, la clé privée étant chez l’utilisateur (ou la machine source éventuellement).

Principe

L’idée de ce type d’authentification est de ne pas faire circuler de secret directement pour l’établissement de la connexion (tel que le couple utilisateur/mot de passe). Ainsi, le mot de passe ne peut pas être intercepté lors de la communication !

Nous utiliserons donc une bi-clé. Pour se connecter sur un serveur (machine 2) avec une identité donnée, il faut (il suffit) d’associer la clé publique à l’identité voulue sur le serveur, et de prouver qu’on est en possession de la clé privée correspondante.

Pour établir la connexion, les deux machines qui parlent ensemble (la machine 1 de l’utilisateur, et la machine 2 où l’on souhaite se connecter de façon sécurisée) vont s’envoyer des messages chiffrés grâce à cette bi-clé. Toute la subtilité revient dans le mécanisme d’échange sécurisé entre les deux machines,

Pour envoyer des éléments chiffrés lors de l’échange, l’utilisateur sur la machine 1 doit donc utiliser sa clé privée, qu’il vaut mieux bien sûr protéger par une passphrase (il faut qu’elle soit protégée en accès afin que tout le monde ne puisse pas lire cette clé). La capacité que l’on a d’utiliser cette clé privée permet donc de prouver qu’on est bien l’utilisateur correspondant à la clé publique, ce qui assure l’accès à la machine 2, avec l’identité à laquelle on a associée la clé publique.

En pratique

Création de la bi-clé

La première étape est de construire la bi-clé, et différents outils le permettent.

ssh-keygen

Tout en ligne de commande. Il y a tout de même une astuce si vous souhaitez ensuite vous connecter à partir de PuTTY sous Windows (cf ci-dessous).

PuTTYgen

Très pratique sous Windows.

Installation de la clé publique

La clé publique doit être positionnée dans un fichier spécial, spécifique à l’identité demandée sur le serveur cible. Si vous souhaitez utiliser le mode de connexion par clé SSH pour l’utilisateur root, il faudra donc installer la clé publique dans le répertoire utilisateur de root (qui est en général /root). Si vous souhaitez utiliser une clé pour un utilisateur user, il faudra installer la clé publique dans le répertoire de l’utilisateur user (qui est en général de la forme /home/user).

Une fois dans le répertoire de l’utilisateur voulu sur la machine cible, il faut aller dans le répertoire .ssh puis modifier le fichier authorized_key (il peut y avoir des variantes, selon les configurations).

machine2$ vi /home/user/.ssh/authorized_key

Ce fichier contient les clés publiques autorisées pour cet utilisateur, au format ssh-rsa (ou ssh-dsa). Par exemple :

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAjMMXnPG6n5j39K924xSAdsxQ6KD0QS55sdw+
s/AB+EkfNJ4l5rWAesm1KhyjsTTb399lOAhDr26qmHt4Zt8yXZzfuwWA+MQI6QL0
PwR2gL6B9F7ogJtqqTmPiXTXu8fTLvzFYW+1VejHfSNBEBuE0Td5R4LjEXcmxorf
vrODeIzQaz5wk2anXaCjRVBiiPi69l4n8YCHyqVPcuiHBxRxAfQMjLpo2RYL6ofb
ZzaxHnQfvfs0h+YntFXDTVL3sMuU8zhyGrGdfI9MpYymDb8Y3hd/4MAUhUrgtg57
88Pbp/xfX79b+qB4QRjnvNLTLi4biPKqU1pbYlvkuhx/aO36qQ==

Installation et utilisation de la clé privée

Connexion sous Linux

La connexion se fait en ajoutant quelques paramètres à la commande ssh.

Connexion sous Windows

PuTTy fait sous Windows un petit caprice au sens où il va demander un format particulier pour la clé privée.

Sources

Voir également

Clé de chiffrement

Une clé de chiffrement est le code secret permettant de chiffrer ou déchiffrer un message codé. Il existe des clés symétriques et asymétriques, qui ont chacune leurs propriétés et leur utilité.

Clé symétrique

Une clé est dite symétrique quand la même clé permet de chiffrer et de déchiffrer un message. On parle aussi d’algorithme symétrique pour un algorithme utilisant des clés symétriques.

Un des principaux inconvénients est la difficulté de transmission de cette clé, car il faut s’assurer que les deux parties s’échangeant un message chiffré par cette clé soient bien les seules à la connaître. Cette clé doit restée privée pour que le secret soit conservé.

L’avantage pratique principal de ce type de clé (et de ce type de chiffrement) est qu’informatiquement, le chiffrement ou déchiffrement à partir d’un algorithme symétrique est très rapide, surtout en comparaison des clés asymétriques.

Clé asymétrique

Le principe est que la clé servant à chiffrer et à déchiffrer sont différentes. L’utilisation de ce type de clé a permis une avancée considérable en cryptographie, car on peut ainsi chiffrer et déchiffrer des messages sans avoir à communiquer de clé privée. L’utilisation de certificats repose sur l’usage de telles clés, tout comme la connexion SSH par clé.

Le principal inconvénient est la lenteur des calculs nécessaires à ce type de chiffrement. Ainsi, lorsqu’on a de longs messages à échanger, on utilise en pratique une clé symétrique ad hoc échangée entre les deux parties par un mécanisme asymétrique.

Voir aussi

Echange de clé

Echange de clé

Un des points majeurs en cryptographie est l’échange des clés : un algorithme de chiffrement peut être le meilleur du monde, s’il est facile de connaître les clés utilisées par chacune des parties lors du chiffrement, il n’y a plus aucun secret dans l’échange !

Diffie Hellman Merkle

Cet algorithme permet à deux parties d’échanger (ou plus précisément de construire) une clé symétrique secrète commune. Il existe une variante basée sur les courbes elliptiques.

Appareils mobiles

Que vous soyez geek ou pas, la technologie fait partie de votre quotidien. Avec l’essor des smartphones hier et des tablettes aujourd’hui, les risques liés à la mobilité sont désormais un enjeu majeur de la sécurité des systèmes d’information.

Cette tendance est renforcée par l’arrivée en entreprise des terminaux personnels : il est en effet très tentant de synchroniser son smartphone, consulter son agenda sur sa tablette ou connecter sa clé USB sur son PC professionnel. Or ces équipements personnels, non maîtrisés par l’entreprise, peuvent induire un risque de compromission du SI ou de fuite d’information, parfois à l’insu de l’utilisateur.

Domaine personnel

Je sais tout de vous

Ce risque est indirectement lié à votre usage : vous laissez des tonnes d’informations sur vous et sur ce que vous faites en utilisant votre smartphone. Vous en laissez non seulement quand vous activez les options de géolocalisation, mais aussi en laissant d’autres types de données remonter vers l’opérateur, le fournisseur du système d’exploitation ou les éditeurs de logiciels.

Google peut par exemple vous localiser sans que vous donniez votre consentement pour la géolocalisation : pour cela, il utilise d’autres données telles que votre activité sur le web1. Certains petits malins sont également des spécialistes pour brouiller les pistes et forcer certains réglages par défaut en les noyant dans la masse2 (NB : il n’y a aucune contrepèterie dans cette phrase). Facebook en a fait sa spécialité.

Milieu professionnel

Quels sont les risques ?

Ces terminaux personnels sont le plus souvent non maîtrisés par l’entreprise, et deviennent de fait un nouveau facteur de risque et notamment de fuite d’informations, si l’entreprise n’a pas mis des mesures de protection adaptées à cette usage. Si les agents logiciels de protection et les antivirus sont entrés dans les mœurs pour ce qui est des ordinateurs fixes, la plupart des utilisateurs de Smartphones n’ont pas conscience de la nécessité de se protéger sur un appareil mobile.

Pourtant, comme tout dispositif informatique, les appareils mobiles sont vulnérables aux programmes malveillants (vers, virus, troyens…). De nombreux analystes pensent qu’avec l’usage accru de ces terminaux mobiles, cette menace va s’accentuer3, et le risque de compromission du SI devient alors réel si ces appareils lui sont connectés ou si des données confidentielles de l’entreprise sont accessibles. Les données personnelles ou l’usage du mobile sont également des cibles soit de ransomwares4 soit de siphonage (comme par exemple les informations de connexion aux sites bancaires).

De plus, par leur nature même, les Smartphones, tablettes, PC Portables et clés USB sont plus exposés au risque de vol, ou tout simplement de perte. Le risque de fuite d’information devient alors considérable s’il n’existe pas de dispositif de chiffrement des données, ou d’effacement et/ou blocage à distance des appareils perdus ou volés.

Et le BYOD ?

Il existe certains cas d’usage de Bring Your Own Device (ou BYOD, qui est l’utilisation par le collaborateur de son terminal mobile personnel en tant qu’outil professionnel) au sein de son entreprise. L’utilisateur dispose donc d’un appareil personnel mais qui est souvent maîtrisé par l’entreprise (pour la partie « usage professionnel »). A DEVELOPPER

Des exemples de menaces déjà existantes

Trend estime que 25% des programmes malveillants sur mobile (en 2012) ont pour objet de dérober des données personnelles ou confidentielles, allant du carnet d’adresses jusqu’aux SMS reçus (comme par exemple les codes de confirmation pour certaines transactions bancaires) ! Zeus, un troyen très dangereux et très répandu sur Windows,  possède déjà des variantes pour BlackBerry5 et Android. Et les futures attaques ne manqueront pas d’exploiter les technologies embarquées sur ces matériels (GPS, caméra, NFC…) ! OBSOLETE

Quelle réponse ?

xxx

Voir aussi