Coders Conquer Security Infrastruktur als Code-Serie: Fehlende Zugriffskontrolle auf Funktionsebene
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!
Ohne eine perfekt funktionierende Zugriffskontrolle auf Infrastrukturebene öffnet sich ein ganzes Unternehmen für Angreifer, die diese Schwachstelle als Einfallstor entweder für unbefugtes Schnüffeln oder einen vollständigen Angriff nutzen können.
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchen
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.
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!
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!
Klicken Sie auf den unten stehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenDemo buchen
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.
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!
Inhaltsübersicht
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen für den Einstieg
Sicher durch Design: Definition von Best Practices, Befähigung von Entwicklern und Benchmarking von präventiven Sicherheitsergebnissen
In diesem Forschungspapier werden die Mitbegründer von Secure Code Warrior , Pieter Danhieux und Dr. Matias Madou, Ph.D., zusammen mit den Experten Chris Inglis, ehemaliger US National Cyber Director (jetzt strategischer Berater der Paladin Capital Group), und Devin Lynch, Senior Director, Paladin Global Institute, die wichtigsten Erkenntnisse aus mehr als zwanzig ausführlichen Interviews mit Sicherheitsverantwortlichen in Unternehmen, darunter CISOs, ein VP of Application Security und Software-Sicherheitsexperten, offenlegen.
Benchmarking von Sicherheitskompetenzen: Optimierung von Secure-by-Design im Unternehmen
Aussagekräftige Daten über den Erfolg von Secure-by-Design-Initiativen zu finden, ist bekanntermaßen schwierig. CISOs stehen oft vor der Herausforderung, den Return on Investment (ROI) und den Geschäftswert von Sicherheitsprogrammen sowohl auf Mitarbeiter- als auch auf Unternehmensebene nachzuweisen. Ganz zu schweigen davon, dass es für Unternehmen besonders schwierig ist, Erkenntnisse darüber zu gewinnen, wie ihre Organisation im Vergleich zu aktuellen Branchenstandards abschneidet. Die Nationale Cybersicherheitsstrategie des Präsidenten forderte die Beteiligten auf, "Sicherheit und Widerstandsfähigkeit durch Design" zu erreichen. Der Schlüssel zum Erfolg von Secure-by-Design-Initiativen liegt nicht nur darin, Entwicklern die nötigen Fähigkeiten zu vermitteln, um sicheren Code zu gewährleisten, sondern auch darin, den Aufsichtsbehörden zu versichern, dass diese Fähigkeiten vorhanden sind. In dieser Präsentation stellen wir eine Vielzahl von qualitativen und quantitativen Daten vor, die aus verschiedenen Primärquellen stammen, darunter interne Daten von über 250.000 Entwicklern, datengestützte Kundeneinblicke und öffentliche Studien. Auf der Grundlage dieser gesammelten Daten wollen wir eine Vision des aktuellen Stands von Secure-by-Design-Initiativen in verschiedenen Branchen vermitteln. Der Bericht zeigt auf, warum dieser Bereich derzeit nicht ausreichend genutzt wird, welche erheblichen Auswirkungen ein erfolgreiches Schulungsprogramm auf die Minderung von Cybersecurity-Risiken haben kann und welches Potenzial zur Beseitigung von Schwachstellen in einer Codebasis besteht.
Ressourcen für den Einstieg
Schließen Sie den Kreis zu Schwachstellen mit Secure Code Warrior + HackerOne
Secure Code Warrior freut sich, unsere neue Integration mit HackerOne, einem führenden Anbieter von offensiven Sicherheitslösungen, bekannt zu geben. Gemeinsam bauen wir ein leistungsstarkes, integriertes Ökosystem auf. HackerOne zeigt auf, wo Schwachstellen in realen Umgebungen tatsächlich auftreten, und deckt das "Was" und "Wo" von Sicherheitsproblemen auf.
Aufgedeckt: Wie die Cyber-Industrie "Secure by Design" definiert
In unserem neuesten Whitepaper haben sich unsere Mitbegründer Pieter Danhieux und Dr. Matias Madou, Ph.D., mit über zwanzig Sicherheitsverantwortlichen in Unternehmen, darunter CISOs, AppSec-Leiter und Sicherheitsexperten, zusammengesetzt, um die wichtigsten Teile dieses Puzzles herauszufinden und die Realität hinter der Secure by Design-Bewegung aufzudecken. Die Sicherheitsteams haben ein gemeinsames Ziel, aber kein gemeinsames Regelwerk.
Wird Vibe Coding Ihre Codebasis in eine Verbindungsparty verwandeln?
Vibe Coding ist wie eine College-Verbindungsparty, und AI ist das Herzstück aller Festivitäten, das Fass. Es macht eine Menge Spaß, sich auszutoben, kreativ zu werden und zu sehen, wohin die eigene Fantasie einen führen kann, aber nach ein paar Bierfässern ist das Trinken (oder die Verwendung von KI) in Maßen zweifellos die sicherere langfristige Lösung.
Entwicklergesteuerte Kodierung.
Sicher ist sicher.
Setzen Sie sich noch heute mit uns in Verbindung und machen Sie Softwaresicherheit zu einem festen Bestandteil Ihres Entwicklungsprozesses.
