A04:2025 Fehlerhafter Einsatz von Kryptografie

Hintergrund.

Diese Schwachstelle ist um zwei Plätze auf Rang 4 zurückgefallen und konzentriert sich auf Fehler im Zusammenhang mit fehlender Kryptografie, unzureichend starker Kryptografie, dem Verlust kryptografischer Schlüssel und damit verbundenen Fehlern. Drei der häufigsten Common Weakness Enumerations (CWEs) in diesem Risikobereich betrafen die Verwendung eines schwachen Pseudozufallszahlengenerators: CWE-327 Use of a Broken or Risky Cryptographic Algorithm, CWE-331: Insufficient Entropy, CWE-1241: Use of Predictable Algorithm in Random Number Generator, and CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG).

Punktetabelle.

Zugeordnete CWEs	Max. Häufigkeit	Durchschn. Häufigkeit	Max. Abdeckung	Durchschn. Abdeckung	Durchschn. gewichtete Ausnutzbarkeit	Durchschn. gewichtete Auswirkung	Gesamtanzahl	Summe CVEs
32	13.77%	3.80%	100.00%	47.74%	7.23	3.90	1,665,348	2,185

Beschreibung.

Generell sollten alle Daten während der Übertragung auf der Transportschicht (OSI-Schicht 4) verschlüsselt werden. Frühere Hindernisse wie die CPU-Leistung werden nun durch CPUs bewältigt, die über Hardwarebeschleunigung der Verschlüsselung verfügen (z. B.: AES-Unterstützung), und die Verwaltung privater Schlüssel und Zertifikate wird durch Dienste wie LetsEncrypt.org vereinfacht, wobei große Cloud-Anbieter noch stärker integrierte Zertifikatsverwaltungsdienste für ihre spezifischen Plattformen bereitstellen.

Neben der Absicherung der Transportschicht ist es wichtig zu ermitteln, welche Daten im Ruhezustand verschlüsselt werden müssen und welche Daten während der Übertragung (auf der Anwendungsschicht, OSI-Schicht 7) zusätzlich verschlüsselt werden müssen. Beispielsweise erfordern Passwörter, Kreditkartennummern, Gesundheitsakten, persönliche Informationen und Geschäftsgeheimnisse zusätzlichen Schutz, vor allem dann, wenn diese Daten unter Datenschutzgesetze, z. B. die Datenschutz-Grundverordnung (DSGVO) der EU, oder andere Vorschriften fallen, beispielsweise dem Payment Card Industry Data Security Standard (PCI-DSS).

Folgendes ist zu klären:

Werden alte oder schwache kryptografische Algorithmen oder Protokolle verwendet, z. B. per Standardeinstellung oder in älterem Code?
Werden vordefinierte kryptografische Schlüssel verwendet, schwache Schlüssel generiert oder Schlüssel wiederverwendet? Fehlt eine Schlüsselverwaltung oder Schlüsselrotation?
Werden kryptografische Schlüssel in Quellcode-Repositories eingecheckt?
Wird Verschlüsselung nicht verbindlich erzwungen, z. B. fehlen bei Webanwendungen Vorgaben für den Browser in den entsprechenden HTTP-Kopfzeilen?
Werden empfangene Serverzertifikate und die Zertifikatskette korrekt validiert?
Werden Initialisierungsvektoren ignoriert, wiederverwendet oder nicht ausreichend sicher für den kryptografischen Betriebsmodus generiert? Ist ein unsicherer Betriebsmodus wie ECB im Einsatz? Wird Verschlüsselung genutzt, wenn authentifizierte Verschlüsselung angebrachter wäre?
Werden Passwörter direkt als kryptografische Schlüssel verwendet ohne eine Schlüsselableitung mittels Key Derivation Function?
Werden Zufallszahlen für kryptografische Zwecke genutzt, die nicht auf kryptografische Anforderungen ausgelegt sind? Selbst wenn die richtige Funktion genutzt wird, muss diese eventuell von Entwickler:innen korrekt initialisiert werden. Wurde eine integrierte starke Initialisierung eventuell durch ein Entwickler:in mit einem schwachen Wert überschrieben, dem es an ausreichender Entropie und Unberechenbarkeit mangelt?
Werden Hash-Funktionen mit bekannten Schwächen wie MD5 oder SHA1 verwendet oder werden nicht-kryptografische Hash-Funktionen verwendet, wenn kryptografische Hash-Funktionen benötigt werden?
Sind kryptografische Fehlermeldungen oder Seitenkanäle ausnutzbar, beispielsweise in Form von Padding-Oracle-Angriffen?
Kann der eingesetzte kryptografische Algorithmus abgeschwächt oder umgangen werden?

Siehe ASVS: Cryptography (V11), Secure Communication (V12) and Data Protection (V14).

Prävention und Gegenmaßnahmen.

Befolgen Sie mindestens die folgenden Schritte und konsultieren Sie die weiterführenden Webseiten:

Klassifizieren Sie die Daten, die von einer Anwendung verarbeitet, gespeichert oder übermittelt werden nach ihrem Schutzbedarf. Berücksichtigen Sie dabei auch Datenschutzgesetze, regulatorische und Geschäfts-Anforderungen.
Speichern Sie Ihre am stärksten gefährdeten Schlüssel in einem Hardware- oder cloudbasierten HSM.
Verwenden Sie nach Möglichkeit überall bewährte Implementierungen kryptografischer Algorithmen
Speichern Sie sensible Daten nicht unnötig. Löschen Sie sensible Daten auf sichere Weise sobald wie möglich oder verwenden Sie Techniken wie PCI-DSS-konformes Speichern von Ersatzwerten (tokenization) oder gar gekürzten (truncation) Werten. Daten, die es nicht mehr gibt, können auch nicht gestohlen werden.
Stellen Sie sicher, dass alle vertraulichen Daten bei Speicherung verschlüsselt werden.
Stellen Sie sicher, dass aktuelle, starke, standardisierte Algorithmen, Protokolle und Schlüssel, z. B. gemäß BSI TR-02102, verwendet werden. Etablieren Sie wirksames Schlüsselmanagement für kryptografische Schlüssel.
Verschlüsseln Sie alle Daten während der Übertragung mit TLS >= 1.2, die Forward Secrecy (FS) bieten, deaktivieren Sie die Unterstützung von cipher block chaining (CBC) Chiffren, unterstützen Sie quantensichere Schlüsselaustauschverfahren. Erzwingen Sie die Verschlüsselung durch HTTP Strict Transport Security (HSTS). Prüfen Sie die Einstellungen mit einem Werkzeug.
Deaktivieren Sie das Caching für Antworten mit vertraulichen Daten. Dazu gehören das Caching in Ihrem CDN, auf Ihrem Webserver sowie jegliches Anwendungs-Caching (z. B. Redis).
Wenden Sie die Sicherheitsmaßnahmen gemäß dem Schutzbedarf der Datenklassifizierung an.
Verwenden Sie keine unverschlüsselten Protokolle wie FTP und STARTTLS. Vermeiden Sie die Verwendung von SMTP für die Übertragung vertraulicher Daten.
Verwenden Sie spezielle Hash-Funktionen für das Hashen von Passwörtern, bei denen für jedes Passwort ein Salz-Wert (salted hash) und Rechenaufwand (work-factor) zum Einsatz kommt. Beispiele sind: Argon2, yescrypt, scrypt, PBKDF2-HMAC-SHA-512. Für Altsysteme, die bcrypt verwenden, finden Sie weitere Hinweise unter OWASP Cheat Sheet: Password Storage
Initialisierungsvektoren müssen passend zum kryptografischen Betriebsmodus gewählt werden. In vielen Fällen bedeutet dies, dass ein CSPRNG (kryptografisch sicherer Pseudozufallszahlengenerator) für die Generierung des Initialisierungsvektors verwendet wird. Für Modi, die eine Nonce erfordern, benötigt der Initialisierungsvektor nicht notwendigerweise einen CSPRNG. In allen Fällen darf der gleiche Initialisierungsvektor niemals zweimal für den gleichen Schlüssel verwendet werden.
Verwenden Sie immer eine authentifizierte Verschlüsselung statt nur einer Verschlüsselung.
Schlüssel sollten kryptografisch zufällig generiert und als Byte-Felder (Arrays) im Speicher gehalten werden. Wenn ein Passwort zur Verschlüsselung verwendet werden soll, muss über eine Funktion zur Schlüsselableitung ein Schlüssel generiert werden.
Stellen Sie sicher, dass an den notwendigen Stellen kryptografisch sichere, unvorhersagbare Zufallszahlen verwendet werden, und dass der Pseudozufallszahlengenerator nicht auf vorhersehbare Weise oder nur mit geringer Entropie initialisiert wurde. Bei den meisten modernen APIs muss die Entwickler:in die Initialisierung des Pseudozufallszahlengenerators (CSPRNG) nicht manuell durchführen.
Meiden Sie veraltete kryptografische Funktionen und Padding-Verfahren wie MD5, SHA1, Cipher Block Chaining Mode (CBC), PKCS Nummer 1 v1.5.
Stellen Sie sicher, dass Einstellungen und Konfigurationen den Sicherheitsanforderungen entsprechen, indem Sie sie von Sicherheitsspezialist:innen, speziell dafür entwickelte Werkzeugen oder beidem überprüfen lassen.
Sie müssen sich bereits jetzt auf die Post-Quanten-Kryptografie (PQC) vorbereiten (siehe Referenz (ENISA)), damit risikoreiche Systeme spätestens bis Ende 2030 sicher sind.

Beispielhafte Angriffsszenarien.

Szenario Nr. 1: Eine Webseite benutzt kein TLS, erzwingt dies nicht auf allen Seiten oder lässt schwache Verschlüsselung zu. Die/Der Angreifer:in liest die Kommunikation mit (z. B. in einem offenen WLAN), ersetzt HTTPS- durch HTTP-Verbindungen, hört diese ab und stiehlt das Sitzungscookie. Durch Wiedereinspielen dieses Cookies übernimmt die/der Angreifer:in die (authentifizierte) Sitzung der Nutzer:in und erlangt Zugriff auf deren private Daten. Anstatt dessen kann die/der Angreifer:in auch die übertragenen Daten ändern, z. B. die Empfänger:in einer Überweisung.

Szenario Nr. 2: Die Passwortdatenbank benutzt einfache Hashwerte oder Hashes ohne Salz zur Speicherung der Passwörter. Eine Schwachstelle in der Uploadfunktion erlaubt Angreifer:innen den Zugriff auf die Passwortdatei. Zu Hashes ohne Salz kann über vorausberechnete Rainbow-Tabellen der Klartext gefunden werden. Hashes, die über einfache oder schnelle Funktionen berechnet wurden, können effizient mit Grafikkarten gebrochen werden, selbst wenn sie gesalzt waren.