Sicherheit in Web-Anwendungen ist eines der Top-Themen im Security-Umfeld. Ist doch die Web-Anwendung an vorderster Front die Schnittstelle ins Internet. Die OWASP Top-10, die 10 gefährlichsten Schwachstellen in Webapplikationen, beinhalten eine Schwachstelle, die genau genommen gar keine ist. Durch das „Unzureichende Logging und Monitoring“ werden Kompromittierungen teilweise gar nicht oder viel zu spät erkannt. Es dauert im Durchschnitt bis zu sieben Monate bis ein Hacker-Angriff erkannt wird. Abhilfe verschaffen können in Applikation eingebaute Sensoren, die Angreifer schon beim ersten Versuch identifizieren und selbst Schutzmaßnahmen einleiten. Warum unzureichendes Logging und Monitoring in den Top 10 dennoch ihre Daseinsberechtigung hat und wie das OWASP AppSensor Projekt für mehr Sicherheit sorgt, darum soll es in diesem Beitrag gehen.

OWASP A10: Unzureichendes Logging und Monitoring

Bei professionellen Umgebungen ist die Protokollierung zur Nachvollziehbarkeit von Ereignissen wichtig. Das Risiko besteht darin, dass fehlgeschlagene Logins, wichtige Transaktionen oder Fehler unzureichend in Logs protokolliert werden. Die OWASP Community hat daher „A10: Insufficient Logging & Monitoring“ in die OWASP Top 10 mit aufgenommen -noch vor Risiken wie Cross-Site-Request-Forgerys (CSRF) oder Open-Redirects. Letztere sind in der neusten Rangliste von 2017 rausgefallen. Viele kritisierten diese Entscheidung, da es sich beim „Logging und Monitoring“ nicht um eine klare Schwachstelle, wie bei den anderen Risiken handelt [1]. Vielmehr ist es ein Best Practice-Leitfaden zum Schutz der Anwendung. OWASP begründet dies damit, dass Logging und Monitoring die Grundpfeiler eines modernen und sicheren Systems sind. Für andere wiederum ist es die eigentliche Überraschung – betrachtet man die lange Zeit, die es dauert, bis ein Angriff erkannt wird – dass Logging und Monitoring noch nicht auf der Liste gestanden hat.

Im Hinblick auf dieses Risiko ordnet OWASP die Chance für Angriffe auf der Grundlage dieser Schwachstelle in “mittel”, Prävalenz “hoch” und Erkennbarkeit “niedrig” ein. Die Auswirkungen werden als etwas schwer zu definieren aufgelistet, vor allem wegen der Art und Weise, wie Angriffe initiiert werden.[2]

Warum wurde Logging und Monitoring der OWASP Top 10 Liste hinzugefügt?

Statistiken zeigen, dass die Identifizierung von Angriffen sich oftmals schwierig gestaltet. Die zeitliche Verzögerung bis zur Identifizierung von Advanced Persistent Threats (dt. „fortgeschrittene, andauernde Bedrohungen“) liegt im Finanzsektor bei 98 Tagen und im Onlinehandel bei 197 Tagen. Das sind fast sieben Monate. 58 Prozent der befragten Finanzdienstleister und 71 Prozent der Onlinehändler schätzen die Wahrscheinlichkeit, im kommenden Jahr zu einer nennenswerten Verbesserung dieser Situation beitragen zu können, eher gering ein.

Angesichts von mehr als 50 Netzwerkangriffen pro Monat bei 83 Prozent der Finanzdienstleister und 44 Prozent der Onlinehändler ist diese Situation alarmierend. Dr. Larry Ponemon, Gründer des Ponemon Insitutes, erläutert:

„Das wichtigste Fazit unserer Studie ist, dass Unternehmen ihre Investitionen in die Sicherheit sowohl auf der Personalseite als auch bei den Tools und Technologien aufstocken müssen, um sicherheitsrelevante Vorfälle effizient und präzise erkennen und adäquat reagieren zu können. […] Es dauert viel zu lange, bis komplexe Bedrohungen erkannt werden. Hat sich ein Angreifer Zugang zu einem Netzwerk verschafft, hat er jede Menge Zeit, um oftmals irreparable Schäden anzurichten.“ [3]

Die Kosten bei einem Angriff können bei schneller Identifikation der Bedrohungen gesenkt bleiben. Eine aktuelle Kaspersky-Studie kommt zu dem Schluss, dass Präventionsmaßnahmen vor Cyber-Angriffen die beste Lösung für Unternehmen seien, um teuren Sicherheitsvorfällen vorzubeugen. Sollte es trotz Vorkehrungen zu einem Angriff kommen, ist eine schnelle Reaktion gefragt. Eine sofortige Identifikation des Vorfalls kostet Großunternehmen 456.000 US-Dollar. Wenn dieser erst nach einer Woche erkannt wird, verdoppeln sich die Kosten sogar auf 1,2 Millionen US-Dollar.[4]

Damit die Logs nicht einfach unbeachtet auf dem Log-Server überquellen, ist ein Monitoring erforderlich. Das Logging alleine reicht daher nicht aus, viel mehr müssen die Logs aufgearbeitet und regelmäßig überprüft werden. Damit können ungewöhnliche Ereignisse und Anomalien rechtzeitig erkannt werden. Neuste Versuche zeigen, wie sogar Angriffe mit Hilfe von Machine Learning prognostiziert werden.

Wann ist eine Anwendung anfällig?

Nach der OWASP Richtlinie tritt ein unzureichendes Logging, eine unzureichende Detection, und ein unzureichendes Monitoring in folgenden Fällen auf [5]

Überprüfbare Ereignisse wie Logins, fehlgeschlagene Logins und hochwertige Transaktionen werden nicht protokolliert.
Warnungen und Fehler führen zu keinen, unzureichenden oder unklaren Protokollmeldungen. Dazu gehört auch eine obskure Fehlerprotokollierung ohne ausreichende Details, welche die Forensik nachvollziehen kann.
Logs von Anwendungen und der APIs werden nicht auf verdächtige Aktivitäten überwacht.
Logs werden nur lokal gespeichert. Logs, die nicht gesichert werden laufen Gefahr, durch Eindringlinge, die auf ein System zugreifen, gelöscht zu werden. Auf diese Weise verschleiern die Eindringlinge ihre Spuren, so dass die Quelle des Einbruchs nicht nachvollziehbar ist.
Angemessene Alarmschwellen und Reaktionseskalationsprozesse sind nicht vorhanden oder unwirksam.
Penetrationstests und Scans durch DAST-Tools (z.B. OWASP ZAP) lösen keine Warnungen aus.
Die Anwendung kann aktive Angriffe nicht in Echtzeit erkennen, eskalieren oder davor warnen.

Neben diesen Fehlern gibt es auch organisatorische Gründe warum das Logging und Monitoring scheitert:

Fehlen eines formalen Eskalationsplans nach einem Verstoß
Fehlende automatisierte Auditierung und Überwachung von Sicherheitsrahmen und/oder Mangel an qualifiziertem Sicherheitspersonal zur Analyse von Protokolldaten
Schlechte Authentifizierungsverwaltung
Unzureichendes Training für das Logging und Monitoring

Wie kann eine Anwendung geschützt werden?

Ein Angreifer verbringt viel Zeit damit, eine Anwendung oder ein System zu untersuchen, um die Schwachstellen zu finden. Verfügt ein System über kein ausreichendes Logging und Monitoring kann der Angreifer in Ruhe nach Fehlern und Schwachstellen suchen. Dies erhöht die Chance, eine Schwachstelle erfolgreich zu finden und zu nutzen. Im Idealfall verfügt die Anwendung über eine Überwachungssoftware, die auf diese bedrohliche Untersuchung aufmerksam macht. Wenn nicht, wird zumindest ein Mechanismus benötigt, der über das Eindringen eines Angreifers informiert.

Es gibt eine Reihe von Open-Source „Intrusion Detection“-Tools und Frameworks, die dabei helfen können, die Überwachung eines Systems zu automatisieren. Eine Auswahl an Protokollverwaltungstools sind beispielsweise „Nagilos“, „Snort“, „Splunk“, „OSSEC“, „Tripwire“ oder „Fluentd“. [6]

Wie kann unzureichendes Logging und Monitoring verhindert werden?

OWASP empfiehlt gemäß dem Risiko der von der Anwendung gespeicherten oder verarbeiteten Daten die Einhaltung folgender Maßnahmen: [7]

Alle Fehler bei der Anmeldung, der Zugriffskontrolle und der serverseitigen Eingabevalidierung sollen mit ausreichendem Benutzerkontext protokolliert werden, um verdächtige oder bösartige Konten zu identifizieren. Die Logs sollen so lange aufbewahrt werden, dass eine verzögerte forensische Analyse möglich ist.
Es soll sichergestellt werden, dass Logs in einem Format erstellt werden, welches von zentralen Protokollverwaltungstools problemlos verwendet werden kann.
Hochwertige Transaktionen sollen über einen Audit Trail mit Integritätskontrollen verfügen, um Manipulationen oder Löschungen zu verhindern.
Eine wirksame Überwachung und Alarmierung soll eingerichtet werden, sodass verdächtige Aktivitäten rechtzeitig erkannt und darauf reagiert werden kann.
Für Vorfälle soll ein Reaktions- und Wiederherstellungsplanerstellt werden, wie zum Beispiel „NIST 800-61 rev. 2“.

Auch hier gibt es sowohl kommerzielle als auch Open-Source Frameworks. OWASP benennt dafür die Lösungen „OWASP AppSensor“, „Web-Application-Firewalls“ wie „ModSecurity“ mit dem „OWASP ModSecurity Core Rule Set“ und Log-Korrelationssoftware mit benutzerdefinierten Dashboards und Benachrichtigungen.

Neben den von OWASP definierten Maßnahmen schlägt Dave Whitelegg von IBM weitere Sicherheitsmaßnahmen vor: [8]

Eine separate und dedizierte, sicherheitsgehärtete Serverplattform, um Ereignisse im Audit-Protokoll zu erfassen und zu speichern.
Der Einsatz von Netzwerkzeitsynchronisationstechnologie, um Systemuhren zu synchronisieren. Dies ermöglicht auch automatisierte Überwachungswerkzeuge zur Analyse von Ereignismustern, die in Echtzeit auftreten.
Eine starke Zugriffskontrolle auf die Logs.
Die Anlage eines formalen Reaktionsplan für Vorfälle.
Die Sicherstellung der 24/7-Überwachung durch die Implementierung eines Warnsystems für das Überwachungspersonal.

Chris Bihary von Tap Into Technology glaubt, dass menschliche Erkenntnisse ein geeignetes Werkzeug seien, um ein System zu schützen. Hierfür sollten Sie Folgendes beachten: [9]

Kennen Sie Ihren Basis-Traffic, um festzustellen, was nicht normal ist.
Identifizieren Sie das Vorhandensein von unbekannten/unautorisierten IP-Adressen in drahtlosen Netzwerken.
Seien Sie vorsichtig bei mehreren fehlgeschlagenen Anmeldeversuchen für die Systemauthentifizierung und Ereignisprotokolle.
Verfolgen Sie verdächtige Aktivitäten im Netzwerk nach Feierabend.
Untersuchen Sie unerklärliche Systemneustarts oder Abschaltungen.
Behalten Sie die Dienste und Anwendungen im Auge, die so konfiguriert sind, dass sie automatisch und ohne Berechtigung gestartet werden.

Erkennen und Reagieren auf Angriffe: AppSensor

Das OWASP AppSensor Projekt ist eine gemeinschaftlich entwickelte Initiative, die Open-Source Materialien und Code für Organisationen bereitstellt, um diesen dabei zu helfen, eigene Angriffsüberwachungen und Reaktions-Implementierungen zu entwickeln.

Trotz der enormen Bedeutung dieser Systeme ist die derzeitige Lage, dass Verteidigungsmaßnahmen bisher in wenigen Anwendungen integriert sind. Jeden Tag werden Angriffe gestartet, um Anwendungen zu inspizieren und Schwachstellen zu suchen. Angreifer verwenden dazu teils automatisierte Vulnerability-Scanner wie OWASP ZAP, welche eine Anwendung auf bekannte Schwachstellenmuster testen. Leider ist es noch traurige Realität, dass fast jede Anwendung völlig blind für diese Angriffe ist.

Das OWASP AppSensor Projekt schreibt, dass Unternehmen oftmals ein falsches Vertrauen in antiquierte Verteidigungsmechanismen, wie signaturbasierte Systeme setzen, die oftmals trivial umgangen werden können. Für die Überwachung der Logs ist es nach einem durchgeführten Angriff zu spät. Daher wird an dieser Stelle eine bessere Verteidigung benötigt, die auch die individuelle Natur der Anwendung versteht. Das bedeutet zu verstehen, wie die Geschäftslogik funktioniert, die Zugriffskontrolle durchgesetzt wird und alle anderen einzigartigen Aspekte der Anwendung berücksichtigt werden.

Weiter schreibt OWASP, dass nicht nur generische Angriffstechniken, sondern auch individuelle Angriffe erkannt werden sollen. Schlussfolgernd sind es Angriffe, die gezielt auf das spezifische Design und die Architektur der Anwendung ausgerichtet sind. [10]

Trotzdem reicht allein die fortgeschrittene Erkennung nicht aus. Einen Schritt voraus ist ein Verteidigungssystem, das einen bösartigen Angreifer identifizieren kann, bevor er eine Schwachstelle findet und ausnutzt. Dieser Ansatz benötigt die Fähigkeit, den Angreifer während seiner Suche nach Schwachstellen in der gesamten Anwendung zu erkennen. Die Reaktion darauf muss schnell und vollautomatisch sein, um die Bedrohung durch den Angreifer zu eliminieren. Eine reaktive Analyse durch den Menschen ist dafür zu langsam. Bis ein Mensch einen Angreifer erkannt hat, kann dieser bereits kritische Daten gestohlen, und das System kompromittiert haben.

“The future of application defense is a system that can understand custom attacks against an application, correlate them against a malicious attacker, and react in real-time to contain and eliminate the threat. This defense is OWASP AppSensor.”
AppSensor Guide, May 2014

Bis 2020 könnten 25 Prozent aller Webanwendungen ein solches Verteidigungssystem implementiert haben [11]. So prognostiziert zumindest das OWASP AppSensor Projekt in seiner Werbebroschüre. Ein Ziel, welches zum derzeitigen Zeitpunkt wohl kaum mehr zu erreichen scheint.

Die derzeitige Lage erlaubt es Angreifern in vielen Anwendungen unentdeckt nach Schwachstellen zu suchen. Bei anschließendem erfolgreichen Kompromittieren der Daten haben die Angreifer oft lange Zeit ihre Spuren zu verwischen, bis ein Einbruch auffällt und eine Strafverfolgung begonnen werden kann. In der Vergangenheit haben Fälle auch bereits gezeigt, dass Logs in der Zwischenzeit schon gelöscht wurden (siehe „Google+ Hack 2018“ [12]). Deshalb ist eine Anwendung, die sich selbst schützen kann und bei Angriffen Reaktionen einleiten kann, bei professionellen Umgebungen das notwendige Mittel.

Dieser Verteidigungsmechanismus wird als Runtime application self-protection (RASP) bezeichnet. RASP ist eine Sicherheitssoftware, die mit in die Anwendung integriert wird oder an die Umgebung geknüpft ist. So können Angriffe auf Anwendungsebene erkannt und direkt blockiert werden. Da RASP auf Anwendungsebene läuft, hat zum Beispiel AppSensor Einblick über die Vorgänge innerhalb der Anwendung. Das Anwendungsverhalten kann genau analysiert werden. Somit wird ermöglicht, dass in Echtzeit reagiert werden kann. Damit unterscheidet sich RASP von perimeterbasierten Technologien, wie Web Application Firewalls (WAF). [13]

Ein Intrusion Prevention System (IPS) wie z.B. eine Web-Application Firewall (WAF) erkennt generische Angriffe, die auf jede Anwendung stattfinden können. Das Ziel von RASP ist es jedoch Angriffe, welche zielgerichtet auf eine Anwendung ausgerichtet sind, rechtzeitig zu erkennen. Sendet ein Anwender keinen wie im Client vorgesehenen, vordefinierten Listenwert, sondern die ID eines unzulässigen Modells („Request Tampering“), würde ein an diesem Ort in die Anwendung integriertes Verteidigungssystem diesen Angriffsversuch erkennen. Eine WAF wäre völlig blind für dieses Event. Der in die Anwendung integrierte Ansatz ermöglicht die anwendungsspezifische Erkennung und erlaubt es die Aktionen und Zugriffe einem spezifischen, authentifizierten Besucher zuzuordnen [14].

Der Integrationsaufwand eines RASP ist im Vergleich zu einem IPS recht hoch, denn es müssen in der Regel Anpassungen am Quellcode der Anwendung gemacht werden. An den kritischen Stellen wie der Authentifizierung werden dabei Sensoren angebracht, die beim Loginversuch Events an das RASP-System sendet. Konkret wird die API des RASP Systems aufgerufen, wobei Informationen zum Kontext des Ereignisses übergeben werden. Das RASP-System entscheidet dann selbst anhand von Regeln und Policies, ob Verteidigungsmaßnahmen eingeleitet werden müssen, oder was zu tun ist. Neben der Integration der Sensoren in die Web-Anwendung ist also die Pflege der Policies im RASP ein erheblicher Aufwand, der bei der Installation eines solchen Systems anfällt. Alternativ zur Nutzung der RASP API kann auch mit Aspektorientierter Programmierung (ASP) gearbeitet werden, um beispielsweise AppSensor mitzuteilen, dass ein Angriff stattfindet.

Zur Visualisierung und Benachrichtigung der Ereignisse, die dabei überwacht werden, kann ein Dashboard als Clientanwendung verwendet werden, dass alle Ereignisse kumuliert darstellt, sowie die eingeleiteten Verteidigungsmaßnahmen, wie z.B. das Sperren von Benutzeraccounts, oder das blockieren einer IP-Adresse. Derartige Maßnahmen müssen natürlich ebenfalls implementiert werden, optimaler Weise in einer separaten Anwendung, die getrennt von der zu verteidigenden Anwendung betrieben wird.

Fazit

Der große Unterschied ist, dass eine WAF vor der eigentlichen Webanwendung und nicht in ihr sitzt. Wenn ein Hacker in der Lage ist, die Eingangsfilter der WAF zu umgehen, besteht die Gefahr, dass die Anwendung gehackt wird. In den meisten Fällen ist die WAF die einzige Verteidigungslinie zum Schutz einer Anwendung. RASP hingegen überwacht ständig die Anwendung und kann so eingerichtet werden, dass es vor einen Angriff warnt oder sogar die Bedrohung in Echtzeit blockiert. Es ist eine Notwendigkeit, den sich entwickelnden Bedrohungen immer einen Schritt voraus zu sein. Der beste Weg, um immer einen Schritt voraus zu sein, ist das Echtzeit-Monitoring dieser potenziellen Bedrohungen und die Möglichkeit, sie sofort zu blockieren.