Pentesting in einer Welt ohne Server
Während bei klassischen Servern die meisten Administratoren eine Vorstellung von Schutzmaßnahmen haben, ist dies bei Serverless-Umgebungen seltener der Fall. Entsprechend unserer Erfahrung aus unzähligen Cloud-Penetrationstests sind diese aber besonders anfällig für bestimmte Fehlkonfigurationen und Schwachstellen. In folgendem Beitrag beleuchten wir drei kritische Sicherheitsrisiken, die Unternehmen im Rahmen eines Cloud-Penetrationstests besonders im Auge behalten sollten. Außerdem geben wir praktische Empfehlungen zur Absicherung solcher Umgebungen.
Hartcodierte Secrets und Umgebungsvariablen-Leaks
Ein häufiger Fehler in Serverless-Funktionen ist der unsichere Umgang mit Zugangsdaten und API-Schlüsseln. Bei den meisten Penetrationstests finden wir Functions, bei welchen Entwickler Zugangsdaten direkt im Code oder in Umgebungsvariablen gespeichert haben. So soll ihnen eine einfache Authentifizierung und Interaktion mit anderen Cloud-Diensten ermöglicht werden. Dies birgt jedoch erhebliche Risiken, da diese Daten jeder Benutzer mit „Read“ Permission auslesen kann.
Angriffsszenario
Es wird angenommen, dass ein Angreifer Zugriff auf den Quellcode einer Serverless-Funktion erhalten kann. Hierfür gibt es viele unterschiedliche Wege, wie etwa durch ein ungeschütztes Repository oder eine unsichere CI/CD-Pipeline. Wenn Access Token, Zertifikate oder Datenbank-Zugangsdaten hartcodiert im Code hinterlegt sind, kann der Angreifer diese nutzen, um sich unbefugt Zugang zu Cloud-Ressourcen zu verschaffen. Noch kritischer wird es, wenn Umgebungsvariablen von der Anwendung auslesbar sind – insbesondere, wenn dort vertrauliche Informationen gespeichert sind –, da diese leichter auszulesen sind und nur Leseberechtigungen benötigt werden.
In der Vergangenheit gab es bereits mehrere Sicherheitsvorfälle, bei denen hartcodierte Secrets in öffentlich zugänglichen GitHub-Repositories entdeckt wurden. Unsere Penetrationstests verwenden automatisierte Scanner, um nach solchen Informationen zu suchen und gestohlene Zugangsdaten für weitergehende Angriffe zu missbrauchen.
Schutzmaßnahmen
Es gibt mehrere Wege, ungesicherte Serverless-Funktionen gegen dieses Szenario abzusichern:
- Vermeidung hartcodierter Secrets: Stattdessen sollten API-Schlüssel und Zugangsdaten in einem sicheren Secrets Management Service wie AWS Secrets Manager, Azure Key Vault oder Google Secret Manager gespeichert werden.
- Eingeschränkte Umgebungsvariablen-Nutzung: Falls Umgebungsvariablen genutzt werden müssen, sollten sie nur für nicht-kritische Informationen eingesetzt werden.
- Code-Scans und Überprüfungen: Tools wie GitGuardian, TruffleHog oder AWS CodeGuru helfen dabei, versehentlich hochgeladene Secrets im Code zu erkennen und zu entfernen.
- Rotation und Zugriffskontrolle: Regelmäßige Rotation von Schlüsseln und der Einsatz von rollenbasierten Zugriffskontrollen (RBAC) verringern das Risiko eines Missbrauchs.
Schreibzugriff auf den Source Code
Bei der Benutzung von Serverless-Funktionen ist die Änderung des Source Codes der Funktion die größte Gefahr für den sicheren Betrieb der Funktion. Dadurch erhält ein Angreifer Code Execution auf diese Funktion und kann die Identität Serverless-Funktion in der Cloud übernehmen. Dadurch erhält der Angreifer oft Zugriff auf weitere Ressourcen und kann seine Rechte ausweiten. Gerade bei Azure Functions ist der Source Code immer in einem eigenen Storage Account gespeichert. Ein Angreifer mit Schreibrechten auf diesen Storage Account kann somit nicht nur den Storage Account, sondern auch die Azure Function übernehmen.
Angriffsszenario
Ein Angreifer in AWS entdeckt, dass eine seiner IAM-Rollen mit Schreibrechten für eine Lambda-Funktion ausgestattet ist. Durch diese Fehlkonfiguration im Identity und Access Management kann er diesen Schreibzugriff ausnutzen, um den Code der Funktion zu modifizieren und eine Hintertür für zukünftige Angriffe zu hinterlassen. Alternativ könnte der Zugriff auf eine fehlkonfigurierte CI/CD-Pipeline es Angreifern ermöglichen, unautorisiert Schadcode in andere Lambda Functions einzuschleusen.
Es konnten bereits in früheren durchgeführten Penetrationstests CI/CD-Pipelines kompromittiert werden, um bösartigen Code in Cloud-Anwendungen einzuschleusen. Diese Attacken sind für die Verbreitung von Malware, Datendiebstahl oder zur Einrichtung persistenter Bedrohungen nutzbar.
Schutzmaßnahmen
- Strikte IAM-Rollen: Serverless-Funktionen sollten nach dem Prinzip der minimalen Rechte (Least Privilege) nur die absolut notwendigen Berechtigungen erhalten.
- Code-Integrität sicherstellen: Die Überprüfung, ob der Code verändert wurde, durch Hash-Werte oder digitale Signaturen kann helfen, Manipulationen frühzeitig zu erkennen.
- Absicherung der CI/CD-Pipeline: Eine sichere Authentifizierung und Autorisierung für Deployments verhindert ungewollte Code-Änderungen durch Dritte.
- Logging und Monitoring: Der Einsatz von Security Information and Event Management (SIEM) und Cloud-native Monitoring-Diensten wie AWS CloudTrail, Azure Monitor oder Google Cloud Audit Logs hilft, unautorisierte Änderungen zu erkennen und darauf zu reagieren.
Unzureichende Eingabevalidierung und Injections
Ein weiteres, oft unterschätztes Risiko im Serverless Computing sind unzureichend validierte Benutzereingaben. Dabei handelt es sich um eine klassische aus der Websicherheit bekannte Angriffsmöglichkeit. Serverless-Funktionen werden oft durch API-Anfragen oder http-Event-Trigger ausgelöst, was sie anfällig für verschiedene Injection-Angriffe macht.
Angriffsszenario
Eine Lambda-Funktion verarbeitet Benutzereingaben wie jede andere Webanwendung. Oft arbeitet eine Funktion auch mit gängigen Datenbanken zusammen. Ohne ausreichende Validierung kann ein Angreifer speziell manipulierte Anfragen senden, um beispielsweise eine SQL Injection auszunutzen. In einem anderen Szenario könnte eine Serverless-Funktion Systembefehle ausführen und durch unzureichend gefilterte Eingaben für eine Command Injection anfällig sein.
In der Vergangenheit haben Angreifer diese Schwachstellen bereits ausgenutzt, um Serverless-Umgebungen zu kompromittieren. Besonders gefährlich ist dies, wenn Cloud-Funktionen mit weitreichenden Berechtigungen ausgestattet sind.
Schutzmaßnahmen
- Eingabevalidierung: Benutzereingaben sollten immer über Whitelisting und Schema-Validierung geprüft werden.
- Prepared Statements nutzen: Falls die Anwendung mit Datenbanken interagiert, sollten SQL oder NoSQL Injections durch vorbereitete Statements verhindert werden.
- Regelmäßige Sicherheitstests: Manuelle Pentests und automatisierte Security-Scans helfen, potenzielle Schwachstellen frühzeitig zu erkennen und zu schließen.
- Web Application Firewalls (WAF): Die Nutzung von WAF-Diensten wie AWS WAF, Azure WAF oder Google Cloud Armor kann helfen, schädliche Eingaben zu blockieren.
Serverless-Funktionen bieten viele Vorteile, doch sie erfordern auch Sicherheitsmaßnahmen, die auf andere als die klassischen Angriffsszenarien bei On-Prem Servern ausgerichtet sind. Injection-Angriffe bringen zusätzliche Herausforderungen für Serverless-Umgebungen mit sich – insbesondere in Bezug auf Identitäts- und Zugriffskontrollen, Konfigurationssicherheit und Code-Integrität.
Alle der hier vorgestellten Schwachstellen finden wir in einem Großteil unserer Penetrationstest. Im folgenden Video zeigen wir Ihnen in einem kurzen Live-Hacking gerne, wie ein solcher Cloud-Penetrationstest ablaufen kann.
Regelmäßiges Cloud-Pentesting hilft Unternehmen also, Schwachstellen in ihren Serverless-Anwendungen frühzeitig zu erkennen und zu beheben. Dabei sollte der Fokus auf den oben genannten Risikobereichen liegen, um Angriffsvektoren zu minimieren und die Sicherheit von Cloud-Diensten nachhaltig zu gewährleisten. Ergänzend sollten Unternehmen auf Sicherheitsframeworks und Best Practices wie AWS Well-Architected Framework, Google Cloud Security Best Practices oder Microsoft Azure Security Benchmarks setzen, um eine robuste Security-Strategie für Serverless Computing zu etablieren.