Cloud
What Exposed OPA Servers Can Tell You About Your Applications
This blog entry discusses what an OPA is and what it’s for, what we’ve discovered after identifying 389 exposed OPA servers via Shodan, and how exposed OPAs can negatively impact your applications’ overall security.
Save to Folio
Anfang dieses Jahres veröffentlichten wir einen Bericht zu den über Shodan gefundenen 243.469 öffentlich zugänglichen Kubernetes-Knoten . Dabei waren auch 389 angreifbare Open Policy Agent (OPA)-Server. OPA ist ein Open-Source-Projekt der Cloud Native Computing Foundation (CNCF), das in der Programmiersprache Go entwickelt wurde und mit bisher über 130 Millionen Downloads als Haupt-Engine für viele Tools zur Durchsetzung von Richtlinien eingesetzt wird. Es verwendet eine spezielle deklarative Policy-Sprache namens Rego für die Gestaltung seiner Richtlinien. OPA kann in verschiedenen Systemen und Umgebungen wie Kubernetes, Microservices, API-Gateways und anderen Cloud-nativen Tools genutzt werden. Wenn OPA-Server ungesichert bleiben, können ihre Richtlinien sensible Anwendungsinformationen offenlegen, einschließlich Benutzerprofilen und verwendeter Dienste. Diese exponierten Richtlinien können auch unwissentlich Informationen darüber preisgeben, wie sich das System verhalten sollte, um Einschränkungen der implementierten Richtlinien zu umgehen. Und das können böswillige Akteure für Angriffe nutzen.
In der heutigen Welt mit Containern, DevOps und DevSecOps ist es für Netzwerk-, Sicherheits- und Compliance-Teams schwierig, mit den Entwicklern und Geschäftsanforderungen Schritt zu halten, wenn keine Automatisierung eingesetzt wird. Deshalb sind Ansätze wie Infrastructure-as-Code (IaC) GitOps und Security-as-Code (SaC) für den Schutz von Cloud-Umgebungen und Microservices unerlässlich. All diese Ansätze arbeiten zusammen, um Cloud-Sicherheit zu erreichen, und zwar bereits zu Beginn von Prozessen und Bereitstellungen, um Bedrohungen und Risiken einzudämmen.
Aber wie sieht es mit der Compliance aus? Wie können Systeme überprüft und kontinuierlich überwacht werden, um zu gewährleisten, dass Best Practices für die Sicherheit eingehalten und die neuesten Sicherheitsstandards erfüllt werden, z. B. Payment Card Industry Data Security Standard (PCI-DSS), Health Insurance Portability and Accountability Act (HIPAA) und System and Organization Controls (SOC 2)? Hier kann Policy-as-Code dabei helfen, die Erstellung, Automatisierung und Überprüfung der Compliance erheblich zu beschleunigen.
Policy-as-Code (oder Compliance-as-Code) stellt eine gute Möglichkeit dar, Änderungen an den Systemrichtlinien zu implementieren, zu verwalten und zu verfolgen und sicherzustellen, dass sie auf die 4 Cs von Cloud-nativen Systemen angewendet und durchgesetzt werden: Code, Container, Cluster und Cloud.
Mit einem ähnlichen Ansatz wie bei IaC und SaC werden bei Policy-as-Code all die Tools und Techniken genutzt, die bereits in der Softwareentwicklung eingesetzt werden, um die Einhaltung von Richtlinien zu gewährleisten. Zum einen werden Richtlinien in Dateiformaten wie JSON oder YAML und mit einer bestimmten Programmiersprache wie Python oder Rego erstellt und gespeichert. Diese werden in einem Git-Repository zur Versionskontrolle, Nachverfolgung und Auditierung gespeichert. So können Unternehmen Pipelines und Automatisierungen für diese Repositories entwickeln und anstoßen, sobald es Änderungen gibt. Policy-as-Code lässt sich programmgesteuert in Code-Reviews, automatisierte Tests und CI/CD-Pipelines (Continuous Integration and Delivery) implementieren und stellt sicher, dass Änderungen ordnungsgemäß validiert und getestet werden, bevor sie die Produktionssysteme erreichen. OPA ist eines der führenden Open-Source-Tools für den Policy-as-Code-Prozess. Einer der führenden Anwender ist jedoch ein Admission Controller für Kubernetes-Cluster, dessen Gatekeeper-Version als Gatekeeper für alle Container fungiert, die versuchen, innerhalb des Clusters zu laufen.
Exponierte Server auf Shodan
Wie bereits erwähnt, fanden wir über Shodan fast vierhundert öffentlich zugängliche OPA-Server, die auf Port 8181 laufen, und diese Zahl ist in den letzten Monaten noch gestiegen. Port 8181 ist der Standard-Port für OPA-Server, und sie waren alle mit dem API-Endpunkt für nicht authentifizierte und unautorisierte Anfragen verfügbar. Unsere Shodan-Suche ergab, dass die USA, die Republik Korea und Deutschland die drei Länder mit der größten Anzahl an offenen OPAs sind.
Wir nutzten „list policies endpoint“, um Informationen zu allen Policy-Modulen zu erhalten, die auf der Instanz installiert sind, so wie es die offizielle OPA-Dokumentation empfiehlt. Einzelheiten zu der Abfrage liefert der Originalartikel. Abgesehen von der Möglichkeit, den Server über diese Seite abzufragen, könnte dies als Einstiegspunkt für Command-Injection-Angriffe dienen, wenn die Benutzereingabedaten nicht korrekt bereinigt und validiert werden. Außerdem besteht das Problem, dass die REST-API offengelegt und nicht authentifiziert ist.
Analyse der exponierten OPA-Richtlinien
Nach der Analyse von 400 Policies von all den exponierten OPA-Servern fanden wir folgendes heraus:
- Mindestens 33 % dieser Richtlinien enthielten irgendwelche sensiblen Informationen über die Anwendung, darunter Benutzerprofile, genutzte Dienste und URLs, die APIs über das Amazon Web Services (AWS) API Gateway und sogar einige interne System-URLs anstoßen würden.
- 91 % Informationen darüber, wie sich das System verhalten sollte, um bestimmte Einschränkungen auf der Grundlage der implementierten Richtlinien zu umgehen.
Mit der richtigen Abfrage oder dem richtigen Token könnte ein Angreifer noch mehr Informationen über diese Dienste erhalten und nach Schwachstellen oder anderen Einstiegspunkten suchen, um in die Systeme eines Unternehmens zu gelangen. Wir empfehlen Unternehmen, die derzeit OPA als Policy-as-Code-Lösung einsetzen, sicherzustellen, dass sie ihre APIs und Richtlinien nicht unwissentlich online stellen. In bestimmten Fällen könnten Unternehmen ohne es zu wissen OPA verwenden; mehrere Anbieter von Kubernetes-verwalteten Diensten verlassen sich bei der Durchsetzung von Richtlinien auf OPA.
Beachten Sie, dass wir lediglich aus ethischen Gründen den Endpunkt „List Policies“ vom REST-API abgefragt haben. Es gibt jedoch viele andere verfügbare Endpunkte und Methoden, die nicht nur sensible Informationen auflisten, sondern es einem Angreifer auch ermöglichen, Daten und Objekte von einem exponierten OPA-Server zu bearbeiten oder sogar zu löschen. Einige davon sind:
Create or update a policy |
PUT /v1/policies/<id> |
Delete a policy |
DELETE /v1/policies/<id> |
Patch a document (Data API) |
PATCH /v1/data/{path:.+} |
Delete a document (Data API): |
DELETE /v1/data/{path:.+} |
Alle diese sind der OPA REST API Documentation verfügbar.
Schutz von OPA-Servern
In erster Linie sollten OPA-Server nicht für das Internet zugänglich sein. Daher muss der Zugang eingeschränkt werden, um zu verhindern, dass jemand über die REST-API in den OPA-Konfigurationen stöbert. Der Standardmodus der OPA-Bereitstellung für die Autorisierung sieht vor, dass OPA auf demselben Rechner läuft wie die Anwendung, die um Entscheidungen ansucht. So brauchen Unternehmen OPA nicht für das Internet oder das interne Netzwerk freizugeben, da die Kommunikation über die localhost-Schnittstelle erfolgt. Darüber hinaus bedeutet dieser Bereitstellungsmodus, dass Unternehmen in der Regel keine Authentifizierung/Autorisierung für die REST-API aktivieren müssen, da nur ein Prozess, der auf demselben Rechner läuft, die OPA-Instanz abfragen kann.
Zweitens ist es bei der Verwendung eines Tools wie OPA wichtig, die Policies an einem Ort wie einem SCM-System (Source Code Management) zu schützen. Darüber hinaus sollten geeignete Zugriffskontrollen verfügbar sein, um zu überwachen, wer was an diesen Richtlinien ändern kann, z. B. durch Funktionen wie Branch-Schutz und Code-Eigentümer. Mit den Möglichkeiten des SCM-Systems können Unternehmen einen strafferen Prozess für die Überprüfung und Genehmigung von Änderungen an diesen Richtlinien einrichten und so sicherstellen, dass alle Änderungen im Quellcode auch auf den OPA-Produktionsservern berücksichtigt werden.
TLS und HTTPS
Die meisten der gefundenen exponierten OPA-Server nutzen keine Art von Verschlüsselung für die Kommunikation, da dies standardmäßig nicht aktiviert ist. Um TLS und HTTPS zu konfigurieren, müssen Systemadministratoren ein Zertifikat und einen privaten Schlüssel erstellen und die folgenden Befehlszeilen-Flags angeben:
- The path of the TLS certificate: --tls-cert-file=<path>
- The path of the TLS private key: --tls-private-key-file=<path>
Weitere Informationen dazu liefert die OPA-Dokumentation zu TLS und HTTPS.
Authentifizierung und Autorisierung
Standardmäßig sind die Authentifizierungs- und Autorisierungsmechanismen von OPA ausgeschaltet. Dies wird in der offiziellen OPA-Dokumentation beschrieben, und es ist wichtig, dass Systemadministratoren und DevOps-Ingenieure diese Mechanismen sofort nach der Installation aktivieren.
Empfehlungen für die Cloud-Sicherheit
Mit einer immer größer werdenden Nutzerbasis müssen Kubernetes-Bereitstellungen vor Bedrohungen und Risiken geschützt werden. Zu diesem Zweck können Entwickler auf Policy-as-Code-Tools zurückgreifen, die bei der automatisierten Implementierung von Kontrollen und der Validierung von Verfahren helfen können.
Abgesehen von der sorgfältigen Anwendung von Grundregeln der Administration für die Sicherheit von Kubernetes-Clustern können Anwender auch auf Cloud-spezifische Sicherheitslösungen zurückgreifen, wie etwa Trend Micro™ Hybrid Cloud Security und Trend Micro Cloud One™.