Des attaques dressées contre vous !

Ecrit le 19/04/2018

Dans l’article précédent, nous avons pu voir quelques attaques qui pourraient être dirigées contre un serveur avec les logs HTTP que j’avais à ma disposition. Maintenant, je vais vous citer quelques attaques ─ quelques unes évidentes ─ qu’on nous tend avec plein de fantaisies.

Certaines attaques, telles que la force brute et plein d’autres failles peuvent aussi être dirigées sur un serveur. Pour illustrer la plupart des attaques, je vais utiliser les petites histoires, des images et des comparaisons.

La force brute

Cette attaque concerne surtout les mots de passe. Imaginons un instant un univers parallèle avec Alice et Carole.

Alice a une compte mail pour ses mails professionnels. Forcément, ce genre de mail peut cacher des secrets qui doivent être à tout prix hors de portée des concurrents et/ou voleurs. Justement, Carole apprend qu’une nouvelle recette secrète vient d’être trouvée et elle veut absolument la découvrir. Conaissant déjà le nom d’utilisateur d’Alice, en l’occurence alice@masuperentreprise.example, elle pourra tester plein de mots de passe en rafale.

Malheureusement pour Alice, son mot de passe est trop faible pour faire tenir face à la rafale de Carole. Éventuellement, Carole réussit à trouver le mot de passe et parvient à voler la recette top secrète.

Comment y remédier ?

Ici, la faiblesse s’est trouvée dans le mot de passe utilisé par Alice pour sécuriser sa boîte mail professionnelle. Dans ce cas, elle a deux choix possibles: changer de mot de passe vers un plus costaud et/ou activer l’authentification à deux facteurs (A2F). Le changement vers un mot de passe plus fort permet de rendre plus dure le forçage du mot de passe puisqu’il y a plus de possibilité de caractères.

Il est également fortement conseillé d’activer l’authentification à deux facteurs sur les sites qui le supporte. Le principe est que vous ne pouvez plus vous connecter directement avec un mot de passe mais avec votre mot de passe ET un numéro de 6 chiffres, changeant toutes les 30 secondes environ, que votre téléphone vous donnera par le biais d’une application. Évitez les codes F2A envoyés par SMS puisque ces derniers peuvent être attrapés au vol. Idem par email.

Le fishing ou le hammeçonnage

Si la force brute n’est pas assez brutale ou rentable car trop d’arrangements possibles, il y a une autre solution: le fishing. Là, pas besoin d’efforts et de machine surpuissante: un email qui ressemble bien au légitime, avec un formulaire qui y ressemble comme deux goûtes d’eau suffit. En effet, le but de l’opération est de pêcher les données d’un maximum de victimes qui seraient tombés dans le panneau.

Revenons à notre petite entreprise fictive avec Carole qui veut dérober les informations bancaires de l’entreprise. Bob, le comptable, reçoit un mail qui vient en apparence du fournisseur de l’entreprise. Vu le caractère urgent du contenu qui demande de payer immédiatement une somme, Bob clique sur un faux lien qui amène vers une fausse page de connexion de la banque “Ma super banque !” avec le site https://masuperbenque.example. Semblant légitime, avec le petit cadenas vert, Bob entre les informations de connexion et clique sur un bouton pour se connecter.

En réalité, Carole a envoyé un mail en se faisant passer pour le fournisseur et a inséré un faux lien qui a dirigé Bob vers une fausse page. Cette fausse page comportait un formulaire qui, une fois envoyé, a récupéré les identifiants délibérément envoyés par Bob et les a enregistrés de telle sorte que Carole puisse avoir accès au compte bancaire de l’entreprise.

Comment se protéger ?

Une erreur faite beaucoup trop de fois est de cliquer sur un lien peu importe le mail, comme l’a fait Bob. De plus, l’adresse du site de la banque comporte une petite faute d’orthographe. Cependant, elle a passé comme une lettre à la poste puisque Bob s’est fait avoir.

Ce que l’on peut tirer des erreurs de Bob, ne jamais cliquer à tout va sur les liens dans un mail est toujours une bonne idée. Le même conseil s’applique aussi pour les pièces jointes. De plus, avant de cliquer sur un lien d’un mail qui semble légitime, regardez attentivement comment celui-ci est épelé et l’orthographe du lien. Si vous avez un doute, allez sur le site manuellement, comme vous le feriez en temps normal, sans cliquer sur le lien suspect. Regardez aussi l’adresse de l’expéditeur. Il y a de bonnes chances que le mail provienne d’une personne random et non de celui qu’il prétend être. Enfin, les fautes d’orthographe figurent parmi les moult symptômes qu’un mail pour hammeçonner possède.

Le cas du cadenas vert

Dans cette situation, le cadenas vert présenté à Bob ne voulait absolument rien dire. Même avec un cadenas vert sur un site qui semble légitime, vous pouvez tout de même être victime de fishing car, de nos jours, tout le monde peut obtenir un certificat grâce à Let’s Encrypt. Attention, je ne dis pas que tous les sites sécurisés au certificat de Let’s Encrypt sont des dangers publiques; je ne fais que mentionner un cas où un petit cadenas vert ne veut rien dire.

Partout le même mot de passe

Utiliser le même mot de passe n’a jamais été une bonne idée, peu importe son utilisation. En effet, il suffit que l’attaquant parvienne à trouver le mot de passe sur un site peu sécurisé et de le tester sur le restant des services où vous êtes succeptible de vous y être inscrit·e. Retournons voir comment procède l’administrateur système de l’entreprise fictive.

Frank, administrateur système de l’entreprise, pour se simplifier la vie, met le même mot de passe surtout les serveurs où il a accès. Carole veut s’emparer de quelques fichiers sur quelques serveurs administrés par Frank. Les serveurs étant bien sécurisés, Carole ne va pas prendre le risque de déclancher des alertes chez Frank.

Par contre, elle va sur un site faiblement sécurisé où Frank est inscrit et parvient avec succès à cracker le mot de passe via une attaque par force brute. Elle va donc tester le mot de passe trouvé sur un autre site. Le mot de passe marche. Alors, elle va se connecter au serveur qu’elle veut accéder. Surprise, le mot de passe marche et le serveur tout entier se retrouve compromis car la connexion s’est faite en root ─ le dieu, sur un serveur sur GNU/Linux. Carole peut donc sauter de serveur en serveur, prendre les fichiers qui l’intéresse et se déconnecter en prenant les précautions nécessaires.

Et c’est ainsi que Carole pu télécharger des fichiers censés rester confidentiels à cause de Frank qui a eu la bonne idée de mettre le même mot de passe partout. Et pour lui apprendre les bonnes manières, elle laisse une backdoor dans un daemon ─ application en arrière plan ─ pour qu’elle revienne facilement.

Finalité de la petite histoire

N’utilisez jamais le même mot de passe partout comme l’a fait Frank. Utilisez un gestionnaire de mot de passe pour générer des mots de passes compliqués qui résisteront à une attaque par force brute. Comme ça, pas besoin de se briser le crâne à se souvenir de mots de passe tout en assurant leur unicité sur les sites que vous utilisez. J’ai posé la question sur Mastodon et j’ai eu quelques recommandations pour KeePassXC et teampass.

Cet article touche à sa faim… donc je vais lui chercher à manger. sort très loin…

Plus sérieusement, nous avons vu trois de plusieurs attaques courantes dont on peut être victime sur Internet. Il y a une panoplie d’attaques possibles, que ce soit contre des serveurs ou contre des utilisateurs. Si cet article vous a aidé à mieux vous protéger, je pourrais éventuellement écrire la suite dans un article séparé. Si vous voulez m’apporter des corrections, la boîte mail de contact est ouverte aux commentaires et aux améliorations. Si je trouve un quelque chose pertinent dans vos commentaires, je le mets en PS avec la date :D