Ist die Anwendung verwundbar?

Ihr stellt Euch vielleicht auch ab und zu die Frage, ob euer Setup und die Konfiguration rund um eure Webanwendungen geeignet sind, damit nicht alles offen ist wie ein Scheunentor. Um diese Frage zu klären müssen wir uns erst mal vor Augen führen, wo genau Probleme auftreten können. Sicherheitsrelevante Fehlkonfiguration können auf jedem Level des Anwendungs-Stacks auftreten. 

Neben der Webanwendung selbst beschäftigt sich dieses Thema also auch mit den Schwachstellen der darunterliegenden Schichten. Auf jeder Ebene können falsche Konfigurationen Probleme machen und Hintertüren für Angreifer öffnen.Alle beteiligten Komponenten des Stacks müssen also aktuell und sicher gehalten werden.

Ursachen

Im Folgenden werden 8 mögliche Ursachen aufgeführt, die zu Schwachstellen führen können.

  • Debugging eingeschaltet
    • Angreifer lieben solche Extra-Informationen, die ihnen bereitgestellt werden
  • Falsch konfigurierte Ordner-Berechtigungen
    • Directory Listing
  • Verwenden von Standard-Accounts oder Passwörtern 
    • Viele Anwendungen und ApplServer haben Standard-Accounts mit Default-Passwörtern
  • Setup- oder Konfigurations-Seiten aktiv
    • Viele Anwendungen haben Setup Seiten, die zum initialen Einrichten dienen.
    • URLs zu Admin-Seiten sollten nicht zu einfach zu finden sein
  • Sicherheits-funktionen deaktiviert oder nicht sicher konfiguriert
  • Unnötige Features aktiviert oder installiert
  • Keine Sicherheits-Header oder -Direktiven im Http-Response
  • Falsch konfigurierte Berechtigungen für Cloud Services

Beispiele

Aktives Directory Listing

  • Bei Webservern ist oft das Directory Listing aktiv, so dass man wie im Explorer die Ordner und Dateien des Webanwendung durchsuchen kann. 
    • Das ist fatal, denn so können Angreifer die Struktur der Webanwendung ausspähen und wichtige Informationen über die Beschaffenheit bekommen. Für Angreifer ist das wichtig, um Schwachstellen zu finden.  
    • Außerdem können Angreifer den Code der Anwendung runterladen und dekompilieren, oder Konfigurationsdateien einsehen. So werden sehr sensible Daten zugänglich, was man unbedingt vermeiden will. Und wenn dann auch noch Zugangsdaten und Passwörter dadurch offengelegt werden, dann ist die Katastrophe perfekt.
      • Beispiel aus der Praxis
        • CERT-Forscher Will Dormann hat 1,8 Millionen Android-Apps heruntergeladen und nach entsprechenden Artefakten untersucht. 
        • In etwa 1% aller untersuchten Apps wurde er fündig – das sind knapp 20.000 Apps. 
        • Gefunden wurden Passwörter, Krypto-Schlüssel oder VPN-Zugangsdaten
  • Fehlermeldungen in Webanwendungen, die dem Benutzer präsentiert werden, sollten allgemein gehalten sein und keine sensiblen Informationen preisgeben, die Rückschlüsse auf das Innenleben der Anwendung zulassen.
    • Es kommt immer wieder vor, dass komplette Stacktraces in Fehlermeldungen erscheinen, oder als Hilfe bei der Fehlersuche versteckt im HTML-Code. 
    • Auch das sind große Hilfen für Angreifer, da sie dann genau wissen, was sie vor sich haben und so ganz gezielt nach verfügbaren Exploits Ausschau halten können, mit denen sie oft ohne tiefes Fachwissen die Anwendung übernehmen können.
    • Eine Anwendung sollte deshalb aus Sicherheitsgründen keine solche Infos rausgeben, um es den Angreifern so schwer wie möglich zu machen.
  • Bei Webservern wird manchmal vergessen, dass die Adminkonsolen mit Standardkonten angelegt sind, die bekannte Default-Passwörter haben. 
    • Wird das vergessen zu ändern und ein Angreifer merkt das, dann hat er sofort die Kontrolle über den Webserver und kann alles übernehmen, im schlimmsten Fall so, dass es keiner merkt und er jahrelang alles ausspionieren und kompromittieren kann
    • Deshalb: immer alle Default-Passwörter durch sichere ersetzen.

Prävention

Wie kann man für mehr Sicherheit sorgen und solche Schwachstellen vermeiden? Hier einige Maßnahmen, die bereits viel Angriffsfläche absichern.

Directory Listing in Webservern deaktivieren

Eine wichtige Maßnahme ist, das Directory Listing in Webservern zu deaktivieren. Per Konfiguration kann man das folgendermaßen abschalten. 

Webserver Apache: Deaktivieren des Directory Listings

Das sollte man ausnahmslos machen, auch wenn man in seiner Anwendung Downloads anbieten will. Anstatt ganze Ordner freizugeben, sollte man die Dateien einzeln verlinken, auch wenn das mehr Arbeit ist. Aber die Gefahr des Ausbrechens auf unautorisierte Bereiche besteht dann nicht mehr.

Robuste Anwendungs-Architektur 

Mehr Sicherheit kann man vor allem dadurch erreichen, dass man eine Trennung und Absicherung der einzelnen Komponenten voneinander vornimmt. Gemäß der Zwiebeltaktik kann ein Eindringling dann nämlich nicht gleich alles übernehmen, nur weil er ein einziges Hindernis genommen hat.

Nehmen wir Beispielsweise eine Anwendung, die ein Shop-System für Kunden aus dem Internet hat, und außerdem einen Bereich fürs Backoffice, wo Bestellabwicklung und Buchhaltung untergebracht ist. Wenn diese Bereiche voneinander getrennt sind, dann ist bei einem Angriff aufs Shopsystem nicht auch gleich das komplette Backoffice kompromittiert. Wenn der Shop mal ausfällt ist das schlimm genug, wenn aber die Daten der Buchhaltung kaputt sind, dann ist das existenzbedrohend fürs Business.

Durch eine Trennung von wichtigen Bereichen bringt man hier also mehr Sicherheit rein: mindestens getrennte Datenbanken, je nach dem auch eine Trennung der Webanwendung. Sehr effektiv ist auch eine Trennung der Erreichbarkeit. Der Shop muss natürlich übers Internet öffentlich erreichbar sein. Das Backoffice muss das nicht zwangsweise. Man kann diesen Bereich besonders schützen, wenn man ihn vom Internet aus nicht erreichbar macht, sondern nur übers Intranet, ggf. mit VPN-Zugang, um ihn auch von zuhause erreichbar zu machen.

Hier das ganze nochmal zum Anschauen: A6:2017