Problematik

Der zehnte und damit letzte Platz der OWASP Top-10 ist im eigentlichen Sinne keine direkte Schwachstelle, sondern thematisiert die Problematik, dass Angriffe nicht erkannt werden, wenn man kein entsprechendes Logging und Monitoring in seiner Anwendung installiert. Mit Logging ist nicht das obligatorische Logfile gemeint, dass die allermeisten Anwendungen durchaus besitzen. Dieses beinhaltet aber üblicherweise Logausgaben der Business-Logik, sowie Debugging-Informationen. Für die Suche bei sicherheitskritischen Aspekten ist dieses Logfile aus mehreren Gründen nicht besonders hilfreich. Der triftigste Grund ist der, dass dieses Logfile meist keine besonders lange Lebensdauer hat. Üblicherweise wird es im Betrieb der Anwendung so eingestellt, dass es sich nach 3-10 Tagen überschreibt, indem ein Rolling-File-Appender dafür sorgt, dass nicht zu viel Speicherplatz dafür verbraucht wird.

Man braucht aber bei der forensischen Analyse, wenn ein Einbruch passiert ist und analysiert werden muss, Zugriff auf Logeinträge die auch noch Monate und Jahre lang zurück liegen. Statistisch gesehen werden Einbrüche in Systeme erst nach 6-8 Monaten erkannt. Zu diesem Zeitpunkt sind die normalen Logfiles längst überschrieben worden. Außerdem beinhalten normale Logfiles viel zu viel Grundrauschen durch oft wenig informative Ausgaben, die bei der forensischen Analyse nicht helfen. Deshalb bedarf es also separater Logfiles für sicherheitsrelevante Ereignisse, die anders behandelt werden müssen als die normalen Logfiles. Wir nennen sie deshalb zur besseren Unterscheidung Security-Logs.

Die Schwachstelle bei Anwendung ohne Security-Logs ist also die unzureichende Protokollierung und Überwachung, sowie die dadurch auch meist fehlende Reaktion auf Vorfälle / Angriffe. Ein Angriff passiert aus diesem Grund meist unbemerkt, so dass ein Angreifer ungestört die Anwendung analysieren kann und die Schwachstellen in aller Ruhe und ohne zeitlichen Druck auswerten und ausnutzen kann.

Die Ziele der Angreifer sind bei einem Angriff einer Anwendung zunächst, die Persistenz aufrechtzuerhalten, also eine Schwachstelle so auszunutzen, dass sie dauerhaft und langfristig ausgenutzt werden kann. Eine solche Hintertür in ein System kann dann über Monate hinweg verwendet werden, oft ohne auch nur einen Verdacht der Missbrauchst auszulösen. Ein weiteres Ziel für einen Angreifer ist es, von diesem einen gekaperten System sich weiter auszubreiten im Netz der Anwendung. Also mehr Systeme zu erobern und zu steuern, um die Infrastruktur des Angreifers zu erweitern und dadurch mehr Kontrolle zu bekommen, um schließlich das eigentliche Ziel optimal erreichen zu können, nämlich interessante Daten zu stehlen, sie zu manipulieren oder zu zerstören. Je nach Motiv oder Auftrag des Angreifers.

Die Auswirkungen dieser Schwachstelle kann man wie folgt beschreiben: Bei unzureichendem Logging und Monitoring in einer Anwendung, wird das Erkennen von Bedrohungen und Angriffen verhindert, sowie das tiefere Eindringen und die Infiltration durch Angreifer gefördert. Wird nicht erkannt, dass ein Angriff stattfindet, dann kann auch nicht darauf reagiert werden. Ein Angreifer wird sich deshalb in aller Ruhe ausbreiten können und auch seine Spuren verwischen können.

Hier nochmals die Liste der Auswirkungen von unzureichendem Logging und Monitoring:

  • Ereignisse werden nicht protokolliert
    • Logins
    • fehlgeschlagene Authentifizierung
    • kritische Aktionen
  • Warnungen und Fehler erzeugen keine oder unklare Protokollmeldungen
  • Anwendung wird nicht auf verdächtige Aktivitäten hin überwacht
  • Protokolle werden nur lokal gespeichert und nicht ausgewertet
    • Logfiles nach ein paar Tagen überschrieben, so dass Angriffe dann nicht mehr ausgewertet werden können
  • Anwendung kann keine aktiven Angriffe in Echtzeit erkennen, eskalieren oder alarmieren
  • Angemessene Alarmierungsschwellen und Eskalationsprozesse sind weder vorhanden noch wirksam
  • Penetrationstests und Scans mit Angreifer-Tools lösen keine Warnmeldungen aus

Zur Veranschaulichung kann man eine Analogie zu unserer alltäglichen Welt bemühen. Man stelle sich folgende Szene vor: Eine Person geht in eine Bankfiliale und schaut sich interessiert um. Was würde wohl passieren, wenn sie einfach mal versuchen würde, Türen zu öffnen und Schränke und Schubladen zu durchsuchen? Würde diese Person das erfolgreich und ungestört machen können? Höchstwahrscheinlich würde sie sofort entdeckt, und ein streng dreinblickender Mitarbeiter der Bank würde das versuchen zu verhindern und Alarm schlagen. Jemand von der Sicherheit würde den Eindringling identifizieren und zur Rechenschaft rufen, möglicherweise festnehmen und einsperren lassen durch die Polizei.

Beim Online-Banking oder bei Webanwendungen allgemein ist das meist anders. Wenn ein Angreifer hier nach Schwachstellen sucht und herumschnüffelt, sagt keiner etwas, so dass der Angreifer ungestört alles durchsuchen kann, was nicht geschützt und verschlossen ist. Ist dieser Vergleich mit unserer realen, analogen Welt überhaupt zulässig? Meiner Ansicht nach sehr wohl, nur dass in der digitalen Welt keine Menschen mit Ihrem Verstand mitdenken und reagieren können. Diese Möglichkeit haben wir in unseren Anwendungen nicht direkt. Eine Reaktion kann immer nur stattfinden, wenn sie bereits im Vorfeld berücksichtigt wurde, indem bei der Programmierung diese Fälle bedacht und eingeplant wurden. Bei Webanwendungen ist das genauso wie in der Bankfiliale – wenn keiner da, und alles offen ist, dann merkt es wohl auch keiner, wenn sich ein Angreifer umsieht und die Schränke und Schubladen durchsucht. Anders ausgedrückt: Wenn keiner beobachtet und monitored – dann kann auch nicht reagiert werden.

Die traurige Realität in den meisten Anwendungen sieht folgendermaßen aus: Es gibt nur schlechte oder gar keine Security-Logs. Ohne diese Informationen können keine Angriffe erkannt werden.

Was man aber haben will:

  1. Angriffe erkennen
  2. Kompromittierte User-Accounts finden
  3. Missbrauch von Berechtigungen erkennen
  4. Auf Ereignisse reagieren

Viele Opfer wissen einfach nicht, dass sie angegriffen wurden. Und noch mehr Opfer wissen nicht, wie sie angegriffen wurden und was genau durch den Angreifer gemacht wurde.

Anforderungen

Welche Anforderungen ergeben sich aus diesen Erkenntnissen? Zunächst einmal können wir feststellen, dass die Situation bei den allermeisten Anwendungen mehr als ungenügend ist. Es liegen manchmal bereits Logausgaben vor, aber diese sind kurzlebig und zudem meist uneinheitlich. Logausgaben sehen im Code dann nicht selten so ähnlich aus:

log.error("Something bad happened to " + name, exception);

Das Problem bei einer solchen Logausgabe ist, dass sie nur sehr schwer automatisiert auswertbar ist. Ein Alarmsystem brauch aber Ereignisse, die automatisiert verarbeitet werden können, damit sie vernünftig interpretiert werden können. Andernfalls ist eine angemessene Reaktion nicht möglich.

Wünschenswert für eine automatisiert auswertbare Ausgabe wären folgende Angaben:

  • Zeitstempel
  • Bewertung des Schweregrads für jedes Ereignis
  • Identität des Kontos/Benutzers, der das Ereignis verursacht hat
  • Quell-IP-Adresse, die der Anfrage zugeordnet ist
  • Benutzerkontext über Anwendungsebenen hinweg
    • z.B. über internem Webservice, alle beteiligten Backend-Services, Messaging-Queue, Datenbanken, etc.
  • Ergebnis des Ereignisses
    • ob Erfolg oder Misserfolg des Angriffs

// UserContext: containing username, ip address, browser etc

Log.security( UserContext, ApplicationEvents.DataValidationFailure, exception);

Ein Freitext in der Logmeldung erschwert die Identifizierung und Korrelation von Ereignissen. Tritt ein Http-Request zunächst in die erste Schicht der Anwendung ein und verursacht durch die entsprechende Businesslogik weitere Aufrufe in verschiedenen Backendservices, dann ist es bei der Forensik extrem schwierig und ein riesiger Aufwand, ein Szenario nachzuvollziehen, wenn nicht zugeordnet werden kann, welche ursprüngliche Request die Anfragen in den Backendsystemen ausgelöst haben. Jeder der die Wartung einer Anwendung macht und schon mal versucht hat, komplizierte Fehler nachzustellen, der kennt diese Problematik. Deshalb ist es in diesem Fall sehr hilfreich, eine Korrelations-ID für den eingehenden Request zu vergeben, und diese ID durchgehend für alle weiteren Aufrufe in der Anwendung weiterzugeben. Diese Korrelations-ID wird dann bei allen Security-Logausgaben angegeben, damit bei der späteren Analyse alle zusammenhängenden Aufrufe gefunden werden können.

Anforderungen an Logging und Monitoring

Die Anforderungen sind sehr vielfältig, da man sowohl forensische, als auch datenschutz-rechtliche Aspekte berücksichtigen muss:

  1. Eine zentrale Funktion für alle Logging-Vorgänge verwenden
    1. um die Übersicht zu behalten und homogene Ausgaben zu erzeugen
  2. Sicherstellen, dass ein Mechanismus zur Durchführung der Log-Analyse vorhanden ist
  3. Den Zugriff auf Protokolle beschränken auf autorisierte Personen
  4. Keine sensiblen Informationen loggen,
    1. einschließlich unnötiger Systemdetails, Session-IDs oder Passwörter
  5. Nur vertrauenswürdige Daten loggen
  6. Mit ausreichendem Benutzerkontext protokollieren,
    1. um verdächtige oder bösartige Konten zu identifizieren
    1. Bsp. Login-, Zugriffskontroll- und serverseitige Fehler bei der Eingabevalidierung
  7. Angemessene Vorhaltezeit der Logs
    1. um verzögerte forensische Analyse zu ermöglichen
  8. Universelles Format
    1. damit Logs automatisch gelesen werden können
  9. Kritische Transaktionen sollen über einen Audit-Trail mit Integritätskontrollen verfügen
    1. um Manipulationen oder Löschungen zu verhindern, wie z. B. nur angehängte Datenbanktabellen
  10. Wirksame Überwachung und Alarmierung
    1. damit verdächtige Aktivitäten erkannt werden und rechtzeitig reagiert werden kann
  11. Notfallreaktions- und Wiederherstellungsplan
    1. damit im Ernstfall klar ist, welche Maßnahmen ergriffen werden müssen, um den Schaden einzudämmen

Abbildung 1: Anforderungen an Logging- und Monitoring

Um alle diese Anforderungen zu erfüllen bedarf es einer durchdachten Integration eines Monitoringsystems. Dieses sollte zentral zugänglich sein und unabhängig von der Anwendung die Ereignisse protokollieren und schützen. Der Zugriff auf die geloggten Daten sollte streng reglementiert sein, damit sowohl unautorisierte Personen keinen Zugang zu diesen sensiblen Informationen erhalten, als auch ein Angreifer seine Spuren nicht beseitigen kann.

Was bedeutet Monitoring auf Anwendungs-Level? Wenn man sich den Stack einer Anwendung und ihrer darunterliegenden Komponenten ansieht, dann existieren in einem professionellen Betrieb bereits einige Komponenten auf dem Level der Netzwerk-Infrastruktur, wie Firewalls, Intrusion-Detection-Systeme (IDS) und Intrusion-Prevention-Systeme (IPS). Diese sind wichtig und notwendig, allerdings haben sie den Nachteil, dass sie sehr wenig Informationen zum Kontext der Anwendung haben. Sie können also meist nicht beurteilen, ob der Request an eine Anwendung ein ganz normaler und legitimer Zugriff ist, oder ob es sich um einen Angriffsversuch handelt. Monitoring auf Anwendungslevel bedeutet also, dass innerhalb der Anwendung, also z.B. im Quellcode selbst untersucht und bewertet wird, was der Request für einen genauen Sinn und Zweck hat.

Wird beispielsweise versucht, durch bekannte Angriffsvektoren über SQL-Injection auf das DBMS zuzugreifen, so kann das in der Eingabevalidierung durch Abgleich einer Blacklist erkannt werden. Ebenso könnten XSS-Angriffe erkannt werden oder auch XXE-Angriffe. Beim einem Brute-Force-Angriff auf die Authentifizierungs-Komponente oder ein Aushebeln des Berechtigungssystems durch Privilege-Escalation können ebenfalls Security-Logeinträge geschrieben werden, damit sämtliche Aktivitäten dokumentiert sind. Dabei ist es auch egal, ob diese Angriffsversuche erfolgreich sind oder nicht. Für die Forensik ist es wichtig zu wissen, ob ein Angriff stattfindet bzw. stattgefunden hat und von wo aus. Abwehrmaßnahmen sollten ja auch bereits beim Angriffsversuch stattfinden, und nicht erst bei einem erfolgreichen Einbruch.

Ein Monitoringsystem auf Anwendungs-Level ist also eine wichtige Ergänzung zu bestehenden Systemen, die auf Host- oder Netzwerk-Level arbeiten. Man erkennt die Angreifer – und nicht nur die Schwachstellen. Man verhindert oder reduziert die Auswirkungen eines Angriffs.

OWASP AppSensor

Eine mögliche Implementierung eines solchen Monitoring Systems wurde mit dem Projekt AppSensor umgesetzt. Es handelt sich dabei um ein Projekt-Template oder -Framework, das bereits viele der erforderlichen Funktionen bereithält.

AppSensor ist weit mehr als nur ein Monitoring-Tool, es ist ein Security Protection System auf Anwendungs-Level. Es konzentriert Security-Relevantes zentral an einem Ort, was normalerweise im Rauschen der Logs untergeht. Es sorgt für dynamische Abwehr, indem von der Anwendung aus via API direkt Events übergeben werden können, wenn z.B. Logins wiederholt scheitern. Nur die Anwendung kennt den kompletten Kontext und kann wertvolle Infos liefern. Dadurch wird eine sinnvolle Abwehr erst möglich, z.B. um Accounts zu locken oder die IP-Adresse des Angreifers zu blockieren.

AppSensor arbeitet für die Erkennung und Einschätzung von Angriffen mit Policies. Ein einfaches Beispiel einer solchen Policy könnte sein:

10 falsche Login-Events in 5 Minuten für 1 User à Blockiere den Account

An den Erkennungspunkten im Quellcode sendet man einen Event an AppSensor, dadurch kann dann in AppSensor durch die Policy festgelegt werden was getan werden muss. In dem Fall den Account blockieren.

Events kann man auf verschiedene Art an AppSensor schicken

  • Individuell über AppSensor API,
  • durch AOP
  • oder über externe Tools

Im Code könnte das dann so aussehen:

if (isUserAuthorized (account)) {

      // present/view account

} else {

     //new code for appsensor

    appSensor.addEvent( logged_in_user, “INSUFFICIENT_AUTHORIZATION” )

}

Beim Scheitern des Logins im Else-Zweig baut man dann die Logik für das Feuern des Events ein. AppSensor prüft dann seine Policy und reagiert entsprechend. Die Abwehrmaßnahme „blockiere den Account“ würde dann beispielweise durch ein Skript umgesetzt werden, dass per SQL-Befehl den Benutzeraccount auf blockiert setzt und ihn nach der Karenzzeit wieder entsperrt. AppSensor agiert hier also als Schaltzentrale, um solche Ereignisse angemessen zu orchestrieren.

Eine andere Policy könnte so aussehen, um einen Credential Stuffing Angriff zu erkennen und zu vereiteln: Erkenne ob in kurzer Zeit von einer einzigen IP-Adresse Anmeldeversuche für viele Benutzer kommen – auch wenn nur je 1-mal. Mit AppSensor könnte man so etwas merken und Maßnahmen ergreifen.

Architekturübersicht AppSensor

Das Herz von AppSensor ist die Server-Komponente, die mit Events versorgt wird, die aus der zu monitorenden Anwendung kommen. In der Webanwendung werden also über die AppSensor-API Events geworfen, die im Server registriert und ausgewertet werden. Die Auswertung geschieht anhand der Policies, die dann im Ernstfall Maßnahmen einleiten, indem sie an den Response Handler die entsprechenden Befehle erteilt. Es ist dabei möglich, dass sich der Response Handler innerhalb der Webanwendung befindet, aber auch durchaus denkbar, dass er sich außerhalb, also in einer separaten Anwendung befindet.

Abbildung 2: AppSensor Architekturübersicht

Dashboard

Zentraler Punkt für das Monitoring ist das AppSensor Dashboard. Es ist dabei dem Integrationsteam überlassen, wie genau das Dashboard gestaltet wird, denn die Monitoring-Anwendung von AppSensor wird üblicherweise selbst entwickelt. Alle Daten, die visualisiert werden sollen, werden vom AppSensor Server zur Verfügung gestellt.

Hier eine Variante einer Design-Studie, die die eingegangenen Events der Anwendung als Indikator anzeigt und Details dazu in der Tabelle Detection. Außerdem werden eingeleitete Maßnahmen in der Response Tabelle angezeigt, sowie Trends und Statistiken rechts unten. Bei Erkennung eines Angriffs leuchten die Indikatoren zunächst rot und werden nach gewisser Zeit orange, gelb, dann wieder weiß. Die rote Ampel links zeigt momentan, dass gerade ein SQL-Injection Angriff stattfindet.

Abbildung 3: AppSensor Dashboard

Durch ein solches Sicherheits-Monitoring kann dann auch tatsächlich bemerkt werden, dass man angegriffen wird. Und zwar rechtzeitig. Außerdem kann gleich den Abwehrmaßnahmen bei der Arbeit zugesehen werden. So wie in der Bank, wenn der Officer von der Security seine Arbeit tut.

Fazit

Was können wir also von diesem 10. Platz der OWASP Top-10 mitnehmen? Es ist sehr wichtig, dass eine Anwendung selbst erkennt, dass sie angegriffen wird und für den Ernstfall entsprechende Maßnahmen einleitet. Verlässliche Security-Logs für eine spätere forensische Analyse sind dabei besonders wichtig. Es ist also eine sehr gute Idee, dafür zu sorgen, dass man diese sicherheitsrelevanten Events separat weg-loggt und sie langfristig aufbewahrt. Denn im Fall eines Angriffs, der gar nicht so selten passiert, wollen wir die Spuren auch Monate später noch analysieren können.

Ein Monitoring-System wie AppSensor, das auf sicherheitskritische Events reagiert, bringt Transparenz und die Möglichkeit zu Abwehrmaßnahmen in Echtzeit mit sich. Wenn man sich über diese Chancen im Klaren wird, dann ist es verwunderlich, dass es immer noch Webanwendungen gibt, die diese Möglichkeit nicht nutzen. Es ist mehr als einleuchtend, dass für den Umgang von Angriffen auf die Anwendung mindestens Maßnahmen ergriffen werden müssen, die der Aufklärung und Nacharbeitung der Folgen eines Angriffs dienen. Allein schon aus rechtlicher Sicht dürfte das eine Anforderung an ein Softwaresystem sein, dass seine Daten zu schützen hat.

Zudem bringt ein solches Monitoring-System die riesigen Mehrwerte wie Prävention und Reaktion mit sich, was in meinen Augen ein klares Killerkriterium ist, und sowohl Kunden als auch die Verantwortlichen der Wartung von Softwaresystemen geradezu begeistern müsste von den Fähigkeiten und dem Nutzen eines Monitoring-Systems wie AppSensor.

Der Aufwand die Sensoren in eine existierende Anwendung einzubauen ist minimal. Erheblich größer ist der Aufwand, den AppSensor Server aufzusetzen und das Dashboard zu entwickeln, das letztendlich den Leitstand für das Sicherheitsmonitoring darstellt. Dazu sollte am besten ein separater Server verwendet werden, der unabhängig von der Anwendung existiert und auch für andere Anwendungen zur Verfügung stehen kann, die zu monitoren sind. Aber wenn Sever und Dashboard einmal errichtet sind, ist die Integration von neuen Sensoren in der Anwendung, sowie die Integration neuer Anwendungen ein verhältnismäßig kleiner Aufwand.

Insgesamt kann gesagt werden, dass die Investition in ein Monitoring-System aus den besprochenen Gründen eine sehr sinnvolle und notwendige Maßnahme ist, die Sicherheit gemäß unseren heutigen Anforderungen an die IT-Welt maßgeblich zu erhöhen.