Coders Conquer Security: Infrastructure as Code-Serie – Verwendung von Komponenten aus nicht vertrauenswürdigen Quellen

Wir nähern uns dem Ende unserer „Infrastructure as Code“-Serie, und es war uns eine Freude, Entwickler wie Sie auf ihrem IaC-Sicherheitsweg zu unterstützen.

Haben Sie die Challenges bereits ausprobiert? Wie ist Ihr bisheriger Punktestand? Bevor wir beginnen, lassen Sie uns prüfen, wie viel Sie bereits über die Tücken bei der Verwendung von Komponenten aus nicht vertrauenswürdigen Quellen wissen:

Sie haben noch etwas Nachholbedarf? Lesen Sie weiter:

Das verletzungsanfällige Verhalten, auf das wir uns heute konzentrieren, ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen – eine scheinbar harmlose Praxis, die jedoch große Probleme verursacht. Die Nutzung von Open-Source-Code und -Ressourcen bietet viele Vorteile. Im Allgemeinen ermöglicht sie es Experten, ihre Ideen, ihre Arbeit und sogar fertigen Code auf Plattformen wie GitHub beizusteuern, damit andere, die bei der Programmierung oder App-Entwicklung vor Herausforderungen stehen, davon profitieren können. Die Verwendung fertiger Codebausteine erspart Entwicklern das ständige Neuerfinden des Rads.

Die Verwendung von Code-Schnipseln aus unzuverlässigen, ungeprüften oder potenziell gefährlichen Quellen birgt jedoch erhebliche Risiken. Tatsächlich ist dies eine der häufigsten Ursachen dafür, dass sowohl schwerwiegende als auch kleinere Sicherheitslücken in ansonsten sichere Anwendungen gelangen. Manchmal werden diese Schwachstellen von den Erstellern versehentlich eingebaut. Es gab jedoch auch Fälle, in denen böswilliger Code von potenziellen Angreifern geschrieben wurde. Dieser Code wird dann in der Hoffnung geteilt, Opfer in die Falle zu locken, die ihn unbedacht in ihre Anwendungen einbinden.

Warum ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen gefährlich?

Nehmen wir an, ein Entwickler steht unter Zeitdruck und muss eine Anwendung konfigurieren. Das kann ein komplexer Prozess sein. Anstatt viel Zeit in die Ausarbeitung jeder möglichen Konfiguration zu investieren, sucht er bei Google und findet jemanden, der bereits eine scheinbar perfekte Konfigurationsdatei erstellt hat. Obwohl der Entwickler nichts über den Autor des Codes weiß, ist das Hinzufügen zur neuen Anwendung relativ einfach. In einer Docker-Umgebung lässt sich dies mit zwei Zeilen erledigen:

RUN cd /etc/apache2/sites-available/ && \
   wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
   9d372cfa8855a6be74bcca86efadfbbf/raw/\
   fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf

Nun lädt das Docker-Image die Konfigurationsdatei eines Drittanbieters dynamisch nach. Selbst wenn die Datei zum Zeitpunkt der Prüfung einwandfrei war, bedeutet die Einbettung des Pointers in den Code der neuen Anwendung eine dauerhafte Abhängigkeit. Tage, Wochen oder Monate später könnte die Datei vom ursprünglichen Autor oder einem Angreifer, der das Code-Repository kompromittiert hat, manipuliert werden. Plötzlich kann die geteilte Konfigurationsdatei die Anwendung dazu bringen, sich völlig anders als beabsichtigt zu verhalten, was unbefugten Benutzern Zugriff gewähren oder sogar direkt Daten stehlen und abgreifen kann.

Ein besserer Weg zur Nutzung geteilter Ressourcen

Wenn Ihr Unternehmen die Verwendung von Code aus externen Quellen erlaubt, müssen Prozesse etabliert werden, um dies sicher zu gestalten. Achten Sie bei der Bewertung von externem Code darauf, Komponenten nur aus offiziellen Quellen über sichere Verbindungen zu beziehen. Selbst dann sollten Sie niemals auf eine externe Quelle verlinken, um den Code direkt zu laden, da Sie damit die Kontrolle über den Prozess verlieren. Stattdessen sollte genehmigter Code in eine sichere Bibliothek importiert und nur von diesem geschützten Ort aus verwendet werden. In einer Docker-Umgebung sähe der Code dann so aus:

COPY src/config/default-ssl.conf /etc/apache2/sites-available/

Anstatt sich auf externe Konfigurationsdateien von Drittanbietern zu verlassen, wird hier eine lokale Kopie dieser Dateien verwendet. Dies verhindert, dass unerwartete oder böswillige Änderungen vorgenommen werden können.

Zusätzlich zur Nutzung einer sicheren Code-Bibliothek sollte ein Patch-Management-Prozess implementiert werden, um Komponenten über den gesamten Software-Lebenszyklus hinweg kontinuierlich zu überwachen. Alle Client- und serverseitigen Komponenten sollten zudem mithilfe von Tools wie NVD oder CVE auf Sicherheitswarnungen geprüft werden. Entfernen Sie schließlich alle ungenutzten oder unnötigen Abhängigkeiten und Funktionen, die möglicherweise mit dem externen Code eingeschleust wurden.

Durch die Befolgung dieser Schritte können Entwickler externe Ressourcen sicherer nutzen, ohne versehentlich Schwachstellen in ihre Anwendungen und ihren Code einzubauen.

Besuchen Sie die Secure Code Warrior Blogseiten für weitere Einblicke in diese Schwachstelle und erfahren Sie, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen anderer Sicherheitslücken schützen können. Sie können auch eine Demo der IaC-Challenges auf der Secure Code Warrior-Trainingsplattform ausprobieren, um Ihre Cybersicherheitskenntnisse stets auf dem neuesten Stand zu halten.