Es ist Zeit für den nächsten Teil unserer "Infrastructure as Code"-Reihe, die Blogs, die Entwickler wie Sie auf eine ganz neue Ebene des Sicherheitsbewusstseins bringen, wenn Sie eine sichere Infrastruktur in Ihrer eigenen Organisation bereitstellen.

Ach, übrigens... wie ist es Ihnen mit der Herausforderung der Sicherheitsfehlkonfiguration im vorherigen Blog ergangen? Wenn Sie jetzt eine Schwachstelle in der Zugriffskontrolle auf Funktionsebene beheben möchten, gehen Sie auf die Plattform:

(Der Link oben führt Sie zur Kubernetes-Herausforderung, aber sobald Sie auf der Plattform sind, können Sie im Dropdown-Menü auch Ansible, CloudFormation, Terraform oder Docker auswählen. Sie haben die Wahl.)

Fast jede Anwendung, die heute eingesetzt wird, verfügt über eine Art Zugriffskontrollmechanismus, der prüft, ob ein Benutzer die Berechtigung hat, die angeforderten Funktionen auszuführen oder nicht. Das ist so ziemlich der Grundstein für gute Sicherheit und Funktionalität bei der Erstellung einer Anwendung. Tatsächlich benötigen alle Webanwendungen Zugriffskontrollen, um Benutzern mit unterschiedlichen Berechtigungen die Nutzung des Programms zu ermöglichen.

Probleme können jedoch auftreten, wenn dieselben Überprüfungsfunktionen für die Zugriffskontrolle nicht auf der Infrastrukturebene durchgeführt werden oder falsch konfiguriert sind. Ohne eine perfekt funktionierende Zugriffskontrolle auf Infrastrukturebene öffnet sich ein ganzes Unternehmen für Hacker, die diese Schwachstelle als Einfallstor für unerlaubtes Schnüffeln oder einen vollständigen Angriff nutzen können.

Tatsächlich ist das Ausnutzen von Schwachstellen in der Zugriffskontrolle durch fehlende oder falsch konfigurierte Funktionen extrem einfach. Angreifer müssen nicht einmal übermäßig geschickt sein. Sie müssen nur wissen, welche Befehle Funktionen innerhalb des Frameworks, das die Anwendung unterstützt, ausführen. Wenn sie das wissen, ist es nur eine Frage von Versuch und Irrtum. Sie können ständig Anfragen stellen, die nicht erlaubt sein sollten, und sobald eine erfolgreich ist, könnte die anvisierte Website, Anwendung, der Server oder sogar das gesamte Netzwerk gefährdet sein.

Wie funktionieren Exploits für fehlende Funktionslevel-Zugriffskontrolle?

Es gibt einige Möglichkeiten, wie sich Zugriffskontrollen auf Funktionsebene in einer Organisation einschleichen können. Zum Beispiel kann der Zugriff auf Funktionsebene einer Anwendung überlassen werden 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 für Benutzer höherer Ebenen zugänglich sein sollten, und verwenden ein "Security by Obscurity"-Modell, das nur selten funktioniert.

Als Beispiel für "Security by Obscurity" ist die folgende URL 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 könnte sein:

http://companywebsite.com/app/AdminPages

Wenn es keine serverseitige Überprüfung gibt, wird ihnen einfach die Admin-Seite angezeigt (wenn ihr Name mit der Anfrage übereinstimmt) und sie haben dann Zugriff auf alle zusätzlichen Funktionen, die Administratoren von der neuen Seite aus ausführen. Wenn der Server dem Angreifer einen "Seite nicht gefunden"-Fehler zurückgibt, kann er es einfach weiter versuchen, bis er herausfindet, welchen Namen die Admin-Seite hat.

Für Angreifer ist das Ausnutzen fehlender Zugriffskontrollen auf Funktionsebene ein ähnlicher Prozess. Anstatt zu versuchen, nicht autorisierte Seiten zu durchsuchen, senden sie stattdessen Funktionsanforderungen. 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 Zugriffssteuerung auf Funktionsebene vorhanden ist, wäre das obige Beispiel erfolgreich und ein neues Administratorkonto würde erstellt werden. Sobald sich der Angreifer wieder als neuer Administrator anmeldet, hätte er denselben Zugriff und dieselben Berechtigungen wie jeder andere Administrator in diesem Netzwerk oder auf diesem Server.

Die Lösung für fehlende Zugriffskontrollen auf Funktionsebene

Da es für Angreifer so einfach ist, Schwachstellen in der Zugriffskontrolle auf Funktionsebene auszunutzen, ist es von entscheidender Bedeutung, dass sie gefunden, behoben und verhindert werden. Zum Glück ist dies mit etwas Know-how und einer grundlegenden Sicherheitsschulung für Infrastructure as Code nicht allzu schwierig.

Der wichtigste Schutz besteht in der Implementierung einer rollenbasierten Autorisierung auf der Infrastrukturebene. Vertrauen Sie niemals darauf, dass Anwendungen diese Funktion übernehmen. Selbst wenn sie das tun, stellt eine infrastrukturseitige Autorisierung sicher, dass nichts übersehen wird. Idealerweise sollte die Autorisierung von einer zentralen Stelle kommen (z. B. AWS IAM, Azure IAM usw.), die in die Routine Ihrer Organisation integriert ist und auf jede neue Anwendung angewendet wird. Diese Autorisierungsprozesse können aus dem Framework selbst oder einer beliebigen Anzahl von einfach zu verwendenden externen Modulen stammen.

Schließlich sollte Ihre Organisation das Konzept der geringsten Berechtigung übernehmen. Alle Aktionen und Funktionen sollten standardmäßig verweigert werden, wobei der Autorisierungsprozess verwendet wird, um gültigen Benutzern die Erlaubnis zu geben, das zu tun, was sie brauchen. Sie sollten nur so viel Berechtigung erhalten, dass sie die erforderliche Funktion ausführen können, und auch nur so lange wie nötig.

Fehlende Zugriffskontrollen auf Funktionsebene können verheerend sein. Aber zum Glück können Sie dieses Problem leicht verhindern, indem Sie gute Autorisierungspraktiken auf Infrastrukturebene in Ihre Organisation einbauen.

Denken Sie, Sie sind bereit, einen Fehler in der Zugriffskontrolle in freier Wildbahn zu erkennen? Vergleichen Sie diese Docker-Code-Schnipsel; einer verwundbar, einer sicher:

Verwundbar:

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 lernen, sich selbst herausfordern

Schauen Sie sich die Secure Code Warrior Blog-Seiten, um weitere Informationen über diese Sicherheitslücke zu erhalten und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken und Schwachstellen schützen können.

Und falls Sie es verpasst haben, können Sie auf der Plattform Secure Code Warrior eine gamifizierte IaC-Sicherheits-Challenge ausprobieren, um Ihre Cybersecurity-Fähigkeiten zu verfeinern und auf dem neuesten Stand zu halten.

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