crimsonfiedofficial/cve-2026-29114Dahua CVE-2026-29114
Tipo di advisory: Divulgazione di sicurezza coordinata dal vendor
ID CVE: CVE-2026-29114
Vendor: Dahua Technology
Pubblicata: 2026-06-10T05:44:50 UTC
Ultima modifica: 2026-06-10T05:44:50 UTC
Fonte: Dahua Product Security Incident (PSI) Trust Center
È stata identificata una vulnerabilità di fiducia dei certificati a bassa gravità in alcuni modelli Dahua IPC (telecamera IP). In determinate condizioni di distribuzione, un attaccante remoto può ottenere il certificato root CA interno del dispositivo — materiale che dovrebbe rimanere riservato alla gerarchia dell'autorità di certificazione.
Se tale root CA (o un'autorità intermedia da essa derivata) è stata installata e considerata attendibile su workstation client, browser o middleware, un attaccante in possesso del materiale della chiave privata può generare certificati X.509 fraudolenti che i client che eseguono la validazione accetteranno come legittimi. Ciò consente attacchi person-in-the-middle (MITM) contro sessioni HTTPS o protette da TLS che fanno riferimento all'ancora di fiducia compromessa, minando la riservatezza e l'integrità delle connessioni client interessate.
Il punteggio base CVSS 4.0 pubblicato è 2.3 (BASSO). Il punteggio relativamente basso riflette le precondizioni di distribuzione (AT:P — requisiti di attacco presenti) e l'interazione passiva dell'utente (UI:P) necessaria per un impatto pratico, oltre a valutazioni Basse (non Alte) di riservatezza e integrità dirette sul dispositivo vulnerabile stesso. La disponibilità non è compromessa (VA:N).
Le organizzazioni che eseguono build di firmware IPC interessate precedenti al 15 aprile 2026 dovrebbero verificare se le CA emesse dal dispositivo siano mai state distribuite agli endpoint, rimuovere le root non attendibili dagli archivi di fiducia dei client, ruotare le configurazioni TLS e aggiornare il firmware.
Nota sull'etichettatura dell'advisory: alcuni indici intitolano questa CVE "Dahua Data Breach." La descrizione del vendor riguarda l'esposizione del certificato root CA del dispositivo e il successivo abuso della fiducia PKI — non l'esfiltrazione di massa di video registrati o database di clienti. Il presente documento segue la descrizione del vendor e i dati di punteggio CVSS.
La CVE-2026-29114 è stata pubblicata il 2026-06-10 insieme ad altre divulgazioni Dahua PSI dello stesso lotto. I problemi sono distinti per meccanismo e profilo di impatto.
Sintesi per i difensori: questa CVE non è un difetto di riavvio della telecamera. È un problema di igiene PKI e di archivio di fiducia. L'applicazione delle patch è importante, ma rimuovere le CA del dispositivo erroneamente considerate attendibili dalle macchine client è spesso il passo di remediation decisivo.
Dahua ha segnalato una vulnerabilità in alcuni modelli IPC tramite la quale un soggetto remoto può ottenere il materiale sensibile dell'autorità di certificazione (CA) associato al dispositivo. Il vendor dichiara che un attaccante può ottenere il certificato root CA del dispositivo.
La sicurezza della PKI X.509 dipende da chiavi private che rimangono segrete e da ancore di fiducia scelte deliberatamente. Se:
allora un attaccante può:
Secondo il vettore pubblicato:
SC:N, SI:N, SA:N)Il danno pratico si manifesta spesso sui sistemi client che considerano attendibile la CA esposta, motivo per cui le metriche requisiti di attacco e interazione dell'utente sono elevate nel modello di punteggio.
Molti dispositivi embedded vengono forniti con PKI di fabbrica o inclusa nel firmware per supportare:
| Caso d'uso | Ruolo tipico della CA del dispositivo |
|---|---|
| Interfaccia web HTTPS | Certificato TLS firmato localmente per https://camera-ip |
| TLS ONVIF / SDK | Canali di gestione crittografati |
Quando gli installer o i pacchetti software inseriscono la CA del dispositivo negli archivi di fiducia di Windows/macOS/Linux, ogni certificato firmato da tale CA diventa affidabile quanto una CA pubblica — per quegli endpoint.
CWE-538 riguarda l'inserimento di informazioni sensibili (chiavi, password, certificati) in file o directory raggiungibili senza un'adeguata protezione. In questo caso, il certificato root CA (e potenzialmente il materiale della chiave o i segreti di firma recuperabili, a seconda dell'implementazione — il testo del vendor enfatizza l'ottenibilità del certificato) è esposto tramite un percorso raggiungibile dalla rete senza autenticazione.
AT:P significa che lo sfruttamento o l'impatto significativo non è universale; esistono condizioni aggiuntive:
| Prerequisito tipico | Spiegazione |
|---|---|
| Installazione della fiducia sul client | I sistemi vittima devono considerare attendibile la root CA del dispositivo |
| Percorso di rete verso il materiale esposto | L'attaccante può raggiungere l'endpoint che serve il certificato |
| Dipendenza TLS da tale ancora di fiducia | Utenti o app devono connettersi a servizi validati tramite la CA compromessa |
Senza fiducia lato client, ottenere il solo certificato CA (componente pubblica) è spesso insufficiente per un MITM — anche la chiave privata deve essere compromessa. Il linguaggio del vendor si concentra sull'ottenimento del certificato root CA; i difensori dovrebbero presupporre che l'intera catena di fiducia possa essere a rischio fino a quando l'analisi del firmware o le rettifiche del vendor non chiariscano l'esposizione delle chiavi.
L'interazione passiva nel CVSS 4.0 significa che la vittima deve compiere un'azione volontaria ma a basso attrito — non necessariamente fare clic su un link dannoso. Gli esempi includono:
In tutti i modelli di distribuzione non è richiesto che l'utente approvi attivamente un'eccezione di sicurezza, ma un certo utilizzo della TLS guidato dall'utente fa parte del percorso di attacco.
Poiché PR:N e AV:N, il meccanismo di esposizione è raggiungibile senza credenziali del dispositivo. Classi probabili di esposizione (dipendenti dal modello, non specificate dal vendor):
I penetration tester dovrebbero mappare i percorsi dei file di certificato sulle revisioni di firmware IPC interessate solo tramite valutazioni autorizzate.
| # | Vendor | Famiglia di prodotti | Indicazioni su versione/build |
|---|---|---|---|
| 1 | Dahua | IPC | Interessati: alcuni modelli IPC con build di firmware precedenti al 15 aprile 2026 |
Totali: 1 vendor interessato · 1 famiglia di prodotti interessata (IPC, sottoinsieme di modelli)
| In ambito | Fuori ambito (questa CVE) |
|---|---|
| Alcuni modelli IPC | Speed dome SD |
| Data di build precedente al 2026-04-15 | NVR, XVR, EVS |
| VTO, VTH, ASI, TPC |
Dahua non elenca ogni modello nella riga di riepilogo della CVE. Gli operatori devono:
| Punteggio | Versione | Gravità | Vettore |
|---|---|---|---|
| 2.3 | 4.0 | BASSO | CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N |
| Fattore | Effetto sul punteggio |
|---|
Nota di gestione del rischio: una CVE 2.3 BASSA può comunque giustificare un'elevata priorità operativa se la vostra procedura operativa standard ha distribuito le CA del dispositivo a livello aziendale.
Riepilogo visivo delle posizioni dei selettori CVSS 4.0 pubblicate:
Attack Vector: [Network] Adjacent Local Physical Attack Complexity: [Low] High Attack Requirements: None [Present] Privileges Required: [None] Low High User Interaction: None [Passive] Active
### Impatto sul Sistema Vulnerabile```
Vuln Confidentiality: None [Low] High
Vuln Integrity: None [Low] High
Vuln Availability: [None] Low High
Subseq Confidentiality: [None] Low High Subseq Integrity: [None] Low High Subseq Availability: [None] Low High
---
## Classificazione CWE
| # | ID CWE | Nome | Rilevanza |
|---|---|---|---|
| 1 | **CWE-538** | [Inserimento di Informazioni Sensibili in File o Directory Accessibili Esternamente](https://cwe.mitre.org/data/definitions/538.html) | Certificato radice della CA del dispositivo raggiungibile tramite storage di rete non sufficientemente protetto |
### CWE correlate (contestuali, non assegnate)
| CWE | Nome | Relazione |
|---|---|---|
| CWE-295 | Validazione impropria del certificato | Errata validazione da parte del client a valle dopo l'installazione della fiducia |
| CWE-320 | Errori di gestione delle chiavi | Se il materiale della chiave privata è co-esposto con il certificato |
| CWE-326 | Forza crittografica inadeguata | Preoccupazione di hardening ortogonale per la TLS del dispositivo |
---
## Prerequisiti di attacco
| Prerequisito | Richiesto? | Note |
|---|---|---|
| Credenziali del dispositivo | **No** | `PR:N` — materiale ottenibile senza login |
| Raggiungibilità di rete verso l'IPC | **Sì** | Sfruttamento remoto |
| CA del dispositivo considerata affidabile sul client | **Sì** (per impatto MITM) | Condizione centrale `AT:P` |
| Attività TLS dell'utente | **Sì** (per MITM pratico) | `UI:P` |
| Modello interessato + firmware | **Sì** | Build IPC precedenti al 2026-04-15 |
| Disponibilità della chiave privata | **Probabile** per MITM completo | Il testo del vendor evidenzia l'ottenibilità della CA radice; verificare tramite test autorizzati |
**Sfruttabile da remoto:** **Sì** (recupero del certificato); **abuso completo della fiducia** dipende dalle precondizioni di distribuzione di cui sopra.
---
## Scenari di sfruttamento
### Scenario 1 — Inquinamento del trust store dell'installer
Un integratore installa la suite client di Dahua su 200 PC degli operatori, importando la **CA root del dispositivo** nell'archivio delle Autorità di certificazione radice attendibili di Windows. Un attaccante recupera il certificato CA e la chiave di firma da un IPC esposto a internet, quindi esegue un MITM sulle sessioni HTTPS verso il portale VMS aziendale da un laptop in un bar sulla stessa VPN.
### Scenario 2 — Accesso dal browser alla Web UI della fotocamera
Gli operatori sono addestrati a navigare su `https://192.168.x.x` per regolazioni rapide della messa a fuoco. Il browser considera affidabile la catena emessa dal dispositivo grazie a una root importata in precedenza. Un attaccante sulla LAN presenta un certificato contraffatto per l'IP della fotocamera, intercettando le credenziali inserite in quella che sembra una sessione TLS valida.
### Scenario 3 — Servizio fraudolento in stile supply-chain
Un attaccante firma un manifest di aggiornamento falso o un host di plugin che appare attendibile sotto la CA compromessa. Gli utenti passivi che aprono il VMS attivano la validazione del download, che riesce sotto la catena dannosa.
### Scenario 4 — Recupero del certificato senza MITM immediato
Gli attaccanti archiviano il materiale CA esposto da telecamere indicizzate su Shodan per un uso **successivo**, se le chiavi sono decifrabili, trapelate nelle immagini del firmware, o se i client installano la fiducia in seguito durante progetti di espansione.
### Scenario 5 — Rilevamento in audit forense / di conformità
Nessun attaccante attivo: gli auditor scoprono **file CA recuperabili pubblicamente** sugli IPC sul campo, facendo fallire i controlli di governance PKI e innescando una rotazione obbligatoria anche senza prove di sfruttamento.
---
## Valutazione dell'impatto
### Impatto tecnico
| Dominio | Sul dispositivo (punteggio) | Sui client (operativo) |
|---|---|---|
| Riservatezza | Bassa (`VC:L`) | Potenziale divulgazione MITM del traffico TLS |
| Integrità | Bassa (`VI:L`) | Certificati contraffatti accettati dai client che ripongono fiducia |
| Disponibilità | Nessuna (`VA:N`) | Non è un problema di riavvio/interruzione |
### Impatto aziendale (contestuale)
| Preoccupazione | Conseguenza |
|---|---|
| **Furto di credenziali degli operatori** | Login alla Web UI intercettati |
| **Falso senso di sicurezza TLS** | I team credono che HTTPS equivalga a un livello di fiducia da CA pubblica |
| **Conformità** | PCI, ISO 27001 o audit interni possono segnalare CA private non gestite |
| **Costo dell'incident response** | La pulizia del trust store a livello aziendale richiede molto lavoro |
### Quando un CVSS basso significa comunque "Sistemare subito"
Dare priorità alla correzione urgente se **una qualsiasi** delle seguenti condizioni è vera:
- CA del dispositivo installata su **>1** endpoint aziendale
- Fiducia della CA distribuita tramite **Criteri di gruppo** o MDM
- Le telecamere sono **esposte alla WAN**
- Le **gold image** dell'integratore includono le root Dahua per impostazione predefinita
---
## Rilevamento e indicatori di compromissione
### Indicatori lato dispositivo
- Richieste di rete che recuperano percorsi `*.pem`, `*.crt`, `*.cer` o `ca` senza autenticazione nei log HTTP
- File di certificato indicizzati da Shodan/Censys nelle root web delle telecamere
- Immagini firmware che contengono **chiavi private statiche** (analisi binaria autorizzata)
### Indicatori lato client
- **CA inattese con marchio Dahua o seriale del dispositivo** in:
- Windows: `certlm.msc` → Autorità di certificazione radice attendibili
- macOS: Accesso Portachiavi → Root di sistema
- Linux: `/usr/local/share/ca-certificates/`, `/etc/pki/`
- Connessioni TLS alle telecamere che mostrano catene **emesse localmente** dove ci si aspettavano CA pubbliche
- Directory dell'installer VMS contenenti `rootCA.crt` o file simili inclusi
### Indicatori di rete
- Infrastruttura MITM che presenta certificati con catena verso un **emittente non pubblico** che corrisponde ai distinguished name della CA del dispositivo
- Numeri di serie CA duplicati su dispositivi geograficamente separati (preoccupazione relativa a una root condivisa in fabbrica)
### Comandi di audit (esempi)
**Windows PowerShell — elenca le root attendibili con stringhe "Dahua" o OEM del dispositivo:**```powershell
Get-ChildItem Cert:\LocalMachine\Root | Where-Object { $_.Subject -match 'Dahua|OEM|IPC' } | Format-List Subject, Thumbprint, NotAfter
Linux — cerca le CA locali importate:```bash grep -ri 'dahua|BEGIN CERTIFICATE' /usr/local/share/ca-certificates/ /etc/ssl/certs/ 2>/dev/null
---
## Mitigazione e Bonifica
### Bonifica Primaria — Aggiornamento del Firmware
1. Fai l'inventario delle unità IPC con modello, numero di serie e **data di build del firmware**.
2. Identifica i dispositivi con build **anteriori al 15 aprile 2026**.
3. Esegui l'upgrade al firmware corretto dal fornitore secondo il [Dahua PSI Trust Center](https://www.dahuasecurity.com/about-dahua/trust-center/dahua-psi).
4. Dopo l'upgrade, verifica che il materiale CA non sia più recuperabile esternamente (retest autorizzato).
### Bonifica del Trust Store (Critica)
| Passo | Azione |
|---|---|
| 1 | **Identifica** tutti gli endpoint dove sono state installate le root CA di dispositivo |
| 2 | **Rimuovi** quelle root dagli archivi di trust di utente e macchina |
| 3 | **Sostituisci** con un modello di trust corretto: certificati CA pubblici, PKI aziendale o certificati per singolo dispositivo tramite ACME/CA interna |
| 4 | **Comunica** agli integratori: non includere le root di dispositivo nelle gold image |
| 5 | **Riemetti** le credenziali TLS sugli IPC interessati dopo la patch del firmware |
### Best Practice PKI per le Distribuzioni IPC
| Pratica | Raccomandazione |
|---|---|
| **Non fidarti mai delle CA integrate nella telecamera a livello aziendale** | Usa l'eccezione del browser solo dove inevitabile, per singolo dispositivo |
| **Preferisci PKI pubblica o aziendale** | Emetti certificati da CA controllate con root offline |
| **Segmenta l'HTTPS di gestione** | Accedi alle telecamere tramite VPN; non fare port forwarding dell'interfaccia self-signed |
| **Monitora la deriva del trust store** | Audit MDM/GPO per aggiunte non autorizzate di root |
| **Ruota dopo l'esposizione** | Tratta il materiale CA recuperato come compromesso |
### Controlli di Rete
- Blocca gli URL amministrativi non autenticati dalle reti non fidate
- Limita l'accesso all'interfaccia web della telecamera ai jump host
- Ispeziona il traffico in uscita dalle telecamere solo come consentito dalle policy; concentrati sull'esposizione **inbound** dei file dei certificati
### Igiene Coordinata del Parco Dispositivi
Su parchi di dispositivi interessati anche da [CVE-2026-29115](../CVE-2026-29115/README.md) o [CVE-2026-29116](../CVE-2026-29116/README.md), combina gli upgrade del firmware — ma tieni presente le **diverse date limite di build** (questa CVE: **2026-04-15** vs. **2026-03-26** per i problemi DoS).
---
## Soluzioni Alternative
Fino a quando il firmware non viene patchato:
1. **Non installare** le root CA di dispositivo scoperte di recente su alcun client.
2. **Rimuovi il trust esistente** per le root emesse da Dahua/dispositivo dove già distribuite.
3. **Blocca l'accesso di rete** ai percorsi noti per servire file di certificati (regole WAF o ACL temporanee — specifiche per modello).
4. Accedi alle telecamere tramite **VPN** e prendi sul serio gli avvisi TLS; non silenziare gli avvisi a livello globale.
5. Usa **connessioni tunnel VMS/SDK** che non dipendono dal trust della CA HTTPS integrata nella telecamera.
Non esiste **alcuna soluzione puramente configurativa** sul dispositivo che sostituisca la correzione del firmware se il materiale CA rimane accessibile esternamente nelle build vulnerabili.
---
## Risposta del Fornitore
Dahua ha pubblicato questo problema tramite il suo programma **Product Security Incident (PSI)**:
- **Trust Center / PSI:** https://www.dahuasecurity.com/about-dahua/trust-center/dahua-psi
Consulta il bollettino del fornitore per:
- Elenco esatto dei modelli IPC interessati
- Versioni di firmware corrette e date di build
- Eventuali indicazioni ufficiali sulla pulizia del trust store
---
## 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-29114 |
| Registro CVE | https://www.cve.org/CVERecord?id=CVE-2026-29114 |
| Correlata: CVE-2026-29115 | https://www.cve.org/CVERecord?id=CVE-2026-29115 |
| Correlata: CVE-2026-29116 | https://www.cve.org/CVERecord?id=CVE-2026-29116 |
| Definizione CWE-538 | https://cwe.mitre.org/data/definitions/538.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 pubblicamente disponibili e dichiarazioni del fornitore. Ha lo scopo di assistere difensori, integratori e ricercatori nella comprensione del rischio di **CVE-2026-29114** e nella definizione delle priorità di bonifica.
- Questo README **non** fornisce codice di exploit, procedure di estrazione di chiavi private o istruzioni di scansione non autorizzate.
- L'analisi tecnica dedotta non è un dettaglio implementativo confermato dal fornitore.
- L'applicabilità a modelli e firmware **deve** essere verificata rispetto alle indicazioni ufficiali Dahua PSI.
- Le modifiche al trust store e alla PKI possono **rompere l'accesso legittimo** se applicate senza test — segui le pratiche di change management.
- Gli autori non sono responsabili per le azioni intraprese sulla base di questo documento.
**Uso responsabile:** Esegui controlli di esposizione dei certificati solo su sistemi di tua proprietà o per i quali sei autorizzato a fare test. Segnala ulteriori risultati attraverso i canali di divulgazione coordinata.
---
## 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-29114 |
---
<p align="center">
<sub>CVE-2026-29114 · Dahua Technology · CVSS 4.0 2.3 LOW · CWE-538 · IPC</sub>
</p>
| Campo | Valore |
|---|
| ID CVE | CVE-2026-29114 |
| Vendor | Dahua Technology |
| Tipo di vulnerabilità | Esposizione di materiale sensibile dei certificati / abuso della catena di fiducia |
| Vettore di attacco | Rete |
| Autenticazione richiesta | No |
| Interazione utente richiesta | Passiva (UI:P) |
| Requisiti di attacco | Presenti (AT:P) |
| Privilegi richiesti | Nessuno |
| Versione CVSS | 4.0 |
| Punteggio base CVSS | 2.3 — BASSO |
| Vettore CVSS | CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N |
| CWE | CWE-538 (Inserimento di informazioni sensibili in file o directory accessibili esternamente) |
| Sfruttabile da remoto | Sì |
| Data di pubblicazione | 2026-06-10 |
| Disponibilità della correzione | Build di firmware a partire dal 15 aprile 2026 (secondo le indicazioni del vendor) |
| Attributo | CVE-2026-29114 (questa advisory) | CVE-2026-29115 | CVE-2026-29116 |
|---|
| Punteggio CVSS 4.0 | 2.3 — BASSO | 6.9 — MEDIO | 8.7 — ALTO |
| Impatto primario | Riservatezza + Integrità (Basso) | Disponibilità (Alto) | Disponibilità (Alto) |
| Autenticazione | Non richiesta | Privilegi elevati richiesti | Non richiesta |
| Prodotti interessati | Solo IPC | IPC, SD | IPC, SD, NVR, XVR, EVS, VTO, VTH, ASI, TPC |
| Cutoff build di correzione | Prima del 2026-04-15 | Prima del 2026-03-26 | Prima del 2026-03-26 |
| CWE | CWE-538 | CWE-617 | CWE-617 |
| Pubblicata (UTC) | 2026-06-10T05:44:50 | 2026-06-10T06:08:21 | 2026-06-10T06:16:34 |
| Data | Evento |
|---|
| ≤ 2026-04-15 | Build di firmware IPC vulnerabili in distribuzione attiva |
| 2026-04-15 | Cutoff della correzione del vendor — le build prodotte in questa data o successivamente sono al di fuori dell'intervallo interessato (secondo l'advisory) |
| 2026-06-10T05:44:50 UTC | CVE-2026-29114 pubblicata |
| 2026-06-10T05:44:50 UTC | Ultima modifica del record NVD |
| 2026-06-10 | Le CVE correlate CVE-2026-29115 e CVE-2026-29116 pubblicate più tardi lo stesso giorno |
| In corso | Gli operatori dovrebbero verificare gli archivi di fiducia e le date di build del firmware IPC |
| Associazione con app mobile | Fiducia personalizzata per funzionalità P2P o di assistenza cloud |
| Installer di software client | Root inclusa per "far funzionare HTTPS" senza il costo di una CA pubblica |
| Metrica | Valore | Significato per questa CVE |
|---|
| AV (Attack Vector) | Rete (N) | Recupero remoto del materiale dei certificati esposto |
| AC (Attack Complexity) | Bassa (L) | Nessuna condizione di temporizzazione o race condition speciale indicata |
| AT (Attack Requirements) | Presenti (P) | Si applicano le condizioni di installazione della fiducia sul client e di utilizzo della TLS |
| PR (Privileges Required) | Nessuno (N) | Nessun accesso al dispositivo necessario per ottenere il materiale esposto |
| UI (User Interaction) | Passiva (P) | Attività TLS/browser/client della vittima coinvolta nella catena di impatto |
| VC (Vuln System Confidentiality) | Bassa (L) | Divulgazione di materiale CA sensibile dal dispositivo |
| VI (Vuln System Integrity) | Bassa (L) | Integrità del meccanismo di fiducia indebolita |
| VA (Vuln System Availability) | Nessuna (N) | Disponibilità del dispositivo non influenzata |
| SC / SI / SA | Nessuno | Sistemi successivi non valutati separatamente |
AT:P | Non ogni distribuzione installa la CA del dispositivo sui client |
UI:P | La catena di impatto include l'attività TLS di utente/client |
VC:L / VI:L | Impatto diretto sul dispositivo valutato Basso, non Alto |
VA:N | Nessuna componente di riavvio/interruzione |