L'Organisation européenne pour la recherche nucléaire fait le point sur sa « campagne annuelle sur les risques en matière de cybersécurité et les dangers liés aux courriels non sollicités (sophistiqués ou non) ». Les résultats sont inquiétants.
Le 1er août, le CERN a ainsi envoyé 22 731 emails à son personnel, avec comme expéditeur une adresse en @cern.ch, que l’on peut facilement usurper pour rappel. « Ils contenaient tous un message paraissant important (« nouvelle facture émise par + 41792231242 », « mise à jour de votre facture », « abonnement Office 365™ », « contrat signé », « action requise » ou « rapport COVID-19 2022 ») ».
« Les messages vous incitaient à cliquer sur un lien qui vous redirigeait vers une page de connexion prête à recevoir votre nom d'utilisateur. Puis, si vous transmettiez cette première information, il vous était demandé d'insérer votre mot de passe du CERN... Et là, c'est le drame ».
C’est l’occasion de rappeler un principe de base en cybersécurité : toujours réfléchir avant de cliquer et/ou d’ouvrir des pièces jointes. « C'est triste à dire, la pêche a été bonne », explique le CERN : « Plus de 1 800 personnes ont cliqué sur le lien, sont tombées dans le piège et ont inséré leur nom d'utilisateur, ainsi que leur mot de passe, dans la fausse page d'authentification unique ».
Rien de neuf sous le Soleil, si ce n’est l’étendue des dégâts potentiels. Cette histoire ne concerne pas que le CERN, mais tout le monde avec une adresse email. 8 % des personnes sont tombées dans le panneau, c’est énorme et c’est la preuve que cela n’arrive pas qu’aux autres.
Commentaires (46)
#1
Yep, facile, même moi j’y arrive …
Ça laissait un peu de traces dans les headers du mail, et ça finissait très souvent en spam. Mais ça passait quand même.
Ça a commencé par le forward de mes mails Google pro vers mon serveur perso, pour pouvoir utiliser Thunderbird. Au passage, j’admets le “OK, boomer”, mais à au moins une occasion, Thunderbird m’a retrouvé un mail que l’interface Web de Google était incapable de me ressortir.
Bref, au bout d’un moment, l’envie de pouvoir aussi envoyer des mails pro avec mon Thunderbird et mon serveur perso a fait son chemin.
Et puis le déclic, un truc tout con, un ajout tout simple dans le main.cf de mon postfix.
Et là, c’est le drame …
#1.1
Ok, et avec le décodeur, ça donne quoi ? Entre le “OK boomer” et l’ajout dans main. cf…..ben rien compris !
#1.2
Bah sans entrer dans les détails :
Avec ça, on peut faire partir de chez soi des mails qui semblent officiels.
Évidemment, ça ne passe pas comme une lettre à la poste (ah ah !), et ça arrive très souvent dans les spams du destinataire. Il reste aussi des traces de la véritable origine dans les headers du mail.
Mais si le destinataire vérifie ses spams régulièrement et qu’il se dit “tient, bizarre, le mail de mon collègue est arrivé dans les spams ? Hop, non, c’est pas un spam”, bah voilà, l’embrouille peut passer.
Le jour où j’ai découvert ça, j’ai fait flipper un gars de l’info de ma boite en lui envoyant des mails en provenance de lui-même. Il a eu un bon réflexe, il a changé son mot passe. Ce qui, en l’occurrence, ne servait à rien … Bien entendu, une fois que je leur ai expliqué le pourquoi du comment (j’ai un chapeau blanc !), il … Ne s’est rien passé du tout …
C’est seulement les années suivantes que se sont généralisés les SPF, DKIM, DMARC et cie, ce qui a rendu l’entourloupe beaucoup plus facilement visible.
#1.3
Merci ! C’est beaucoup mieux ! J’avais bien pensé que c’était quelque chose dans le genre mais là maintenant c’est “crystal clear” avec les détails qui vont bien !
Bon week-end !
#2
Surprenant, de la part du CERN, de partager publiquement ce type de contenu (exercice + réflexes) avec autant de detail. Un veritable attaquant n’en demanderait pas plus. Par ailleurs, le 2FA est présenté comme une solution miracle ce qui peut désormais être considéré comme abusif.
#2.1
Tu peux détailler stp ? Sur le côté abusif du 2FA.
#2.2
Dans la mesure où c’est un type d’exercice particulièrement banal dans les grosses boîtes, je doute que la procédure soit inconnue des pirates un minimum “sérieux”.
Et si expliquer le protocole du test permet de sensibiliser quelques personnes de plus aux risques, ça sera gagnant pour tout le monde.
#2.3
Au contraire, ça dit aux attaquants : on a fait l’exercice, nos personnels se sont faits avoir une fois, ils ne se feront plus avoir la deuxième fois.
Moi aussi au boulot j’ai régulièrement ce genre d’exercice, parfois assez grossier, parfois particulièrement vicieux avec un scénario qui utilise un nom de domaine spécialement acheté pour l’occasion, et toujours un compte-rendu donné aux utilisateurs après coup.
#3
Les mécanismes DMARC et SPF sont bien présents sur le domaine @cern.ch (voir le résultat de
dig TXT cern.ch). Il me semble donc a minima imprécis de dire que l’usurpation est facile, sauf peut-être à considérer que la majorité des serveurs de réception des e-mails ne fassent pas correctement cette vérification.#3.1
(Erratum : il n’y a pas d’enregistrement DMARC, mais seulement SPF. Ce qui est néanmoins suffisant pour empêcher l’usurpation simple du nom de domaine)
#3.2
Manque dkim dans ce cas, spf seul ne suffit pas
#3.3
ils ont l’air d’avoir raté leur SPF , car moi j’ai ça en retour
v=spf1 include:spf.cern.ch ?all
un -all serait pas mieux ?
je suis dubitatif sur ?all et encore plus sur spf.cern.ch au lieu de cern.ch ( bon à voir les serveur )
avec DMARC DKIM SPF , je vois pas comment on peut usurper l’envoi de cern.ch sans être directement SUR le serveur du CERN.
Donc leur tests me laisse perplexe ou .. ils ont foiré le paramétrage du serveur mail
#4
C’est dire que “2FA est un miracle” qui est abusif, pas son usage.
Il y a des attaques pour contourner le 2FA https://www.nextinpact.com/article/49316/hameconnage-plus-en-plus-sites-sattaquent-aussi-a-double-authentification
#5
Je me fais vieux, fini le temps des princes nigériens, des britney nude, enlarge your finger, place aux “alertes Covid”, “vous avez un colis”, “on vous dois des sous”
#6
Sur une boite perso tu peux toujours en recevoir, mais pour les pros ça s’est modernisé oui. D’ailleurs, mêmes pour les particuliers on est plus dans le bon cadeau (SFR, Lidl & co) désormais.
#7
C’est une catastrophe. Non pas que les gens aient cliqués/entrés des infos.
C’est une catastrophe qu’une structure comme le CERN n’ai pas activé et n’applique pas les bases de la protection email/usurpation. Comme évoqué, les protocoles SPF, DKIM et DMARC en particulier permettent de lutter contre le “spoofing” ou usurpation de nom de domaine (voir ca comme l’adresse de l’expéditeur sur un courrier recommandé, c’est purement déclaratif et non vérifié).
Sauf que… sur internet, il est possible en tant qu’organisation “d’imposer” au destinataire (antispam, système de messagerie tel Microsoft, Google, etc.) de vérifier que l’expéditeur est bien qui il prétend être. C’est simple, c’est gratuit, ca exite depuis + de 10 ans. C’est dans tous les guides de secu/configs de la terre (guide de l’anssi paragraphe 5.4 même…). Bref. Avec l’analogie du courrier, c’est comme si le CERN pouvait indiquer dans l’annuaire des pages jaunes que tous ses emails/courriers légitimes ne partaient QUE depuis telle ou telle adresse postale d’origine (le fameux tampon de la poste source). Par exemple, ils disent “on enverra nos courriers légitimes QUE depuis le bureau de poste numéro 451 de Lausanne”. Donc si vous recevez une courrier qui prétend venir de nous, mais que le tampon n’est pas celui là, supprimez le courrier.
Idem avec SPF et DMARC, on indique les IP sourcent des serveurs “legitimes” qu’on utilisent, et on peut ainsi aider les destinataires à savoir si ca vient de chez nous ou pas. Or, la le CERN a explicitement désactivé ces protocoles ! C’est meme pas un oubli, cest une desactivation explicite. C’est comme mettre un douanier et qu’il porte une pancarte “tout le monde peut passer, je ferme les yeux” (la directive ?all dans l’entrée SPF ici).
Bref, ca me rend fou ce niveau d’incompétences. Y’a aucune excuse valable en 2022 pour cela. Ils mettent à risque tout l’écosysteme à ne pas monter d’un cran leurs configs. Car n’importe qui peut se faire passer pour le CERN facilement. Ca peut pieger leurs salariés, fournisseurs, partenaires, etc.
Si besoin, on a dév dans ma société un testeur gratuit (et francais) pour checker facilement vos domaines pour leurs configurations SPF, DKIM, DMARC etc.
Ici avec le cern : https://check.merox.io/?domain=cern.ch
#7.1
Ouh là, prends un Valium et relis la news. Là il s’agissait d’un exercice, donc l’expéditeur était réellement du CERN. C’est NXI qui a ajouté qu’on pouvait facilement l’usurper.
#7.2
Tu peux mettre toutes les sécurités en place que tu veux, mais si les utilisateurs ne sont pas sensibilisés, il y aura toujours un moment donné une personne pour ouvrir une pièce jointe qui ne devrait pas être ouverte (ou lien pourri, au choix). Cette campagne montre tout de même le manque de formation face à ce danger.
Des entreprises (mais pas que) sensibilisent les gens avec des campagnes de faux/vrai mails de pishing. Si la personne ouvre la PJ ou le lien, on lui explique le pourquoi il ne faut pas et comment la personne aurait pu détecter le pishing.
#7.3
Et généralement on te répond: mais vous avez que ça à faire nous piégez, j’ai pas le temps de jouer à vos jeux stupide, j’ai beaucoup de travail.
Et chez nous, on a très souvent (voire tout le temps) les même 10 personnes qui cliquent sur un lien, et donnent leur email / pwd et qui sont super énervés quand on leur dit que c’était un test
Mais ce n’est largement pas la majorité, c’est déjà rassurant.
C’est pour cela que en plus de la sensibilisation, il faut aussi mettre toute la sécurité nécessaire côté infra, et la ce n’est clairement pas le cas au CERN.
#7.4
Merci pour le lien, je le met précieusement de côté !
Quand je regarde pour
https://check.merox.io/?domain=numericable.fr
https://check.merox.io/?domain=orange.fr
https://check.merox.io/?domain=free.fr
c’est pas brillant du tout…je comprend mieux les pourriels de NC…
#7.5
je suis aussi de ton avis …
mais comme dit leur tests .. enfin je l’espère ( même si le SPF me semble cassé , et le DMARC n’existe pas ) que ces derniers ont été fait directement via leur serveur mail et en interne .
#7.6
Si c’est si facile, pourquoi les faux mails de gafam et autres grosses boites passent si souvent ?
Le nombre de faux mails Amazon/Google/Netflix/banque ou bien même l’état français …
Les spams j’en reçois sur tous mes mails (google / mail fai / hotmail / yahoo), ya toujours un organisme que tu penses de confiance qui finit par vendre ton mail.
Ya vraiment une fois où j’ai pris 15 minutes à identifier un spam, le truc paraissait légit mais jamais cliquer/répondu.
#8
Pour le SPF, DKIM et DMARC, ce qui est dommage, c’est que les plus gros client e-mail n’affiche pas ces informations (souvent contenues dans les headers) sous la forme de badge (comme les cadenas du HTTPS), cela permettra d’avoir un visuel simple pour identifier des potentiels e-mails problématique et de sensibiliser les utilisateurs aussi.
#9
Ces derniers temps le prince nigérian ça a été remplacé par des riches héritiers ukrainiens… J’en ai vu passer quelques uns comme ça…
#10
Tout à fait d’accord avec @zongap et @manus.
Ces mécanismes (SPF, DKIM, et DMARC) existent depuis des lustres, ça a mis beaucoup de temps à se mettre en place surtout par négligence de la part des acteurs les plus concernés (FAI fournissant des services de messagerie : Orange, Free, SFR, Bouygues, …).
Aujourd’hui ça va mieux même si ce n’est pas encore parfait.
Il est inadmissible qu’une organisation comme le CERN néglige cet aspect de sécurité incontournable, surtout vu leurs activités un brin sensibles (du pain béni pour les hackers de tous poils).
Concernant l’exercice décrit dans l’article, on voit très bien que le problème n’est ni technique, ni situé entre le clavier et la chaise. La seule solution est de sensibiliser au maximum les utilisateurs, à la fois par l’éducation et la communication en leur donnant les clés pour qu’ils puissent s’assurer par eux-mêmes de la légitimité des contenus qu’ils reçoivent.
Quand un utilisateur me demande mon avis sur un mail bizarre qu’il a reçu, je lui réponds simplement que son soupçon est toujours fondé dans 99,9% des cas. Il n’est pas plus bête qu’un autre, si ça lui semble suspect c’est que ça l’est.
Pro-tip : Utilisez des outils de validation en ligne pour tester la configuration de vos serveurs de messagerie, comme Mail-Tester.com par exemple.
(ça y est, j’ai faim
)
#11
Et dans la vraie vie, s’ils ont un mail [email protected] ils doivent faire quoi ? Ne pas l’ouvrir ?
#11.1
Dans la vraie vie, des comptes se font hacker, donc il faut effectivement se méfier d’un mail bizarre, même envoyé par une personne de confiance.
#11.2
Non, mais justement, on a des solutions pour éviter ce genre d’usurpation (SPF et compagnie, comme expliqué par plusieurs personnes), et le CERN au lieu de l’activer et de faire des campagnes de spam réalistes avec leur sécurité, désactive (volontairement ? ) le SPF pour faire une campagne de spam avec usurpation de domaine, c’est juste stupide…
En gros, on dirait que plutôt que d’éprouver leur sécurité, ils veulent juste montrer que les utilisateurs sont naïf, c’est débile…
#11.3
Mais qui a dit que le SPF était désactivé pour cern.ch ?
Il semble que le but du test était de vérifier si les utilisateurs ouvrent aveuglément un mail parce qu’il provient du domaine cern.ch, ce qui correspond à un scénario où un compte CERN se fait pirater, les hackers en profitant pour envoyer des mails de phishing “de manière légitime”.
#11.4
Il est sur ?all …
#11.5
Si tu reçois un mail qui semble louche d’un expéditeur (supérieur ou non) connu tu lui passes un coup de fil pour lui signaler & lui demander si c’est bien lui qui l’a envoyé.
Si oui, tu peux décider de la suite en fonction de la confiance que tu lui accordes
Sinon, poubelle & il faut qu’il vérifie de son côté si son compte n’est pas compromis (avec sa DSI le cas échéant)
J’ai bossé dans une organisation ou la mise en place du SPF était bloquée par le fait que trouzmille serveurs non répertoriés envoyaient des mails avec le domaine de l’entreprise. La continuité du service et l’évitement du risque de casser des choses utiles étaient jugés prioritaires devant la sécurité. Je ne serais pas étonné que le CERN soit dans le même cas.
On peut le déplorer, mais c’est loin d’être une exception. Les choses changent un peu quand l’entreprise se prend un bonne baffe suite à un mail foireux (j’ai eu la ‘chance’ d’assister au pouvoir sensibilisateur d’un ransomware reçu en PJ, c’est assez efficace… mais pour un temps limité seulement).
Le legacy, c’est la vieL’enfer, c’est le legacy#12
Bah si tu as un mail de ton supérieur qui te dit de suivre un lien sur un site extérieur mais qui visiblement usurpe le design de ta boîte et demande login/mdp, tu dois le signaler à la DSI et ne pas rentrer ton mdp. Les comptes qui se font hacker, ça arrive (et justement c’est un peu l’objet de l’article).
#13
La pêche est bonne car la quasi totalité des entreprises n’est toujours pas en SSO. Pour l’utilisateur, il n’est donc pas anormal de devoir rentrer son user/mdp dans des interfaces disparates pour accéder à du contenu.
Ce qui est triste, c’est de demander à l’employé de fournir l’effort de vérification de la légitimité des interfaces des saisie user/mdp.
Et ce qui est encore plus triste, c’est de s’apercevoir que les entreprises qui ont tout centralisé dans un cloud microsoft n’ont pas ce problème. Et que ca va donc devenir la solution de facilité.
#14
Il est effectivement présent, mais leur enregistrement SPF se termine en ?all… ce qui revient plus ou moins à désactiver il me semble.
Bon par contre je doute qu’ils aient configuré ça comme ça juste pour leur test…
#15
Si ton unique action consiste en l’ouverture du mail mais qu’il y a une faille 0 day d’exchange qui est en tort ? Le SI qui a laissé passer un mail [email protected] ou l’utilisateur qui a ouvert le mail parce qu’il venait de cern.ch ?
#16
Alors pour ces 10 personnes, je m’excuses mais soit elles ne veulent rien comprendre ou soit elles s’en foutent royalement et là on ne peux rien y faire…
Pour le CERN, je ne jugerais pas car je ne suis clairement pas assez compétent dans ce sujet.
#17
Voyons le résultat avec un peu d’optimisme : plus de 92 % ne sont pas tombés dans le piège. Je trouve au contraire que c’est un beau résultat. Ok, ça fait 1800 parce qu’ils sont nombreux et ça suffit pour avoir des dégâts mais c’est plutôt bien je trouve.
#18
Evidemment, il faut aussi sensibliser et faire du training, mais dans ce cas précis, tu ne peux “pas” sensibiliser efficacement un utilisateur, si l’expediteur de sa propre entité est justement parfaitement usurpé (ca affichera reelement l’email de leur collegue/superieur/etc. dans le champ expediteur). Il faut avancer sur les deux tableaux. Mais la ca leur prend 10mn à corriger quand même…
#19
Dans le cas ou tu as un comptes compromis en interne, tu ne peux “que” sensibliser, et mettre des process, etc. Mais le soucis, cest que le CERN fait parti des derniers % d’organisation avec un niveau en cyber très bas sur ces parties là, cas ils n’appliquent pas les normes/standards en place pour commencer. C’est evidemment toujours mieux si l’utilisateur arrive à se rendre compte de la tromperie. Mais sans même s’appliquer les bases à eux même, le cern met tout le monde à risque. Et ils se passent d’un moyen eprouvé et fiable pour bloquer le spam tel qu’il est présenté. Pour la compromission de compte, là, la seule bonne solution c’est la mfa.
#20
SPF + DMARC reject ca fait le job, mais c’est clair que DKIM reste la rolls…
Et malheureusement, meme si DMARC est un bon “protocole”, il n’est pas parfait, si SPF ou DKIM est valide, c’est ok pour DMARC (c’est un OU logique).
Autant, les serveurs sortants avec DKIM ce n’est pas encore dispo partout, mais lister ses entrées dans le SPF, ça devrait être le cas de tout le monde… On est loin d’être au chômage là dedans…
#21
Ce qui aurait était intéressant c’est d’avoir le nombre de signalement. Car ils peuvent permettent la mise en place d’une contre mesure pour bloquer le site depuis le SI j’imagine. Et du coup réduire le nombre de fuite de login/MDP.
#22
C’est une pratique courante des entreprises, et exactement avec ce types de mails. Le fait de communiquer dessus ça permet de dissuader en se disant que le fait que les employés aient été entraînés réduit les chances que ça marche.
#23
Par rapport au SPF et au ?all, c’est malheureusement une pratique qui reste courante car l’usage de -all complique beaucoup l’utilisation d’outil d’envoi de mail (pour des notifications, les campagnes de promotion, les newsletter, etc…) dès qu’on passe par un outil en ligne (Mailchimp et compagnie).
Dans un monde idéal, il faudrait modifier le SPF pour ajouter les serveurs qui vont bien. En pratique, c’est le ?all qui est mis, car cela évite de faire des demandes aux services techniques dès qu’un nouvel outil est mis en place…
#24
dans 99% des communications que je reçois, le ssignaux précurseurs d’arnaque ou d’escroquerie (appels, mails, sms) sont devinés/évalués par le contenu.
je recois un mail de microsoft.com, pour moi ca vient de microsoft, point barre.
ya deux ans je recevais un mail soit disant de pole emploi ; bourré de fautes, promouvant ue formation partenaire ; je l’envoyais à mon conseiller : “non c’est un vrai, bien que le domaine ne soit pas celui d’ordinaire”
le nom de domaine est un indicateur trompeur, normalement il ne devrait pas etre possible à usurper, de nombreuses personnes (dont moi, et je compte pas changer mes habitudes) s’y réfèrent comme principe fiable pour déterminer la crédibilité d’un expéditeur. Nombreuses arnaques sont envoyées avec des emails farfelus, type microsofft.com ou netfliix.fr, si les hackers font l’effort des fautes obligatoires c’est parce que le domaine “correct/strict” bien écrit au caractère pret est 100% digne de confiance.
je fonctionnerai pas autrement : pour moi les effectifs du CERN ont été illégitimement poussés à l’erreur au meme titre que le prof d’histoire a tendu un piège à ses élèves en 2010 en modifiant wikipédia avant de leur donner un devoir traitant du sujet qu’il avait intentionnellement erroné (vous vous souvenez de l’histoire, si..)
en conséquence, si je bossais au CERN, il est évident que le @cern.ch est 100% source de fiabilité, et se voir accusé de faiblesse informatique en termes de sécurité pour avoir répondu à un courriel de mon organisation m’aurait occasionné d’aller péter un cable auprès de la direction informatique, quitte à déposer plainte : utiliser le ndd propre de la boite pour faire croire à un mail pirate en utilisant le domaine officiel, c’est aller à l’encontre des habitudes : toujours regarder le domaine en premier quand il y a un doute ! je leur aurai collé une belle raclée… c’est presque de la conspiration.
#25
Bon…
Tiens, on a trouvé un des dix dont parlait ce post :
#26
La transparence des méthodes est la clé de voûte de la sécurité.
Ne pas comprendre ça, c’est militer pour l’obscurantisme/la dissimulation : “la sécurité par l’obscurité n’est pas de la sécurité”.
Félicitations au CERN pour annoncer sur la place publique ce qui malheureusement n’est qu’un secret de Polichinelle depuis des dizaines d’années : la pêche à l’hameçon fonctionne toujours aussi bien..
J’ajouterais : y compris auprès de populations sensibilisées. En effet, la même expérimentation au sein d’entités liées à la sécurité induirait des sueurs froides quand au réel état de “l’hygiène numérique” instinctive, puisqu’elle n’est pas enseignée (et donc inlassablement répétée).