Cybersécurité au CERN : plus de 1 800 personnes sont tombées dans le piège d’un faux email
Le 22 août 2022 à 06h42
2 min
Sciences et espace
Sciences
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.
Le 22 août 2022 à 06h42
Commentaires (46)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 22/08/2022 à 07h05
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 …
Le 22/08/2022 à 08h45
Ok, et avec le décodeur, ça donne quoi ? Entre le “OK boomer” et l’ajout dans main. cf…..ben rien compris !
Le 25/08/2022 à 19h55
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.
Le 26/08/2022 à 10h31
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 !
Le 22/08/2022 à 07h09
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.
Le 22/08/2022 à 07h21
Tu peux détailler stp ? Sur le côté abusif du 2FA.
Le 22/08/2022 à 07h47
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.
Le 22/08/2022 à 08h05
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.
Le 22/08/2022 à 08h02
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.Le 22/08/2022 à 08h41
(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)
Le 22/08/2022 à 11h17
Manque dkim dans ce cas, spf seul ne suffit pas
Le 22/08/2022 à 22h22
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
Le 22/08/2022 à 08h55
C’est dire que “2FA est un miracle” qui est abusif, pas son usage.
Il y a des attaques pour contourner le 2FA
Next INpact
Le 22/08/2022 à 09h05
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”
Le 22/08/2022 à 09h20
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.
Le 22/08/2022 à 09h25
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
Le 22/08/2022 à 09h38
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.
Le 22/08/2022 à 13h43
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.
Le 22/08/2022 à 13h52
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.
Le 22/08/2022 à 16h04
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…
Le 22/08/2022 à 22h27
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 .
Le 24/08/2022 à 13h06
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.
Le 22/08/2022 à 09h34
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.
Le 22/08/2022 à 10h05
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…
Le 22/08/2022 à 10h26
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
)
Le 22/08/2022 à 10h28
Et dans la vraie vie, s’ils ont un mail [email protected] ils doivent faire quoi ? Ne pas l’ouvrir ?
Le 22/08/2022 à 10h49
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.
Le 22/08/2022 à 11h11
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…
Le 22/08/2022 à 12h27
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”.
Le 22/08/2022 à 12h33
Il est sur ?all …
Le 23/08/2022 à 06h45
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 legacyLe 22/08/2022 à 11h24
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).
Le 22/08/2022 à 11h34
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é.
Le 22/08/2022 à 12h31
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…
Le 22/08/2022 à 14h09
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 ?
Le 22/08/2022 à 14h13
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.
Le 22/08/2022 à 14h15
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.
Le 22/08/2022 à 14h28
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…
Le 22/08/2022 à 14h32
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.
Le 22/08/2022 à 14h38
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…
Le 22/08/2022 à 15h29
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.
Le 23/08/2022 à 03h38
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.
Le 23/08/2022 à 06h48
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…
Le 24/08/2022 à 01h07
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.
Le 24/08/2022 à 06h40
Bon…
Tiens, on a trouvé un des dix dont parlait ce post :
Le 24/08/2022 à 19h26
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).