Mon seignaur, il est l'AUR de se protéger

Une attaque non revendiquée a permis à des pirates d’infecter des centaines de paquets dans le dépôt AUR d’Arch Linux. La distribution n’est pas directement touchée, le dépôt étant consacré aux paquets gérés par la communauté. L’ampleur de l’attaque montre une nouvelle fois les limites d’un modèle de sécurité avant tout basé sur la confiance.

AUR, pour Arch User Repository, est un dépôt communautaire pour la distribution Arch Linux (et celles qui en dérivent). Comme indiqué sur le wiki d’Arch Linux, il « a été créé pour organiser et partager les nouveaux paquets de la communauté et pour aider à accélérer l’inclusion des paquets populaires dans le dépôt « extra » ». Il n’est donc pas géré par l’équipe de maintenance d’Arch Linux, n’est le plus souvent pas activé par défaut et contient un grand nombre de paquets (archives regroupant les fichiers nécessaires à un logiciel et les métadonnées associées) non présents dans la distribution.

Pratique, AUR est aussi un fourre-tout dans lequel la traçabilité est parfois très relative. C’est cet aspect qui a été exploité par les pirates.

L’attaque

Le 11 juin, les chercheurs de l’entreprise de sécurité Sonatype découvrent une campagne d’attaque coordonnée contre le dépôt AUR. Le ou les pirates ont pris le contrôle de paquets AUR dits « orphelins », c’est-à-dire abandonnés et en quête d’un repreneur. Ces paquets ont été modifiés : les fichiers de description des paquets (PKGBUILD) pointent vers un paquet npm malveillant à l’installation.

Dans son billet, Sonatype indique qu’une vingtaine de paquets modifiés ont ainsi été détectés. Un script post-installation a même été injecté pour appeler la commande « npm install atomic-lockfile ».

Entre les 11 et 12 juin, le nombre de paquets détectés comme malveillants s’envole, comme rapporté par le collectif de renseignement open source IFIN (Independent Federated Intelligence Network) et la communauté AUR. On passe ainsi de 20 à plus de 400 paquets, qui distribuent à la fois un rootkit assurant la persistance dans les machines infectées et un malware dédié au vol d’identifiants et de jetons d’accès (tokens d’authentification).

Le loup dans la bergerie

Aqara, fabricant d’appareils connectés populaires dans l’univers HomeKit, a récemment corrigé la bagatelle de 26 défaillances de sécurité détectées principalement au niveau de la plateforme cloud qui sous-tend ses services. Dix des failles découvertes ont donné lieu à publication d’une CVE. L’exploitation combinée des quatre premières aboutit à une vulnérabilité notée 10, le niveau maximal de sévérité.

Une recherche indépendante, publiée le 11 juin dernier, vient de mettre en lumière un vaste ensemble de vulnérabilités affectant les produits de la marque Aqara. Ce fabricant chinois commercialise pour mémoire une large gamme de capteurs de température, caméras IP, ampoules pilotées, thermostats et autres serrures ou verrous connectés. La bonne intégration de ses produits dans Apple Maison (HomeKit) les rend particulièrement populaires chez les amateurs de domotique.

La plateforme cloud qui sous-tend leur fonctionnement présentait toutefois quelques sérieuses failles en matière de sécurité. L’exploitation combinée de plusieurs d’entre elles créait ainsi une voie pour usurper n’importe quel compte enregistré sur la plateforme Aqara, et donc potentiellement de forger un accès à l’ensemble de l’écosystème domotique d’un utilisateur.

Dix CVE et de nombreux problèmes de configuration

L’une de ces failles a reçu la note maximale de 10.0 dans la base de Common Vulnerabilities and Exposures (CVE) officielle – une sévérité qui reflète son rôle dans la chaîne plutôt que son impact pris isolément, le chercheur lui ayant lui-même attribué 7.5. « La passerelle Aqara IAM/SSO (gw-builder.aqara.com) expose des échanges AES bidirectionnels contre la clé de signature de la plateforme sans authentification », indique la notice associée.

Derrière ce scénario du pire (dont aucune mise en œuvre malveillante n’a été attestée) se cache en réalité un catalogue de failles et de lacunes de sécurité bien plus vastes, comme le présente sur GitHub l’auteur de ces découvertes, le Français Sammy Azdoufal. Ses travaux, confirmés par Tod Beardsley de runZero, ont donné lieu à la publication de dix CVE individuelles, dont quatre sont qualifiées de critiques (note supérieure à 9).

« L’audit a révélé dix vulnérabilités côté produit suffisamment graves pour justifier l’attribution de CVE, ainsi que onze problèmes côté opérateur affectant l’infrastructure d’Aqara (son CRM, ses plateformes CI/opérations internes, sa passerelle IAM, son forum et son GitHub). Les quatre premières CVE sont liées entre elles. Aucune d’entre elles n’atteint individuellement le niveau 10.0. C’est leur enchaînement qui aboutit à ce niveau », décrit Sammy Azdoufal.

Il a découvert ces failles en étudiant l’application mobile dédiée à ses utilisateurs, ce qui lui avait déjà permis de découvrir plus d’un million de babyphones espion basés sur le cloud Meari, et près d’un million de pièces d’identité exposées sur Internet par le fournisseur d’un outil de CRM dédié aux coffee shops et autres cannabis clubs sociaux.

Sammy Azdoufal indique avoir listé et informé Aqara d’un total de 27 défaillances. Le fabricant aurait reconnu et corrigé 26 d’entre elles, laissant de côté l’allusion à un forum Discourse dont les messages et les comptes utilisateurs étaient accessibles sans authentification préalable. « L’un des éléments signalés comme corrigés est un problème structurel (CVE-2026-50091, clés cryptographiques codées en dur intégrées au SDK mobile et au firmware déployé) pour lequel un correctif côté serveur n’est pas architecturalement suffisant », estime de son côté l’auteur de la découverte.

La marque minimise l’impact

Il relate par ailleurs la chronologie de ses échanges avec Aqara, de la première prise de contact, en mars, à la déclaration publique transmise le 11 juin, date de la publication de ses découvertes. Dans cette dernière, telle que reproduite par Sammy Azdoufal, l’entreprise affirme que « la possibilité potentielle de contrôler les appareils des utilisateurs se rapporte à un environnement de test totalement distinct des systèmes de production d’Aqara », et que l’accès « à de véritables appareils ou comptes utilisateurs via l’environnement de test est impossible dans notre architecture, car les environnements ne partagent aucune donnée utilisateur, identifiant ni service backend ».

Des affirmations que réfute le chercheur indépendant. « Le point d’accès de récupération des jetons (famille CVE-2026-50083) a renvoyé 2 969 sessions actives, dont les sessions JWT actives de deux employés d’Aqara. Les environnements de test ne contiennent pas les sessions de travail actives des employés réels », fait-il par exemple valoir.

Nous avons contacté Aqara pour essayer de tirer au clair ces contradictions. En attendant, les utilisateurs de l’application du même nom ont sans doute tout intérêt à révoquer les autorisations tierces qu’ils n’auraient pas eux-mêmes accordées dans les paramètres de leur compte. Ainsi qu’à privilégier les options de contrôle local, notamment via HomeKit, plutôt que de piloter leurs appareils par l’intermédiaire d’un cloud opéré par le fabricant. Un conseil qui vaut sans doute d’ailleurs bien au-delà du cas particulier d’Aqara…

• Domotique « intelligente » : ne nous laissons pas enfermer par nos objets connectés

Le loup dans la bergerie

Aqara, fabricant d’appareils connectés populaires dans l’univers HomeKit, a récemment corrigé la bagatelle de 26 défaillances de sécurité détectées principalement au niveau de la plateforme cloud qui sous-tend ses services. Dix des failles découvertes ont donné lieu à publication d’une CVE. L’exploitation combinée des quatre premières aboutit à une vulnérabilité notée 10, le niveau maximal de sévérité.

Une recherche indépendante, publiée le 11 juin dernier, vient de mettre en lumière un vaste ensemble de vulnérabilités affectant les produits de la marque Aqara. Ce fabricant chinois commercialise pour mémoire une large gamme de capteurs de température, caméras IP, ampoules pilotées, thermostats et autres serrures ou verrous connectés. La bonne intégration de ses produits dans Apple Maison (HomeKit) les rend particulièrement populaires chez les amateurs de domotique.

La plateforme cloud qui sous-tend leur fonctionnement présentait toutefois quelques sérieuses failles en matière de sécurité. L’exploitation combinée de plusieurs d’entre elles créait ainsi une voie pour usurper n’importe quel compte enregistré sur la plateforme Aqara, et donc potentiellement de forger un accès à l’ensemble de l’écosystème domotique d’un utilisateur.

Dix CVE et de nombreux problèmes de configuration

L’une de ces failles a reçu la note maximale de 10.0 dans la base de Common Vulnerabilities and Exposures (CVE) officielle – une sévérité qui reflète son rôle dans la chaîne plutôt que son impact pris isolément, le chercheur lui ayant lui-même attribué 7.5. « La passerelle Aqara IAM/SSO (gw-builder.aqara.com) expose des échanges AES bidirectionnels contre la clé de signature de la plateforme sans authentification », indique la notice associée.

Derrière ce scénario du pire (dont aucune mise en œuvre malveillante n’a été attestée) se cache en réalité un catalogue de failles et de lacunes de sécurité bien plus vastes, comme le présente sur GitHub l’auteur de ces découvertes, le Français Sammy Azdoufal. Ses travaux, confirmés par Tod Beardsley de runZero, ont donné lieu à la publication de dix CVE individuelles, dont quatre sont qualifiées de critiques (note supérieure à 9).

« L’audit a révélé dix vulnérabilités côté produit suffisamment graves pour justifier l’attribution de CVE, ainsi que onze problèmes côté opérateur affectant l’infrastructure d’Aqara (son CRM, ses plateformes CI/opérations internes, sa passerelle IAM, son forum et son GitHub). Les quatre premières CVE sont liées entre elles. Aucune d’entre elles n’atteint individuellement le niveau 10.0. C’est leur enchaînement qui aboutit à ce niveau », décrit Sammy Azdoufal.

Il a découvert ces failles en étudiant l’application mobile dédiée à ses utilisateurs, ce qui lui avait déjà permis de découvrir plus d’un million de babyphones espion basés sur le cloud Meari, et près d’un million de pièces d’identité exposées sur Internet par le fournisseur d’un outil de CRM dédié aux coffee shops et autres cannabis clubs sociaux.

Sammy Azdoufal indique avoir listé et informé Aqara d’un total de 27 défaillances. Le fabricant aurait reconnu et corrigé 26 d’entre elles, laissant de côté l’allusion à un forum Discourse dont les messages et les comptes utilisateurs étaient accessibles sans authentification préalable. « L’un des éléments signalés comme corrigés est un problème structurel (CVE-2026-50091, clés cryptographiques codées en dur intégrées au SDK mobile et au firmware déployé) pour lequel un correctif côté serveur n’est pas architecturalement suffisant », estime de son côté l’auteur de la découverte.

La marque minimise l’impact

Il relate par ailleurs la chronologie de ses échanges avec Aqara, de la première prise de contact, en mars, à la déclaration publique transmise le 11 juin, date de la publication de ses découvertes. Dans cette dernière, telle que reproduite par Sammy Azdoufal, l’entreprise affirme que « la possibilité potentielle de contrôler les appareils des utilisateurs se rapporte à un environnement de test totalement distinct des systèmes de production d’Aqara », et que l’accès « à de véritables appareils ou comptes utilisateurs via l’environnement de test est impossible dans notre architecture, car les environnements ne partagent aucune donnée utilisateur, identifiant ni service backend ».

Des affirmations que réfute le chercheur indépendant. « Le point d’accès de récupération des jetons (famille CVE-2026-50083) a renvoyé 2 969 sessions actives, dont les sessions JWT actives de deux employés d’Aqara. Les environnements de test ne contiennent pas les sessions de travail actives des employés réels », fait-il par exemple valoir.

Nous avons contacté Aqara pour essayer de tirer au clair ces contradictions. En attendant, les utilisateurs de l’application du même nom ont sans doute tout intérêt à révoquer les autorisations tierces qu’ils n’auraient pas eux-mêmes accordées dans les paramètres de leur compte. Ainsi qu’à privilégier les options de contrôle local, notamment via HomeKit, plutôt que de piloter leurs appareils par l’intermédiaire d’un cloud opéré par le fabricant. Un conseil qui vaut sans doute d’ailleurs bien au-delà du cas particulier d’Aqara…

• Domotique « intelligente » : ne nous laissons pas enfermer par nos objets connectés