### Impact sur le système vulnérable```
Vuln Confidentiality:   [None]     Low      High
Vuln Integrity:         [None]     Low      High
Vuln Availability:      [High]     Low      None

---

## Classification CWE

| # | ID CWE | Nom | Pertinence |
|---|---|---|---|
| 1 | **CWE-617** | [Reachable Assertion](https://cwe.mitre.org/data/definitions/617.html) | Le code de production expose une assertion ou un contrôle fatal accessible par une entrée non fiable, entraînant l'arrêt du processus ou du système |

### Pourquoi CWE-617 s'applique

CWE-617 décrit les situations où les développeurs s'appuient sur des assertions pour des conditions que des **attaquants externes peuvent provoquer**. Contrairement à une gestion élégante des erreurs (codes de retour, réponses assainies), une assertion accessible se termine souvent par un **arrêt brutal** — ce qui correspond au comportement de **crash ou de redémarrage** décrit par le fournisseur.

---

## Prérequis d'attaque

| Prérequis | Requis ? | Notes |
|---|---|---|
| Identifiants valides de l'appareil | **Non** | Attaque non authentifiée |
| Interaction de l'utilisateur victime | **Non** | Déclenchement réseau entièrement distant |
| Compromission préalable d'un autre système | **Non** | Exploitation autonome |
| Accessibilité réseau de l'appareil | **Oui** | Le vecteur d'attaque est le réseau |
| Connaissance du modèle d'appareil | Utile, pas strictement requis | Le paquet forgé peut être spécifique à une famille |
| Exposition à Internet | **Non requise**, mais augmente le risque | La redirection de port WAN et l'exposition via relais cloud sont courantes en pratique |

**Exploitable à distance :** **Oui**

---

## Scénarios d'exploitation

### Scénario 1 — Caméra exposée à Internet

Une IPC fixe est configurée avec une redirection de port pour la visualisation à distance. Un attaquant scanne l'hôte, envoie le paquet forgé à un port de service ouvert et force un redémarrage. La caméra se déconnecte pendant un incident de sécurité actif, créant une lacune d'enregistrement.

### Scénario 2 — VLAN CCTV plat

Un attaquant prend pied sur un ordinateur portable d'entreprise (hameçonnage, appareil de prestataire, etc.) et cible chaque hôte Dahua du VLAN de surveillance. Des déclenchements séquentiels produisent un événement « toutes les caméras hors ligne » à l'échelle du site, sans jamais s'authentifier auprès du logiciel VMS.

### Scénario 3 — Perturbation de l'interphonie (VTO/VTH)

Un magasin de détail utilise des stations de porte Dahua. Un attaquant proche du réseau (ou via un WAN exposé) redémarre à plusieurs reprises la station extérieure aux heures de pointe. La validation d'entrée et le déverrouillage de porte à distance échouent, provoquant un arrêt opérationnel ou des procédures de contournement manuelles.

### Scénario 4 — Dégradation en chaîne de la sécurité physique

Un redémarrage du NVR pendant une intrusion active retarde la vérification des alarmes et le suivi PTZ. Bien qu'il ne s'agisse pas d'une CVE d'« intégrité » directe selon le CVSS, l'**impact sur la sécurité physique** peut être grave.

### Scénario 5 — Harcèlement prolongé / Dégradation de service

Le rejeu automatisé du déclencheur toutes les N minutes empêche une disponibilité stable, même si l'appareil récupère rapidement à chaque fois — une attaque à **faible effort et forte perturbation**, adaptée à un abus à l'échelle d'un botnet contre des empreintes de firmware connues.

---

## Évaluation de l'impact

### Impact technique

| Domaine | Évaluation | Détail |
|---|---|---|
| Confidentialité | Aucune (directe) | Aucune exfiltration de données prouvée via cette seule faille |
| Intégrité | Aucune (directe) | Aucune altération prouvée de la configuration ou des séquences vidéo via cette seule faille |
| Disponibilité | **Élevée** | Panne au niveau du redémarrage ; reproductible |

### Impact métier (contextuel)

| Secteur | Conséquence potentielle |
|---|---|
| Commerce de détail / Banque | Perte de vidéo d'enquête lors d'événements de démarque ou de fraude |
| Infrastructure critique | Lacunes dans la vérification visuelle des alarmes |
| Résidentiel / PME | Angles morts dans la surveillance du domicile lors d'effractions |
| Ville intelligente | Perte de signal des caméras de circulation ou de sécurité publique |
| Intégrations de contrôle d'accès | Portes et interphones indisponibles aux heures de pointe |

### Considérations à l'échelle du parc

Les organisations disposant de **centaines ou de milliers** de points de terminaison Dahua devraient modéliser :

- Le délai moyen de récupération par redémarrage
- Le bruit de la supervision centralisée lors de pannes massives
- Les violations de SLA avec les clients de services gérés
- Les implications en matière d'assurance et de conformité pour la continuité des enregistrements

---

## Détection et indicateurs de compromission

Étant donné que le fournisseur n'a pas publié de captures de paquets ni de signatures spécifiques à la CVE, la détection doit se concentrer sur des **indicateurs comportementaux** :

### Indicateurs hôte / appareil

- Redémarrages inattendus sans mises à niveau initiées par l'administrateur ni événements d'alimentation
- Indicateurs de motif de démarrage faisant référence à une panique du noyau, à une réinitialisation du watchdog ou à un redémarrage anormal
- Journaux d'application montrant des échecs d'assertion ou des erreurs fatales immédiatement avant la panne
- Durées de fonctionnement courtes corrélées à des rafales de trafic réseau anormal

### Indicateurs réseau

- Rafales de paquets anormaux, mono-source ou distribuées, précédant les événements de mise hors ligne des appareils
- Nouvelle activité de scan sur les ports de service associés à Dahua depuis des sous-réseaux non fiables
- Corrélation entre les schémas SYN/UDP/HTTP externes et les horodatages de redémarrage syslog des caméras/NVR

### Corrélations opérationnelles

- Plusieurs appareils hors ligne simultanément sans panne du commutateur PoE
- Événements de mise hors ligne **non** accompagnés d'erreurs d'interface de commutateur (suggérant un crash au niveau du point de terminaison)
- Pannes récurrentes à intervalles fixes (possible attaque par rejeu automatisé)

### Journalisation recommandée

- Centraliser les journaux **syslog** des caméras, NVR et interphones
- Conserver les flux **pare-feu / périphérie** pour les segments contenant des équipements de surveillance
- Alerter sur les événements de **déconnexion massive d'appareils** depuis le VMS dans de courtes fenêtres de temps

---

## Atténuation et remédiation

### Remédiation principale — Mise à jour du firmware

1. Inventorier tous les appareils Dahua avec le modèle, le numéro de série et la **date de compilation du firmware**.
2. Identifier les unités dont les compilations sont **antérieures au 26 mars 2026**.
3. Télécharger le firmware approuvé par le fournisseur depuis le [Dahua PSI Trust Center](https://www.dahuasecurity.com/about-dahua/trust-center/dahua-psi) ou des canaux de distribution autorisés.
4. Planifier les mises à niveau dans une fenêtre de maintenance ; valider la fonction d'enregistrement et d'interphonie après l'application du correctif.
5. Re-tester les services exposés à l'extérieur uniquement après confirmation de la compilation corrigée.

### Contrôles compensatoires (jusqu'au correctif)

| Contrôle | Objectif |
|---|---|
| **Segmentation du réseau** | Placer les caméras/NVR sur des VLAN dédiés avec des ACL en refus par défaut |
| **Supprimer la redirection de port** | Éliminer l'exposition WAN directe ; utiliser un VPN ou un accès zero-trust à la place |
| **Restreindre les IP sources** | Autoriser uniquement le VMS, les hôtes de rebond et les sous-réseaux d'opérateurs à atteindre les ports de gestion des appareils |
| **Désactiver les services inutilisés** | Réduire la surface d'attaque des protocoles (désactiver HTTP/ONVIF/PPPoE/etc. non nécessaires) |
| **Filtrage sortant** | Limiter le comportement de relais inattendu là où la politique le permet |
| **Pièces de rechange physiques / bascule** | Pour les angles critiques, maintenir une couverture redondante |

### Gestion du changement en entreprise

- Documenter les versions de firmware dans la CMDB
- Lier le statut des correctifs aux flux de travail d'approvisionnement et RMA
- Inclure la surveillance Dahua PSI dans la cadence d'examen des risques fournisseurs

---

## Contournements

Aucun **contournement basé uniquement sur la configuration** documenté par le fournisseur n'est connu pour éliminer entièrement la vulnérabilité sans passer à une compilation corrigée. Jusqu'à l'application du firmware, le **confinement au niveau réseau** est le contournement pratique :

1. Bloquer les réseaux non fiables pour qu'ils ne puissent pas atteindre les ports de gestion des appareils et les ports de services propriétaires.
2. Surveiller les schémas de redémarrage répétés et isoler les sources fautives au niveau du pare-feu périphérique.
3. Lorsque c'est possible, placer les appareils derrière des concentrateurs VPN authentifiés plutôt qu'en exposition directe.

---

## Réponse du fournisseur

Dahua a publié ce problème via son programme **Product Security Incident (PSI)**. Ressources officielles :

- **Trust Center / PSI :** https://www.dahuasecurity.com/about-dahua/trust-center/dahua-psi

Les opérateurs doivent considérer le bulletin du fournisseur comme la source faisant autorité pour :

- Les listes d'appareils affectés par modèle
- Les liens de téléchargement des firmwares corrigés
- Les recommandations de durcissement supplémentaires

---

## Références

| Ressource | URL |
|---|---|
| Dahua PSI Trust Center | https://www.dahuasecurity.com/about-dahua/trust-center/dahua-psi |
| Fiche NVD | https://nvd.nist.gov/vuln/detail/CVE-2026-29116 |
| Enregistrement CVE | https://www.cve.org/CVERecord?id=CVE-2026-29116 |
| Définition CWE-617 | https://cwe.mitre.org/data/definitions/617.html |
| Spécification CVSS 4.0 | https://www.first.org/cvss/v4.0/specification-document |

---

## Avertissement

Ce document est un **avis de sécurité informatif** compilé à partir de métadonnées CVE publiquement disponibles et de déclarations du fournisseur. Il est destiné à aider les défenseurs, les intégrateurs et les chercheurs à comprendre le risque **CVE-2026-29116** et à prioriser la remédiation.

- Ce README **ne fournit pas** de code d'exploitation, de modèles de paquets forgés ni d'instructions d'attaque étape par étape.
- Les sections d'analyse technique marquées *inférées* sont des interprétations raisonnables des données publiques, et non une divulgation de cause racine confirmée par le fournisseur.
- La détermination des modèles affectés **doit** être vérifiée par rapport au bulletin officiel Dahua PSI et à la date de compilation du firmware de votre appareil.
- Les auteurs ne sont pas responsables des actions entreprises sur la base de ce document. Corrigez, testez et déployez conformément aux politiques de gestion du changement de votre organisation.

**Utilisation responsable :** Signalez toute découverte supplémentaire via des canaux de divulgation coordonnée (PSI du fournisseur, CERT national ou programmes de bug bounty établis le cas échéant).

## Historique des révisions du document

| Version | Date | Modifications |
|---|---|---|
| 1.0 | 2026-07-11 | README d'avis initial complet basé sur les données de publication de CVE-2026-29116 |

---

<p align="center">
  <sub>CVE-2026-29116 · Dahua Technology · CVSS 4.0 8.7 HIGH · CWE-617</sub>
</p>