### Impatto sul sistema vulnerabile```
Vuln Confidentiality:   [None]     Low      High
Vuln Integrity:         [None]     Low      High
Vuln Availability:      [High]     Low      None

---

## Classificazione CWE

| # | CWE ID | Nome | Rilevanza |
|---|---|---|---|
| 1 | **CWE-617** | [Reachable Assertion](https://cwe.mitre.org/data/definitions/617.html) | Il codice di produzione espone un'asserzione o un controllo fatale raggiungibile da input non fidato, terminando il processo o il sistema |

### Perché CWE-617 è pertinente

CWE-617 descrive situazioni in cui gli sviluppatori fanno affidamento su asserzioni per condizioni che **gli attaccanti esterni possono forzare**. A differenza di una gestione degli errori pulita (codici di ritorno, risposte sanificate), un'asserzione raggiungibile termina spesso con **un'interruzione improvvisa**, in linea con il comportamento di **crash o riavvio** descritto dal fornitore.

---

## Prerequisiti dell'attacco

| Prerequisito | Richiesto? | Note |
|---|---|---|
| Credenziali valide del dispositivo | **No** | Attacco non autenticato |
| Interazione dell'utente vittima | **No** | Attivazione completamente remota tramite rete |
| Compromissione preliminare di un altro sistema | **No** | Sfruttamento autonomo |
| Raggiungibilità di rete del dispositivo | **Sì** | Il vettore di attacco è la Rete |
| Conoscenza del modello di dispositivo | Utile, non strettamente richiesta | Il pacchetto appositamente costruito può essere specifico per famiglia |
| Esposizione a Internet | **Non richiesta**, ma aumenta il rischio | L'esposizione tramite port-forwarding WAN e relay cloud è comune nella pratica |

**Sfruttabile da remoto:** **Sì**

---

## Scenari di sfruttamento

### Scenario 1 — Telecamera esposta a Internet

Una telecamera IP fissa è configurata con port-forwarding per la visualizzazione remota. Un attaccante esegue una scansione dell'host, invia il pacchetto appositamente costruito a una porta di servizio aperta e forza un riavvio. La telecamera va offline durante un incidente di sicurezza in corso, creando un vuoto nelle registrazioni.

### Scenario 2 — VLAN CCTV piatta

Un attaccante ottiene un punto d'appoggio su un laptop aziendale (phishing, dispositivo di un appaltatore, ecc.) e prende di mira ogni host Dahua sulla VLAN di sorveglianza. Attivazioni sequenziali producono un evento "tutte le telecamere offline" a livello di sito senza mai autenticarsi al software VMS.

### Scenario 3 — Interruzione del citofono (VTO/VTH)

Un negozio al dettaglio utilizza citofoni Dahua. Un attaccante vicino alla rete (o tramite WAN esposta) riavvia ripetutamente la postazione esterna durante le ore di punta. La validazione degli ingressi e lo sblocco remoto delle porte falliscono, causando l'arresto operativo o procedure manuali di bypass.

### Scenario 4 — Degrado a catena della sicurezza fisica

Il riavvio dell'NVR durante un'intrusione in corso ritarda la verifica degli allarmi e il tracciamento PTZ. Pur non essendo una CVE di "integrità" diretta secondo CVSS, l'esito sulla sicurezza fisica può essere grave.

### Scenario 5 — Molestie sostenute / Degrado del servizio

La riproduzione automatica del trigger ogni N minuti impedisce un uptime stabile anche se il dispositivo si ripristina rapidamente ogni volta — un attacco a **basso sforzo e alta interruzione**, adatto ad abusi su scala botnet contro impronte firmware note.

---

## Valutazione dell'impatto

### Impatto tecnico

| Dominio | Valutazione | Dettaglio |
|---|---|---|
| Riservatezza | Nessuno (diretto) | Nessuna esfiltrazione di dati dimostrata tramite questa sola vulnerabilità |
| Integrità | Nessuno (diretto) | Nessuna manomissione dimostrata di configurazione o filmati tramite questa sola vulnerabilità |
| Disponibilità | **Alto** | Interruzione a livello di riavvio; ripetibile |

### Impatto aziendale (contestuale)

| Settore | Conseguenza potenziale |
|---|---|
| Vendita al dettaglio / Bancario | Perdita di video forensi durante eventi di calo inventariale o frode |
| Infrastrutture critiche | Lacune nella verifica visiva degli allarmi |
| Residenziale / PMI | Angoli ciechi nel monitoraggio domestico durante le effrazioni |
| Città intelligente | Caduta delle telecamere per il traffico o la sicurezza pubblica |
| Integrazioni di controllo accessi | Porte e citofoni non disponibili nelle ore di punta |

### Considerazioni a livello di parco dispositivi

Le organizzazioni con **centinaia o migliaia** di endpoint Dahua dovrebbero modellare:

- Tempo medio di ripristino per riavvio
- Rumore nel monitoraggio centrale durante interruzioni di massa
- Violazioni degli SLA con i clienti di servizi gestiti
- Implicazioni assicurative o di conformità per la continuità delle registrazioni

---

## Rilevamento e indicatori di compromissione

Poiché il fornitore non ha pubblicato catture di pacchetti o firme specifiche per la CVE, il rilevamento dovrebbe concentrarsi su **indicatori comportamentali**:

### Indicatori su host / dispositivo

- Riavvii imprevisti senza aggiornamenti iniziati dall'amministratore o eventi di alimentazione
- Flag del motivo di avvio che fanno riferimento a kernel panic, reset del watchdog o riavvio anomalo
- Log applicativi che mostrano errori di asserzione o errori fatali immediatamente prima del fermo
- Uptime brevi correlati a raffiche di traffico di rete anomalo

### Indicatori di rete

- Raffiche da fonte singola o distribuite di pacchetti anomali che precedono eventi di messa offline dei dispositivi
- Nuova attività di scansione sulle porte di servizio associate a Dahua da sottoreti non fidate
- Correlazione tra modelli esterni SYN/UDP/HTTP e timestamp di riavvio nel syslog di telecamere/NVR

### Correlazioni operative

- Più dispositivi offline contemporaneamente senza guasto dello switch PoE
- Eventi di offline **non** accompagnati da errori di interfaccia dello switch (che suggeriscono un crash a livello di endpoint)
- Interruzioni ricorrenti a intervalli fissi (possibile attacco di riproduzione automatica)

### Registrazione consigliata

- Centralizzare il **syslog** di telecamere, NVR e citofoni
- Conservare i **flussi firewall / perimetrali** per i segmenti che contengono apparecchiature di sorveglianza
- Avvisare su **eventi di disconnessione di massa** dei dispositivi dal VMS entro brevi finestre temporali

---

## Mitigazione e rimedio

### Rimedio principale — Aggiornamento firmware

1. Inventariare tutti i dispositivi Dahua con modello, seriale e **data di build del firmware**.
2. Identificare le unità con build **precedenti al 26 marzo 2026**.
3. Scaricare il firmware approvato dal fornitore dal [Dahua PSI Trust Center](https://www.dahuasecurity.com/about-dahua/trust-center/dahua-psi) o da canali di distribuzione autorizzati.
4. Programmare gli aggiornamenti in una finestra di manutenzione; validare la funzione di registrazione e citofonia dopo la patch.
5. Ritestare i servizi esposti esternamente solo dopo la conferma della build corretta.

### Controlli compensativi (fino alla patch)

| Controllo | Obiettivo |
|---|---|
| **Segmentazione di rete** | Posizionare telecamere/NVR su VLAN dedicate con ACL deny-by-default |
| **Rimuovere il port-forwarding** | Eliminare l'esposizione WAN diretta; utilizzare invece VPN o accesso zero-trust |
| **Limitare gli IP di origine** | Consentire solo a VMS, host di salto e sottoreti operative di raggiungere le porte di gestione dei dispositivi |
| **Disabilitare i servizi non utilizzati** | Ridurre la superficie di attacco dei protocolli (disabilitare HTTP/ONVIF/PPPoE/ecc. non necessari) |
| **Filtraggio in uscita** | Limitare comportamenti di relay imprevisti dove la policy lo consente |
| **Ricerambi fisici / failover** | Per le riprese critiche, mantenere una copertura sovrapposta |

### Gestione del cambiamento aziendale

- Documentare le versioni del firmware nel CMDB
- Collegare lo stato delle patch ai flussi di lavoro di approvvigionamento e RMA
- Includere il monitoraggio del Dahua PSI nella cadenza di revisione del rischio fornitore

---

## Soluzioni alternative

Non è nota alcuna **soluzione alternativa documentata dal fornitore, basata solo sulla configurazione**, in grado di eliminare completamente la vulnerabilità senza passare a una build corretta. Fino all'applicazione del firmware, il **contenimento a livello di rete** è la soluzione alternativa pratica:

1. Bloccare le reti non fidate dall'accesso alle porte di gestione dei dispositivi e ai servizi proprietari.
2. Monitorare i modelli di riavvio ripetuti e isolare le sorgenti problematiche sul firewall perimetrale.
3. Dove disponibile, collocare i dispositivi dietro concentratori VPN autenticati invece dell'esposizione diretta.

---

## Risposta del fornitore

Dahua ha pubblicato questo problema attraverso il suo programma **Product Security Incident (PSI)**. Risorse ufficiali:

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

Gli operatori dovrebbero considerare il bollettino del fornitore come la fonte autorevole per:

- Elenchi dei modelli interessati specifici
- Link di download del firmware corretto
- Ulteriori raccomandazioni di hardening

---

## Riferimenti

| Risorsa | URL |
|---|---|
| Dahua PSI Trust Center | https://www.dahuasecurity.com/about-dahua/trust-center/dahua-psi |
| Voce NVD | https://nvd.nist.gov/vuln/detail/CVE-2026-29116 |
| Record CVE | https://www.cve.org/CVERecord?id=CVE-2026-29116 |
| Definizione CWE-617 | https://cwe.mitre.org/data/definitions/617.html |
| Specifica CVSS 4.0 | https://www.first.org/cvss/v4.0/specification-document |

---

## Disclaimer

Questo documento è un **advisory di sicurezza informativo** compilato da metadati CVE disponibili pubblicamente e dichiarazioni del fornitore. È inteso ad assistere difensori, integratori e ricercatori nella comprensione del rischio di **CVE-2026-29116** e nella prioritizzazione del rimedio.

- Questo README **non** fornisce codice di exploit, modelli di pacchetti appositamente costruiti o istruzioni di attacco passo-passo.
- Le sezioni di analisi tecnica contrassegnate come *inferite* sono interpretazioni ragionevoli dei dati pubblici, non una divulgazione della causa principale confermata dal fornitore.
- La determinazione dei modelli interessati **deve** essere verificata rispetto al bollettino ufficiale Dahua PSI e alla data di build del firmware del dispositivo.
- Gli autori non sono responsabili per le azioni intraprese sulla base di questo documento. Applica le patch, esegui test e distribuisci secondo le policy di gestione del cambiamento della tua organizzazione.

**Uso responsabile:** segnala risultati aggiuntivi attraverso canali di divulgazione coordinata (PSI del fornitore, CERT nazionale o programmi bug bounty consolidati dove applicabili).

---

## Cronologia delle revisioni del documento

| Versione | Data | Modifiche |
|---|---|---|
| 1.0 | 2026-07-11 | README advisory completo iniziale basato sui dati di pubblicazione di CVE-2026-29116 |

---

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