Unsichere Standardinitialisierung von Ressourcen
Beschreibung
Unsichere Standardinitialisierung von Ressourcen tritt auf, wenn ein Produkt Ressourcen auf einen unsicheren Standardwert initialisiert oder setzt, obwohl ein sichererer Wert erwartet wird. Diese Schwachstelle manifestiert sich in verschiedenen Komponenten wie Konfigurationseinstellungen, Berechtigungen, Sicherheitsfunktionen und kryptografischen Parametern. Angreifer können den unsicheren Standardzustand vor der ordnungsgemäßen Konfiguration ausnutzen und sich unbefugten Zugang zu verschaffen oder Sicherheitskontrollen zu umgehen.
Risiko
Unsichere Standardinitialisierungen schaffen erhebliche Sicherheitsrisiken. Angreifer können Systeme während der Boot- oder Setup-Phasen kompromittieren. Deaktivierte Sicherheitsfunktionen in der Standardkonfiguration setzen Systeme Angriffen aus. Übermäßig freizügige Standardberechtigungen ermöglichen unbefugten Zugriff. Schwache kryptografische Standardeinstellungen ermöglichen das Knacken der Verschlüsselung. Fehlende Authentifizierungsanforderungen standardmäßig ermöglichen anonymen Zugriff. Debug-Schnittstellen, die standardmäßig aktiviert sind, bieten Angriffsangriffsflächen.
Lösung
Entwerfen Sie sichere Standardkonfigurationen für alle Einstellungen. Stellen Sie sicher, dass der Standardzustand sicher ist, wenn keine Konfiguration angegeben wird. Wenden Sie das Prinzip der geringsten Rechte auf Standardeinstellungen an. Dokumentieren Sie sichere Konfigurationsbaselines. Implementieren Sie "Fail-Secure"-Standardeinstellungen, die den Zugriff verweigern, bis er explizit gewährt wird. Testen Sie das Standardverhalten während der Sicherheitsüberprüfungen. Aktivieren Sie Sicherheitsfunktionen standardmäßig mit Opt-out statt Opt-in.
Häufige Auswirkungen
| Auswirkung | Details |
|---|---|
| Vertraulichkeit | Bereich: Vertraulichkeit Unautorisierter Datenzugriff - Unsichere Standardeinstellungen können sensitive Daten unbefugten Benutzern zugänglich machen. |
| Integrität | Bereich: Integrität Datenmodifikation - Übermäßig freizügige Standardeinstellungen können unbefugte Änderungen ermöglichen. |
| Zugriffskontrolle | Bereich: Zugriffskontrolle Umgehung des Schutzmechanismus - Deaktivierte Sicherheitsfunktionen ermöglichen standardmäßig das Umgehen von Kontrollen. |
Beispielcode und Lösung
Verwundbarer Code
// Verwundbar: Unsichere Standardkonfiguration
#include <stdint.h>
typedef struct {
uint32_t debug_enabled; // Standard ist was?
uint32_t auth_required; // Standard ist was?
uint32_t encryption_level; // Standard ist was?
uint32_t max_login_attempts; // Standard ist was?
} security_config_t;
// VERWUNDBAR: Keine explizite Initialisierung
security_config_t global_config; // Könnte alles sein!
// VERWUNDBAR: Unsichere Standardwerte
void vulnerable_init_config(security_config_t* config) {
config->debug_enabled = 1; // Debug standardmäßig aktiviert!
config->auth_required = 0; // Keine Auth erforderlich!
config->encryption_level = 0; // Keine Verschlüsselung!
config->max_login_attempts = 0; // Unbegrenzte Versuche!
}
// VERWUNDBAR: Factory-Reset setzt auf unsichere Werte
void vulnerable_factory_reset(void) {
// Setzt alle Sicherheitsfunktionen auf "aus"
global_config.debug_enabled = 1;
global_config.auth_required = 0;
global_config.encryption_level = 0;
}
// Verwundbar: Unsichere Standardregisterwerte
module vulnerable_security_controller (
input wire clk,
input wire reset_n,
input wire [31:0] reg_write_data,
input wire [7:0] reg_addr,
input wire reg_write,
output reg [31:0] reg_read_data,
output wire security_enabled,
output wire debug_locked,
output wire encryption_on
);
// Sicherheitskonfigurationsregister
reg [31:0] security_ctrl;
reg [31:0] debug_ctrl;
reg [31:0] crypto_ctrl;
// VERWUNDBAR: Unsichere Standardwerte nach Reset
always @(posedge clk or negedge reset_n) begin
if (!reset_n) begin
// VERWUNDBAR: Sicherheit standardmäßig deaktiviert
security_ctrl <= 32'h0000_0000; // Alle Sicherheiten aus
// VERWUNDBAR: Debug standardmäßig aktiviert
debug_ctrl <= 32'h0000_0001; // Debug aktiviert
// VERWUNDBAR: Verschlüsselung standardmäßig deaktiviert
crypto_ctrl <= 32'h0000_0000; // Keine Verschlüsselung
end
else if (reg_write) begin
case (reg_addr)
8'h00: security_ctrl <= reg_write_data;
8'h04: debug_ctrl <= reg_write_data;
8'h08: crypto_ctrl <= reg_write_data;
endcase
end
end
// VERWUNDBAR: Unsichere Standardausgänge
assign security_enabled = security_ctrl[0]; // Standard: 0 (deaktiviert)
assign debug_locked = debug_ctrl[0]; // Standard: 1 (entsperrt!)
assign encryption_on = crypto_ctrl[0]; // Standard: 0 (aus)
endmodule
Sichere Lösung
// Sicher: Sichere Standardkonfiguration
#include <stdint.h>
typedef struct {
uint32_t debug_enabled;
uint32_t auth_required;
uint32_t encryption_level;
uint32_t max_login_attempts;
} security_config_t;
// SICHER: Konstante mit sicheren Standardwerten
static const security_config_t SECURE_DEFAULTS = {
.debug_enabled = 0, // Debug standardmäßig deaktiviert
.auth_required = 1, // Auth standardmäßig erforderlich
.encryption_level = 2, // Starke Verschlüsselung Standard
.max_login_attempts = 3 // Versuche begrenzt
};
// SICHER: Mit sicheren Standardwerten initialisiert
security_config_t global_config = {
.debug_enabled = 0,
.auth_required = 1,
.encryption_level = 2,
.max_login_attempts = 3
};
// SICHER: Explizite sichere Standardwerte
void secure_init_config(security_config_t* config) {
// Von sicheren Standardwerten kopieren
*config = SECURE_DEFAULTS;
}
// SICHER: Factory-Reset behält Sicherheit
void secure_factory_reset(void) {
// Reset auf sichere Standardwerte, nicht unsichere
global_config = SECURE_DEFAULTS;
// Protokollieren des Resets zu Audit-Zwecken
audit_log("Factory reset mit sicheren Standardwerten");
}
// SICHER: Konfiguration validieren
int validate_config(const security_config_t* config) {
// Sicherstellen, dass Konfiguration Mindestanforderungen erfüllt
if (config->encryption_level < 1) {
return -1; // Minimale Verschlüsselung erforderlich
}
if (config->max_login_attempts == 0 || config->max_login_attempts > 10) {
return -1; // Vernünftige Grenzen erforderlich
}
return 0;
}
// Sicher: Sichere Standardregisterwerte
module secure_security_controller (
input wire clk,
input wire reset_n,
input wire [31:0] reg_write_data,
input wire [7:0] reg_addr,
input wire reg_write,
input wire secure_master, // Nur Secure Master kann ändern
output reg [31:0] reg_read_data,
output wire security_enabled,
output wire debug_locked,
output wire encryption_on
);
// Sicherheitskonfigurationsregister
reg [31:0] security_ctrl;
reg [31:0] debug_ctrl;
reg [31:0] crypto_ctrl;
// SICHER: Sichere Standardwerte nach Reset
always @(posedge clk or negedge reset_n) begin
if (!reset_n) begin
// SICHER: Sicherheit standardmäßig aktiviert
security_ctrl <= 32'h0000_0001; // Sicherheit aktiviert
// SICHER: Debug standardmäßig gesperrt
debug_ctrl <= 32'h0000_0000; // Debug gesperrt
// SICHER: Verschlüsselung standardmäßig aktiviert
crypto_ctrl <= 32'h0000_0001; // Verschlüsselung an
end
else if (reg_write && secure_master) begin
// SICHER: Nur Secure Master kann Sicherheitsregister ändern
case (reg_addr)
8'h00: security_ctrl <= reg_write_data;
8'h04: debug_ctrl <= reg_write_data;
8'h08: crypto_ctrl <= reg_write_data;
endcase
end
end
// SICHER: Sichere Standardausgänge
assign security_enabled = security_ctrl[0]; // Standard: 1 (aktiviert)
assign debug_locked = ~debug_ctrl[0]; // Standard: 1 (gesperrt)
assign encryption_on = crypto_ctrl[0]; // Standard: 1 (an)
endmodule
Ausgenutzt in der Praxis
Standardanmeldeinformationen führten zu massivem DDoS-Angriff (2016)
Das Mirai-Botnetz nutzte IoT-Geräte aus, die mit werkseitig voreingestellten Benutzernamen und Passwörtern ausgeliefert wurden. Diese unsicheren Standardanmeldedaten ermöglichten es Angreifern, Millionen von Geräten zu kompromittieren und einen der größten DDoS-Angriffe der Geschichte zu starten.
Standardmäßig unsichere Cloud-Storage-Konfigurationen (2017-2019)
Zahlreiche Datenlecks entstanden durch Cloud-Storage-Buckets, die standardmäßig mit öffentlichem Zugriff konfiguriert waren, was zur Offenlegung sensibler Daten von Millionen von Nutzern führte.
Tools zum Testen und Ausnutzen
-
Nmap — Netzwerkscanner zur Erkennung von Standardkonfigurationen und -diensten.
-
Shodan — Suchmaschine für mit dem Internet verbundene Geräte mit Standardeinstellungen.
-
Default Credential Scanner — Tool zum Testen auf Standardanmeldedaten.
CVE-Beispiele
-
CVE-2020-3566 — Router-Standardkonfiguration aktivierte unbefugten Fernzugriff.
-
CVE-2019-1653 — Netzwerkgerät mit standardmäßig aktivierter unsicherer Konfigurationsschnittstelle.
Referenzen
-
MITRE Corporation. "CWE-1188: Insecure Default Initialization of Resource." https://cwe.mitre.org/data/definitions/1188.html
-
OWASP. "Secure Configuration Guide." https://owasp.org/www-project-web-security-testing-guide/
-
NIST SP 800-123. "Guide to General Server Security."