Schlagwort-Archive: IDE

Supply Chain-Angriffe im Cloud Computing vermeiden

Originalartikel von Trend Micro

Sicherheit ist einer der wichtigen Aspekte, die Unternehmen berücksichtigen müssen, wenn sie auf Cloud-basierte Technologien setzen. Ganz oben auf der Liste der zu sichernden Ressourcen stehen Netzwerke, Endpunkte und Anwendungen. Um Betriebskosten zu optimieren, verlagern einige Organisationen ihre Backend-Infrastruktur in die Cloud oder betreiben ihre eigene firmeninterne private Cloud mit Cloud-basierten Lösungen. Doch wird dieser Ansatz vom Standpunkt der Architektur oder auch die Konfigurationen nicht korrekt durchgeführt, so kann das Backend Bedrohungen ausgesetzt werden und ein leichtes Ziel für Supply Chain-Angriffe darstellen. Die Folge sind der Verlust von Daten, Reputation und Vertrauen der Kunden.

In dem Whitepaper „Supply Chain Attacks in the Age of Cloud Computing: Risks, Mitigations, and the Importance of Securing Back Ends“ liefern die Sicherheitsforscher von Trend Micro einen Überblick über verschiedene Sicherheitsrisiken und Techniken zur Minimierung der Gefahren für DevOps.

Die Analysen beziehen sich auf konkrete Beispiele wie Jenkins (quelloffener Integrationsserver für Softwarekomponenten), Docker Container, Kubernetes (Orchestrierungs-Tool) und Cloud-basierten integrierten Entwicklungsumgebungen (IDE) wie AWS Cloud9 und Visual Studio Codespaces.

Authentifizierung und Access Control Lists (ACL)

Wird keine Authentifizierung aufgesetzt oder rollenbasierte Sicherheit mit ACL nicht angewendet, hat jeder, der in das System gelangen kann, Administratorzugriff. Diese Risiken werden anhand von Jenkins als Beispiel aufgezeigt.

Jenkins

Standardkonfigurationen in Backend-Systemen stellen selbst bei Anwendung der Authentifizierung ein erhebliches Sicherheitsrisiko dar. Jenkins Primary ist standardmässig in der Lage, Build-Aufgaben durchzuführen und erlaubt es Nutzern mit geringeren Privilegien, die Jenkins-Instanz vollständig zu übernehmen, einschliesslich der vertraulichen Daten, Job-Konfiguration und Source Code. Es ist kein Authentifizierungs- oder Access Control Lists (ACLs)-Modell vorhanden. Wird die Matrix-basierte Sicherheit von Jenkins angewendet, erhalten Nutzer irrtümlich den Eindruck, mit einer sicheren Konfiguration zu arbeiten. Um die Ausführung von Jobs auf dem Primary zu deaktivieren, könnte das Plug-In Authorize Project zusammen mit der Einstellung Shell executable in /bin/false auf der Seite „Configure System“ verwendet werden.

Des Weiteren sollten Entwicklerteams die Nutzung von Community Pug-Ins überdenken. Den Sicherheits-Advisories von Jenkins zufolge stehen die meisten Sicherheitslücken in der Plattform in Zusammenhang mit Plug-Ins, wobei es sich bei den meisten um die unsichere Speicherung von vertraulichen Daten sowie Sandbox-basierte Ausbruchmöglichkeiten handelt.

Einsatz von Docker Containern

Die Verwendung von Containern ist inzwischen sehr beliebt, da sie entweder Software bieten, die sofort einsatzbereit ist oder nur einer minimalen Konfiguration bedarf. Containerisierung hilft also bei schnellen Implementierungen und sorgt für eine stabile Umgebung.

Docker ist die bei Entwicklerteams am weitesten verbreitete Container Engine. Sie wird bei der Anwendungserstellung, beim Testen, Packaging sowie bei der Bereitstellung eingesetzt. Doch seit dem Siegeszug dieser Technologie fanden die Sicherheitsforscher viele Container Images auf Docker Hub, die bösartig waren oder für verschiedene Angriffe missbraucht wurden. Allein im Jahr 2020 wurden zahlreiche bösartige Container Images für Kryptowährungs-Mining genutzt. Diese Vorfälle unterstreichen die Empfehlung, nur offizielle Docker Images zu verwenden, um potenzielle Sicherheitsrisiken zu minimieren und Bedrohungen zu verhindern.

Bild 1. Infektionsablauf in einem Docker Image

Exponierte Docker-APIs erleichtern es zudem Angreifern, die Server zu nutzen, um Krypto-Miner zu installieren. Privilegierte Docker Container und exponierte Daemon-Ports könnten ebenfalls zu Angriffsflächen werden.

Kubernetes

Kubernetes ist ein Orchestrierungs-Tool zur für die skalierbare Bereitstellung und Verwaltung von Containern. Kubernetes-Dienste werden von vielen Cloud-Anbietern wie Microsoft Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS) und Google Kubernetes Engine (GKE) angeboten. Solche Managed Services tragen dazu bei, das Risiko grösserer Fehlkonfigurationsprobleme zu verringern. Da dies jedoch für einige Umgebungen keine Option darstellt, können beim On-Premise Betrieb von Kubernetes-Clustern Risiken im Zusammenhang mit Fehlkonfigurationen auftreten.

Bild 2. Skizze eines Kubernetes Clusters und dessen Komponenten (Quelle: Kubernetes.io)

Die API spielt eine wichtige Rolle für die Kubernetes-Sicherheit. Kann eine Anwendung, die innerhalb eines Clusters eingesetzt wird, mit dem API-Server interferieren, muss dies als Sicherheitsrisiko betrachtet werden. Daher sollte die API nur den Geräten zur Verfügung gestellt werden, die sie benötigen, eine Massnahme, die durch die Implementierung einer rollenbasierten Zugriffskontrolle und durch die Gewährleistung des Prinzips der geringsten Privilegien erreicht werden kann.

In einem falsch konfigurierten Szenario kann eine einzige anfällige Anwendung als Einstiegspunkt für den gesamten Cluster dienen. Benutzer sollten sicherstellen, dass nur der kube-api-server-Zugriff auf den etcd (ein verteilter Schlüsselwert-Speicher für kritische Daten) hat, da sonst unbeabsichtigte Datenlecks oder unbefugte Änderungen auftreten könnten. Zudem sollte ein Pod (eine grundlegende Bereitstellungseinheit innerhalb eines Kubernetes-Clusters) mit weniger Privilegien betrieben werden, um eine Kompromittierung von Knoten oder des gesamten Clusters zu vermeiden.

Online IDEs

Die Online Cloud-Entwicklungsumgebungen stellen eine interessante Alternative zu den Desktop-Systemen dar.

Cloud IDEs bringen alle Fähigkeiten und Tools zusammen, die ein Softwareentwickler benötigt. Zu den beliebtesten IDEs gehören AWS Cloud9 und Microsofts Visual Studio Codespaces. Visual Studio Codespaces ist eine komplette Anwendung in einer vernetzten Umgebung, während AWS Cloud9 nur Backend Services auf einer verlinkten Maschine bietet, und zusätzlich Frontend Services innerhalb der AWS Cloud.

Die interne Backend-Implementierung variiert je nach Cloud-IDE-Anbieter, aber alle bieten eine Terminal-Schnittstelle zur Umgebung des Benutzers. In den meisten Fällen haben die Benutzer die volle Kontrolle über die Umgebung und sind gleichzeitig für die Gewährleistung einer sicheren Konfiguration verantwortlich. Fehlkonfigurationen können auftreten, wenn Ports für eine erweiterte Nutzung von Anwendungen exponiert werden, sollte der Cloud Provider Timeouts einsetzen, die das verlinkte Gerät bei längerer Inaktivität abschalten.

Im Gegensatz dazu stehen für Visual Studio Codespaces eine Reihe von Erweiterungen zur Verfügung. Diese eignen sich jedoch auch als potenzielle Angriffsfläche. Beispielsweise kann eine in mit einem Backdoor versehene Erweiterung zu einer Systemkompromittierung führen aufgrund fehlender Berechtigungsprüfungen während der Installation oder Nutzung. Um solche Risiken zu mindern, sollten Entwicklungsteams nur vertrauenswürdige Plug-Ins oder Erweiterungen installieren und ihre Umgebungen auf die neueste Version aktualisieren.

Auch sind die Fälle von bösartigen Browser Plug-Ins bekannt, und ihre Funktionalität lässt sich auf Online IDE-Entwicklung erweitern. Ein Proof-of-Concept hat gezeigt, wie ein Angreifer darüber Code stehlen kann. Auch ist bekannt, dass Banking-Trojaner Browser-Funktionen nutzen, um Zugangsdaten von Nutzern zu stehlen. Eine Alternative dazu könnte Code stehlen oder auf Tokens für die IDE zugreifen.

Empfehlungen

Mit zunehmender Komplexität der im Backend verwendeten Software steigt das Risiko von Fehlkonfigurationen. Deshalb sollten Entwicklerteams sich immer dessen bewusst sein, dass es keine sichere Umgebung gibt. Folgende Best Practices können die Backend-Sicherheit verbessern helfen:

  • Umsetzung des Prinzips der Mindestprivilegien: Beschränken der Kontoprivilegien in Cloud-Diensten, vor allem wenn diese an öffentliche Cloud-Anbieter gebunden sind. Darüber hinaus sollten die Berechtigungen und der Zugriff auf Tools limitiert sein, um zu verhindern, dass Angreifer in der Computerumgebung Fuss fassen.
  • Admin-Konten nicht für alltägliche Aufgaben nutzen: Der Admin sollte nur für Continuous Integration and Continuous Deployment (CI/CD)-Tools eingesetzt werden.
  • Checks durchführen auf veraltete oder angreifbare Bibliotheken im Code: Tools wie der OWASP Dependency-Check und Lösungen etwa von Snyk liefern kostenlose Drittanbieter-Überprüfung für quelloffene Projekte.
  • Compliance zu Industriestandards: So können etwa Kubernetes-Anwender die CIS Kubernetes Benchmark vom Center for Internet Security (CIS) checken, um kritische Dateien und Verzeichnisse zu monitoren. Container-Nutzer können das Gleiche mithilfe des Application Container Security Guide vom National Institute of Standards and Technology (NIST) erreichen.

Cloud-Sicherheitslösungen

Cloud-spezifische Sicherheitslösungen wie die Trend Micro™ Hybrid Cloud Security können zum Schutz von Cloud-nativen Systemen und ihren verschiedenen Schichten beitragen. Die Software bietet schlanke, automatisierte Sicherheit für die DevOps Pipeline mit mehreren XGenTM Threat Defense-Techniken. Unterstützt wird sie von Trend Micro Cloud One™ , einer Sicherheitsdienste-Plattform für Cloud-Entwickler. Sie bietet automatisierten Schutz für die CI/CD-Pipeline und Anwendungen. Sie trägt auch dazu bei, Sicherheitsprobleme früher zu erkennen und zu lösen und die Lieferzeit für die DevOps-Teams zu verkürzen. Die Plattform umfasst:

Der vollständige Report „Supply Chain Attacks in the Age of Cloud Computing: Risks, Mitigations, and the Importance of Securing Back Ends“ steht Interessierten zur Verfügung.