Standardkonfigurationen von Software und Anwendungen in der Cybersicherheit
Dieser Artikel ist Teil einer Serie, in der wir uns mit einem aktuellen NSA/CISA Joint Cybersecurity Advisory über die wichtigsten Cybersicherheitsprobleme, die bei den von diesen Organisationen durchgeführten Red/Blue-Team-Übungen festgestellt wurden. In diesem Artikel finden Sie einen ausführlicheren Blick auf das spezifische Problem, mit realen Szenarien, in denen es anwendbar ist, sowie Abhilfestrategien, die angewendet werden können, um es zu begrenzen oder zu überwinden. Damit werden die Informationen aus dem NSA/CISA-Bericht erweitert.
–
Häufig sind die von den Herstellern bereitgestellten Standardkonfigurationen nicht für die Sicherheit optimiert, so dass die Systeme anfällig für Angriffe sind. Standardkonfigurationen von Systemdiensten und Anwendungen können unbeabsichtigt Türen für unbefugten Zugriff und böswillige Aktivitäten öffnen oder gegnerische Aufklärungsmaßnahmen erleichtern, indem sie sich auf bekannte Betriebsbedingungen stützen.
Zwei wesentliche Probleme sind weit verbreitet: Standardanmeldeinformationen und freizügige Standarddienstberechtigungen und Konfigurationseinstellungen. Diese Konfigurationen, die für eine einfache Einrichtung und Nutzung gedacht sind, werden oft zum schwächsten Glied in der Cybersicherheit.
Auswirkungen in der realen Welt
Bei der Bereitstellung eines bekannten Software-Stacks (z. B. LAMP - Linux, Apache, Mysql und PHP) kann der resultierende Systemzustand leicht abgeleitet und repliziert werden. Auf diese Weise kann das System eines potenziellen Ziels leicht nachgebildet und auf Schwachstellen untersucht werden, anstatt Überwachungs- und Warnsysteme bei Sondierungsversuchen von Bedrohungsakteuren gegen die tatsächlichen Systeme auszulösen. Außerdem wird es für einen Angreifer einfacher, potenzielle Angriffsvektoren zu identifizieren, indem er einfach eine Komponente identifiziert und dann (richtigerweise) annimmt, dass der gesamte Stack vorhanden ist.
Probleme mit der Standardkonfiguration
Bei ihren Tests der roten und blauen Teams haben die NSA und die CISA die folgenden gemeinsamen Beispiele gefunden:
Standard-Anmeldeinformationen
Kommerzielle Standard-Netzwerkgeräte (COTS) werden oft mit vordefinierten Standard-Anmeldeinformationen für administrative Konten geliefert. Diese sind leicht auffindbar und können von böswilligen Akteuren ausgenutzt werden, um unbefugt auf Geräte zuzugreifen, administrative Konten zurückzusetzen oder VPN-Anmeldeinformationen zu nutzen. Außerdem können Geräte wie Drucker, Scanner und IoT-Geräte mit ihren geladenen privilegierten Domänenkonten Angreifern die Möglichkeit bieten, sich innerhalb eines Netzwerks zu bewegen.
In der Vergangenheit gab es sehr aufsehenerregende Vorfälle, die durch die Ausnutzung solcher Standardkonfigurationen verursacht oder verschlimmert wurden. Botnets, die insbesondere auf IoT-Geräte abzielen, gedeihen und wachsen in Umgebungen, in denen die Bewegung und Entdeckung neuer Bots durch die Ausnutzung bekannter Standardkonfigurationen erfolgt, was eine schnelle und einfache Verbreitung des Botnets über mehrere Geräte, Netzwerke und Organisationen ermöglicht.
Unsichere Active Directory-Zertifikatsdienste (ADCS)
ADCS, eine wichtige Komponente bei der Verwaltung der Public Key Infrastructure (PKI) in Active Directory-Umgebungen, kann aufgrund von Fehlkonfigurationen der Vorlagen gefährdet werden. Wenn beispielsweise die Webregistrierung ohne angemessene Schutzmaßnahmen aktiviert wird, können Angreifer gefälschte Zertifikate erlangen, sich als legitime Entitäten ausgeben und unbefugten Zugriff auf wichtige Systeme und Daten erhalten.
Unsichere Legacy-Protokolle und -Dienste
Anfällige Netzwerkdienste wie LLMNR und NetBIOS Name Service in Windows können durch Spoofing-, Poisoning- und Relay-Techniken ausgenutzt werden. Wenn diese Protokolle aktiviert bleiben, können Angreifer Domänen-Hashes abfangen und Systemzugriff erlangen, was eine erhebliche Bedrohung für Windows-Umgebungen darstellt.
Unsicherer Server Message Block (SMB) Dienst
Der SMB-Dienst, der in erster Linie für die gemeinsame Nutzung von Dateien in Windows verwendet wird, ist ein weiteres Opfer unsicherer Standardeinstellungen. Das Fehlen einer obligatorischen SMB-Signierung ermöglicht Angreifern Machine-in-the-Middle-Angriffe, bei denen sie auf entfernte Systeme zugreifen können, ohne dass sie Hashes erfassen und knacken müssen.
Diese Ergebnisse scheinen darauf hinzudeuten, dass das Problem in Windows-basierten Netzwerken häufiger auftritt, aber das ist nicht unbedingt der Fall. Die Ergebnisse können einfach durch die verfügbaren Testumgebungen verzerrt worden sein. Bekannte Standardkonfigurationen können sich auf alle Arten von Betriebssystemen und Umgebungen auswirken und tun dies auch. Beispielsweise werden die meisten Linux-Distributionen mit einer aktivierten sshd-Konfiguration (Secure Shell Daemon) ausgeliefert, die eine schlüsselbasierte Anmeldung nicht erzwingt (oder sie sogar aktiviert), selbst wenn diese Form der Authentifizierung zuverlässiger ist als die herkömmliche Anmeldung mit Passwort. Eine weitere häufige Standardkonfiguration ist das Fehlen eines Brute-Force-Schutzes für denselben sshd-Dienst, was jedes neu installierte (und mit dem Internet verbundene) Linux-System sofort zu einem Ziel für Heerscharen von Bots macht, die durch Ausprobieren nach verwundbaren Konten suchen.
Strategien zur Schadensbegrenzung
Um diese Schwachstellen zu bekämpfen, ist es wichtig, die Standardkonfigurationen von Anwendungen und Geräten vor deren Einsatz zu ändern. Dazu gehört das Ändern oder Deaktivieren von Standardbenutzernamen und -kennwörtern, die vom Hersteller bereitgestellt werden, und das Erzwingen der Verwendung starker Kennwörter. Bei ADCS sollten Sie für sichere Konfigurationen sorgen, indem Sie die Infrastruktur aktualisieren und patchen, robuste Überwachungs- und Prüfmechanismen einsetzen und strenge Zugriffskontrollen implementieren. Die Überprüfung und Einschränkung von Berechtigungen für ADCS-Vorlagen ist ebenfalls wichtig, um die unberechtigte Ausstellung von Zertifikaten zu verhindern.
Als invasivere Strategie sollten die Systeme nicht unmittelbar nach der Bereitstellung in einem nutzbaren Zustand belassen werden. Wenn ein System in Betrieb genommen wird und sofort nutzbar ist, wird der Nutzen einer Konfigurationsänderung geringer. Wenn man also dafür sorgt, dass der Standardzustand nicht sofort nutzbar ist, wird die Änderung der Konfiguration nicht mehr optional, sondern obligatorisch. Auch wenn dies den Erwartungen zuwiderläuft und einige Gegner hat, würde es die IT-Teams auch dazu zwingen, absichtlich umgebungsspezifische Konfigurationsänderungen vorzunehmen, die eine Bereitstellung von der nächsten unterscheiden würden, was diese Art von Risiko erheblich reduzieren würde. Diese Art von Ansatz ist zwar effektiver, hat aber auch einige Nachteile, nämlich eine höhere Arbeitsbelastung und eine längere Bereitstellungszeit für neue Systeme.
Kurz gesagt, einige mögliche Strategien zur Entschärfung des Problems sind:
Ändern von Standardkonfigurationen vor der Bereitstellung
Ändern oder deaktivieren Sie die Standardbenutzernamen und -kennwörter, bevor Sie Systeme einrichten. Verwenden Sie sichere Passwörter und halten Sie sich an die Sicherheitsrichtlinien des Herstellers.
Einsatz von Konfigurationsmanagement-Tools
Verwenden Sie automatisierte Tools für das Konfigurationsmanagement, um von Anfang an eine sichere Bereitstellung zu gewährleisten.
Regelmäßige Prüfungen und Aktualisierungen einbeziehen
Durchführung regelmäßiger Prüfungen der Konfigurationen und Anwendung der erforderlichen Aktualisierungen zur Behebung von Schwachstellen.
Mitarbeiter ausbilden und schulen
Implementieren Sie umfassende Schulungsprogramme, um das Bewusstsein für die mit Standardkonfigurationen verbundenen Risiken zu schärfen. Dies ist besonders wichtig in BYOD-Umgebungen, wo das Risiko von Standardkonfigurationen von fremden Geräten ausgeht.
Implementieren einer Richtlinie für den nicht verwendbaren Standardzustand
Bereitstellung von Systemen in einem nicht nutzbaren Standardzustand, um IT-Teams zu zwingen, die erforderlichen Sicherheitskonfigurationen vorzunehmen. Erörtern Sie die Nachteile dieses Ansatzes, z. B. die längere Bereitstellungszeit und den möglichen Widerstand.
Kontinuierliche Überwachung und Protokollierung
Führen Sie kontinuierliche Überwachungs- und Protokollierungsverfahren ein, um unbefugte Änderungen an Konfigurationen zu erkennen. Erwägen Sie die Erstellung von Warnungen für Standardkonfigurationen, die in einem System vorhanden sind.