Coders Conquer Security Infrastructure as Code Serie: Fehlende Zugriffskontrolle auf Funktionsebene

Es ist Zeit für den nächsten Teil unserer Infrastructure-as-Code-Serie – die Blogbeiträge, die Entwickler wie Sie auf ein völlig neues Level des Sicherheitsbewusstseins bei der Bereitstellung sicherer Infrastrukturen in Ihrem Unternehmen heben.

Übrigens... wie sind Sie mit der Herausforderung zur Sicherheitsfehlkonfiguration im letzten Blog zurechtgekommen? Wenn Sie sich direkt an eine Schwachstelle durch fehlende Zugriffskontrolle auf Funktionsebene wagen möchten, besuchen Sie unsere Plattform:

(Der obige Link führt Sie zur Kubernetes-Challenge. Sobald Sie auf der Plattform sind, können Sie über das Dropdown-Menü auch zwischen Ansible, CloudFormation, Terraform oder Docker wählen. Sie haben die Wahl.)

Fast jede heute bereitgestellte Anwendung verfügt über eine Art Zugriffskontrollmechanismus, der prüft, ob ein Benutzer die Berechtigung zur Ausführung der angeforderten Funktionen hat. Dies ist bei der Erstellung einer Anwendung so gut wie der Grundstein für gute Sicherheit und Funktionalität. Tatsächlich benötigen alle Webanwendungen Zugriffskontrollen, damit Benutzer mit unterschiedlichen Berechtigungen das Programm nutzen können.

Probleme können jedoch auftreten, wenn diese Überprüfungsfunktionen für die Zugriffskontrolle nicht auf Infrastrukturebene durchgeführt oder falsch konfiguriert werden. Ohne eine einwandfreie Zugriffskontrolle auf Infrastrukturebene ist das gesamte Unternehmen für Hacker offen, die diese Schwachstelle als Einfallstor für unbefugte Spionage oder einen umfassenden Angriff nutzen können.

Tatsächlich ist die Ausnutzung von fehlenden oder falsch konfigurierten Zugriffskontrollen auf Funktionsebene extrem einfach. Angreifer müssen nicht einmal besonders qualifiziert sein. Sie müssen nur wissen, welche Befehle Funktionen innerhalb des Frameworks ausführen, das die Anwendung unterstützt. Wenn sie das wissen, ist es nur eine Frage von „Trial and Error“. Sie können kontinuierlich Anfragen senden, die eigentlich nicht zulässig sein sollten, und sobald eine erfolgreich ist, könnten die Ziel-Website, die Anwendung, der Server oder sogar das gesamte Netzwerk offengelegt werden.

Wie funktionieren Exploits durch fehlende Zugriffskontrolle auf Funktionsebene?

Es gibt einige Wege, wie Zugriffskontrollen auf Funktionsebene in ein Unternehmen gelangen können. Zum Beispiel kann die Zugriffskontrolle auf Funktionsebene der Anwendung überlassen und nicht von der zugrunde liegenden Infrastruktur überprüft werden. Oder die Zugriffskontrolle auf Infrastrukturebene kann falsch konfiguriert sein. In manchen Fällen gehen Administratoren davon aus, dass nicht autorisierte Benutzer nicht wissen, wie sie auf Infrastrukturressourcen zugreifen können, die nur Benutzern mit höheren Berechtigungen vorbehalten sein sollten – ein Modell der „Sicherheit durch Unklarheit“, das selten funktioniert.

Als Beispiel für Sicherheit durch Unklarheit: Die folgende URL ist wahrscheinlich anfällig für Angriffe:

http://companywebsite.com/app/NormalUserHomepage

Wenn ein authentifizierter Benutzer eine Technik namens „Forced URL Browsing“ anwendet, könnte er versuchen, eine Seite zu erreichen, die nur Administratoren angezeigt wird. Ein Beispiel wäre:

http://companywebsite.com/app/AdminPages

Wenn keine serverseitige Überprüfung existiert, werden ihm einfach die Admin-Seiten angezeigt (falls der Name mit der Anfrage übereinstimmt), und er erhält Zugriff auf alle zusätzlichen Funktionen, die Administratoren auf dieser neuen Seite ausführen können. Wenn der Server dem Angreifer einen „Seite nicht gefunden“-Fehler zurückgibt, kann er es einfach weiter versuchen, bis er den Namen der Admin-Seite herausgefunden hat.

Für Angreifer ist die Ausnutzung von fehlenden Zugriffskontrollen auf Funktionsebene ein ähnlicher Prozess. Anstatt zu versuchen, unbefugte Seiten zu durchsuchen, senden sie stattdessen Funktionsanfragen. Sie könnten zum Beispiel versuchen, einen neuen Benutzer mit Administratorrechten zu erstellen. Ihre Anfrage würde also je nach Framework etwa so aussehen:

POST/action/createuser name=hacker&pw=password&role=admin

Wenn keine Zugriffskontrolle auf Funktionsebene existiert, wäre das obige Beispiel erfolgreich und ein neues Administratorkonto würde erstellt werden. Sobald sich der Angreifer als neuer Administrator wieder anmeldet, hätte er dieselben Zugriffsrechte und Berechtigungen wie jeder andere Administrator in diesem Netzwerk oder auf diesem Server.

Die Lösung für fehlende Zugriffskontrollen auf Funktionsebene

Da Angreifer Schwachstellen durch fehlende Zugriffskontrollen auf Funktionsebene sehr leicht ausnutzen können, ist es entscheidend, diese zu finden, zu beheben und zu verhindern. Glücklicherweise ist dies mit etwas Know-how und grundlegenden Schulungen zur Sicherheit von Infrastructure as Code.

Der wichtigste Schutz besteht in der Implementierung einer rollenbasierten Autorisierung auf Infrastrukturebene. Verlassen Sie sich niemals darauf, dass Anwendungen diese Funktion übernehmen. Selbst wenn sie dies tun, stellt eine Autorisierung auf Infrastrukturebene sicher, dass nichts übersehen wird. Idealerweise sollte die Autorisierung von einem zentralen Ort aus erfolgen (z. B. AWS IAM, Azure IAM usw.), der in die Routine Ihres Unternehmens integriert und auf jede neue Anwendung angewendet wird. Diese Autorisierungsprozesse können vom Framework selbst oder von einer Vielzahl einfach zu bedienender externer Module stammen.

Schließlich sollte Ihr Unternehmen das Prinzip der geringsten Rechte (Least Privilege) verfolgen. Alle Aktionen und Funktionen sollten standardmäßig verweigert werden. Der Autorisierungsprozess dient dann dazu, berechtigten Benutzern die notwendigen Zugriffsrechte zu erteilen. Sie sollten nur so viele Berechtigungen erhalten, wie für die Ausführung der erforderlichen Funktion nötig sind – und nur für die Dauer, die sie diese benötigen.

Fehlende Zugriffskontrollen auf Funktionsebene können verheerende Folgen haben. Glücklicherweise können Sie dieses Problem jedoch leicht vermeiden, indem Sie bewährte Verfahren für die Autorisierung auf Infrastrukturebene in Ihrem Unternehmen etablieren.

Bereit, eine Zugriffskontroll-Schwachstelle in der Praxis zu erkennen? Vergleichen Sie diese Docker-Code-Snippets: eines ist anfällig, das andere sicher.

Anfällig:

FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
   tar -xvf $FILENAME.tar.gz && \
   mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER root
EXPOSE 9104
ENTRYPOINT  [ "sh", "~/entrypoint.sh" ]
CMD  [ "/bin/mysqld_exporter" ]

Sicher:

FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
   tar -xvf $FILENAME.tar.gz && \
   mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER nobody
EXPOSE 9104
ENTRYPOINT  [ "sh", "~/entrypoint.sh" ]
CMD  [ "/bin/mysqld_exporter" ]

Mehr erfahren, sich selbst herausfordern

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 Auswirkungen anderer Sicherheitslücken schützen können.

Und falls Sie es vorhin verpasst haben: Sie können eine spielerische IaC-Sicherheits-Challenge auf der Secure Code Warrior-Plattform ausprobieren, um Ihre Cybersicherheits-Kenntnisse stets auf dem neuesten Stand zu halten.

Bleiben Sie dran für das nächste Kapitel!