
A01:2021 – Defekte Zugangskontrolle
Celia CatalánAktie
Die Zugriffskontrolle auf einer Website definiert, ob ein Benutzer auf eine bestimmte Ressource zugreifen oder eine bestimmte Aktion ausführen darf. Diese Steuerung kann horizontal und vertikal erfolgen:
- Vertikale Zugriffskontrolle: Ein unprivilegierter Benutzer hätte nicht auf die Ressourcen eines Administratorbenutzers zugreifen können.
- Horizontale Zugriffskontrolle: Ein Benutzer kann beispielsweise auf einer Bank-Website auf seine Karten und Konten zugreifen, nicht jedoch auf die anderer Benutzer.
Wie geht diese Zugangskontrolle verloren?
Damit diese Kontrolle ordnungsgemäß funktioniert, müssen Sicherheitsmaßnahmen gut umgesetzt werden, was nicht immer der Fall ist. Schlechte Konfigurationen, anfällige Softwareversionen oder ein schlechtes Sicherheitsdesign können zu einer schlechten Zugriffskontrolle führen und somit die Vertraulichkeit, Integrität und Verfügbarkeit von Informationen verletzen.
So wie wir die Zugriffskontrolle als vertikal oder horizontal klassifizieren, können diese Schwachstellen zu einer vertikalen Rechteausweitung oder horizontalen Verschiebung führen.
Vertikale Rechteausweitung
Eine vertikale Privilegienausweitung tritt auf, wenn ein Angreifer eine Schwachstelle ausnutzt, um seine Zugriffsebene von einem Benutzer mit niedrigen Privilegien (z. B. einem Standardbenutzer) auf eine privilegiertere Rolle, z. B. einen Administrator, zu erhöhen. Mit anderen Worten: Sie erlangen die Kontrolle über Funktionen oder Daten, die nur Benutzern mit höheren Zugriffsebenen vorbehalten sein sollten, wodurch die Sicherheit der Anwendung gefährdet wird. Hier sind einige Beispiele für die Eskalation von Berechtigungen:
- Unbefugter Zugriff auf das Administrationspanel.
- Änderung der Rolle eines Plattformbenutzers.
- Zugriff auf Administratorfunktionen (Benutzer löschen, Benutzerkennwort ändern ...).
Horizontale Bewegung
Eine horizontale Bewegung tritt auf, wenn ein Angreifer mit Zugriff auf ein Benutzerkonto im System Zugriff auf andere Benutzerkonten mit ähnlichen Berechtigungen erhält. Diese horizontale Bewegung findet unabhängig davon statt, ob Sie direkt auf ein Benutzerkonto zugreifen können oder ob Sie auf Funktionen oder Daten des nichtprivilegierten Benutzers zugreifen können.
Im Gegensatz zur vertikalen Bewegung, bei der der Angreifer größere Berechtigungen innerhalb des Systems erhält, konzentriert sich die horizontale Bewegung darauf, andere nicht privilegierte Konten zu kompromittieren, um neue Angriffsvektoren in der Anwendung zu entdecken. Einige Beispiele für diese horizontale Bewegung sind:
- Ermittlung der Anmeldeinformationen eines anderen Systembenutzers.
- Eine Benutzerprofil-Zugriffskontrolle basierend auf einer vorhersehbaren ID.
- Zugriff auf Dateien anderer Systembenutzer.
Von der horizontalen Skalierung zur vertikalen Skalierung
Zwar unterscheiden wir diese beiden Arten von Bewegungen, doch Fälle horizontaler Bewegungen, die zu einer vertikalen Eskalation von Privilegien führen, sind häufig. Dies geschieht, wenn ein Angreifer durch horizontale Bewegungstechniken Zugriff auf einen Systembenutzer mit Administratorrechten erhält. Wenn ein Angreifer beispielsweise die Benutzer-ID in der URL ändert, um auf das Profil eines anderen Benutzers zuzugreifen, führt er eine horizontale Bewegung aus. Wenn Sie diese Technik verwenden, greifen Sie jedoch letztendlich auf einen Administratorbenutzer der Website zu.
Auf diese Weise stellen wir fest, dass es nicht so einfach ist, zwischen einer Eskalation der Privilegien und einer horizontalen Bewegung zu unterscheiden, da es nicht so sehr auf die durchgeführte Technik oder den durchgeführten Angriff ankommt, sondern auf das erzielte Ergebnis, wie bereits erwähnt Es wurde ein Angriff durchgeführt.
Schwachstellen bei der Zugriffskontrolle
Wie wir im vorherigen Abschnitt erklärt haben, beschränken wir uns in diesem Abschnitt auf die Erläuterung der verschiedenen Angriffe, ihrer Durchführung und der möglichen Ergebnisse, da es schwierig ist, Angriffe zwischen Privilegieneskalationsangriffen und horizontalen Bewegungsangriffen zu klassifizieren.
IDOR (Unsichere direkte Objektreferenz)
IDOR ist eine Unterkategorie der Zugriffskontrolle, bei der vom Benutzer veränderbare Parameter für den Zugriff auf Ressourcen verwendet werden. Ein Beispiel wäre eine Schaltfläche im Benutzerprofil zum Herunterladen des Chatverlaufs.
Diese Schaltfläche stellt eine Anfrage an eine example.txt-Datei, aber dieser Parameter kann über einen Proxy geändert werden, sodass Sie auf den Chatverlauf anderer Benutzer zugreifen können.
Wenn wir in diesem Beispiel versuchen, den Chatverlauf unseres Benutzers herunterzuladen, indem wir die Anfrage mit einem Proxy abfangen, sehen wir, dass dieser eine Abfrage an eine 2.txt-Datei durchführt. Nach dieser GET-Anfrage erhalten wir folgende Antwort:
Dieser Parameter ist jedoch änderbar. Wenn wir also diese 2.txt durch 1.txt ersetzen, erhalten wir den Chatverlauf eines anderen Benutzers, in dem wir sein Passwort finden können:
Ungeschützte Funktionalität
Dabei handelt es sich um einen sehr einfachen Angriff, der eine fast vollständige fehlende Zugriffskontrolle seitens des Servers erfordert. Es ist möglich, Webseiten zu finden, auf denen die Ressourcen eines Administrators verborgen, aber nicht geschützt sind. In diesem Fall können wir diese Ressourcen auf unterschiedliche Weise finden:
-
Eine Methode besteht darin, auf die robots.txt-Datei zuzugreifen. Diese Datei ist normalerweise im Stammverzeichnis der Webseite verfügbar und enthält Informationen darüber, welche Ressourcen und Verzeichnisse die Google- und Microsoft-Bots besuchen dürfen. Oftmals finden wir versteckte Verzeichnisse oder Verwaltungsverzeichnisse mit der Bezeichnung „Disallow“ und verraten so den Speicherort von Administrationspanels oder sensiblen Dateien:
- Eine weitere Quelle zum Auffinden dieser Art versteckter Verzeichnisse ist der JavaScript-Code selbst. In Funktionen dieser Programmiersprache findet man häufig Verweise auf vertrauliche Dateien und Verzeichnisse, wie wir im folgenden Bild sehen:
Trotz der Relevanz der Informationen, die wir in diesen Quellen finden können, ist das Fehlen einer Zugriffskontrolle unerlässlich, wenn wir als unprivilegierter Benutzer auf diese Verzeichnisse und Ressourcen zugreifen möchten.
Parameterbasierte Zugriffskontrolle
In anderen Fällen basieren die Berechtigungen eines Benutzers auf gespeicherten Werten, die der Benutzer ändern kann, z. B. einem ausgeblendeten Feld, einem Cookie oder einem vordefinierten Wert, wenn er Abfragen durchführt.
In diesem Beispiel liegen die Berechtigungen des Benutzers in den Händen des Benutzers selbst, da ein im Browser gespeichertes Cookie mit dem Wert „false“ verwendet wird. Durch einfaches Ändern des Wertes dieses Cookies können wir auf vertrauliche Ressourcen zugreifen, ohne dass ein Administratorbenutzer erforderlich ist:
Einen weiteren Fall sehen wir im folgenden Beispiel. Wenn wir bei unserem Benutzer eine E-Mail-Änderung vornehmen und die gestellte Anfrage und die erhaltene Antwort mit einem Proxy abfangen, stellen wir fest, dass wir in der POST-Anfrage unsere neue E-Mail im JSON-Format senden und außerdem die folgenden Informationen erhalten: JSON-Format:
Wie im Bild oben gezeigt, erhalten wir beim Ändern der E-Mail im Antwort-JSON einen Roleid-Parameter mit dem Wert 1. Wenn wir bei der Anfrage nicht nur die E-Mail senden, sondern auch einen Roleid-Parameter mit dem Wert 2 senden, Wir sehen, dass der Server diesen Wert an uns zurückgibt, was darauf hinweist, dass sich die Berechtigungen unseres Benutzers geändert haben:
Auf diese Weise gelang es uns, durch das Senden eines Parameters an den Server, den dieser nicht erwartet hatte, die Privilegien unseres Benutzers zu ändern und ihn in einen privilegierten Benutzer zu verwandeln.
Schlechte Konfiguration
Bei schlechter Konfiguration ist es möglich, Websites zu finden, die Anfragen basierend auf der URL einschränken, sodass ein Benutzer beispielsweise keinen POST an die URL senden darf /admin/löschen. Wenn wir jedoch auf derselben Website URL-Rewriting-Header wie X-Original-URL oder X-Rewrite-URL verwenden können, können wir diese Sicherheitskontrollen umgehen.
Wie wir in diesem Fall sehen, ist der Zugriff auf die URL für uns eingeschränkt /admin/delete?Benutzername=carlos, wodurch wir den Benutzer carlos löschen könnten. Aber indem wir die Stamm-URL der Seite eingeben und den X-Original-URL-Header verwenden, um diese URL umzuschreiben, sehen wir, dass wir diese Zugriffskontrolle für diese URL umgehen können:
In anderen Fällen, wenn die Seite hinsichtlich der von ihr verarbeiteten Methoden flexibel ist und durch Methode und URL eingeschränkt ist, können wir die Methode in ändern und so die Zugriffskontrolle umgehen. Wenn wir in diesem Beispiel versuchen, die Berechtigungen des Benutzers Carlos durch einen unprivilegierten Benutzer zu ändern, sehen wir, dass wir nicht berechtigt sind, diese Änderung vorzunehmen:
Aufgrund der Flexibilität der Webseite können wir jedoch dieselbe Anfrage im GET-Format stellen. Der Server verarbeitet sie korrekt, wendet jedoch keine Zugriffskontrolle an, sodass wir die Sicherheitskontrolle umgehen können:
Diskrepanzen bei der URL-Übereinstimmung
Es gibt auch Seiten, die den Zugriff auf bestimmte URLs mithilfe von Zeichenfolgen einschränken, dann aber intern „ähnliche“ Ergebnisse derselben URL zuordnen.
Wenn Sie beispielsweise eine URL in Großbuchstaben eingeben, z. B /ADMIN/DELETEUSER leitet intern weiter zu /admin/Benutzer löschen, aber da es sich nicht genau um dieselbe Zeichenfolge handelt, findet keine Zugriffskontrolle statt. Wenn Sie in Spring beispielsweise eine URL eingeben, um auf eine Datei (mit einer Erweiterung) zuzugreifen, wird die Datei, wenn sie nicht gefunden wird, in dieselbe Ressource aufgelöst, jedoch ohne Erweiterung, was zu einer Umgehung der Steuerung führen kann. Zugang:
/admin/deleteUser.anything → /admin/deleteUser
Es ist zu beachten, dass diese Umleitung in Spring-Versionen vor Version 5.3 standardmäßig aktiviert ist.
Mehrstufiger Prozess ohne Zugangskontrolle
Wenn es mehr als eine Anfrage oder mehr als einen Schritt zum Ausführen einer bestimmten Aktion gibt, wie zum Beispiel das Löschen eines Benutzers, ist es möglich, dass eine der Anfragen ordnungsgemäß gesichert ist, während der zweite oder dritte Schritt angreifbar ist.
In diesem Beispiel sehen wir deutlich diesen mehrfachen Prozess zur Erhöhung der Berechtigungen eines Benutzers. Wenn wir die erste Anfrage zur Änderung von Berechtigungen an einen nicht privilegierten Benutzer stellen, erhalten wir die folgende Antwort vom Server, die angibt, dass wir keine Berechtigung zum Ausführen dieser Aktion haben:
Wenn wir jedoch den Privilegienausweitungsprozess mit einem privilegierten Benutzer fortsetzen würden, würden wir eine Bestätigungsseite sehen, auf der wir gefragt werden, ob wir diese Aktion wirklich durchführen möchten.
Wenn wir diese Anfrage abfangen und versuchen, dieselbe Anfrage mit dem Cookie des unprivilegierten Benutzers zu stellen, sehen wir, dass es uns erlaubt, diese Aktion unter Umgehung der Sicherheitskontrolle durchzuführen:
Es ist wichtig zu bedenken, dass wir oft Vorkenntnisse über die Funktionalitäten eines Administratorbenutzers benötigen, um diese Art von Angriffen durchführen zu können. In diesem Fall sollten wir als normaler Benutzer niemals auf diese Bestätigungsseite zugreifen können, da diese den Vorgang von Anfang an blockieren würde.
Diese Schwachstellen sind viel einfacher zu erkennen, wenn Sie zuvor einen Administratorbenutzer haben, der deren Funktionen analysiert. Aus diesem Grund ist es bei Web-Audits oft unerlässlich, sowohl einen unprivilegierten als auch einen privilegierten Benutzer zu haben.
Zugriffskontrolle basierend auf dem Referer-Header
Manchmal, um den Zugriff auf Unterseiten einzuschränken, z /admin/Benutzer löschen, Der Referer-Header wird daraufhin überprüft, ob er die Haupt-URL /admin enthält. Auf diese Weise versucht der Server zu überprüfen, ob der Benutzer aus einem Verzeichnis stammt, das ausschließlich einem Benutzer mit erhöhten Rechten vorbehalten ist. Da es jedoch vom Benutzer geändert werden kann, kann es zu einer Verletzung dieser Zugriffskontrolle kommen.
Im folgenden Fall sehen wir genau das. Indem im Referrer angegeben wird, dass die Anfrage zuvor von der URL /admin stammt (auch wenn dies nicht der Fall ist), ermöglicht das System eine Änderung der Benutzerberechtigungen mithilfe eines Cookies für nicht privilegierte Benutzer, da der Webserver dies nur überprüft Referrer-Header:
Einfache Beispiele für horizontale Bewegung
Abschließend stellen wir einige einfache horizontale Bewegungstechniken vor. Ein sehr wiederkehrender Fall ist normalerweise der Zugriff auf das Benutzerprofil über eine Kennung in der URL selbst. Durch einfaches Ändern dieser Kennung können wir auf die Profile anderer Benutzer zugreifen:
Um dies zu vermeiden, werden diese Identifikatoren üblicherweise randomisiert, sodass sie nicht erraten werden können. Von Zeit zu Zeit ist es jedoch möglich, irgendwo auf der Website Hinweise auf diese Kennung zu finden.
In diesem Beispiel können wir beim Navigieren zu einem von Carlos veröffentlichten Blog sehen, dass seine Benutzerkennung in der Blog-URL selbst zu finden ist:
Ein weiterer recht häufiger Fall ist das Auffinden von Informationen in Weiterleitungen. Wenn wir nicht auf eine Ressource zugreifen können, beispielsweise auf das Administrator-Panel, gibt der Server einen 302-Code zurück, um uns beispielsweise zurück zum Stammverzeichnis der Seite umzuleiten. Es kann jedoch vorkommen, dass wir, wenn wir die Antwort des Servers abfangen, im Hauptteil der Weiterleitungsantwort selbst den gesamten HTML-Code der Ressource finden, auf die wir zugreifen wollten:
Sanierung
Alle diese Angriffe sind aufgrund einer schlechten Zugriffskontrolle seitens der Website möglich. Aus diesem Grund wird empfohlen, bei der Implementierung einer korrekten Zugangskontrolle die folgenden Grundsätze zu beachten:
- Verlassen Sie sich bei der Zugriffskontrolle nicht ausschließlich auf Verschleierung.
- Sofern eine Ressource nicht öffentlich zugänglich sein soll, verweigern Sie standardmäßig den Zugriff auf diese Ressource.
- Verwenden Sie nach Möglichkeit einen einzigen Zugriffskontrollmechanismus für die gesamte Anwendung.
- Erklären Sie auf Codeebene den zulässigen Zugriff auf jede Ressource und verweigern Sie den Zugriff standardmäßig.
- Überprüfen und testen Sie die Zugriffskontrollen gründlich, um sicherzustellen, dass sie wie vorgesehen funktionieren.
Hauptsitz San Martín , Grupo Zerolynx des Pentesters