Je viens de recevoir un email comme si ça venait de chez Hyundai, bien sûr j'imagine que c'est le fishing ?

 

 

Ça semble venir du site GSW (Global Service Way) de Hyundai, le site technique dorénavant payant qui permet de télécharger des données techniques sur les véhicules Hyundai.

Au bout d'un certain temps de non connexion, le site propose systématiquement de changer son mot de passe. Et c'est bien l’e-mail "[email protected]" qui m'a envoyé un mail de confirmation à chaque fois (lien valable 24 heures).

Tu n'aurais pas tenté une connexion récemment ?

 

En règle générale il vaut toujours mieux aller directement sur le site officiel (ici) que de cliquer sur un lien dans un e-mail, mais là il s'agit de confirmer une demande de changement de mot de passe..

Modifié février 18, 20251 a par Didier_

Le 18/02/2025 à 14:31, Didier_ a dit :

il vaut toujours mieux aller directement sur le site officiel (ici) que de cliquer sur un lien dans un e-mail

Toujours  

Ce n'est pas l'adresse de l'expéditeur qui va pouvoir t'aider à déterminer si le mail est du phishing, il faut surtout regarder l'adresse web vers lequel le mail essaie de te rediriger.

Le 18/02/2025 à 17:21, KLinou a dit :

Ce n'est pas l'adresse de l'expéditeur qui va pouvoir t'aider à déterminer si le mail est du phishing, il faut surtout regarder l'adresse web vers lequel le mail essaie de te rediriger.

En l’occurrence si parce que hyundai.com a protégé sa messagerie. Ce n'est pas parfait mais si ça arrive en boite de réception, c'est que le contrôle est OK.

Le 18/02/2025 à 14:31, Didier_ a dit :

Tu n'aurais pas tenté une connexion récemment

Ahhh mais quel idiot, c'est vrai, hier j'ai ouvert cette page, en fait je cherchais le site allemand pour afficher les rappels. Je devais réinitialiser le mot de passe et l'email n'est jamais venu, en fait il est venu longtemps après, j'étais passé à autre chose.

Pfffff. Bon , il vaut mieux être méfiant que de cliquer trop vite, j'en reçois tellement.

 

Avez vous le lien du site allemand qui affiche les rappels ? Je ne le trouve plus.

 

Merci

 

 

Ah ah, j'étais en train d'écrire un post sur ce sujet (SPF and co).

 

Je ne serai pas si catégorique.
Hyundai a intégré O365 dans le SPF, ce qui peut poser soucis (been there, done that).

Aussi le SPF de hyundai.com est non valide strict (trop long).

 

Quant au "le contrôle est OK", c'est OK pour autant qu'il soit fait.
Si si, il reste des gens qui n'ont pas implémenté SPF et/ou DKIM (sans DKIM le spoofing entre domaines O365 c'est open bar).

 

Il y a aussi un soucis possible avec la lecture des mails sur mobile (et/ou certains webmails), l'expéditeur réel pouvant ne pas être affiché.

Modifié février 18, 20251 a par Klug

Le 18/02/2025 à 17:37, Klug a dit :

 l'expéditeur réel pouvant ne pas être affiché.

Mais son IP ou domaine doit être intégré dans le SPF justement. Le ~all fait que ce qui n'est pas conforme fini en SPAM au lieu d'une destruction complète (-all).

Non.

 

Tu peux envoyer un mail depuis "[email protected]" <[email protected]>  et si ton client de messagerie est aux fraises (en particulier sur les mobiles mais pas que), il va afficher le displayName uniquement et pas le champ complet (displayName + adresse mail).

 

Dans mon exemple, le displayName est [email protected], on peut donc penser que c'est un mail légitime : on ne verra pas [email protected] (qui est le vrai expéditeur) sauf à aller loin dans les options (dans le screenshot, il n'y a pas de displayName affiché - est-ce la configuration du client mail ou est-il absent du mail d'origine ?).

 

Le SPF/DKIM/whatever qui sera testé par le serveur de réception sera celui de truc.com, qui sera valide (*), donc le mail passera.

 

(*) parce que l'expérience montre que le compte [email protected] (qui envoie le mail pour de vrai) aura lui même été phishé un peu plus tôt et utilisé pour envoyer la campagne de spam/phishing suivante...

Modifié février 18, 20251 a par Klug
Mise en forme

ok c'est tordu mais ca passe selon le client !

Le 18/02/2025 à 14:31, Didier_ a dit :

il vaut toujours mieux aller directement sur le site officiel (ici) que de cliquer sur un lien dans un e-mail

Le 18/02/2025 à 15:32, Électrochoqué a dit :

Toujours  

 

Sauf que dans le cas présent, il s'agit d'un mail avec un lien à suivre pour confirmer la demande de changement de mot de passe initié par un membre qui fournit une adresse mail valide. Utiliser le lien directe vers le site ne permettra pas la réinitialisation du MdP.

 

Le 18/02/2025 à 17:21, KLinou a dit :

Ce n'est pas l'adresse de l'expéditeur qui va pouvoir t'aider à déterminer si le mail est du phishing, il faut surtout regarder l'adresse web vers lequel le mail essaie de te rediriger.

 Oui, j'aurais dû le préciser, l'adresse web vers lequel pointait le lien fourni dans le mail que j'avais reçu reçu était bien "https://service.hyundai-motor.com/euro5/requestPwd.action?xxxxxxx'

 

Le 18/02/2025 à 17:32, okidok a dit :

Ahhh mais quel idiot, c'est vrai, hier j'ai ouvert cette page, en fait je cherchais le site allemand pour afficher les rappels. Je devais réinitialiser le mot de passe et l'email n'est jamais venu, en fait il est venu longtemps après, j'étais passé à autre chose.

Pfffff. Bon , il vaut mieux être méfiant que de cliquer trop vite, j'en reçois tellement.

Avez vous le lien du site allemand qui affiche les rappels ? Je ne le trouve plus.

Merci

 

 

Problème résolu, c'est ce qui compte.👍

GSW met en effet pas mal de temps à envoyer le mail de confirmation de changement de MdP.

 

L'adresse du site allemand pour les rappels ici.

 

Modifié février 18, 20251 a par Didier_

Le 18/02/2025 à 19:03, sim_v a dit :

ok c'est tordu mais ca passe selon le client !

Tordu mais tout à fait réaliste. Par exemple, sur mon PC, mon opérateur Internet me présente la vraie adresse (au format <...>) derrière l'adresse "publique", mais si par exemple tu consultes une boite aux lettres gmail sur ton smartphone, il faudra chercher un peu pour trouver cette vraie adresse....

Le 18/02/2025 à 17:21, KLinou a dit :

Ce n'est pas l'adresse de l'expéditeur qui va pouvoir t'aider à déterminer si le mail est du phishing, il faut surtout regarder l'adresse web vers lequel le mail essaie de te rediriger.

Pas forcément mais c’est quand même une indication que l’e-mail pue, Toute campagne d’awareness pour utilisateur lambda fera vérifier le from

 

en effet toujours en 2025, même si c’est assez simpliste il y a des millions d’admin qui n’ont pas implémenté SPF, honte à eux, la RFC même si expérimentale date de 2006 quand même !

 

Pour le mail O365 (et autre gros provider)

en effet utiliser le TXT record de Microsoft ne garantie aucune sécurité car il est très facile de spoofer un email en utilisant un autre mail server qui est autorisé dans le SPF.

 

DKIM et DMARC sont indispensables pour éviter le spoofing plus d’autres protections complémentaires dans O365 comme les « domain spoofing prevention rules »

 

Pour compléter ce que disait @Klug

SPF valide le champ envelope-from (la commande mail from au niveau protocole SMTP qui est envoyée juste avant la commande DATA.) Le champ from que l’on voit sur un client mail c’est un autre champ qui lui  est généré après la commande DATA. Les spammers spoof habituellement le champ from pas le enveloppe-from, c’est pour cela que SPF ne fait rien à ce niveau-là.

Modifié février 18, 20251 a par bi_weiss

"SPF is broken by design" - http://www.open-spf.org/FAQ/Forwarding/

SPF casse le principe du forward.

 

 

SPF n'aurait _*jamais*_ dû être validé/déployé sans les outils nécessaires et utilisables pour gérer les forwards.

Le SRS existe mais ses implémentations sont incomplètes (postsrsd en particulier qui ne fonctionne qu'en mono domaine alors que postfix est le MTA le plus utilisé).

 

DKIM ne sert qu'à valider que le mail n'a pas été modifié pendant le transport.
Si je reprends mon exemple, le mail envoyé depuis [email protected] sera signé avec un sélecteur DKIM de truc.com et passera les tests DKIM. Et DMARC.

Modifié février 19, 20251 a par Klug

SPF.  DKIM.  DMARC

 

C'est du chinois pour moi, vous êtes dans l'informatique je suppose ?

Modifié février 19, 20251 a par okidok

L'informatique

 

Tout cela étant dit, ta réaction (poser la question en cas de doute sur un mail) est la bonne.

Modifié février 19, 20251 a par Klug

Le 19/02/2025 à 08:54, Klug a dit :

"SPF is broken by design" - http://www.open-spf.org/FAQ/Forwarding/

SPF casse le principe du forward.

 

 

SPF n'aurait _*jamais*_ dû être validé/déployé sans les outils nécessaires et utilisables pour gérer les forwards.

Le SRS existe mais ses implémentations sont incomplètes (postsrsd en particulier qui ne fonctionne qu'en mono domaine alors que postfix est le MTA le plus utilisé).

 

DKIM ne sert qu'à valider que le mail n'a pas été modifié pendant le transport.
Si je reprends mon exemple, le mail envoyé depuis [email protected] sera signé avec un sélecteur DKIM de truc.com et passera les tests DKIM. Et DMARC.

Pas tout à fait correct, si le domain alignement est configuré avec DMARC (tags aspf et adkim du DMARC record) le domain du from adresse devra correspondre exactement au domaine validé par SPF et/ou DKIM, qui se base sur le from enveloppe, on peut aussi autoriser pour des sous domaines .Du coup avec une DMARC policy configurée en reject, les mails qui sont une tentative de spoofing ne seront pas acceptés par le MTA qui reçoit 

Modifié février 19, 20251 a par bi_weiss

Le 19/02/2025 à 12:37, okidok a dit :

SPF.  DKIM.  DMARC

 

C'est du chinois pour moi, vous êtes dans l'information je suppose ?

Oui et même un peu plus que l’informatique dans la cyber sécurité 

Le 19/02/2025 à 13:33, bi_weiss a dit :

Pas tout à fait correct, si le domain alignement est configuré avec DMARC (tags aspf et adkim du DMARC record) le domain du from adresse devra correspondre exactement au domaine validé par SPF et/ou DKIM, qui se base sur le from enveloppe, on peut aussi autoriser pour des sous domaines .Du coup avec une DMARC policy configurée en reject, les mails qui sont une tentative de spoofing ne seront pas acceptés par le MTA qui reçoit 

S'il y a un enregistrement DMARC et qu'il ne sert pas juste à faire joli (et passer les tests "il faut un DMARC").

 

Il a fallu plusieurs années pour voir apparaître des enregistrements SPF (tous les domaines ne les ont pas, tous les serveurs ne les gèrent pas).
DKIM, j'ai l'impression que ça va plus vite (avec une mise en place incomplète chez plein de gens qui ne gèrent que leur serveur principal et pas les serveurs/sites autour).

DMARC, c'est la cerise sur le gâteau et on n'y est pas encore (sauf chez les gros ou tendus), je ne parle même pas de la non-lecture des rapports...

 

Mais oui, sur un domaine _bien_ configuré, oui, tu as raison.