Alle Beiträge von Bernhard Hirschmann

Artikel in der Computerwoche

In der Computerwoche ist auf computerwoche.de am 26. August ein Fachartikel von mir erschienen. Unter dem Titel „Logging und Monitoring – Anwendungssicherheit effektiv überwachen“ beschreibe ich, wie Cyberangriffe auf Anwendungen durch Logging und Monitoring frühzeitig erkannt und verhindert werden, wo die Herausforderungen dabei liegen und was bei der Einführung eines Monitoring-Systems zu beachten ist.

Neues Video – Unzureichendes Logging und Monitoring

Den meisten Webanwendungen fehlt ein effektives und nachhaltiges Monitoring, über das man Angriffe erkennen kann. Und wenn man Angriffe nicht erkennt, dann kann man auch nicht darauf reagieren.
In meinem 10. Video der Secure Coding Reihe sprechen wir über dieses Thema, und was das in der Folge für Probleme mit sich bringt.

Neues Video: A9:2017 Nutzung von Komponenten mit bekannten Schwachstellen

Eine sehr häufig auftretende Sicherheitslücke in Webanwendungen entsteht durch den Einsatz unsicherer Libraries. Wenn auch Ihr in Euren Webanwendungen fremde Libraries einsetzt, dann solltet ihr jetzt ganz genau zuhören!

Platz 9 der OWASP Top 10 nennt sich „Nutzung von Komponenten mit bekannten Schwachstellen“. Hier geht es um den Einsatz von 3rd-Party-Libraries, die bekannte Schwachstellen enthalten, und dadurch die Sicherheit unserer Anwendung gefährden. Ich werden Euch zeigen, die man das entdecken und vermeiden kann.

A9:2017 Nutzung von Komponenten mit bekannten Schwachstellen

Talk „Hack me if you can“ auf der JAX2019

Auf der diesjährigen JAX in Mainz (6.-10. Mai 2019), der Konferenz für Java, Architektur- und Software-Innovation, habe ich am 8. Mai den Talk „Hack me if you can – Sicherheit in Webanwendungen“ gehalten. Inhaltlich habe ich dabei herausgearbeitet, wie wichtig die Berücksichtigung von Sicherheitsschwachstellen ist, bzw. dass man diese konsequent und strategisch vermeidet. Die richtige Vorgehensweise ist dabei, zunächst die Angriffe zu verstehen, damit man eine wirksame Verteidigung aufbauen kann.

Es gibt viel zu viele Webanwendungen, die zu einfach zu hacken sind. Der Grund ist fast immer, dass sich die Entwickler während der Implementierung keine Gedanken über die Sicherheit machen – weil sie die Angriffe nicht kennen. Deshalb ist es eine Grundvoraussetzung für sichere Software, dass man die Grundlagen sicherer Software kennt.

Den Vortrag habe ich aus diesem Grund in 4 Teile aufgeteilt:

  1. Einleitung: Warum das Ganze?
  2. Wie man hackt
  3. Wie man sich schützt
  4. Wie man sich wehrt

In der Einleitung geht es darum, zu zeigen, dass man sich aktiv um die Sicherheit kümmern muss. Man muss die Angriffe verstehen, um wirksame Verteidigung aufbauen zu können. Ich erläutere, dass viele Basics nicht berücksichtigt werden können, wenn das Know-How bei der Entwicklung nicht vollständig vorhanden ist.

Im 2. Teil „Wie man hackt“ zeige ich die Vorgehensweise von Hackern, so wie man es auch in Hacker-Kursen lernt. Der Grund dafür ist, damit ein Verständnis aufgebaut wird, wie man eine Anwendung angreift, bzw. von der anderen Perspektive aus gesehen, wie man angegriffen wird. Dadurch kann dann im 3. Teil besser verstanden werden, welche Maßnahmen man treffen muss, damit diese offenen Flanken nicht mehr bestehen.

Der 4. Teil beschäftigt sich dann mit der angemessenen Reaktion auf Angriffe. Denn niemand muss für eine Anwendung hinnehmen, dass sie durch Angriffe lahmgelegt wird. Es gibt hier Verteidigungsmaßnahmen, die das unterbinden können. Dabei stelle ich Tools vor, die eine Schaltzentrale für Sicherheitsmonitoring bieten, damit man Angriffe auf seine Anwendungen in Echtzeit verfolgen kann, und den Abwehrmaßnahmen live bei Ihrer Arbeit zuschauen kann.

Vortrag auf der JAX 2019

Am 8. Mai 2019 halte ich auf der JAX 2019 einen Vortrag über Sicherheit in Webanwendungen. Die JAX ist eine Konferenz für Java-, Architektur- und Software-Innovationen.

Der Titel des Vortrags lautet: Hack me if you can – Sicherheit in Webanwendungen. Wie auch schon letztes Jahr in kleiner Runde im Rahmen eines Meetups, werde ich bei diesem Thema über die Wichtigkeit und Notwendigkeit referieren, warum es so essenziell wichtig ist, sich um die Sicherheit in der Software zu kümmern.

Ich werde dabei zeigen, wie einfach es inzwischen die Angreifer haben, insbesondere über arglos entwickelte Anwendungen, bei denen keiner auf die Sicherheit geachtet hat. Dabei ist es oft so einfach darauf zu achten. Man muss eben nur die Basics kennen, um einen wirksamen Grundschutz zu bekommen.

Promovideo für meinen Vortrag auf der JAX in Mainz

Hier die genauen Angaben zum Vortrag: Donnerstag, 8. Mai um 15:15 Uhr in der Rheingoldhalle, Raum Gutenberg 2+3. Den Rest des Tages könnt ihr mich am Stand von EXXETA antreffen, ich würde mich freuen Euch dort zu treffen!

Jackson-Databind und das Problem mit CVE-2017-7525

Wird Jackson-Databind als 3rd-Party-Lib in einem Projekt eingebunden, oder es ist über eine transitive Abhängigkeit mit im Projekt, dann melden Analysetools umgehend ein Finding. Aber in welchem Fall ist Jackson-Databind tatsächlich gefährlich?

Hintergrund

Jackson-Databind wird verwendet, wenn Json Strings deserialisiert werden. Die Deserialisierung ist etwas komplizierter als die Serialisierung, was daran liegt, dass beim Serialisieren die Klassen noch bekannt sind. Werden abstrakte Klassen oder Interfaces verwendet, ist das beim Serialisieren egal – der Json String ist immer der gleiche. Anders herum muss beim Deserialisieren, wenn der Json String wieder in reale Objekte gemappt wird, eine Entscheidung für konktete Klassen gefällt werden, die auch instantiiert werden können.

Damit Jackson bei der Deserialisierung konkrete Klassen ermitteln kann, wird mit Annotations gearbeitet, über die die Klassen angegeben werden können:

{ "phone" : {
"@class" : "package.InternationalNumber",
"areaCode" : 555,
...
}
}

Auf Seite der Java-Klasse wird als Gegenstück z.B. mit @JsonTypeInfo gearbeitet, damit Jackson die richtige Klasse findet. Es gibt hier eine Vielzahl an Annotations, die bei komplexeren Strukturen helfen sollen.

Die Gefahr

Die Sicherheitslücke besteht dann, wenn der Json String so manipuliert werden kann, dass bei der Deserialisierung eine Klasse instanziiert wird, die Schaden anrichten kann (Denial of Service, Sensitive Data Exposure, Data Manipulation, …). Solche Klassen werden in diesem Kontext als „Gadgets“ bezeichnet.

Eine Gadget-Klasse muss allerdings im Klassenpfad der Anwendung liegen, weshalb zunächst unlogisch erscheint, dass damit Schaden angerichtet werden kann. Es gibt aber verschiedene polymorphe Klassen, über die generischer Code eingeschleust werden kann, der dann zur Ausführung kommt. Jackson hat deshalb bereits eine Blacklist an bekannten Gadget-Klassen, die bei der Deserialisierung nicht ausgeführt werden. Allerdings kommen immer neue kreative Varianten dazu, so dass naturgemäß eine Blacklist kein vollkommener Schutz sein kann.

Voraussetzungen für erfolgreichen Angriff

  1. Die Anwendung akzeptiert Json von Clients, das manipuliert werden kann. 
    • Bei der Kommunikation zwischen 2 Anwendungen, die sich in einer Trustzone befinden, sollte diese Gefahr nicht gross sein, da darauf vertraut wird, dass keine bösartigen und manipulierten Json Strings verwendet werden.
    • Wurde die Trustzone allerdings kompomittiert, dann fällt dieses Argument, so dass man auch bei interner Kommunikation weitere Maßnahmen vorsehen sollte.
  2. Die Anwendung beinhaltet im Classpath mindestens 1 Gadget-Klasse, mit der ein Angriff ausgeführt werden kann.
    • Da in einer Anwendung meist sehr viele Klassen über transitive Abhängigkeiten enthalten sind, sind auch viele bekannte Gadget-Klassen verfügbar. Selbst im JDK existieren Klassen, die als Gadgets missbraucht werden können.
    • Aus diesem Grund trifft auch diese Voraussetzung streng genommen immer zu.
  3. Die Anwendung hat aktives polymorphes Typehandling für Felder mit dem Type Object aktiviert (oder andere allgemeine Typen wir Serializable, Comparable, …)
    • Dies wird im Code über die Methode org.codehaus.jackson.map.ObjectMapper.enableDefaultTyping() aktiviert
  4. Die Anwendung verwendet Jackson-Databind in einer Version, die (noch) keine fragwürdige Gadget-Klassen blockiert via Blacklisting.
    • Ist die Jackson-Version aktuell, dann ist es sehr schwer, aber nicht ausgeschlossen, Gadget-Klassen zu finden, die einen Angriff zulassen.

Da (1) und (2) nie komplett ausgeschlossen werden können, sollten wir uns auf (3) und (4) fokussieren.

Folgendes ist noch festzustellen für die beiden Ausprägungen:

  1. Polymorphie: Anhand des Parameters valueType wird über die Annotation JsonTypeInfo definiert, welche „Zielklasse“ bei der Deserialisierung verwendet werden soll. Das ist entweder diese übergebene Klasse valueType selbst oder wird wiederum durch Annotationen dieser Klasse bestimmt. Durch die Annotation JsonTypeInfo kann definiert werden, dass die tätsächlich instanzierte Klasse, durch einen Parameter innerhalb des JSON-Textes vorgegeben wird, was bedeutet, dass der Sender des JSON-Textes die Entscheidung trifft. Die Entscheidung ist nicht völlig frei: die instanzierte Klasse, muss eine Erweiterung der Klasse valueType sein. Jackson bietet dazu mehrere Möglichkeiten. Die Kritische ist die, bei der Klassenname, bzw. ein Teil des Klassennamens, als JSON-Inhalt definiert/ausgewertet wird.
  2. DefaultTyping: unbestimmte/generische Attribute – beispielsweise von Type Tattr Object – können bei eingeschaltetem DefaultTyping mit Objekten befüllt werden, deren konkreter Typ Tconc durch den JSON-Inhalt bestimmt wird. Im Falle des Attributstyps Tattr Object unterliegt Tconc lediglich der Einschränkung, dass Tconc im Klassenpfad zu finden sein muss.


Ein Beispiel für eine gefährliche Codestelle ist folgende:

public class Person {
@JsonTypeInfo(use = Id.CLASS)
public Object phone;
}

Hier wird über @JsonTypeInfo der Klassenname angegeben, so dass dieser in der Json Struktur über die @class Annotation angegeben werden kann. Ist DefaultTyping aktiviert, dann kann an Stelle des Typs Object eine Gadget-Klasse treten, die der Angreifer angibt.

Prävention

  1. Immer die neueste Jackson-Databind Version verwenden
    • denn diese enthält die vollständigste Liste der gefährlichen Gadget-Klassen in der Blacklist
    • das ist kein perfekter Schutz, aber das mindeste was man tun sollte
  2. Default Typing vermeiden
    • statt dessen explizit die Klassen angeben, die bei der Deserialisierung verwendet werden sollen
  3. Allgemeine Klassen wie Object, Serializable, … vermeiden in den Objekten, die übertragen werden
    • dadurch wird vermieden, dass beliebige Klassen für den Angriff verwendet werden können
  4. Möglichst „type name“ verwenden und nicht classname als Type-Id
    • @JsonTypeInfo(use = Id.NAME)  anstatt  @JsonTypeInfo(use = Id.CLASS)

Referenzen

Statische Codeanalyse mit Xanitizer

Wenn man eine Webanwendung nach Sicherheits-Schwachstellen untersuchen will, dann bietet sich neben der dynamischen Analyse – Pentesten – vor allem die statische Codeanalyse an. Doch was steckt hinter den beiden Ansätzen und worin unterscheiden sie sich?

Pentesten ist eine Black-Box Analyse, bei der man die Interna der Anwendung nicht kennt. Man greift die Anwendung so an, wie es ein Angreifer auch tun würde tut. Auch wenn diese Methodik seine Berechtigung hat und wichtiger Bestandteil der Sicherheitsanalyse ist, gegenüber der statischen Codeanalyse hat sie einige Nachteile, denn viele Schwachstellen sind nicht so einfach zu erkennen. Oft ist es sogar Glücksache bzw. eine Frage des Geschicks des Pentesters, ob gut versteckte Schwachstellen in all ihren speziellen Bedingungen auch gefunden werden.

Bei der statischen Codeanalyse benötigt man den Quellcode der Anwendung. Es kann auch reichen, die Binaries der Anwendung zu haben und diese zu dekompilieren. Der Quellcode der Anwendung wird dann gezielt nach Schwachstellen untersucht, und zwar zunächst an den Stellen, wo sie üblicherweise auftreten: bei der Authentizitierung, dem Berechtigugsmanagement, und den nach außen exponierten Schnittstellen.

Die statische Codeanalyse ist also eine White-Box Analyse, bei der man sich die Logik des Programms anschauen kann. Dort gefundene Schwachstellen könnten dann in Kombination mit den Pentests viel effektiver gefunden werden. Ich empfehle sogar, beide Techniken zu kombinieren, aus mehreren Gründen:

  • Beweisführung
    • Beweisen der Gültigkeit des Findings
    • False Positives werden dadurch aussortiert (fälschlich gefundene Schwachstellen)
  • Nachvollziehbarkeit
    • Das Dev-Team kann dadurch besser nachvollziehen, dass diese Codestelle eine Schwachstelle ist
    • Die Wirksamkeit von Patches vom Dev-Team kann dadurch bewiesen werden

Tools

FindSecBugs

Es gibt verschiedene Tools für die statische Codeanalyse. Am einfachsten sind Pattern-basierte Tools wie FindSecBugs – einem Plugin für das weit verbreitete SpotBugs. Die Ergebnisse sind ganz ordentlich.

Xanitizer

Weit mehr Abdeckung kann man mit einer gezielteren Datenflußanalyse erreichen, wie es mit Xanitizer möglich ist. Man hat damit mehr Aufwand, als nur einen Scanner über den Code laufen zu lassen, aber auch bessere Resultate. Die Idee dahinter ist, dass sämtliche Benutzereingaben simuliert und durch den Code verfolgt werden. Benutzereingaben müssen generell als Gefahrenpotential, als böse eingestuft werden. Werden diese nicht gefiltert und damit neutralisiert, dann muss davon ausgegangen werden, dass dies ein Einfallstor für Angriffsvektoren ist.

Die verschiedenen Stationen, die die Benutzereingaben, in der Anwendung durchlaufen, werden von Xanitizer in 3 Kategorien eingeteilt:

  • Sources
  • Sinks
  • Sanitizer

Als Source wird die Station bezeichnet, wo Daten von außen ins System eindringen. Also Schnittstellen aller Art, sowohl von der Benutzerschnittstelle her, als auch technische Schnittstellen, beispielsweise bei einem Web-Service. Daten die hier ankommen, werden als tainted bezeichnet, also als schmutzig, die noch „gewaschen“ werden müssen.

Sinks sind die Datensenken, wohin die Daten letztendlich wandern. Wenn die Daten immer noch tainted sind, wenn sie bei den Sinks ankommen, dann ist dies ein Finding und wird im Report als Schwachstelle angezeigt.

Damit die Daten „gewaschen“ werden, braucht es die genannten Filter, die Sanitizer, die die potenziell schadhaften Daten neutralisieren. Angriffsvektoren die solche Schwachstellen ausnutzen, werden von den Sanitizern sozusagen außer Gefecht gesetzt.

Von Haus aus erkennt Xanitizer bereits viele dieser Elemente im Quellcode vollautomatisch, allerdings muss meist auch noch nachjustiert werden, damit insbesondere Sourcen erkannt werden. Sie sind die wichtigsten Elemente bei der Datenflußanalyse, da sie die Eintrittspunkte ins System repräsentieren.

Insgesamt wird eine gute Analyse durch Xanitizer ermöglicht, die allerdings einiges an Aufwand mit sich bringt. Belohnt wird man aber durch brauchbare Ergebnisse und das gute Gefühl, die Sicherheit in seiner Anwendung deutlich zu verbessern.

Wie man genau mit Xanitizer arbeitet und ihn in den Software-Development-Life-Cycle (SDLC) einbindet und so automatisiert und regelmäßig Sicherheitsanalysen durchführen kann, werde ich in weiteren Blogbeiträgen zeigen.