Zurück zur Schwachstellen-Datenbank

Einfügung sensibler Informationen in Debugging-Code

Beschreibung

Einfügung sensibler Informationen in Debugging-Code tritt auf, wenn Entwickler sensible Daten in Debug-Anweisungen, Logging oder Diagnosecode einschließen, die offengelegt werden können, wenn Debugging-Funktionen in Produktionsumgebungen nicht ordnungsgemäß deaktiviert sind. Während der Entwicklung kann es praktisch sein, Anmeldedaten, API-Schlüssel, persönliche Daten oder interne Systemzustände zur Fehlerbehebung zu protokollieren. Wenn dieser Debugging-Code jedoch in der Produktion aktiv bleibt, werden die sensiblen Informationen für Angreifer über Logdateien, Debug-Konsolen oder offengelegte Debugging-Endpunkte zugänglich.

Risiko

Debug-Code-Offenlegung ist eine häufige Schwachstelle bei übereilten Deployments, bei denen Entwicklungskonfigurationen versehentlich in die Produktion gelangen. Die Konsequenzen können schwerwiegend sein: offengelegte Datenbank-Anmeldedaten ermöglichen vollständige Daten-Breaches, durchgesickerte API-Schlüssel erlauben unbefugten Service-Zugriff, offengelegte Benutzerdaten verletzen Datenschutzvorschriften. Debug-Endpunkte können Angreifern auch erlauben, den Anwendungszustand zu manipulieren oder Sicherheitskontrollen zu umgehen. Diese Schwachstelle hat zu mehreren hochkarätigen Breaches geführt, bei denen Entwicklungs-Anmeldedaten in Produktionssystemen aktiv blieben.

Lösung

Entfernen Sie alle Debug-Anweisungen, die sensible Informationen enthalten, vor dem Release. Verwenden Sie umgebungsbewusstes Logging, das ausführliche Ausgaben in der Produktion automatisch deaktiviert. Implementieren Sie Kompilierzeit- oder Deployment-Zeit-Prüfungen, um sicherzustellen, dass Debug-Code entfernt wird. Verwenden Sie Logging-Frameworks, die Log-Level unterstützen und sensible Daten automatisch maskieren können. Konfigurieren Sie CI/CD-Pipelines, um Builds mit Debug-Markierungen oder sensiblen Datenmustern fehlschlagen zu lassen. Führen Sie Sicherheitsüberprüfungen durch, die speziell auf Debug-Code vor dem Deployment abzielen. Implementieren Sie Secrets-Management, um das Hardcodieren sensibler Werte zu vermeiden.

Häufige Auswirkungen

AuswirkungDetails
VertraulichkeitBereich: Informationsoffenlegung

Sensible Daten einschließlich Anmeldedaten, API-Schlüssel, persönlicher Informationen und interner Systemdetails durch Debug-Ausgabe offengelegt.
ZugriffskontrolleBereich: Unbefugter Zugriff

Offengelegte Anmeldedaten oder Debug-Endpunkte bieten Angreifern unbefugten Systemzugriff.
ComplianceBereich: Regulierungsverletzung

Persönliche Daten in Debug-Logs verletzen DSGVO, HIPAA und andere Datenschutzvorschriften.

Beispielcode + Lösungscode

Anfälliger Code

// ANFÄLLIG: Debug-Code mit Anmeldedaten
public class DatabaseService {
    private static final boolean DEBUG = true;  // Aktiviert gelassen!

    public Connection connect() {
        String url = "jdbc:mysql://prod-db.internal:3306/users";
        String user = "admin";
        String password = "SuperSecret123!";

        if (DEBUG) {
            // Loggt Anmeldedaten in Konsole/Datei
            System.out.println("DEBUG: Verbinde mit " + url);
            System.out.println("DEBUG: User=" + user + ", Pass=" + password);
        }

        return DriverManager.getConnection(url, user, password);
    }
}

# ANFÄLLIG: Sensible Daten in Debug-Logs
import logging

logging.basicConfig(level=logging.DEBUG)  # DEBUG in Produktion!

def authenticate(username, password, api_key):
    logging.debug(f"Auth-Versuch: user={username}, pass={password}")
    logging.debug(f"Verwende API-Schlüssel: {api_key}")

    # Debug-Endpunkt aktiviert gelassen
    if request.args.get('debug') == 'true':
        return {
            "internal_config": app.config,  # Legt alle Einstellungen offen
            "env_vars": dict(os.environ),   # Legt Geheimnisse offen
            "db_password": DB_PASSWORD
        }

// ANFÄLLIG: Debug-Code in clientseitigem JavaScript
const DEBUG = true;

function processPayment(creditCard, cvv, amount) {
    if (DEBUG) {
        // Sichtbar in Browser-Konsole und Netzwerk-Tab!
        console.log('Payment Debug:', {
            cardNumber: creditCard,
            cvv: cvv,
            internalToken: MERCHANT_SECRET_TOKEN
        });
    }
    // ...
}

Korrigierter Code

// SICHER: Umgebungsbewusstes Debugging
public class DatabaseService {
    private static final Logger logger = LoggerFactory.getLogger(DatabaseService.class);
    private static final boolean DEBUG = Boolean.parseBoolean(
        System.getenv().getOrDefault("DEBUG_MODE", "false")
    );

    public Connection connect() {
        // Anmeldedaten aus sicherer Konfiguration
        String url = config.getDatabaseUrl();
        String user = config.getDatabaseUser();
        String password = config.getDatabasePassword();

        if (DEBUG && !isProduction()) {
            // Nur in Nicht-Produktion loggen, niemals Anmeldedaten loggen
            logger.debug("Verbinde mit Datenbank");
            // Niemals loggen: Passwort, Verbindungsstrings mit Anmeldedaten
        }

        return DriverManager.getConnection(url, user, password);
    }

    private boolean isProduction() {
        return "production".equals(System.getenv("ENVIRONMENT"));
    }
}

# SICHER: Produktionsgerechtes Logging
import logging
import os

# Umgebungsbasiertes Log-Level
log_level = logging.DEBUG if os.getenv('ENV') == 'development' else logging.WARNING
logging.basicConfig(level=log_level)

def authenticate(username, password, api_key):
    # Niemals sensible Daten loggen, auch nicht auf DEBUG-Level
    logging.debug(f"Auth-Versuch für Benutzer: {username}")

    # Keine Debug-Endpunkte in Produktion
    # Debug-Funktionalität vollständig aus Produktions-Build entfernt

def mask_sensitive(value, visible_chars=4):
    """Sensible Daten für sicheres Logging maskieren"""
    if len(value) <= visible_chars:
        return "****"
    return value[:visible_chars] + "****"

# Verwendung: logging.info(f"Verwende API-Schlüssel: {mask_sensitive(api_key)}")

// SICHER: Build-Zeit Debug-Entfernung
// Verwendung von Umgebungsvariablen und Build-Prozess

// Webpack/Build-Konfiguration entfernt Debug-Code in Produktion
if (process.env.NODE_ENV === 'development') {
    // Dieser gesamte Block wird in Produktions-Builds entfernt
    console.log('Entwicklungsmodus aktiv');
}

function processPayment(creditCard, cvv, amount) {
    // Kein Debug-Code mit sensiblen Daten
    // Ordentlichen Logging-Service verwenden, der sensible Felder maskiert
    logger.info('Verarbeite Zahlung', {
        lastFourDigits: creditCard.slice(-4),
        amount: amount
        // Niemals loggen: vollständige Kartennummer, CVV, Tokens
    });
}

Ausgenutzt in der Praxis

Quick Share Agent MAC-Adressen-Offenlegung (Android, 2024)

Debug-Code in Quick Share Agent für Android legte MAC-Adressen an lokale Angreifer offen, ohne Berechtigungen zu erfordern, und betraf Android 12 und 13 Geräte.

Kubernetes Ingress Metrics-Offenlegung (Kubernetes, 2020)

Kubernetes Ingress Default Backend Versionen < 1.5 legten Prometheus-Metriken öffentlich über Debug-Endpunkte offen und gaben interne Cluster-Informationen preis.

Django Debug-Modus-Offenlegungen (Django, Mehrfach)

Mehrere produktive Django-Deployments wurden aufgrund von DEBUG=True in der Produktion kompromittiert und legten Datenbank-Anmeldedaten, geheime Schlüssel und vollständige Stack-Traces offen.

Tools zum Testen/Ausnutzen

  • Nuclei — Vorlagen zur Erkennung offengelegter Debug-Endpunkte.

  • Burp Suite — Identifizierung von Debug-Parametern und Endpunkten.

  • GitLeaks — Erkennung von Debug-Code mit Geheimnissen in Versionskontrolle.

CVE-Beispiele

Referenzen

  1. MITRE. "CWE-215: Insertion of Sensitive Information Into Debugging Code." https://cwe.mitre.org/data/definitions/215.html

  2. OWASP. "Logging Cheat Sheet." https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html