Le site de Kintsu restauré, mais les utilisateurs sont toujours invités à ne pas connecter leur portefeuille
Le site de Kintsu restauré, mais les utilisateurs sont toujours invités à ne pas connecter leur portefeuille
Kintsu, un protocole de staking liquide bâti sur la blockchain Monad, aurait restauré son site officiel après une attaque présumée visant son interface front-end. Cependant, l’équipe du projet continue de déconseiller aux utilisateurs de se rendre sur kintsu.xyz ou d’y connecter un portefeuille tant qu’une confirmation officielle de sécurité n’aura pas été publiée.
Cet incident met en lumière un risque de plus en plus important dans la finance décentralisée : même lorsque les smart contracts restent inchangés, un site compromis peut toujours rediriger les utilisateurs vers des transactions malveillantes.
La restauration du site ne signifie pas que l’incident est terminé
Kintsu a indiqué que son domaine avait été restauré et qu’il pointait de nouveau vers sa propre infrastructure. Toutefois, les caches du système de noms de domaine (DNS) ne se mettent pas à jour simultanément chez tous les fournisseurs d’accès à Internet ni dans toutes les régions.
Par conséquent, certains utilisateurs peuvent encore être redirigés vers une version malveillante du site pendant un certain temps. L’équipe a indiqué que ce risque pouvait persister pendant environ une heure après la correction du domaine et a conseillé aux utilisateurs d’attendre une annonce officielle confirmant le retour à la normale.
Cette distinction est essentielle. Le fait qu’un site apparaisse normal à un endroit donné ne prouve pas nécessairement que tous les utilisateurs accèdent à la même infrastructure. La propagation DNS, la mise en cache des navigateurs et la mise en cache au niveau du réseau peuvent toutes créer des conditions d’accès différentes.
Pour obtenir les dernières informations propres au projet, les utilisateurs doivent se fier uniquement aux canaux de communication vérifiés de Kintsu et éviter de considérer l’apparence restaurée du site comme une preuve de sa sécurité.
Que s’est-il passé lors de l’attaque présumée visant l’interface front-end ?
La société de sécurité Blockaid a averti avoir détecté une attaque front-end en cours visant plusieurs sites consacrés aux cryptomonnaies, dont Kintsu, Flap et Stonkbrokers.
Selon cette alerte, les sites concernés avaient été modifiés afin de charger des scripts malveillants associés à l’outil StepDrainer. Ces scripts pouvaient manipuler le processus de connexion au portefeuille et rediriger les utilisateurs vers une page conçue pour faciliter le transfert d’actifs numériques.
L’attaque ne nécessitait pas forcément que les utilisateurs téléchargent une application suspecte ou saisissent leur phrase de récupération. Le danger apparaissait plutôt au moment où ils cliquaient sur un bouton familier du type « Connecter le portefeuille », puis interagissaient avec une demande de transaction ou de signature présentée par la page malveillante.
C’est pourquoi les incidents de sécurité affectant le front-end peuvent être particulièrement difficiles à détecter. Le site peut conserver son identité visuelle, sa mise en page et sa navigation habituelles tout en remplaçant discrètement les interactions légitimes avec le portefeuille par des opérations dangereuses.
Pourquoi « Connecter le portefeuille » n’est pas une action anodine
De nombreux utilisateurs considèrent la connexion d’un portefeuille comme une simple procédure d’identification. En réalité, connecter un portefeuille peut révéler des informations sur l’adresse utilisée et établir un canal de communication entre une application décentralisée et l’interface du portefeuille.
Le risque le plus sérieux apparaît lorsqu’une dApp demande à l’utilisateur de :
- Autoriser une allocation de tokens
- Signer un message inhabituel
- Confirmer une transaction dont les paramètres ne sont pas clairs
- Transférer des actifs vers une adresse inconnue
- Accorder des autorisations qui restent actives après la fin de la session
Un site malveillant peut présenter ces demandes avec un vocabulaire familier ou une interface soignée. Si la demande est approuvée, l’attaquant peut être en mesure de déplacer certains tokens ou de convaincre l’utilisateur d’autoriser un transfert direct d’actifs.
Les utilisateurs doivent donc évaluer chaque demande adressée à leur portefeuille indépendamment, plutôt que de supposer qu’elle est sûre parce qu’elle apparaît sur un site connu.
Mesures recommandées aux utilisateurs de Kintsu
Tant que Kintsu n’aura pas publié de confirmation claire concernant la sécurité de ses services, les utilisateurs doivent prendre les précautions suivantes :
-
Ne vous rendez pas sur
kintsu.xyzpour le moment.
Un domaine restauré peut encore renvoyer vers des infrastructures différentes en raison de la mise en cache DNS et de celle des navigateurs. -
Ne connectez pas de portefeuille à Kintsu, Flap ou Stonkbrokers.
Cette recommandation s’applique même si l’interface semble normale ou se charge sans afficher d’avertissement évident. -
Refusez les demandes de signature inhabituelles.
N’approuvez jamais une transaction simplement parce qu’un site affirme qu’elle est nécessaire pour poursuivre. -
Vérifiez les autorisations et permissions accordées aux tokens.
Si un portefeuille a été connecté ou si une transaction a été approuvée pendant la période présumée de l’attaque, les utilisateurs doivent examiner leurs autorisations on-chain et révoquer les allocations inutiles à l’aide d’un outil de gestion des permissions reconnu. -
Ne confondez pas la réponse à l’incident avec les phrases de récupération.
Ne saisissez jamais une phrase de récupération ou une clé privée sur un site, dans un formulaire d’assistance, dans une fenêtre d’extension de navigateur ou dans un message privé. Si la phrase de récupération d’un portefeuille a pu être exposée, il peut être nécessaire de transférer les actifs vers un portefeuille nouvellement généré. -
Suivez les annonces vérifiées.
Les domaines des projets, les comptes sur les réseaux sociaux et les canaux communautaires peuvent tous être imités. Les utilisateurs doivent vérifier l’authenticité d’un compte avant de suivre des instructions urgentes.
Les recommandations de sécurité concernant les portefeuilles de la Fondation Ethereum conseillent également de traiter avec prudence les demandes de signature inattendues et les applications inconnues.
Une leçon plus générale pour les utilisateurs de la DeFi
L’incident impliquant Kintsu montre que la sécurité de la finance décentralisée ne se limite pas aux audits des smart contracts. Les utilisateurs se concentrent souvent sur le code des contrats, le risque lié aux validateurs et la gouvernance des protocoles, mais le front-end constitue lui aussi une partie importante de la surface d’attaque.
Une application décentralisée peut s’appuyer sur plusieurs composants, notamment :
- L’enregistrement du domaine et la configuration DNS
- Les fournisseurs d’hébergement et les chaînes de déploiement
- Les bibliothèques JavaScript et les scripts tiers
- Les fournisseurs de services de connexion aux portefeuilles
- Les comptes sur les réseaux sociaux utilisés pour les annonces
La compromission d’une seule de ces couches peut affecter les utilisateurs, même lorsque la blockchain sous-jacente continue de fonctionner normalement.
L’incident montre également pourquoi la simulation des transactions et la vérification humaine restent importantes. Une demande affichée par un portefeuille doit être évaluée en fonction du contrat réellement appelé, de la fonction exécutée, du destinataire et du montant concerné — et non pas uniquement en fonction du nom du site qui l’a générée.
Quelle place pour les portefeuilles matériels dans ce modèle de sécurité ?
Un portefeuille matériel peut offrir une protection supplémentaire en conservant les clés privées à l’écart des environnements en ligne ordinaires. Cependant, il ne peut pas rendre automatiquement sûre une transaction malveillante. Si un utilisateur confirme une autorisation ou un transfert sans avoir vérifié les détails de la transaction, le portefeuille matériel peut tout de même la signer.
Pour les utilisateurs qui interagissent avec des protocoles DeFi sur des réseaux comme Monad, un portefeuille matériel tel que OneKey peut s’inscrire dans une stratégie de sécurité plus globale. L’approche la plus efficace consiste à combiner l’isolation des clés avec une vérification attentive du domaine, des autorisations limitées, des portefeuilles distincts selon les niveaux de risque et le refus de signer les demandes peu claires ou inattendues.
À retenir
La restauration du site de Kintsu ne doit pas être interprétée comme la fin de l’incident de sécurité. Tant que le projet n’aura pas confirmé explicitement que son interface front-end et les infrastructures associées sont sûres, les utilisateurs doivent éviter kintsu.xyz, ne pas connecter leur portefeuille et rejeter toute demande de signature inhabituelle.
Pour les utilisateurs de la DeFi, la leçon est simple : un site familier ne garantit pas qu’une transaction est sûre. Vérifiez le domaine, examinez chaque demande affichée par le portefeuille, limitez les permissions accordées aux tokens et considérez toute urgence inattendue comme un possible signal d’alerte.



