Unsachgemäß implementierte Sicherheitsprüfung für Standard

Beschreibung

Unsachgemäß implementierte Sicherheitsprüfung für Standard ist eine Schwachstelle, die auftritt, wenn ein Produkt eine oder mehrere sicherheitsrelevante Prüfungen, die von standardisierten Algorithmen, Protokollen oder Techniken vorgeschrieben sind, nicht ordnungsgemäß implementiert oder gänzlich auslässt. Dies repräsentiert eine Implementierungslücke, bei der erforderliche Sicherheitsvalidierungen, die in Standards wie X.509-Zertifikatsbehandlung, Authentifizierungsprotokollen wie RADIUS oder kryptografischen Spezifikationen festgelegt sind, entweder fehlen oder falsch ausgeführt werden. Häufige Manifestationen umfassen das Versäumnis, X.509-Zertifikat-Basic-Constraints zu verifizieren (wodurch jeder Zertifikatsinhaber als Zertifizierungsstelle agieren kann), das Auslassen der Shared-Secret-Verifizierung in RADIUS-Authentifizierung, das Nicht-Validieren kryptografischer Signaturen gemäß Spezifikation und unvollständige Implementierung von Challenge-Response-Protokollen. Die Schwachstelle ist besonders heimtückisch, weil Systeme Sicherheitsstandards zu implementieren scheinen, während sie tatsächlich schwächeren Schutz bieten als der Standard erfordert.

Risiko

Wenn Sicherheitsprüfungen, die von Standards gefordert werden, nicht ordnungsgemäß implementiert sind, können Angreifer die Lücken ausnutzen, um Sicherheitsmechanismen vollständig zu umgehen. Systeme, die X.509-Basic-Constraints nicht verifizieren, erlauben jedem Inhaber eines gültigen End-Entity-Zertifikats, betrügerische Zertifikate für beliebige Domains auszustellen, was das PKI-Vertrauen vollständig untergräbt. Die DigiNotar-Kompromittierung von 2011 führte zur Ausstellung von über 500 betrügerischen Zertifikaten für Domains einschließlich cia.gov, microsoft.com und google.com, wobei das betrügerische Google-Zertifikat in Man-in-the-Middle-Angriffen gegen etwa 300.000 iranische Gmail-Benutzer verwendet wurde. Der Blast-RADIUS-Angriff (CVE-2024-3596) nutzt eine fundamentale Designschwäche in der Verwendung von MD5 durch das RADIUS-Protokoll für Authentifizierung aus, um die Authentifizierung vollständig zu umgehen, ohne Passwörter oder Shared Secrets zu kennen, und betrifft Enterprise-VPNs, Wi-Fi-Authentifizierung, kritische Infrastrukturzugänge und Carrier-Netzwerke. OpenSSLs CVE-2015-1793 ermöglichte Angreifern, gültige Leaf-Zertifikate als CA-Zertifikate zu verwenden, aufgrund unsachgemäßer Basic-Constraints-Validierung. Das Risiko wird verstärkt, weil Benutzer und Administratoren davon ausgehen, dass Standardkonformität die dokumentierten Sicherheitseigenschaften bietet, während die Implementierung tatsächlich weit schwächere Garantien liefert.

Lösung

Befolgen Sie Sicherheitsstandards vollständig und präzise, indem Sie alle erforderlichen Prüfungen implementieren, nicht nur die bequemen. Bei der Implementierung von X.509-Zertifikatsvalidierung verifizieren Sie Basic Constraints, Key Usage, Extended Key Usage, Gültigkeitszeiträume, Widerrufsstatus und vollständige Vertrauenskette. Verwenden Sie Compliance-Test-Tools und Testsuiten, die von Standardisierungsgremien bereitgestellt werden, um die ordnungsgemäße Implementierung zu verifizieren. Für kryptografische und Authentifizierungsprotokolle verwenden Sie gut getestete Referenzimplementierungen oder gründlich auditierte Bibliotheken anstelle von benutzerdefinierten Implementierungen. Führen Sie Sicherheitsaudits durch, die sich speziell auf Standardkonformität konzentrieren, nicht nur auf funktionale Korrektheit. Für RADIUS-Deployments aktualisieren Sie auf RADIUS über TLS (RADSEC), verwenden Sie EAP-Methoden, die nicht anfällig für Angriffe auf Protokollebene sind, und isolieren Sie RADIUS-Verkehr von nicht vertrauenswürdigen Netzwerken. Implementieren Sie Verteidigung in der Tiefe — verlassen Sie sich nicht ausschließlich auf eine einzelne Sicherheitsprüfung. Bleiben Sie über entdeckte Schwachstellen in Standardprotokollen informiert und aktualisieren Sie Implementierungen entsprechend. Für Zertifikatsbehandlung implementieren Sie Zertifikat-Pinning für kritische Verbindungen und verwenden Sie Certificate-Transparency-Logs, um unautorisierte Zertifikatsausstellung zu erkennen.

Häufige Auswirkungen

Auswirkung	Details
Zugriffskontrolle	Umfang: Zugriffskontrolle Schutzmechanismus umgehen - Angreifer können Zugriffskontrollmaßnahmen umgehen, indem sie fehlende oder fehlerhafte Sicherheitsvalidierungen ausnutzen. Fehlende Basic-Constraints-Prüfungen ermöglichen Zertifikatsfälschung; unsachgemäße RADIUS-Validierung ermöglicht Authentifizierungs-Bypass.
Authentifizierung	Umfang: Authentifizierung Privilegien erlangen oder Identität annehmen - Unsachgemäße Implementierung von Authentifizierungsstandards ermöglicht Angreifern, sich als beliebiger Benutzer zu authentifizieren oder Authentifizierung vollständig zu umgehen, wodurch unautorisierter Zugang zu Systemen und Daten erlangt wird.
Integrität	Umfang: Integrität, Vertraulichkeit Man-in-the-Middle-Angriffe - Fehlgeschlagene Zertifikatsvalidierung oder Protokollverifizierung ermöglicht Angreifern, Kommunikation abzufangen und zu modifizieren, während sie beiden Parteien gegenüber legitim erscheinen, was sensible Daten offenlegt und Injection bösartiger Inhalte ermöglicht.

Beispielcode

Anfälliger Code

// ANFÄLLIG: Fehlende Basic-Constraints-Verifizierung bei Zertifikatsvalidierung
public class VulnerableCertificateValidator {

    // ANFÄLLIG: Prüft nur Signatur, ignoriert kritische Erweiterungen
    public boolean validateCertificate(X509Certificate cert, X509Certificate issuer)
            throws Exception {

        // Prüfen ob Zertifikat innerhalb des Gültigkeitszeitraums
        cert.checkValidity();

        // ANFÄLLIG: Verifiziert nur Signatur - kritische Prüfungen fehlen
        cert.verify(issuer.getPublicKey());

        // ANFÄLLIG: Keine Prüfung für Basic Constraints!
        // Angreifer mit beliebigem gültigem Zertifikat kann Zertifikate für jede Domain ausstellen

        // ANFÄLLIG: Keine Key-Usage-Verifizierung
        // Zertifikat ist möglicherweise nicht für diesen Zweck autorisiert

        return true;  // Zertifikat ohne ordnungsgemäße Validierung akzeptiert
    }
}

// ANFÄLLIG: RADIUS-Client ohne ordnungsgemäße Authenticator-Verifizierung
public class VulnerableRadiusClient {

    // ANFÄLLIG: Akzeptiert Access-Accept ohne Response-Authenticator zu verifizieren
    public boolean authenticate(String username, String password) {
        RadiusPacket request = createAccessRequest(username, password);
        RadiusPacket response = sendAndReceive(request);

        // ANFÄLLIG: Prüft nur Pakettyp, nicht Authenticator
        if (response.getType() == ACCESS_ACCEPT) {
            // ANFÄLLIG: Verifiziert Response-Authenticator nicht
            // Angreifer kann Access-Accept-Antworten fälschen
            return true;
        }
        return false;
    }

    // ANFÄLLIG: MD5-basierter Authenticator ohne Kollisionsresistenz
    private byte[] calculateAuthenticator(RadiusPacket packet) {
        // ANFÄLLIG: MD5 ist anfällig für Kollisionsangriffe
        MessageDigest md5 = MessageDigest.getInstance("MD5");
        md5.update(packet.getBytes());
        md5.update(sharedSecret);
        return md5.digest();  // Blast-RADIUS-Angriffsziel
    }
}

Korrigierter Code

// KORRIGIERT: Umfassende Zertifikatsvalidierung gemäß X.509-Standard
public class SecureCertificateValidator {

    public boolean validateCertificate(X509Certificate cert, X509Certificate issuer,
                                       boolean expectCA) throws CertificateException {
        try {
            // Gültigkeitszeitraum prüfen
            cert.checkValidity();

            // KORRIGIERT: Signatur verifizieren
            cert.verify(issuer.getPublicKey());

            // KORRIGIERT: Basic-Constraints-Erweiterung verifizieren
            int basicConstraints = cert.getBasicConstraints();
            if (expectCA) {
                // Für CA-Zertifikate muss Basic Constraints CA:true angeben
                if (basicConstraints < 0) {
                    throw new CertificateException(
                        "Zertifikat ist nicht autorisiert als CA zu agieren (Basic Constraints)");
                }
            } else {
                // Für End-Entity-Zertifikate sollte CA:true nicht gesetzt sein
                if (basicConstraints >= 0) {
                    log.warn("End-Entity-Zertifikat hat CA:true - ungewöhnlich");
                }
            }

            // KORRIGIERT: Key-Usage-Erweiterung verifizieren
            boolean[] keyUsage = cert.getKeyUsage();
            if (keyUsage != null) {
                if (expectCA && !keyUsage[5]) {  // keyCertSign-Bit
                    throw new CertificateException(
                        "CA-Zertifikat fehlt keyCertSign in Key Usage");
                }
                if (expectCA && !keyUsage[6]) {  // cRLSign-Bit
                    throw new CertificateException(
                        "CA-Zertifikat fehlt cRLSign in Key Usage");
                }
            }

            // KORRIGIERT: Extended Key Usage prüfen wenn vorhanden
            List<String> extendedKeyUsage = cert.getExtendedKeyUsage();
            if (extendedKeyUsage != null) {
                validateExtendedKeyUsage(extendedKeyUsage, cert.getSubjectDN());
            }

            // KORRIGIERT: Verifizieren dass Zertifikat nicht widerrufen ist
            checkRevocationStatus(cert);

            // KORRIGIERT: Zertifikatsketten-Tiefe verifizieren
            if (expectCA && basicConstraints >= 0) {
                // pathLenConstraint begrenzt Kettentiefe
                validatePathLength(basicConstraints);
            }

            return true;

        } catch (Exception e) {
            throw new CertificateException(
                "Zertifikatsvalidierung fehlgeschlagen: " + e.getMessage(), e);
        }
    }

    private void checkRevocationStatus(X509Certificate cert)
            throws CertificateException {
        // KORRIGIERT: CRL oder OCSP auf Widerrufsstatus prüfen
        // Implementierung hängt von PKI-Infrastruktur ab
        CertificateRevocationChecker.check(cert);
    }
}

// KORRIGIERT: Sichere RADIUS-Implementierung mit ordnungsgemäßer Verifizierung
public class SecureRadiusClient {

    // KORRIGIERT: RADIUS über TLS (RADSEC) für Transportsicherheit verwenden
    private final RadSecConnection connection;
    private final SecureRandom secureRandom;

    public boolean authenticate(String username, String password) {
        // Kryptografisch sicheren Request-Authenticator generieren
        byte[] requestAuthenticator = new byte[16];
        secureRandom.nextBytes(requestAuthenticator);

        RadiusPacket request = createAccessRequest(
            username, password, requestAuthenticator);

        RadiusPacket response = connection.sendAndReceive(request);

        if (response.getType() == ACCESS_ACCEPT) {
            // KORRIGIERT: Response-Authenticator verifizieren
            if (!verifyResponseAuthenticator(response, request, requestAuthenticator)) {
                log.error("Response-Authenticator-Verifizierung fehlgeschlagen - " +
                          "möglicher Angriff");
                return false;
            }

            // KORRIGIERT: Message-Authenticator-Attribut verifizieren wenn vorhanden
            if (response.hasAttribute(MESSAGE_AUTHENTICATOR)) {
                if (!verifyMessageAuthenticator(response, sharedSecret)) {
                    log.error("Message-Authenticator-Verifizierung fehlgeschlagen");
                    return false;
                }
            }

            return true;
        }
        return false;
    }

    // KORRIGIERT: Ordnungsgemäße Response-Authenticator-Verifizierung
    private boolean verifyResponseAuthenticator(
            RadiusPacket response, RadiusPacket request, byte[] requestAuth) {

        // KORRIGIERT: HMAC-basierte Verifizierung statt rohem MD5 verwenden
        // wenn verfügbar (RADIUS über TLS)
        byte[] expectedAuth = calculateExpectedResponseAuthenticator(
            response, requestAuth, sharedSecret);

        // KORRIGIERT: Konstant-Zeit-Vergleich um Timing-Angriffe zu verhindern
        return MessageDigest.isEqual(
            response.getAuthenticator(), expectedAuth);
    }
}

Der anfällige Code demonstriert häufige Implementierungsfehler: Zertifikatsvalidierung, die nur Signaturen prüft, während kritische Erweiterungen wie Basic Constraints und Key Usage ignoriert werden, und RADIUS-Clients, die Antworten ohne Verifizierung der Authenticatoren akzeptieren. Der korrigierte Code implementiert alle vom jeweiligen Standard geforderten Sicherheitsprüfungen, einschließlich Basic-Constraints-Verifizierung zur Verhinderung von Zertifikatsfälschung, Key-Usage-Validierung, Widerrufsprüfung und ordnungsgemäßer RADIUS-Authenticator-Verifizierung.

Ausgenutzt in der Praxis

DigiNotar Zertifizierungsstellen-Kompromittierung (DigiNotar/Niederlande, 2011)

Der DigiNotar-Einbruch repräsentiert eines der bedeutendsten Beispiele für ausgenutzte Zertifikatsvalidierungsschwächen. Angreifer kompromittierten DigiNotars Zertifizierungsstellen-Infrastruktur und stellten über 500 betrügerische Zertifikate für hochkarätige Domains aus, einschließlich google.com, cia.gov, microsoft.com, windowsupdate.com und mozilla.org — einschließlich eines, das sich als VeriSign Root CA ausgab. Das betrügerische Google-Wildcard-Zertifikat wurde in Man-in-the-Middle-Angriffen gegen etwa 300.000 iranische Gmail-Benutzer verwendet. Der Angriff war teilweise erfolgreich, weil viele Systeme zu dieser Zeit Zertifikatsketten nicht ordnungsgemäß validierten oder Zertifikat-Pinning implementierten. Die Untersuchung ergab, dass DigiNotar keinen Virenschutz hatte, schwache Administratorpasswörter verwendete, unzureichende Protokollierung hatte und schlecht durchgesetzte Netzwerksegmentierung aufwies. Der Vorfall führte direkt zu DigiNotars Insolvenz und veränderte grundlegend, wie die Branche Zertifizierungsstellen-Sicherheit anging, was zu Certificate Transparency und verbesserten Zertifikat-Pinning-Praktiken führte.

Blast-RADIUS Authentifizierungs-Bypass (Global, 2024)

Der Blast-RADIUS-Angriff (CVE-2024-3596) nutzt einen fundamentalen Designfehler in der Verwendung von MD5 durch das RADIUS-Protokoll für Authentifizierung aus. Forscher demonstrierten, dass ein Angreifer mit Zugang zu RADIUS-Verkehr Access-Accept-Antworten fälschen kann, ohne Passwörter oder Shared Secrets zu kennen, wodurch die Authentifizierung vollständig umgangen wird. Der Angriff betrifft alle standardkonformen RADIUS-Implementierungen, die UDP- oder TCP-Transport verwenden, und betrifft Enterprise-VPNs, Wi-Fi-Authentifizierung (einschließlich 802.1X für PAP, CHAP, MS-CHAPv2), DSL/FTTH-Internetzugang, Mobilfunk-Roaming-Authentifizierung, kritische Infrastruktur-Zugriffskontrollen und Bildungsnetzwerke wie Eduroam. Die Schwachstelle existiert, weil die Sicherheit des RADIUS-Standards vollständig auf dem Shared Secret beruht, und die verbesserte MD5-Kollisionstechnik ermöglicht Angreifern, gültig erscheinende Antworten zu erstellen. Nur EAP-Methoden und RADIUS über TLS (RADSEC) sind nicht anfällig.

Tools zum Testen/Ausnutzen

testssl.sh — Kommandozeilentool, das TLS/SSL-Cipher-Suites, Protokolle und Zertifikatsvalidierung einschließlich Basic-Constraints-Verifizierung prüft.
Certigo — Utility zur Untersuchung und Validierung von Zertifikaten, nützlich zum Testen, ob Anwendungen Zertifikatserweiterungen und -constraints ordnungsgemäß verifizieren.
FreeRADIUS — Referenz-RADIUS-Implementierung mit umfangreichen Debugging-Funktionen zum Testen von Authentifizierungsprotokoll-Implementierungen.

CVE-Beispiele

CVE-2002-0862 — Internet Explorer, Outlook und andere Microsoft-Produkte verifizierten X.509-Zertifikat-Basic-Constraints nicht, wodurch jeder Zertifikatsinhaber als CA agieren könnte.
CVE-2015-1793 — OpenSSL verarbeitete Basic Constraints während der alternativen Zertifikatskettenverifizierung nicht ordnungsgemäß, wodurch Leaf-Zertifikate als CAs agieren könnten.
CVE-2024-3596 — Blast-RADIUS-Schwachstelle ermöglicht Authentifizierungs-Bypass im RADIUS-Protokoll durch MD5-Kollisionsangriffe.
CVE-2004-2163 — RADIUS-Implementierung ließ Shared-Secret-Verifizierung aus, was Authentifizierungs-Bypass ermöglichte.

Referenzen

MITRE Corporation. "CWE-358: Improperly Implemented Security Check for Standard." https://cwe.mitre.org/data/definitions/358.html
Fox-IT. "Black Tulip: Report of the Investigation into the DigiNotar Certificate Authority Breach." 2012. https://www.researchgate.net/publication/269333601_Black_Tulip_Report_of_the_investigation_into_the_DigiNotar_Certificate_Authority_breach
Cloudflare. "RADIUS/UDP vulnerable to improved MD5 collision attack." Juli 2024. https://blog.cloudflare.com/radius-udp-vulnerable-md5-attack/
IETF RFC 5280. "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile." https://datatracker.ietf.org/doc/html/rfc5280