A04:2021 - Insecure design - Information disclosure

A04:2021 – Unsicheres Design – Offenlegung von Informationen

4. November 2024 Celia Catalán

Einführung

Die Offenlegung von Informationen stellt eine Sicherheitslücke dar, deren Schwere davon abhängt, wie sensibel die erhaltenen Informationen sind.

Dies geschieht, wenn eine Webanwendung unbefugten Benutzern unbeabsichtigt sensible oder vertrauliche Daten zugänglich macht. Diese Schwachstelle kann sich auf verschiedene Weise manifestieren, einschließlich der Offenlegung technischer Systemdetails, Konfigurationsinformationen, Benutzerdaten oder sogar Quellcodefragmente.

Diese Offenlegung gefährdet nicht nur die Integrität und Vertraulichkeit der Anwendung, sondern kann potenziellen Angreifern auch wertvolle Informationen liefern, um komplexere Angriffe auf das System zu planen und auszuführen.

Auswirkungen

Die Auswirkungen der Offenlegung von Informationen auf die Sicherheit einer Webanwendung können erheblich sein:

Offenlegung sensibler Daten: Kann vertrauliche Informationen wie Passwörter, Benutzerdaten oder Infrastrukturdetails preisgeben.

Ermöglichung komplexerer Angriffe: Angreifer können die erhaltenen Informationen nutzen, um präzisere und effektivere Angriffe zu planen und auszuführen.

Vertrauensverlust: Wenn Benutzer feststellen, dass die Anwendung angreifbar ist, kann dies zu einem Vertrauensverlust und einer Rufschädigung des Unternehmens führen.

Nichteinhaltung von Vorschriften: Abhängig von der Art der offengelegten Informationen kann es zu Verstößen gegen Datenschutz- und Datensicherheitsbestimmungen kommen.

Gefährdung der Systemintegrität: Die offengelegten Informationen können dazu verwendet werden, die Gesamtintegrität und Sicherheit des Systems zu gefährden.

Diese Auswirkungen unterstreichen, wie wichtig es ist, Schwachstellen bei der Offenlegung von Informationen in Webanwendungen zu identifizieren und zu beheben.

Praxisbeispiele

Nachfolgend finden Sie einige praktische Beispiele für Schwachstellen bei der Offenlegung von Informationen in Webanwendungen. Diese Fälle veranschaulichen, wie vertrauliche Informationen unbeabsichtigt offengelegt werden können und Angreifern wertvolle Daten über die Infrastruktur und die internen Abläufe der Anwendung liefern.

Jedes Beispiel enthält eine Beschreibung des Szenarios, der möglichen Auswirkungen und empfohlener Abhilfemaßnahmen. Es ist wichtig, diese Fälle zu verstehen, um die Sicherheit von Webanwendungen zu verbessern und die vertraulichen Informationen des Unternehmens zu schützen.

1. Fehlermeldungen

In diesem speziellen Fall handelt es sich um eine absichtliche Technik, mit der aus strategischen Gründen Fehler auf einer Webseite verursacht werden. Das Hauptziel dieser Vorgehensweise besteht darin, das System dazu zu bringen, wichtige Informationen über die Version der verwendeten Software preiszugeben.

Obwohl diese Taktik scheinbar einfach ist, kann sie einem Angreifer wertvolle Daten über die zugrunde liegende technologische Infrastruktur der Webanwendung liefern. Indem ein Angreifer diese Fehler absichtlich erzwingt, versucht er, Systemreaktionen auszunutzen, um an technische Details zu gelangen, die normalerweise verborgen bleiben würden.

Diese Informationen können nicht nur die genaue Version der Software umfassen, sondern auch andere Details wie den Typ des Webservers, das zugrunde liegende Betriebssystem oder sogar Quellcodefragmente. All diese Elemente können später zur Planung komplexerer und gezielterer Angriffe genutzt werden.

Zusammenfassung

In der Webanwendung wird absichtlich ein Fehler verursacht.

Die generierte Fehlermeldung enthält einige Informationen. Die erhaltenen Informationen können Softwareversionen, Dateipfade oder Serverkonfigurationen umfassen.

Beispiel

Es gibt mehrere Möglichkeiten, einen Fehler auf einer Webseite zu generieren. In diesem Fall erklären wir einen sehr häufigen Fall, der auftritt, wenn einem Parameter, von dem erwartet wird, dass er einen numerischen Wert INTEGER empfängt, ein nicht numerischer Wert gesendet wird.

https://<victim_web>/product?productId=2

In diesem Fall wird der Wert des Parameters „productId“ geändert, um einen nicht numerischen Wert zu senden und somit einen Fehler zu erzwingen:

https://<victim_web>/product?productId="

Im Bild sehen Sie, dass es auf diese Weise möglich ist, einen Fehler zu erzwingen und die Version des verwendeten Webservers zu erhalten.

Schadensbegrenzung

Um diese Art von Sicherheitslücke zu verhindern, wird empfohlen:

Konfigurieren Sie Fehlermeldungen ordnungsgemäß, sodass keine vertraulichen Informationen preisgegeben werden

Implementieren Sie eine benutzerdefinierte Fehlerbehandlung, die technische Details verbirgt

Halten Sie Software und Systeme auf dem neuesten Stand, um bekannte Schwachstellen zu reduzieren

Führen Sie regelmäßige Sicherheitstests durch, um potenzielle Datenlecks zu identifizieren und zu beheben

2. Standardinstallationsdateien/Debugdateien

In diesem Szenario besteht das Ziel darin, Installationsdateien zu identifizieren und zu lokalisieren, die in ihrer Standardkonfiguration belassen wurden. Diese Dateien können wertvolle und potenziell vertrauliche Informationen über bestimmte Versionen der in der Systeminfrastruktur verwendeten Software enthalten.

Das Vorhandensein dieser Dateien kann nicht nur wichtige technische Details preisgeben, sondern auch bekannte Schwachstellen im Zusammenhang mit bestimmten Versionen der Software aufdecken, die von böswilligen Angreifern ausgenutzt werden könnten, um die Systemsicherheit zu gefährden.

Zusammenfassung

Es wird eine Erkennungsphase ausgeführt, in der Dateien und Verzeichnisse zusätzlich zu Crawling-Tools oder der Verzeichnisaufzählung mithilfe von Dateien wie sitemap.xml oder robots.txt durchsucht werden.

Die Debug-Datei oder die während der Installation generierte Datei enthält bestimmte vertrauliche Informationen. Zu den erhaltenen Informationen können Softwareversionen, Dateipfade, Serverkonfigurationen, Schlüssel und Token im Klartext gehören

Beispiel

In diesem Fall war es mithilfe des Dirsearch-Verzeichnisaufzählungstools und des big.txt-Wörterbuchs von SecList möglich, die folgende Datei aufzulisten.

dirsearch -u https://victim_web -w ~/Tools/SecLists/Discovery/Web-Content/big.txt

Die Datei phpinfo.php ist ein Diagnoseskript, das häufig auf PHP-fähigen Webservern verwendet wird. Wenn auf diese Datei zugegriffen wird, werden detaillierte Informationen zur PHP-Serverkonfiguration angezeigt, einschließlich Softwareversionen, aktivierten Erweiterungen und Systemvariablen.

In diesem Fall ist ersichtlich, dass sich unter den in dieser Datei enthaltenen Informationen mehrere vertrauliche Informationen befinden, auf die ohne vorherige Authentifizierung zugegriffen werden kann.

Wie wir sehen, kann es ein erhebliches Sicherheitsrisiko darstellen, diese Datei in einer Produktionsumgebung zugänglich zu lassen, da dadurch vertrauliche Informationen preisgegeben werden, die von böswilligen Angreifern ausgenutzt werden könnten.

Schadensbegrenzung

Um die mit Standardinstallations- oder Debugging-Dateien verbundenen Risiken zu vermeiden, wird Folgendes empfohlen:

Löschen Sie Diagnosedateien in Produktionsumgebungen oder beschränken Sie den Zugriff darauf

Implementieren Sie robuste Zugriffskontrollen für vertrauliche Dateien

Verwenden Sie Web Application Firewalls (WAFs), um den Zugriff auf potenziell gefährliche Dateien zu blockieren

Führen Sie regelmäßige Sicherheitsüberprüfungen durch, um unnötige Dateien zu identifizieren und zu entfernen

Konfigurieren Sie die Datei- und Verzeichnisberechtigungen auf dem Webserver korrekt

Verwenden Sie Tools zum Scannen von Schwachstellen, um exponierte Dateien zu erkennen

Implementieren Sie Sicherheitsrichtlinien, die das Vorhandensein von Debugging-Dateien in der Produktion verhindern

Informieren Sie Entwickler über die Risiken, die sich daraus ergeben, dass Diagnosedateien zugänglich bleiben

3. Versteckte Dateien

In diesem Szenario besteht das Ziel darin, versteckte Dateien zu identifizieren und zu lokalisieren, die möglicherweise vertrauliche oder potenziell gefährliche Informationen für das Unternehmen enthalten. Diese Dateien, die oft versehentlich offengelegt werden, können ein erhebliches Risiko für die Unternehmenssicherheit darstellen, wenn sie von böswilligen Akteuren entdeckt und ausgenutzt werden.

Obwohl die in den vorherigen Beispielen erwähnten Verzeichnis-Crawling- und Enumerationstechniken anwendbar sein könnten, konzentriert sich dieser spezielle Fall auf alternative, subtilere Methoden zum Aufdecken dieser verborgenen Ressourcen. Zu diesen alternativen Strategien können neben anderen ausgefeilteren und weniger aufdringlichen Ansätzen auch die Analyse von Serverantworten, die Überprüfung des Quellcodes und die Nutzung gängiger Benennungsmuster gehören.

Zusammenfassung

Es wird eine Erkennungsphase ausgeführt, in der Dateien und Verzeichnisse zusätzlich zu Crawling-Tools oder der Verzeichnisaufzählung mithilfe von Dateien wie sitemap.xml oder robots.txt durchsucht werden.

Die mit diesen Techniken gefundenen Dateien können interne Dokumentationen, Finanzdaten, Benutzeranmeldeinformationen, Quellcode usw. umfassen.

Beispiel

In diesem Beispiel werden Informationen über die Dateistruktur der Webanwendung durch Zugriff auf die Datei robots.txt abgerufen.

Die robots.txt-Datei ist eine Textdatei, die auf Websites verwendet wird, um Suchmaschinen-Robots mitzuteilen, welche Seiten oder Abschnitte der Website gecrawlt und indiziert werden sollen und welche nicht.

https://victim_web/robots.txt

Nach dem Zugriff auf das Verzeichnis /backup können Sie in diesem Beispiel sehen, dass dort eine Datei mit dem Quellcode der Anwendung vorhanden ist.

In diesem Fall ist ersichtlich, dass die Sicherungsdatei den Quellcode der Anwendung mit sensiblen Informationen wie der Verbindungszeichenfolge zu einer Datenbank enthält, in der sich das Passwort befindet. Zusätzlich zu einer Abfrage an die Datenbank, wo eine SQL-Injection erkannt werden kann.