Contexte et limites du cloud Coway

Le modèle Coway Airmega IconS est un purificateur d’air équipé d’un filtre HEPA et d’un capteur de qualité d’air. La version vendue entre 2017 et 2022 intègre le Wi‑Fi et repose exclusivement sur le service cloud de Coway pour toute commande à distance. L’application iPhone officielle agit comme un client HTTPS qui interroge api.coway.com pour récupérer l’état et envoyer les réglages du ventilateur. Une intégration tierce pour Home Assistant a été créée en reproduisant le protocole de l’application : elle interroge le même endpoint cloud et transmet les réponses à Apple Home. Cette solution fonctionne tant que le serveur cloud reste disponible et que Coway ne modifie pas le format HTML scrappé par l’intégration.

Le texte indique plusieurs ruptures observées : bannissement de l’IP après trop de requêtes, refonte de l’application (IoCare → IoCare+), changements mineurs du HTML, indisponibilité ponctuelle du serveur et suspension du compte utilisateur. Ces incidents démontrent la dépendance totale du dispositif à une infrastructure externe qui n’est pas garantie à long terme.

Mécanisme de la communication et points d’interception

Le purificateur établit une connexion TLS vers le domaine Coway dès le démarrage. Le certificat présenté est signé par une autorité racine incluse dans le firmware. Aucun mécanisme de pinning de certificat n’est mentionné, ce qui laisse la porte ouverte à une interception si le dispositif accepte un certificat alternatif signé par une autorité compromise. L’article cite un incident d’octobre 2026 où l’autorité eMudhra a utilisé des paramètres de clé privés faibles, créant ainsi un vecteur potentiel d’usurpation de certificat.

En pratique, la première étape consiste à placer le dispositif entre le purificateur et Internet afin de capturer le trafic TLS. Le choix d’un Raspberry Pi comme point d’accès Wi‑Fi dédié permet d’isoler le flux sans perturber le réseau domestique.

Mise en place du proxy MITM avec nftables

Le Pi est configuré en mode point d’accès (interface wlan0) et relié à l’ordinateur portable via Ethernet, qui assure la passerelle vers le réseau principal. Le filtrage NAT est réalisé avec nftables, redirigeant les paquets TCP destinés aux ports 80 et 443 vers le port local 8080 où un proxy transparent (par ex. mitmproxy) écoute. Le jeu de règles complet, extrait du journal de l’auteur, est présenté ci‑dessous :

table inet mitmproxy_ap {
    set client_interfaces {
        type ifname
        elements = { "wlan0" }
    }
    chain prerouting {
        type nat hook prerouting priority dstnat; policy accept;
        meta nfproto ipv4 iifname @client_interfaces tcp dport { 80, 443 } \
            counter packets 2 bytes 120 redirect to :8080
    }
    chain input {
        type filter hook input priority filter - 10; policy accept;
        iifname != "lo" iifname != @client_interfaces tcp dport 8080 \
            counter packets 0 bytes 0 reject with tcp reset
        iifname @client_interfaces meta nfproto ipv6 counter packets 9 bytes 2397 drop
        iifname @client_interfaces ct state established,related accept
    }
}

Ces règles assurent que tout le trafic HTTP/HTTPS du purificateur transite par le proxy, où le certificat du serveur peut être remplacé par un certificat auto‑signé accepté par le dispositif grâce à l’absence de pinning.

Analyse des risques et perspectives

Le contournement du cloud élimine la dépendance aux serveurs Coway, mais introduit de nouveaux vecteurs de menace. Le proxy doit être maintenu à jour pour éviter les failles TLS, et le certificat factice doit rester valide vis‑à‑vis du firmware. De plus, l’interception expose les données de qualité d’air et les réglages du ventilateur à un point de contrôle local, ce qui peut être exploité si le Pi est compromis.

Le recours à un LLM (ChatGPT) pour générer automatiquement les règles nftables et le script de mise en place montre comment l’IA accélère le prototypage d’infrastructures de test. Cependant, la solution reste fragile : toute mise à jour du firmware qui introduirait le pinning ou qui supprimerait les certificats racines embarqués rendrait l’attaque impossible sans re‑flash du dispositif.

En conclusion, le projet démontre qu’un appareil IoT grand public peut être libéré de son service cloud en combinant analyse du trafic, exploitation d’une faiblesse de chaîne de confiance et automatisation par IA. La viabilité à long terme dépendra de la capacité du fabricant à renforcer la chaîne TLS ou à fournir une API locale officielle.