### Auswirkung auf das verwundbare System```
Vuln Confidentiality:   [None]     Low      High
Vuln Integrity:         [None]     Low      High
Vuln Availability:      [High]     Low      None

---

## CWE-Klassifizierung

| # | CWE ID | Name | Relevanz |
|---|---|---|---|
| 1 | **CWE-617** | [Reachable Assertion](https://cwe.mitre.org/data/definitions/617.html) | Produktionscode setzt eine Assertion oder fatale Prüfung aus, die durch nicht vertrauenswürdige Eingaben erreichbar ist und den Prozess oder das System beendet |

### Warum CWE-617 zutrifft

CWE-617 beschreibt Situationen, in denen Entwickler sich auf Assertions für Bedingungen verlassen, die **externe Angreifer erzwingen können**. Im Gegensatz zu einer eleganten Fehlerbehandlung (Rückgabecodes, bereinigte Antworten) endet eine erreichbare Assertion oft in einem **abrupten Abbruch** – was mit dem vom Hersteller beschriebenen **Absturz- oder Neustartverhalten** übereinstimmt.

---

## Angriffsvoraussetzungen

| Voraussetzung | Erforderlich? | Anmerkungen |
|---|---|---|
| Gültige Geräteanmeldeinformationen | **Nein** | Nicht authentifizierter Angriff |
| Benutzerinteraktion des Opfers | **Nein** | Vollständig entfernter Netzwerkauslöser |
| Vorherige Kompromittierung eines anderen Systems | **Nein** | Eigenständige Ausnutzung |
| Netzwerkerreichbarkeit zum Gerät | **Ja** | Angriffsvektor ist Netzwerk |
| Kenntnis des Gerätemodells | Hilfreich, aber nicht zwingend erforderlich | Maßgeschneidertes Paket kann familienabhängig sein |
| Internet-Exposition | Nicht erforderlich, erhöht jedoch das Risiko | WAN-Portweiterleitung und Cloud-Relay-Exposition sind in der Praxis üblich |

**Entfernt ausnutzbar:** **Ja**

---

## Ausnutzungsszenarien

### Szenario 1 — Internet-exponierte Kamera

Eine feste IPC ist für die Fernansicht per Portweiterleitung zugänglich. Ein Angreifer scannt den Host, sendet das maßgeschneiderte Paket an einen offenen Dienstport und erzwingt einen Neustart. Die Kamera fällt während eines aktiven Sicherheitsvorfalls offline, wodurch eine Aufzeichnungslücke entsteht.

### Szenario 2 — Flaches CCTV-VLAN

Ein Angreifer verschafft sich Zugang zu einem Unternehmens-Laptop (Phishing, Gerät eines Auftragnehmers usw.) und greift jeden Dahua-Host im Überwachungs-VLAN an. Aufeinanderfolgende Auslöser erzeugen ein standortweites „Alle Kameras offline“-Ereignis, ohne jemals eine Authentifizierung gegenüber der VMS-Software durchzuführen.

### Szenario 3 — Gegensprechanlagen-Störung (VTO/VTH)

Ein Einzelhandelsgeschäft verwendet Dahua-Türstationen. Ein Angreifer in der Nähe des Netzwerks (oder über ein exponiertes WAN) startet die Außenstation während der Hauptgeschäftszeiten wiederholt neu. Die Zugangskontrolle und die Fernfreigabe der Tür schlagen fehl, was zu einer Betriebseinstellung oder manuellen Umgehungsverfahren führt.

### Szenario 4 — Verkettete physische Sicherheitsverschlechterung

Ein Neustart des NVR während eines aktiven Einbruchs verzögert die Alarmüberprüfung und das PTZ-Tracking. Obwohl es sich laut CVSS nicht um eine direkte „Integritäts“-CVE handelt, kann das **physische Sicherheitsergebnis** schwerwiegend sein.

### Szenario 5 — Anhaltende Belästigung / Dienstverschlechterung

Automatisiertes wiederholtes Auslösen des Triggers alle N Minuten verhindert eine stabile Betriebszeit, selbst wenn sich das Gerät jedes Mal schnell erholt – ein **aufwandsarmer, störungsintensiver** Angriff, der sich für Botnetz-Maßstab-Missbrauch gegen bekannte Firmware-Fingerabdrücke eignet.

---

## Auswirkungsbewertung

### Technische Auswirkungen

| Bereich | Bewertung | Details |
|---|---|---|
| Vertraulichkeit | Keine (direkt) | Keine nachgewiesene Datenextraktion allein durch diesen Fehler |
| Integrität | Keine (direkt) | Keine nachgewiesene Manipulation von Konfiguration oder Aufnahmen allein durch diesen Fehler |
| Verfügbarkeit | **Hoch** | Neustart-Ausfall; wiederholbar |

### Geschäftsauswirkungen (kontextbezogen)

| Sektor | Mögliche Folge |
|---|---|
| Einzelhandel / Banken | Verlust von forensischem Video bei Schwund- oder Betrugsvorfällen |
| Kritische Infrastruktur | Lücken in der visuellen Überprüfung von Alarmen |
| Wohngebäude / KMU | Tote Winkel der Hausüberwachung während Einbrüchen |
| Smart City | Ausfall von Verkehrs- oder Sicherheitskameras im öffentlichen Raum |
| Zutrittskontrollintegrationen | Türen und Gegensprechanlagen zu Spitzenzeiten nicht verfügbar |

### Flottenweite Überlegungen

Organisationen mit **Hunderten oder Tausenden** von Dahua-Endpunkten sollten Folgendes modellieren:

- Mittlere Wiederherstellungszeit pro Neustart
- Zentrales Überwachungsrauschen bei Massenausfällen
- SLA-Verletzungen bei verwalteten Dienstkunden
- Versicherungs- oder Compliance-Auswirkungen für die Aufzeichnungskontinuität

---

## Erkennung und Indikatoren einer Kompromittierung

Da der Hersteller keine Paketerfassungen oder CVE-spezifischen Signaturen veröffentlicht hat, sollte sich die Erkennung auf **Verhaltensindikatoren** konzentrieren:

### Host-/Geräteindikatoren

- Unerwartete Neustarts ohne durch den Administrator initiierte Upgrades oder Stromereignisse
- Boot-Grund-Flags, die auf Kernel-Panik, Watchdog-Reset oder abnormalen Neustart verweisen
- Anwendungsprotokolle, die Assertionsfehler oder fatale Fehler unmittelbar vor Ausfallzeiten zeigen
- Kurze Betriebszeiten korreliert mit Ausbrüchen anomalen Netzwerkverkehrs

### Netzwerk-Indikatoren

- Einzelquellen- oder verteilte Ausbrüche anomaler Pakete vor Geräte-Offline-Ereignissen
- Neue Scanaktivität auf Dahua-assoziierten Dienstports aus nicht vertrauenswürdigen Subnetzen
- Korrelation zwischen externen SYN/UDP/HTTP-Mustern und Syslog-Neustartzeitstempeln von Kameras/NVRs

### Betriebliche Korrelationen

- Mehrere Geräte gleichzeitig offline ohne PoE-Switch-Ausfall
- Offline-Ereignisse **nicht** begleitet von Switch-Schnittstellenfehlern (was auf einen Absturz auf Endpunkt-Ebene hindeutet)
- Wiederkehrende Ausfälle in festen Abständen (möglicher automatisierter Replay-Angriff)

### Empfohlenes Logging

- Zentralisieren Sie **syslog** von Kameras, NVRs und Gegensprechanlagen
- Behalten Sie **Firewall-/Edge**-Flows für Segmente mit Überwachungsgeräten bei
- Alarmieren Sie bei **Massen-Geräte-Trennungs**-Ereignissen vom VMS innerhalb kurzer Zeitfenster

---

## Minderung und Behebung

### Primäre Behebung — Firmware-Update

1. Erfassen Sie alle Dahua-Geräte mit Modell, Seriennummer und **Firmware-Build-Datum**.
2. Identifizieren Sie Einheiten mit Builds **vor dem 26. März 2026**.
3. Laden Sie die vom Hersteller genehmigte Firmware aus dem [Dahua PSI Trust Center](https://www.dahuasecurity.com/about-dahua/trust-center/dahua-psi) oder von autorisierten Vertriebskanälen herunter.
4. Planen Sie Upgrades in einem Wartungsfenster; validieren Sie die Aufzeichnungs- und Gegensprechfunktion nach dem Patch.
5. Testen Sie extern exponierte Dienste erst nach Bestätigung des korrigierten Builds erneut.

### Kompensierende Kontrollen (bis zum Patch)

| Kontrolle | Ziel |
|---|---|
| **Netzwerksegmentierung** | Platzieren Sie Kameras/NVRs in dedizierten VLANs mit Standard-Verweigerungs-ACLs |
| **Portweiterleitung entfernen** | Beseitigen Sie direkte WAN-Exposition; verwenden Sie stattdessen VPN oder Zero-Trust-Zugriff |
| **Quell-IPs einschränken** | Erlauben Sie nur VMS, Jump-Hosts und Operator-Subnetzen den Zugriff auf Geräteverwaltungsports |
| **Nicht genutzte Dienste deaktivieren** | Reduzieren Sie die Protokollangriffsfläche (deaktivieren Sie unnötige HTTP/ONVIF/PPPoE usw.) |
| **Ausgehende Filterung** | Begrenzen Sie unerwartetes Relay-Verhalten, wo die Richtlinie dies zulässt |
| **Physische Ersatzteile / Failover** | Für kritische Aufnahmen wahren Sie eine überlappende Abdeckung |

### Unternehmens-Change-Management

- Dokumentieren Sie Firmware-Versionen in der CMDB
- Verknüpfen Sie den Patch-Status mit Beschaffungs- und RMA-Workflows
- Beziehen Sie die Dahua-PSI-Überwachung in den Rhythmus der Lieferantenrisikoprüfung ein

---

## Umgehungen

Es ist keine vom Hersteller dokumentierte **reine Konfigurationsumgehung** bekannt, die die Schwachstelle vollständig beseitigt, ohne auf einen korrigierten Build zu aktualisieren. Bis die Firmware angewendet wird, ist die **Netzwerkschicht-Eindämmung** die praktische Umgehung:

1. Blockieren Sie nicht vertrauenswürdigen Netzwerken den Zugriff auf Geräteverwaltungs- und proprietäre Dienstports.
2. Überwachen Sie auf wiederholte Neustartmuster und isolieren Sie verursachende Quellen an der Edge-Firewall.
3. Platzieren Sie Geräte, wo verfügbar, hinter authentifizierten VPN-Konzentratoren anstatt sie roher Exposition auszusetzen.

---

## Herstellerreaktion

Dahua hat dieses Problem über sein **Product Security Incident (PSI)**-Programm veröffentlicht. Offizielle Ressourcen:

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

Betreiber sollten das Hersteller-Bulletin als maßgebliche Quelle betrachten für:

- Modellspezifische betroffene Listen
- Links zum Download korrigierter Firmware
- Zusätzliche Härtungsempfehlungen

---

## Referenzen

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

---

## Haftungsausschluss

Dieses Dokument ist ein **informatives Sicherheitsbulletin**, das aus öffentlich verfügbaren CVE-Metadaten und Herstellererklärungen zusammengestellt wurde. Es soll Verteidiger, Integratoren und Forscher dabei unterstützen, das Risiko von **CVE-2026-29116** zu verstehen und Abhilfemaßnahmen zu priorisieren.

- Diese README **enthält keinen** Exploit-Code, keine maßgeschneiderten Paketvorlagen oder Schritt-für-Schritt-Angriffsanleitungen.
- Mit *geschlussfolgert* gekennzeichnete technische Analyseabschnitte sind angemessene Interpretationen öffentlicher Daten, keine herstellerbestätigte Ursachenoffenlegung.
- Die Bestimmung betroffener Modelle **muss** anhand des offiziellen Dahua PSI-Bulletins und Ihres Geräte-Firmware-Build-Datums überprüft werden.
- Die Autoren haften nicht für Handlungen, die auf der Grundlage dieses Dokuments durchgeführt werden. Patchen, testen und bereitstellen gemäß den Change-Management-Richtlinien Ihrer Organisation.
- **Verantwortungsvoller Gebrauch:** Melden Sie zusätzliche Erkenntnisse über koordinierte Offenlegungskanäle (Hersteller-PSI, nationales CERT oder etablierte Bug-Bounty-Programme, falls zutreffend).

---

## Dokumentenrevisionsverlauf

| Version | Datum | Änderungen |
|---|---|---|
| 1.0 | 2026-07-11 | Erstes umfassendes Beratungs-README basierend auf den Veröffentlichungsdaten von CVE-2026-29116 |

---

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