Security Misconfiguration

Nicht jede Schwachstelle ist ein Programmierfehler. Bei Security Misconfiguration funktioniert die Software genau wie vorgesehen, nur die Einstellungen stimmen nicht. Ein vergessenes Standardpasswort, ein in Produktion aktiver Debug-Modus oder ein öffentlich lesbarer Cloud-Bucket: kleine Nachlässigkeiten mit großen Folgen. In diesem Artikel erfahren Sie, was unter Security Misconfiguration fällt, wie Angreifer solche Fehler automatisiert aufspüren, welcher Schaden droht und wie Sie Ihre Umgebung dauerhaft absichern.

Was ist Security Misconfiguration?

Security Misconfiguration ist der Sammelbegriff für Sicherheitsrisiken, die nicht im Quellcode stecken, sondern in Installation und Konfiguration der Software: nie geänderte Standardkonten, unnötig offene Funktionen und Ports, Fehlermeldungen, die interne Details preisgeben, fehlende Security-Header oder viel zu großzügig vergebene Cloud-Berechtigungen. Die Kategorie steht als A05:2021 auf Platz fünf der OWASP Top 10 und wird unter CWE-16 (Configuration) geführt.

Stellen Sie sich ein nagelneues Bürogebäude mit zertifizierten Schlössern vor. An den Schlössern liegt es nicht, aber der Bauunternehmer hat alle Türen auf dem Werkscode gelassen, der Notausgang steht für die Möbelpacker noch offen und im Foyer hängt der Lageplan der Alarmanlage. Nichts ist kaputt; das Gebäude wurde nur nie sicher eingerichtet. Genau das ist Security Misconfiguration: funktionierende Technik, deren Einstellungen die Tür offen lassen.

Das Tückische an dieser Kategorie ist ihre Breite. Der Fehler kann in jeder Schicht des Systems stecken: im Betriebssystem, im Webserver, im Framework, in der Datenbank, in einem Container oder in der Cloud-Plattform. Eine einzige vergessene Einstellung in einer einzigen Schicht genügt einem Angreifer bereits.

Wie funktioniert ein Angriff über eine Fehlkonfiguration?

Angreifer müssen sich dafür selten anstrengen. Suchmaschinen wie Shodan und Censys indexieren laufend alles, was am Internet hängt, samt Versionsnummern, offenen Ports und Verwaltungsoberflächen. Automatisierte Skripte klopfen bekannte Pfade wie /admin, /.git, /backup und /phpinfo.php ab und arbeiten Listen mit Standardpasswörtern durch. Wer einen falsch konfigurierten Server betreibt, wird meist innerhalb weniger Stunden gefunden, nicht, weil es jemand gezielt auf Sie abgesehen hätte, sondern weil das gesamte Internet rund um die Uhr durchleuchtet wird.

Wie das in der Praxis aussieht, zeigt dieses Express-Beispiel: eine API, in der gleich drei häufige Konfigurationsfehler zusammenkommen.

Verwundbar:

const express = require('express');
const cors = require('cors');
const serveIndex = require('serve-index');
const app = express();

// CORS sperrangelweit offen: jede Website darf die API aufrufen
app.use(cors({ origin: '*' }));

// Verzeichnisauflistung zeigt jede Datei in /backup
app.use('/backup', serveIndex('backup'), express.static('backup'));

// Fehlerbehandlung verrät Stacktraces und Versionen an den Besucher
app.use((err, req, res, next) => {
  res.status(500).send('<pre>' + err.stack + '</pre>');
});

Ein Angreifer, der /backup aufruft, bekommt eine saubere Liste aller Dateien in diesem Verzeichnis, inklusive des Datenbank-Exports vom letzten Jahr. Die sperrangelweit offene CORS-Einstellung erlaubt jeder beliebigen Website, aus dem Browser eines Besuchers mit der API zu sprechen. Und jeder Fehler der Anwendung liefert einen vollständigen Stacktrace zurück: Dateipfade, Verzeichnisstruktur, Framework-Versionen und mitunter sogar Bruchstücke von Abfragen. Jedes Detail beschleunigt den nächsten Schritt des Angriffs.

Sicher:

const express = require('express');
const helmet = require('helmet');
const cors = require('cors');
const app = express();

app.disable('x-powered-by');   // das Framework nicht verraten
app.use(helmet());             // gängige Security-Header setzen

// Nur die Origins, denen Sie wirklich vertrauen
app.use(cors({ origin: ['https://app.example.com'] }));

// Statische Dateien ohne Auflistung, Dotfiles blockiert
app.use('/files', express.static('files', { index: false, dotfiles: 'deny' }));

// Generischer Fehler für den Client, Details nur ins Log
app.use((err, req, res, next) => {
  console.error(err);
  res.status(500).json({ error: 'Interner Serverfehler' });
});

Die sichere Variante dreht jeden Hahn zu: CORS arbeitet mit einer expliziten Allowlist, statische Dateien werden ohne Verzeichnisübersicht und mit blockierten Dotfiles ausgeliefert, und der Besucher sieht im Fehlerfall nur eine generische Meldung, während die Details im internen Log landen. Helmet setzt obendrein die gängigen Security-Header, und der Header, der das Framework verrät, ist abgeschaltet. Wichtiger als die einzelnen Zeilen ist das Prinzip dahinter: Alles, was nicht ausdrücklich gebraucht wird, bleibt geschlossen.

Welche Auswirkungen hat Security Misconfiguration?

Der Schweregrad reicht von niedrig bis hoch, und genau diese Spannweite zeigt sich in der Praxis. Ein fehlender Header oder eine sichtbare Versionsnummer ist für sich genommen überschaubar: Es sickern Informationen durch, mit denen ein Angreifer gezielter vorgehen kann. Ein Admin-Panel mit Standardpasswort, eine ohne Authentifizierung am Internet hängende Datenbank oder ein öffentlich lesbarer Storage-Bucket dagegen öffnet den direkten Zugriff auf Systeme und sensible Daten. Ungesicherte Elasticsearch- und MongoDB-Instanzen haben in den vergangenen Jahren wiederholt Millionen von Kundendatensätzen preisgegeben, ohne dass eine einzige Zeile Code fehlerhaft gewesen wäre.

Hinzu kommt: Eine Fehlkonfiguration ist selten die Endstation. Eine ausführliche Fehlermeldung verrät Pfade, die einen Path-Traversal-Angriff ermöglichen, ein XML-Parser mit Standardeinstellungen öffnet die Tür zu XXE, und eine vergessene Debug-Konsole wächst sich zu Remote Code Execution aus. Für das Unternehmen bedeutet das schnell eine meldepflichtige Datenpanne nach DSGVO, Wiederherstellungskosten, Reputationsschaden und unangenehme Fragen von Kunden und Aufsichtsbehörden, verursacht durch eine Einstellung, die in fünf Minuten richtig gestanden hätte.

Wie spürt man Fehlkonfigurationen auf?

Die gute Nachricht: Konfigurationsfehler lassen sich gut finden. Automatisierte Scanner vergleichen Header, TLS-Einstellungen, bekannte Pfade und Versionsnummern mit sicheren Referenzwerten und fangen so die offensichtlichen Fälle ab. Die Einordnung bleibt jedoch Handarbeit: Ob ein erreichbarer Endpunkt wirklich ein Problem ist, hängt davon ab, was dahinterliegt. Pentester orientieren sich deshalb unter anderem an den Konfigurationskapiteln des OWASP Web Security Testing Guide: Sie probieren Standardpasswörter aus, suchen vergessene Test- und Verwaltungsoberflächen, provozieren Fehlermeldungen, prüfen Cloud-Berechtigungen und Bucket-Richtlinien und vergleichen, ob Umgebungen voneinander abweichen. AssistSec nimmt diese Prüfungen in jedem Penetrationstest standardmäßig mit auf, gerade weil hier so oft der erste Fuß in der Tür steht.

Wie verhindert man Security Misconfiguration?

• Machen Sie Härtung zu einem wiederholbaren Prozess: Halten Sie die sichere Konfiguration als Code fest (Infrastructure as Code, Golden Images), damit jede Umgebung identisch und nachvollziehbar ausgerollt wird.
• Verkleinern Sie die Angriffsfläche: Entfernen oder deaktivieren Sie Beispielanwendungen, ungenutzte Funktionen, Ports, Pakete und Konten.
• Ersetzen Sie vor dem Livegang sämtliche Standardpasswörter und löschen Sie Standardkonten.
• Trennen Sie Entwicklung, Test und Produktion strikt; schalten Sie Debug-Modi und ausführliche Fehlermeldungen in Produktion ab.
• Zeigen Sie Besuchern nur generische Fehlerseiten und schreiben Sie technische Details ausschließlich in interne Logs.
• Setzen Sie Security-Header wie HSTS, Content-Security-Policy und X-Content-Type-Options.
• Vergeben Sie Cloud-Berechtigungen nach dem Least-Privilege-Prinzip und stellen Sie Storage-Buckets standardmäßig auf privat.
• Prüfen Sie die Konfiguration automatisiert in der CI/CD-Pipeline, gleichen Sie sie regelmäßig mit Benchmarks wie denen von CIS ab und wiederholen Sie die Prüfung nach jeder Änderung.