Coders Conquer Security Infrastruktur als Code-Serie: Fehlende Zugriffskontrolle auf Funktionsebene

Veröffentlicht Nov 07, 2022
von Matias Madou
tl;dr?

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.

Ressource anzeigen

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!

Sie wollen mehr?

Tauchen Sie ein in unsere neuesten Erkenntnisse über sichere Kodierung im Blog.

Unsere umfangreiche Ressourcenbibliothek zielt darauf ab, die menschliche Herangehensweise an eine sichere Weiterbildung im Bereich der Programmierung zu stärken.

Blog ansehen
Sie wollen mehr?

Holen Sie sich die neuesten Forschungsergebnisse zur entwicklergesteuerten Sicherheit

Unsere umfangreiche Ressourcenbibliothek ist voll von hilfreichen Ressourcen, von Whitepapers bis hin zu Webinaren, die Ihnen den Einstieg in die entwicklungsorientierte sichere Programmierung erleichtern. Erforschen Sie sie jetzt.

Ressourcendrehscheibe

Secure Code Warrior Ernennung zum Gartner® Cool Vendors™ des Jahres 2022

Veröffentlicht Nov 07, 2022
Von Matias Madou

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!

Geben Sie Ihre Daten ein, um den vollständigen Bericht aufzurufen.

Wir bitten Sie um Ihre Erlaubnis, Ihnen Informationen über unsere Produkte und/oder verwandte Themen der sicheren Codierung zuzusenden. Wir werden Ihre persönlichen Daten immer mit äußerster Sorgfalt behandeln und sie niemals zu Marketingzwecken an andere Unternehmen verkaufen.

Huch, Gänseblümchen