TanStack et bien d'autres paquets affectés : analyse et examen approfondi

Françaisالعربية Deutsch English Español हिन्दी Bahasa Indonesia 日本語 한국어 Português Русский 中文

MMaximilian Schwarzmüller

컴퓨터/소프트웨어경제 뉴스AI/미래기술

Transcript

00:00:00Nous subissons une autre attaque majeure de la chaîne d'approvisionnement en ce moment même,”

00:00:06et elle s'est propagée de NPM à l'écosystème Python, donc évitez d'installer tout paquet”

00:00:12NPM ou Python pour l'instant. Assurez-vous que votre système est bien sécurisé. J'ai une vidéo”

00:00:19à ce sujet, je partagerai le lien ci-dessous et j'y reviendrai aussi dans cette vidéo, mais d'abord”

00:00:23je veux vous donner des détails sur ce qui est touché et comment savoir si vous l'êtes. Tout a commencé avec”

00:00:30les paquets TanStack : TanStack query, TanStack router, TanStack start, etc. Hier, le 11 mai,”

00:00:36en un temps très court, plusieurs paquets malveillants, ou en fait tous les paquets TanStack,”

00:00:43ont été publiés dans des versions malveillantes. L'attaque a été contenue en 20 minutes.”

00:00:50Finalement, elle a été détectée et stoppée rapidement, mais tous ces paquets malveillants ont été publiés”

00:00:57durant ce court laps de temps. Ensuite, la propagation s'est poursuivie et elle continue encore.”

00:01:03Elle a touché les paquets Mistral qui n'ont que quatre utilisateurs, mais ils ont quand même été”

00:01:09affectés car ce malware agit comme un ver : il vole des données et des identifiants, potentiellement”

00:01:16les vôtres s'il est installé sur votre système. Je reviendrai sur comment savoir si vous êtes touché”

00:01:20dans un instant, mais il a continué à se propager à d'autres paquets NPM car c'est son but,”

00:01:26et même dans l'écosystème Python en ce moment même. Cela ne date que de quelques heures,”

00:01:32deux heures au moment où j'enregistre ceci. Maintenant, comment savoir si vous êtes touché ?”

00:01:39Si vous avez installé un paquet TanStack hier soir, dans mon cas sur le fuseau horaire allemand,”

00:01:45vous devez vous considérer comme affecté. Si vous l'avez installé vers cette heure-là, gardez à l'esprit”

00:01:54que c'est en UTC, donc convertissez-le selon votre zone. Dans ce cas, vous êtes probablement touché.”

00:02:00Mais comme cela se propage aux paquets Mistral et à bien d'autres paquets JavaScript,”

00:02:06trop nombreux pour être listés ici, vous devez considérer votre machine comme compromise.”

00:02:13Je partagerai les liens vers ces publications pour que vous puissiez voir la liste complète”

00:02:18de tous les paquets concernés au fur et à mesure. Mais comme indiqué, c'est encore en cours,”

00:02:22donc n'installez rien pour l'instant. Il existe aussi des indicateurs de compromission.”

00:02:31Cherchez certaines empreintes de fichiers, des hashes SHA, pour le routeur dans un fichier JS.”

00:02:38Si vous avez un moyen de surveiller les requêtes réseau effectuées sur votre machine,”

00:02:42cherchez du trafic sortant vers cette URL. Ce serait un indicateur clair”

00:02:48que des données ont été exfiltrées de votre système. Que signifie concrètement une compromission ?”

00:02:55Ce malware fait deux choses principales. D'abord, il récolte des données. Il cherche”

00:03:03des jetons NPM, GitHub, des identifiants AWS et d'autres secrets. Il scanne votre système”

00:03:12aux endroits habituels où sont stockés les secrets, les collecte et les envoie”

00:03:18à l'URL que je vous ai montrée. Il vole donc ces secrets. Mais il ne s'arrête pas là.”

00:03:26Comme je l'ai dit, il agit comme un ver et utilise les jetons GitHub volés.”

00:03:33Il s'en sert avec les jetons NPM pour publier d'autres paquets compromis. Si vous maintenez”

00:03:40un autre paquet, ou si un workflow CI/CD s'est exécuté durant cette période et”

00:03:46dépendait de paquets TanStack, alors dans ce workflow, les paquets TanStack compromis”

00:03:53ont été récupérés. Le code malveillant a pu s'y exécuter. Et dans ce workflow,”

00:04:00même si ce n'est pas sur votre machine, il a pu voler des identifiants”

00:04:06pour publier une version malveillante du paquet que votre workflow CI/CD”

00:04:14essayait de construire. C'est ainsi qu'il se propage. Il agit vraiment comme un ver.”

00:04:20Il utilise les jetons volés pour infecter plus de paquets. C'est ainsi que cela a atteint”

00:04:26vers Mistral, d'autres paquets JavaScript, et même l'écosystème Python. Et nous en

00:04:32Et à ma connaissance, cela continue de s'étendre. Alors, comment s'en protéger ?”

00:04:39J'ai créé une vidéo à ce sujet sur mon autre chaîne, AkataMind. Le lien sera en description.”

00:04:44Pour faire court, vous devez vous assurer de ne pas exécuter votre code ou développer”

00:04:51directement sur votre machine hôte, mais plutôt dans une machine virtuelle ou un conteneur dev.”

00:04:57Ne stockez pas de secrets en clair sur votre machine. Pour AWS,”

00:05:03par exemple, privilégiez le Single Sign-On plutôt que de stocker des identifiants IAM,”

00:05:10et utilisez des techniques similaires pour vos autres services. De plus,”

00:05:16envisagez d'utiliser des services comme Infisical ou Doppler pour stocker vos secrets”

00:05:25dans le cloud et non sur votre disque dur ou dans des fichiers .env.”

00:05:30J'en parle dans l'autre vidéo. Utilisez aussi des gestionnaires de paquets”

00:05:38qui permettent de configurer un âge minimum de publication, comme le permet Bun.”

00:05:44Dans le fichier bunfig.toml, vous pouvez définir un âge minimum de sortie pour garantir”

00:05:49que 'bun install' n'installe que des paquets vieux d'au moins X secondes ou jours.”

00:05:56pnpm a une fonction similaire, tout comme les dernières versions de npm.”

00:06:02Encore une fois, j'ai couvert cela ailleurs. Si vous utilisez Bun ou une bonne config npm,”

00:06:09Bun bloque par défaut l'exécution des scripts post-install,”

00:06:15c'est-à-dire les scripts de cycle de vie des paquets que vous installez.”

00:06:21C'est un autre mécanisme de sécurité car ce malware s'appuie souvent”

00:06:28sur l'exécution de tels scripts. Utiliser un gestionnaire de paquets sécurisé,”

00:06:36isoler votre code dans une VM et ne pas stocker de secrets en clair :”

00:06:41voilà ce qu'il faut faire, surtout maintenant que ces attaques deviennent plus sérieuses.”

00:06:46Nous allons voir comment celle-ci a fonctionné car c'est très intéressant.”

00:06:52Malheureusement, elles sont de plus en plus fréquentes. Je fais une vidéo par mois là-dessus,”

00:06:58voire plus, car je pense qu'elles sont plus faciles à réaliser désormais.”

00:07:04À l'ère de l'IA, il est plus simple d'analyser les paquets ou les dépendances ciblées,”

00:07:12d'étudier leur code source ou leur configuration CI/CD pour trouver des failles.”

00:07:22C'est ce qui s'est passé pour TanStack. Ce n'est pas la machine d'un mainteneur”

00:07:28qui a été touchée, mais le workflow CI/CD de TanStack. J'y reviendrai.”

00:07:34L'IA facilite la recherche de vulnérabilités et l'écriture de code, même malveillant.”

00:07:40En parallèle, nous vivons une explosion logicielle : on écrit plus de code que jamais.”

00:07:45Il y a donc plus de cibles, dont beaucoup négligent la sécurité,”

00:07:51ce qui rend ces attaques d'autant plus attractives. Comment tout cela a commencé ?”

00:07:57C'est fascinant. Ce n'est pas une approche inédite, mais elle est très élaborée.”

00:08:03L'équipe TanStack a publié un rapport d'incident expliquant le déroulement de l'attaque.”

00:08:09Je mettrai le lien, mais je vais vous en faire le résumé ici.”

00:08:15En résumé, cette attaque a reposé sur trois étapes clés que je vais détailler.”

00:08:22D'abord, un schéma de 'pull request pwn request'. Je vais expliquer ce que c'est.”

00:08:30Ensuite, l'empoisonnement du cache GitHub Actions via les limites de confiance des forks,”

00:08:38et l'extraction en mémoire d'un jeton OIDC. Qu'est-ce que tout cela signifie ?”

00:08:45Vous pouvez lire l'article pour les détails, mais voici l'essentiel. Commençons par”

00:08:50la 'pull request pwn request'. Pour comprendre, il faut savoir que GitHub Actions”

00:08:58est la solution CI/CD de GitHub. J'ai d'ailleurs un cours complet à ce sujet”

00:09:05si vous voulez apprendre à configurer GitHub Actions pour vos tâches d'automatisation,”

00:09:10publier vos paquets ou vos sites web. Comme tout outil CI/CD,”

00:09:16il repose sur des événements qui déclenchent des workflows automatisés.”

00:09:24Par exemple, déployer votre site automatiquement quand vous poussez sur la branche principale.”

00:09:29Le 'push' est l'un de ces événements. Vous pouvez définir des tâches spécifiques :”

00:09:34installer des dépendances, compiler le projet, le mettre en ligne.”

00:09:40Un autre déclencheur est 'pull_request_target'. Il s'active”

00:09:44lorsqu'une pull request est ouverte sur votre dépôt. Cela signifie”

00:09:49que n'importe qui peut forker votre dépôt, y faire des modifications et ouvrir”

00:09:56une pull request, ce qui déclenchera ce workflow. Ça a l'air dangereux ? Ça l'est,”

00:10:05et c'est le point de départ de l'attaque. Il existe aussi le déclencheur 'pull_request'.”

00:10:14Ce dernier exécute le workflow dans le contexte du dépôt forké. Ainsi,”

00:10:19tout ce qui est malveillant reste confiné au fork, pas au dépôt de base.”

00:10:25En revanche, 'pull_request_target' s'exécute dans le contexte du dépôt de base.”

00:10:31C'est là que réside le danger. Dans le cas de TanStack, l'attaquant a inclus”

00:10:38le code malveillant du ver dans son fork, puis a ouvert une pull request.”

00:10:45Cela a déclenché 'pull_request_target' sur un exécuteur GitHub Actions,”

00:10:52tournant dans le contexte du dépôt principal. Cela ne donne pas un accès direct”

00:10:58au code source de base pour le modifier, mais cela signifie que le cache utilisé”

00:11:04Et c'est ce qui s'est passé ici pour l'attaque TanStack : dans cette pull request,

00:11:10au sein de ce fork, l'attaquant a inclus le code malveillant, le code du ver, le malware dans le dépôt TanStack,

00:11:20plus précisément dans son fork. Ensuite, l'attaquant a ouvert la pull request,

00:11:26ce qui a déclenché l'exécution de pull_request_target. Et comme mentionné, cela lance

00:11:33un runner GitHub Actions, qui s'exécute alors dans le contexte du dépôt de base. Qu'est-ce que cela signifie ?

00:11:40Cela ne signifie pas que l'attaquant accède au code de base ou peut y fusionner le code malveillant,

00:11:46mais cela signifie, par exemple, que le cache utilisé à cet endroit

00:11:53sera partagé avec les exécutions ultérieures de GitHub Actions issues du dépôt de base,

00:12:00potentiellement via des hooks ou des déclencheurs totalement différents comme le push.

00:12:05L'étape suivante a été l'empoisonnement du cache. Mais qu'est-ce que cela signifie ? Eh bien,

00:12:11l'attaquant a ajouté du code à son fork pour s'assurer que lorsque l'action GitHub

00:12:17s'exécutait via le déclencheur pull_request_target, elle lancerait une commande, la commande hash files,

00:12:23qui est supportée par GitHub Actions, pour stocker quelque chose dans le cache. Maintenant,

00:12:28quel est l'intérêt de ce cache ? L'idée derrière le cache GitHub Actions est simplement d'accélérer

00:12:33a volé un jeton NPM éphémère (OIDC) pour publier une version infectée de TanStack.”

00:12:39NPM propose une fonction de 'trusted publishing' censée être plus sûre.”

00:12:46Normalement, on peut utiliser un jeton de compte, mais s'il est volé, c'est fini.”

00:12:52Avec la publication de confiance, on doit passer par un fournisseur comme GitHub Actions.”

00:12:56Un jeton à durée de vie très courte est alors généré pour signer la nouvelle version.”

00:13:00Mais si le code qui s'exécute dans le workflow est déjà compromis,”

00:13:06il a accès à ce jeton tout neuf. C'est ce qui s'est passé : le malware”

00:13:12a utilisé ce jeton pour publier la version malveillante sur NPM. Fait intéressant,”

00:13:18l'attaque a partiellement échoué car le workflow GitHub Actions s'est interrompu”

00:13:24comme celles du déclencheur push, partagent le même contexte et le même cache. Et c'est

00:13:31Si le code avait été valide, le workflow se serait terminé normalement”

00:13:39et la version compromise aurait paru parfaitement authentique.”

00:13:46L'attaquant n'avait plus qu'à attendre qu'un flux de travail GitHub Actions normal s'exécute pour les paquets TanStack.

00:13:53Lorsqu'un mainteneur poussait du code, cette autre exécution de GitHub Actions réutilisait

00:14:01le même cache configuré précédemment par l'exécution malveillante, et récupérait alors

00:14:08le cache empoisonné préparé, qui incluait le code malveillant. C'est ainsi que ce code

00:14:13est passé du fork vers l'exécution normale de GitHub Actions lors d'un push standard par un mainteneur

00:14:21qui n'avait pas été affecté par un quelconque code malveillant. Le cache a servi de véhicule de transport

00:14:28entre ces deux exécutions de GitHub Actions au final. Puis, dans une troisième étape, une fois que

00:14:35Ce n'est pas fini, et toutes les futures attaques ne seront pas détectées aussi vite.”

00:14:44La surface d'attaque grandit : plus de code, plus de cibles potentielles,”

00:14:54et l'IA qui aide les attaquants. Si vous le pouvez, n'installez rien pour le moment,”

00:15:00vérifiez vos configurations et consultez les liens ci-dessous pour plus de détails.

00:15:04Il existe grosso modo deux façons de publier un paquet sur NPM, on pourrait dire. La première consiste à créer un

00:15:11jeton avec votre compte NPM et à l'utiliser pour publier de nouvelles versions de votre paquet. Le problème,

00:15:19c'est que si ce jeton est volé, n'importe qui peut publier une nouvelle version de ce paquet. Pour renforcer la

00:15:26sécurité, il existe ce processus de publication de confiance où NPM dit : non, vous ne pouvez pas publier de paquets depuis

00:15:33votre machine, vous devez passer par l'un de ces fournisseurs de confiance, GitHub Actions étant l'un d'entre

00:15:37eux, et il existe une intégration de publication de confiance pour GitHub Actions que vous pouvez configurer. Ensuite,

00:15:44dans le cadre de ce processus de publication de confiance, un jeton de publication à courte durée de vie sera récupéré

00:15:50ou demandé. Et ensuite, ce jeton à courte durée de vie sera utilisé pour signer cette nouvelle version

00:15:57du paquet en cours de publication. En théorie, l'idée est que le jeton est difficile à voler parce

00:16:03qu'il n'est sur la machine d'aucun mainteneur. Et de plus, il est de courte durée. Même s'il était volé,

00:16:08il n'est pas actif très longtemps. Le problème, bien sûr, est simplement que si le code qui s'exécute dans le workflow

00:16:15CI/CD qui demande ce jeton de confiance a été infecté, alors ce code

00:16:21malveillant a accès à ce tout nouveau jeton de publication de confiance à courte durée de vie. Et c'est ce qui s'est passé

00:16:27ici. Ce code malveillant a donc abusé de ce jeton ou a utilisé ce jeton pour publier ensuite une nouvelle version

00:16:36du paquet TanStack. Maintenant, assez curieusement, cette attaque a un peu échoué parce qu'elle a bien

00:16:44obtenu ce jeton de confiance et l'a utilisé pour contacter l'API NPM afin de publier une nouvelle version

00:16:52du paquet TanStack qui incluait ce ver, qui incluait le code malveillant. Mais elle s'est en fait

00:16:58retrouvée dans un workflow GitHub Actions qui n'a pas pu se terminer parce qu'il y avait un problème dans

00:17:06le code qui avait été poussé vers le CI/CD. Si les attaquants avaient fait attention à lancer leur

00:17:12attaque à un moment où un code valide était poussé, alors bien sûr ce workflow se serait

00:17:19terminé et ils n'auraient pas eu besoin de publier un paquet malveillant manuellement en contactant

00:17:26l'API NPM, mais ils auraient pu injecter le code malveillant dans ce workflow,

00:17:32le laisser se terminer avec succès, et une version compromise de TanStack aurait alors été

00:17:38publiée tout en paraissant tout à fait valide, puisqu'il s'agissait d'un push normal par un mainteneur et que le workflow

00:17:45s'était terminé avec succès. La façon dont cette attaque a fonctionné, parce que ce workflow ne s'est pas terminé avec succès,

00:17:51a rendu un peu plus facile la détection de ce qui se passait par un contributeur externe, au final,

00:18:00parce qu'on pouvait voir qu'une nouvelle version des paquets TanStack avait été publiée alors même que le

00:18:05workflow GitHub Actions avait échoué, donc aucune nouvelle version n'aurait dû être publiée. On pouvait donc voir une

00:18:12incohérence, ce qui a facilité la détection de cette attaque, et c'est en partie là que les

00:18:19mainteneurs de TanStack et nous tous avons eu de la chance. C'est néanmoins une attaque assez élaborée comme vous pouvez

00:18:26probablement le dire, qui a fonctionné sans compromettre la machine de qui que ce soit, et même si elle a été stoppée

00:18:32rapidement, elle a fait de sérieux dégâts car, comme je l'ai mentionné, elle se propage encore, et c'était un long

00:18:41épisode sur tout cela, je sais, mais je veux vraiment insister sur le fait que vous devez travailler à sécuriser

00:18:49votre système, comme je l'ai partagé plus tôt et dans cette vidéo. Vous voulez vous assurer de réduire le

00:18:56risque d'être affecté. Cette attaque a été stoppée rapidement, et pourtant elle continue de se propager,

00:19:05ce n'est donc pas encore fini, et il est possible que toutes les attaques ne soient pas détectées aussi rapidement

00:19:11à l'avenir. Ils ont eu un peu de chance ici, il aurait pu être plus difficile de détecter cette

00:19:18attaque, et les dégâts auraient alors pu être encore plus importants ; mais ils sont déjà conséquents ici et

00:19:24ce n'est pas fini. Nous verrons d'autres attaques de ce type, j'en suis sûr, car comme je l'ai dit, la surface

00:19:31d'attaque s'agrandit et devient plus intéressante. Il y a plus de gens qui écrivent du code, beaucoup de gens

00:19:36qui ne savent pas ce qu'ils font, et l'IA aide à mener de telles attaques. Voilà donc ce qui se

00:19:42passe en ce moment. Si vous ne le devez pas, n'installez peut-être rien, vérifiez bien votre configuration, et vous

00:19:48trouverez tous les liens ci-dessous si vous voulez approfondir, si vous voulez voir la liste complète des paquets

00:19:51affectés, et ainsi de suite.

Key Takeaway

L'attaque de la chaîne d'approvisionnement contre TanStack exploite le déclencheur pull_request_target et l'empoisonnement du cache GitHub Actions pour voler des secrets système et propager automatiquement le malware vers de nouveaux paquets NPM et Python.

Highlights

L'attaque du 11 mai a compromis l'intégralité des paquets de l'écosystème TanStack sur NPM en moins de 20 minutes.
Le malware agit comme un ver informatique en utilisant des jetons GitHub et NPM volés pour publier automatiquement des versions infectées d'autres paquets.
Une exfiltration de données est confirmée si le trafic réseau sortant pointe vers l'URL malveillante identifiée dans les indicateurs de compromission.
Le gestionnaire de paquets Bun permet de bloquer l'installation de versions trop récentes via le fichier bunfig.toml pour éviter les versions malveillantes immédiates.
L'attaque a exploité une faille dans le déclencheur pull_request_target de GitHub Actions pour empoisonner le cache partagé du dépôt principal.
Le stockage de secrets en clair sur le disque dur, comme les fichiers .env ou les identifiants IAM AWS, constitue le vecteur principal de vol d'identité lors de cette infection.

Timeline

Étendue de l'infection sur NPM et Python

L'attaque touche simultanément les écosystèmes JavaScript via NPM et Python.
Tous les paquets TanStack comme Query, Router et Start ont reçu des mises à jour malveillantes le 11 mai.
Le malware se propage de manière autonome vers des paquets tiers comme Mistral après l'infection initiale.

L'attaque a débuté par la publication massive de versions infectées des bibliothèques TanStack sur une période très courte de 20 minutes. Bien que contenue rapidement, la nature virale du code lui permet de continuer sa progression vers d'autres bibliothèques. Même des paquets avec un très faible nombre d'utilisateurs sont ciblés car le but est la collecte systématique d'identifiants.

Identification d'une machine compromise

Toute installation de paquet TanStack effectuée le soir du 11 mai (heure UTC) indique une compromission probable.
La présence de hashes SHA spécifiques dans les fichiers JavaScript du routeur confirme l'infection.
Le monitoring du trafic réseau sortant vers des URL suspectes révèle l'exfiltration de données en cours.

Le risque de compromission s'étend au-delà de TanStack en raison de la propagation rapide du ver à d'autres dépendances JavaScript trop nombreuses pour être listées. Les utilisateurs doivent vérifier l'intégrité de leurs fichiers locaux et surveiller toute activité réseau anormale. Si une interaction avec ces paquets a eu lieu durant la fenêtre d'attaque, la machine hôte doit être considérée comme totalement compromise.

Mécanismes de vol de secrets et propagation

Le malware scanne le système pour extraire des jetons NPM, GitHub et des identifiants AWS.
Les workflows CI/CD qui utilisent les paquets infectés servent de relais pour publier de nouvelles versions malveillantes.
Le ver utilise les permissions des jetons volés pour infecter les dépôts dont l'utilisateur est mainteneur.

Le processus malveillant priorise la récolte de secrets stockés dans les emplacements standards du système de fichiers. Une fois les jetons GitHub et NPM obtenus, le script les utilise pour s'injecter dans d'autres projets via les pipelines d'intégration continue. Cette méthode permet au malware de passer d'un environnement de développement à un autre sans intervention humaine.

Stratégies de protection et isolation

Le développement dans des machines virtuelles ou des conteneurs isolés prévient l'accès du malware à la machine hôte.
L'utilisation de services comme Infisical ou Doppler remplace le stockage dangereux de secrets en local.
La configuration d'un âge minimum de publication dans Bun ou pnpm bloque l'installation automatique de paquets suspects trop récents.

La sécurisation repose sur la suppression des secrets en clair, notamment en privilégiant le Single Sign-On (SSO) pour AWS plutôt que les clés IAM statiques. Les gestionnaires de paquets modernes offrent des leviers techniques comme la désactivation des scripts post-install par défaut dans Bun. Ces mesures barrières limitent l'impact d'une dépendance compromise sur l'intégrité globale du système de développement.

Anatomie technique de l'attaque via GitHub Actions

L'attaquant exploite le déclencheur pull_request_target qui s'exécute avec les privilèges du dépôt de base.
Le cache GitHub Actions sert de vecteur pour transférer le code malveillant du fork vers le workflow de push officiel.
Le malware intercepte les jetons OIDC éphémères de la 'Trusted Publishing' de NPM pour signer les versions infectées.

L'attaque utilise une technique de 'pull request pwn' où un contributeur externe déclenche un workflow malveillant sur le dépôt cible. En manipulant la commande 'hash files', l'attaquant empoisonne le cache que les mainteneurs utiliseront plus tard lors de leurs propres mises à jour. Cela permet d'injecter du code dans le pipeline officiel sans jamais modifier directement le code source visible sur GitHub.

Détection fortuite et avenir des attaques par IA

L'échec technique du workflow GitHub Actions a permis de détecter l'incohérence entre l'absence de build réussi et la publication sur NPM.
L'intelligence artificielle accélère l'analyse des failles dans les configurations CI/CD complexes.
L'augmentation du volume de code produit mondialement multiplie les cibles vulnérables.

La détection de cette attaque spécifique a été facilitée par une erreur des attaquants qui a provoqué l'échec du workflow, alertant ainsi les contributeurs attentifs. Toutefois, l'IA rend la découverte de telles vulnérabilités plus systématique et facile pour les acteurs malveillants. La fréquence de ces incidents augmente car la surface d'attaque logicielle ne cesse de croître tandis que la rigueur sécuritaire ne suit pas toujours cette cadence.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video