Extension du domaine de la lutte

Le domaine t.me, utilisé par la messagerie Telegram, a été placé pendant plusieurs heures en pause par le registre chargé de l’extension nationale du Monténégro. L’incident, qui a handicapé les échanges et les partages de fichiers pendant plusieurs heures, découle d’une sanction prise par les États-Unis à l’encontre de First VPN, pourtant démantelé quelques semaines plus tôt.

Un domaine vous manque et tout est dépeuplé. Entre lundi 13 et mardi 14 juillet, les utilisateurs de la messagerie Telegram ont constaté des dysfonctionnements au niveau des liens courts, utilisés soit pour renvoyer vers des canaux internes à la messagerie, soit pour pointer vers des ressources externes (des images par exemple).

t.me passé en serverHold

Les soupçons se sont rapidement portés vers le nom de domaine t.me, utilisé par Telegram comme raccourcisseur d’URL. À juste titre : comme l’a par exemple documenté Stéphane Bortzmeyer, le domaine t.me a tout simplement cessé de répondre aux requêtes.

L’examen du whois associé a révélé que le domaine en question avait été placé en statut serverHold, qui correspond à une interdiction temporaire prononcée par le registre en charge de l’extension concernée. « Il s’agit d’un statut inhabituel qui est généralement mis en œuvre lors de litiges juridiques ou lorsque votre domaine est susceptible d’être supprimé », précise à ce sujet la documentation de l’Icann.

Fallait-il voir dans cette suspension une censure, comme l’ont suggéré certains internautes sur X ? Le patron de Telegram, Pavel Durov, qui dénonçait quatre jours plus tôt la remise au goût du jour de la dérogation Chat Control par le Parlement européen, n’aurait sans doute pas manqué de réagir si tel avait été le cas.

À la place, il a interpellé, mardi 14 juillet, le compte X associé au domaine .me, qui dépend pour rappel du Monténégro : « Les liens t.me ont cessé de fonctionner, pouvez-vous regarder ? ».

Le registre en question s’est exprimé le même jour vers 19 heures, soit quelques heures après la reprise d’activités du domaine t.me. Il a indiqué avoir répondu à une injonction du département du Trésor des États-Unis : « Le registre .ME travaille en étroite collaboration avec les forces de l’ordre pour surveiller et traiter les problèmes liés au domaine .ME conformément aux lois applicables, y compris les exigences en matière de sanctions ».

Une sanction émanant des États-Unis

L’injonction en question émane plus précisément de l’OFAC (Office of Foreign Assets Control), l’agence rattachée au Trésor chargée d’administrer et d’appliquer les sanctions économiques ou commerciales. Lundi 13 juillet, l’OFAC a désigné de nouvelles cibles de sanctions, parmi lesquelles figurent plusieurs actifs associés à First VPN, un service qui était « presque exclusivement » promu sur les forums de cybercriminels russophones, récemment démantelé par les autorités.

• Saisie d’un VPN utilisé dans la quasi-totalité des grandes enquêtes cyber d’Europol

L’OFAC place à cette occasion plusieurs adresses e-mail, des portefeuilles de cryptomonnaie et plusieurs noms de domaine sur liste noire. Dans le lot figure une URL, t.me/FirstVPNService, qui semble avoir été interprétée de façon expéditive par les services monténégrins.

« Une chaîne Telegram utilisant le domaine http://t.me figurait parmi l’infrastructure identifiée de 1VPNS. En conséquence, le domaine http://t.me a été suspendu. Le 14 juillet, Telegram a confirmé avoir supprimé tous ses liens et affiliations avec 1VPNS. Après vérification de cette confirmation, la suspension du domaine http://t.me a été levée », justifie le registre.

Telegram a de son côté temporairement basculé ses liens vers le domaine telegram.me. Durov, d’humeur badine, a profité de l’occasion pour s’offrir le domaine t.you.

Grouik Grouik

L’assistant dédié au code informatique de SpaceXAI, Grok Build, envoyait des projets entiers vers des serveurs distants, sans consentement préalable des développeurs concernés. L’entreprise et son patron Elon Musk ont reconnu le problème, assurant que les éléments distants seraient supprimés. Le comportement litigieux a été corrigé côté serveur, ce qui laisse donc la porte ouverte à une réactivation ultérieure.

Voilà une publicité dont SpaceXAI se serait sans doute bien passé. Un chercheur en sécurité, connu sous le pseudonyme Cereblab, a documenté le 10 juillet dernier la façon dont l’assistant en ligne de commande (CLI) dédié au code Grok Build envoyait le contenu des dépôts sur lesquels travaille l’utilisateur vers des serveurs distants.

Un assistant IA un peu trop curieux

Pour ce faire, il indique avoir simplement installé un proxy en sortie de sa machine, pour monitorer les échanges réseau. Sur un dossier de travail de 12 Go, il affirme avoir constaté que 5,1 Go de données, pourtant non manipulées lors de la session en cours, ont transité vers un bucket hébergé sur Google Cloud et avaient été « acceptés » par ce dernier.

Dans le lot figurait notamment un fichier .env, envoyé sans caviardage automatique des secrets. Son contenu se révèle pourtant sensible puisqu’il est dédié aux variables d’environnement telles que les clés d’accès aux interfaces de programmation (API) mises en œuvre dans le projet.

Son analyse illustre deux canaux d’échange en parallèle : un canal « modèle » dédié aux traitements, par lequel seuls 192 ko de données ont transité, et un canal « stockage », qui a donc chargé 5,1 Go d’informations. Pour aller plus loin, le chercheur a reproduit la manipulation, mais avec un prompt indiquant explicitement à Grok Build de ne lire aucun fichier. Là encore, il constate qu’un lot complet est expédié vers Google Cloud.

Le chercheur explique ensuite avoir reproduit l’expérience avec Claude Code, Codex d’OpenAI et Gemini, sans constater de transfert de données inapproprié. Il se garde en revanche de spéculer sur la finalité de cet envoi de données. « Rien de tout cela ne prouve que xAI [entraine ses modèles] sur les données. Ce qui est prouvé, c’est la transmission, l’acceptation et le stockage », écrit-il.

Plusieurs témoignages partagés sur les réseaux sociaux abondent dans le sens de ses découvertes. « Une simple commande vous permettra de voir si un fichier a été téléchargé : cat ~/.grok/logs/unified.jsonl | grep repo_state.upload », précise à ce sujet un développeur.

SpaceXAI a réagi en modifiant le comportement litigieux, comme le souligne Cereblab dans une mise à jour datée du 14 juillet :

« Depuis la publication : xAI a désactivé le chargement côté serveur (disable_codebase_upload : true) ; a ajouté une option de désactivation de la confidentialité (/privacy) — que j’ai testée et qui s’est avérée être un paramètre de conservation des données, et non un blocage de l’envoi. »

SpaceXAI admet à demi-mots un problème

L’entreprise n’a pas publié de note de version dédiée, mais elle s’est exprimée le 13 juillet sur X, en affirmant qu’aucune donnée n’était conservée pour les entreprises qui avaient fait le choix d’un fonctionnement sans rétention de données (ZDR). Pour les autres, elle indique que le nouveau paramètre /privacy permet de supprimer cette rétention de données directement depuis l’interface en ligne de commande, et que l’activation de cette dernière supprimait les données précédemment synchronisées.

Elon Musk a quant à lui minimisé la portée de l’incident, tout en assurant qu’en guise de mesure de précaution, toutes les données précédemment uploadées par SpaceXAI seraient supprimées. L’examen de la dernière version en date de Grok Build laisse toutefois supposer que la fonction d’envoi reste intégrée au client, ce qui signifie que SpaceXAI n’a pas bloqué en dur cette possibilité, mais simplement modifié à son niveau la politique associée. Un nouveau changement de configuration reste donc possible.

En attendant de voir si SpaceXAI clarifie la situation et propose des garde-fous plus solides, les utilisateurs de Grok Build ont sans doute intérêt à vérifier le statut de leurs propres dépôts et à en modifier les secrets.

• Dans la foulée de son IPO, SpaceX rachète Cursor et ses modèles dédiés aux développeurs