CVE-2026-79551 Clé privée TLS codée en dur Tenda

ID CNVD : CNVD-2026-25884

Fournisseur : Tenda Technology Co., Ltd.

Produit : Enregistreur vidéo réseau NVR_4H (version matérielle CH3V2.1)

Micrologiciel : V27.5.58.6

Classe : CWE-321 — Utilisation d'une clé cryptographique codée en dur

Aperçu

Le micrologiciel du NVR_4H stocke une paire de clés ECDSA dans sa partition en lecture seule user-x.squashfs (montée sur /opt/app/) : la clé privée dans /etc/privkey.pem et le certificat auto-signé correspondant dans /etc/cacert.pem. Les deux ont été générés une seule fois au moment de la compilation et intégrés à l'image, de sorte que chaque appareil exécutant la version V27.5.58.6 est livré avec la même clé privée.

L'image du micrologiciel est téléchargeable gratuitement depuis le site web de Tenda. Quiconque la décompresse détient une clé privée fonctionnelle pour l'interface HTTPS de chaque NVR_4H sous cette version. Un attaquant présent sur le même réseau (LAN, Wi-Fi ou un appareil exposé à Internet) peut interposer un proxy entre le navigateur de l'administrateur et le NVR via un empoisonnement ARP ou DNS, présenter le véritable certificat Tenda avec la clé extraite, et le navigateur n'affichera aucun avertissement. La session complète est alors lisible et modifiable en temps réel : connexion administrateur, jetons de session, identifiants RTSP des caméras, configuration de l'appareil.

Fichiers concernés

Fichier	Description
`/etc/privkey.pem`	Clé privée EC de 302 octets (P-256)
`/etc/cacert.pem`	Certificat auto-signé de 802 octets, `O=Tenda, OU=Video Surveillance, CN=www.tenda.com.cn`

Reproduction

Le conteneur du micrologiciel est une archive ZIP située à l'offset 0xBBB :

# 1. unpack the firmware
binwalk -e ted.bin

cd ted.bin.extracted/BBB

# 2. strip the 64-byte proprietary header
dd if=user-x.squash.img of=pure_system.squashfs bs=1 skip=64

# 3. unpack the filesystem
unsquashfs pure_system.squashfs

# 4. locate the key material
find squashfs-root -name "*.pem"
# squashfs-root/etc/cacert.pem
# squashfs-root/etc/privkey.pem

Pour confirmer que la clé privée appartient bien au certificat livré, exportez la clé publique des deux et comparez :

openssl ec -in squashfs-root/etc/privkey.pem -pubout > pub_from_priv.pem
openssl x509 -in squashfs-root/etc/cacert.pem -pubkey -noout > pub_from_cert.pem

diff pub_from_priv.pem pub_from_cert.pem
# no output

sha256sum pub_from_priv.pem pub_from_cert.pem
# 80b6aa4b9e8f4cd30e857ff5b9bfcf7e0227e268f4d397efdaffe37d4b0e9bcc  (both files)

La clé fonctionne également directement depuis l'image :

openssl s_server \
  -key  squashfs-root/etc/privkey.pem \
  -cert squashfs-root/etc/cacert.pem \
  -accept 4433 -www
# ACCEPT — TLS server starts with no errors

Une seule clé pour chaque appareil

user-x.squashfs est un système de fichiers compressé en lecture seule, son contenu est donc identique octet pour octet sur chaque unité livrée.
Il n'existe aucun provisionnement par appareil nulle part dans l'image : aucun script d'initialisation, aucun binaire openssl, aucune génération de clé au premier démarrage. Les seules chaînes liées à la génération de clés dans l'ensemble du système de fichiers proviennent de hostapd et wpa_supplicant, qui n'ont rien à voir avec le serveur HTTPS.
Le répertoire /etc/ à l'intérieur du squashfs ne contient que quatre fichiers, dont deux constituent ce matériel de clé. Les deux portent l'horodatage de compilation du squashfs plutôt qu'un horodatage d'exécution.

Certificat et clé extraits

Le certificat est de type X.509 v1, auto-signé (émetteur = sujet = C=CN, ST=ZJ, L=HZ, O=Tenda, OU=Video Surveillance, CN=www.tenda.com.cn), valide du 1999-12-31 au 2049-12-18, sans SAN ni extensions d'usage de clé. Le numéro de série 1c:f2:13:a0:7b:e2:7c:91:63:f3:e0:0c:be:0f:0d:42:2e:6b:e8:69 est fixe et identique sur tous les appareils.

La clé privée extraite, utilisable telle quelle :

Impact

La confidentialité et l'intégrité de toute l'interface de gestion HTTPS sont perdues pour chaque appareil sous cette version du micrologiciel, face à quiconque a téléchargé l'image publique. Aucun privilège et aucune interaction utilisateur ne sont nécessaires du côté de la cible — un MITM passif suffit. Les identifiants administrateur volés donnent un contrôle total sur l'enregistreur et ses caméras.

Correctif

Générer une paire de clés unique par appareil au premier démarrage et la stocker sur une partition inscriptible (par exemple la zone JFFS2 sous /opt/sav/), et supprimer entièrement privkey.pem et cacert.pem de l'image en lecture seule. À plus long terme, émettre des certificats par appareil signés au moment de la fabrication.

CVE-2026-79551-Tenda

Populaires