Quand le WTF rencontre le JPP

Que se passe-t-il chez Relais Colis ? La question mérite vraiment d’être posée, vu l’email reçu par certains clients. Il contient pas moins de… 10 000 adresses email d’autres personnes. Pendant ce temps, un pirate mettrait en vente un fichier avec 10 millions de données de Relais Colis.

Emailception : un email de Relais Colis, avec 10 000 adresses emails

VivaSentenza, lecteur de Next a reçu hier un email pour le moins étrange et inquiétant. Il fait en effet partie des destinataires à avoir reçu, dans le corps d’un email, une liste de 10 000 emails d’autres personnes (le contenu représente 10 000 @ et 240 315 caractères).

Le lecteur a ensuite reçu un second courrier quelques heures plus tard l’informant d’un « incident de sécurité informatique ». Il nous a fait suivre les deux emails au complet (exportation au format .eml) pour que nous les analysions.

Contacté, le service presse de Relais Colis nous confirme « avoir été alerté d’un accès frauduleux cette semaine à certaines données clients ».

Voici ce que nous apprennent les informations dans les métadonnées. L’email a été créé le 15 janvier à 12h02 (en UTC) et son sujet est « Information relative à la sécurité de vos données personnelles ». Il passe entre les mains du service de messagerie SimpleLogin (qui appartient à Proton) puis enfin dans la boite email du destinataire (Proton Mail).

Sur les réseaux sociaux, d’autres personnes ont visiblement reçu le même email (SaxX par exemple). Le destinataire n’est pas le même (l’heure diffère aussi un peu), mais la liste des emails dans le contenu du message semble être identique à chaque fois.

DKIM, DMARC et SPF : tout est ok !

Toutes les signatures DKIM, DMARC et SPF sont au vert. Les champs signés sont notamment From, Subject, To et Date.

Arc-Authentication-Results: i=1; mail.protonmail.ch;
dmarc=pass (p=quarantine dis=none) header.from=relaiscolis.com;
spf=pass smtp.mailfrom=eu-central-1.amazonses.com;
dkim=pass (1024-bit key) header.d=amazonses.com header.i=@amazonses.com […];
dkim=pass (1024-bit key) header.d=relaiscolis.com header.i=@relaiscolis.com […];

Nous vérifions au passage les serveurs autorisés à envoyer des emails au nom du domaine relaiscolis.com (via le DNS). Allons directement à la partie importante : « include:amazonses.com ». Amazonses.com est bien autorisé à envoyer des emails pour le compte de Relaiscolis.com. Dans l’email reçu par le lecteur, DKIM confirme que relaiscolis.com a bien signé l’email.

Il est donc légitime, mais nous ne savons pas comment cela a pu se produire. Piratage du compte de gestion des envois d’emails de Relais Colis ? Fausse manip’ du stagiaire ? Bug technique ? Impossible à dire pour le moment.

Relais Colis informe d’un « incident de sécurité »

Quelques heures plus tard, à 20h18, le lecteur reçoit donc un autre email de Relais Colis, intitulé « Information – Incident de sécurité affectant certaines données de contact ». L’email qui reçoit le message est utilisé uniquement pour Le Bon Coin nous précise le lecteur, alors que la communication vient de Relais Colis, mais les deux sont partenaires pour l’expédition des colis.

« Nous souhaitions vous informer qu’un incident de sécurité informatique a récemment été porté à notre connaissance et a affecté l’un de nos prestataires techniques intervenant dans le cadre de nos activités. Bien que cet incident soit désormais contenu et résolu, il a pu entraîner une atteinte limitée à la confidentialité de certaines données à caractère personnel vous concernant ».

Dans le lot, nom, prénom, adresse e-mail et numéro de téléphone. « Aucune donnée bancaire, aucun mot de passe, ni aucune information de paiement ou donnée sensible ne sont concernés par cet incident », ajoute Relais Colis. La CNIL a été notifiée, comme la loi l’y oblige.

Pas un mot par contre sur le précédent email.

Relais Colis nous confirme « un accès frauduleux cette semaine »

Nous avons contacté le transporteur en leur expliquant la situation et notamment les 10 000 emails dans le message et la signature de l’email par relaiscolis.com. Son agence de presse nous répond que, « à l’issue des premières vérifications, Relais Colis confirme avoir été alerté d’un accès frauduleux cette semaine à certaines données clients ».

La suite de la réponse est du même acabit que le second email envoyé aux clients : « Les données concernées sont des données téléphoniques et postales. Aucune donnée bancaire, aucun mot de passe ni aucune information sensible liée à la sécurité n’ont été compromis ».

« Dès l’identification de l’incident, Relais Colis a engagé les actions nécessaires et a entamé les démarches réglementaires en cours, notamment auprès de la CNIL, conformément aux obligations en vigueur. Cet incident est bien entendu regrettable et fait l’objet d’un suivi attentif visant à renforcer les dispositifs de sécurité », ajoute le service presse.

Nous avons redemandé comment un email avec 10 000 adresses emails a été envoyé à des clients, sans réponse pour l’instant.

Une base de données « relaiscolis » en vente sur Breachforum

Cette semaine, un nouveau message sur Breachforum annonçait « la vente de la base de données “relaiscolis” » avec les nom, prénom, nom de l’entreprise, adresse, téléphone et email. Le fichier contiendrait près de 10 millions de données.

Une vingtaine de comptes sont donnés en exemples avec la publication. Nous avons comparé les e-mails aux 10 000 dans l’email envoyé au lecteur : aucun ne correspond, mais cela ne permet pas d’en conclure grand-chose pour le moment.

Faut mettre des GANs

Le chargeur Ikea 20 W Power Delivery vendu 4 euros cachait une partie de son jeu. Nous l’avons démonté et découvert que le contrôleur primaire utilisait la technologie GaN, sans qu’Ikea n’en fasse la promotion. Ce démontage est aussi l’occasion de découvrir le PCB et le reste des composants.

Hier, nous avons testé le nouveau chargeur Ikea de 20 watts en Power Delivery vendu 3 euros à son lancement, et désormais proposé à 4 euros.

Les performances sont bonnes, la puissance annoncée est tenue et il ne chauffe pas trop. Curieux, nous avons décidé de voir quels composants il utilise, et si ces derniers sont à la hauteur du reste de notre analyse.

En étudiant les références des puces, nous tombons sur une (bonne) surprise concernant le module de charge. Explications.

On ouvre le chargeur (sans marteau, promis)

Première étape, ouvrir le boîtier du chargeur. À l’examiner, il n’y a qu’une seule possibilité sans tout casser : enlever le cache au niveau du port USB. Quelques coups de tournevis (c’était tentant, mais le marteau est resté sagement dans la caisse à outils), le cache saute et nous voyons l’intérieur du chargeur.

Nous découvrons un PCB chargé en composants, plus en tout cas que celui des chargeurs à quelques euros de chez AliExpress. Avec une pince, nous attrapons le PCB pour le retirer du boîtier en plastique. Il glisse facilement. Le reste de la coque est une même pièce moulée, avec des connecteurs sous la forme de petites griffes pour « attraper » le PCB et faire circuler le courant en 230 volts.

Dongke Semiconductor aux commandes, en primaire et secondaire

Yo ! Et paf 350 milliards d’opérations !

Quand on parle d’intelligence artificielle, on pense prompt, GPU, inférence, milliards de paramètres, consommation de ressources, etc. Dans ce #Nextquick, on vous explique pourquoi des centaines de milliards d’opérations sont nécessaires pour un petit Yo. C’est aussi à relativiser face à la puissance de calcul des GPU.

Nous allons parler du modèle GPT-3 d’OpenAI car nous disposons d’informations précises sur son fonctionnement. Son architecture est décrite dans cette publication sur arXiv : le modèle a 175 milliards de paramètres, il dispose de 96 couches, l’embedding d’un token est 12 288… Le quoi du quoi ?

Token et embedding en version abrégée

Sinon il y a le pare-feu d’OpenOffice

Des failles, ça peut arriver à tout le monde même en prenant un maximum de précautions. Aujourd’hui nous parlons de ce qui se passe après : la manière de réagir face à un signalement. Au lieu de vouloir faire peur et de tirer sur le messager, la bonne pratique est d’écouter, remercier, corriger. Rappelons qu’il existe un moyen d’expliquer comment contacter les équipes de manière sure et responsable.

Imaginez, vous êtes un expert en cybersécurité et vous trouvez une faille sur un site. Quatre choix (pour simplifier) s’offrent à vous.

Le premier est l’appat du gain en essayant de vendre votre découverte à des personnes malveillantes ou sur des forums. Le second est d’en profiter directement en récupérant des données, pour ensuite les revendre, les exploiter, faire chanter l’entreprise… Le troisième est de signaler de manière responsable la faille aux responsables du site.

Il est également possible de saisir l’ANSSI en tant que lanceur d’alerte « en cas de non-respect d’une disposition issue d’un cadre réglementaire en matière de sécurité des systèmes d’information susceptible de faire l’objet d’une sanction », et donc si la faille est particulièrement grave.

L’ANSSI sera « susceptible de demander au lanceur d’alerte tout élément qu’elle jugerait nécessaire à l’appréciation de l’exactitude des allégations formulées », mais s’engage à garantir la confidentialité de son identité.

50 nuances de chapeaux

Les « white hats » sont les « gentils » hackeurs avec une éthique et un sens des responsabilités ; ils ne font pas n’importe quoi et n’exploitent pas ni ne mettent en danger les données des utilisateurs. Ils sont à l’opposé des « black hats », ces « méchants » qui exploitent les vulnérabilités. On retrouve aussi des « grey hats » qui sont un peu entre les deux (ou les deux à la fois suivant les cas).

L’éthique des « white hats » ne les empêche pas de fixer des limites, par exemple lorsqu’une faille béante est découverte et que rien n’est fait malgré des signalements à répétition. L’équipe Project Zero de Google, par exemple, attend maximum 120 jours pour publier les détails d’une faille, qu’elle soit bouchée ou non. Il y a une dizaine d’années, Microsoft et Google s’étaient publiquement écharpées sur la question des délais stricts de publication avec un patch prévu le lendemain de la publication des détails de la faille.

• Microsoft fustige Google pour les détails publics d’une faille corrigée demain

Google n’est pas la seule à avoir un calendrier de publication, bon nombre de sociétés et de « hackers » font de même… Ce qui n’empêche pas les choses de parfois trainer en longueur, parfois à cause d’un flagrant manque de volonté des responsables.

C’est pour signaler une fuite… Allo… Allo ?! Allloooooooo…

Prenons un exemple : un hackeur découvre qu’il peut accéder sans authentification à une API et récupérer des données telles que des noms d’utilisateur et des mots de passe, en clair (non chiffrés, cela ne devrait pas être possible, mais passons…). Dans les données, notamment, des identifiants (en clair donc) d’un compte administrateur de la plateforme. Imaginons que ce soit une plateforme logistique, vous avez maintenant une idée des dégâts possibles.

À ce niveau, ce n’est pas une petite faille, c’est une brèche béante, de quoi rejouer le Titanic en version 2.0. Coup de chance, notre gentil hackeur du jour est un « white hat ». Il ne publie ni ne monétise sa découverte, et contacte plutôt l’entreprise comme il peut : messages LinkedIn aux responsables, messages sur les téléphones de l’entreprise… Pas de réponse, le lendemain rebelote avec en plus un message sur l’e-mail de contact indiqué par l’entreprise sur son site.