zurück zur Übersicht

Bericht von dem German OWASP Day 2017

Einführung

Der German OWASP Day findet jedes Jahr im Herbst statt und bringt Leute aus verschiedenen Ecken mit dem gleichen Interesse rund um Anwendungssicherheit zusammen. In dieser Edition lief die Veranstaltung am 14.11.2017 in Essen und die iT-CUBE war wieder dabei. Die spannenden Vorträge umfassten neueste Erkenntnisse aus dem Applikationssicherheits Umfeld: neue Abwehrmaßnahmen, aktuelle Applikationsangriffe und interessante, manchmal überraschende Statistiken, die sich aus den Projekten ergeben hatten.

Vorträge

In dem Keynote-Vortrag hat Professor Matthew Smith darüber gesprochen, wie kompliziert und daher benutzerunfreundlich die Sicherheitsmaßnahmen geworden sind, vor allem für den Endbenutzer. Sichere Umsetzung von HTTPS ist trotz steigender Framework-Unterstützung nicht immer richtig implementiert. An einem Beispiel wurde demonstriert, wie sich ausgerechnet ein Virenscanner aufgrund mangelnden Server Zertifikatschecks durch bösartige Updates infizieren lässt und sich dann selbst als Malware erkennt, was zu einer Deinstallation führen kann. Fehlerhafte Implementierungen von Passwortablagen und Auswirkung von Usability auf die Malwareanalyse wurden ebenfalls präsentiert.

Neue „Cheat Sheets“: DoS.Attacken und REST-Services

Das OWASP Cheatsheet Projekt war dieses Jahr in Deutschland besonders aktiv. Die zwei herausgegebenen Cheatsheets zielten auf Abwehr vor DoS Attacken und den Schutz von REST-Services. Das Arbeitsmodell in kleineren hochfokussierten Gruppen hat sich bewährt. Für nächstes Jahr sollen weitere Cheatsheets in Angriff genommen werden.

Vorträge: Neue Projekte & spannende Tools, nicht nur für Entwickler

Martin Klobloch hat in seinem Vortrag eine Reihe von anderen OWASP Projekten präsentiert. Entwickler können sich z.B. über die TOP 10 Proactive Controls freuen, die grundlegende Sicherheitskonzepte wie  „Validate All Input“ beinhalten. Der OWASP Dependency Check kann vor allem in .NET und JAVA Umgebung die genutzten externen Komponenten mit bekannten Schwachstellen erkennen. Das Tool lässt sich im Build Prozess als Task, Plugin oder Command Line einsetzen. Für Security-Verantwortliche gibt es auch einiges Neues: Unter vielen anderen Tools möchte ich hier auf das OWASP DefectDojo  Projekt hinweisen.  Das Tracking Tool ermöglicht es, Vulnerability Reporting von verschiedenen Lösungen unter eine Plattform zu bringen. Die komplette Projektliste beinhaltet alle weiteren Tools.

In dem nächsten Vortrag wurde eine online Plattform gezeigt, die Websites automatisiert auf Privacy prüft und einstuft. So könnte zum Beispiel ein Benchmark entstehen, in dem sichtbar ist, welche deutschen Städte auf Tracking Tools am meisten setzen – könnten Sie erraten, welche große Stadt auf dem Platz 1 ist? Außer Tracking werden auch die Kriterien wie TLS-Verschlüsselungsstärke, bekannte Schwachstellen und weitere Checks durchgeführt, die eigentlich jeder auch selber machen könnte (bzw. sollte), da die Netzwerkkommunikation ganz normales Verhalten simuliert. Das interaktive Portal bietet auch die Möglichkeit an, eigene Listen mit Scan-Kandidaten zu bauen, in der die Webseiten nach Privacy Score sortiert werden.

Thomas Patzke mit seinen Kollegen wollte die Erkennung potenzieller Attacken anhand von Logs verbessern und dabei nicht nur auf die typischen Betriebssystem- und Netzwerklogs angewiesen sein. Dass viele Anwendungen keine ausreichenden Log-Dateien liefern, ist kein Geheimnis. Zu weiteren wichtigen Logquellen gehören außerdem auch Anwendungskomponenten wie Web Server oder Web Gateways. Thomas Projekt hat das Format „Sigma“ entwickelt, in dem die Log Events generisch beschrieben werden und mit anderen einfach geteilt werden können. Um diese Sigma Regeln für ein SIEM System verwenden zu können, wird ein Konvertor gebraucht. Momentan gibt es Konvertoren für LogPoint, Splunk und Elastic Search. Diverse entwickelte Sigma Regeln sind hier zu finden. Wie bei jedem Projekt der OWASP Konferenz kann auch hier jeder mitentwickeln.

Neue Erkennungsmethode für CSRF-Vulnerabilities

CSRF (Cross Site Request Forgery) ist immer noch eines der Top-Themen. Über diese oft unterschätzte Gefahr haben wir hier schon in einer Serie von Artikeln berichtet. CSRF-Schwachstellen lassen sich derzeit vor Allem manuell recht gut erkennen. Die automatisierten Quellcode Analyzers liefern dabei allerdings viele False Positives und die dynamischen Scanner verstehen die Workflows und Business Logik nicht automatisch und sind so auch nicht in der Lage, diese Schwachstelle einfach zu identifizieren. Jetzt steht Abhilfe in Aussicht: Ein wissenschaftlicher Ansatz mit Zustandsmaschinen und Property Graphs wurde im Rahmen des Projektes Deemon entwickelt. Property Graphs enthalten Informationen über die Anwendung wie Execution Traces und Datenworkflows. Die Graphen werden dann durchgequert und die potentiell gefährlichen Operationen werden identifiziert. Externe Tools wie Selenium IDE und HTTP Proxy werden für die Erstellung der Tests benötigt. Die CSRF Erkennung soll technologieunabhängig sein, bis jetzt wurden allerdings vor allem PHP Projekte getestet.

Mobile Anwendungen, Blitzgespräche & Neues im OWASP-Saftladen

In dem einzigen dedizierten Vortrag über mobile Anwendungen hat Erik Derr von seinem Tool berichtet, das Android Apps auf verwundbare, externe Komponenten prüft. Mit LibScout lassen sich meistens auch die Android Apps mit entstelltem Code im .jar Format anhand von vorher angelegten Library Profiles statisch scannen.

In den kurzen Lightning Talks wurde zum Beispiel die neue Version von TLS Attacker vorgestellt, mit der sowohl bekannte als auch neue Schwachstellen und Anomalien in TLS Bibliotheken erkannt werden können.

Wie letztes Jahr wurde auf der Konferenz wieder von den verwundbaren Testanwendungen gesprochen mit Fokus auf die neuen „Features“. Die neue Version des OWASP Juice Shop bietet jetzt noch mehr Herausforderungen an – z.B. im Zusammenhang mit der integrierten MarsDB. Nach wie vor ist es möglich, eigene „Challenges“ zu implementieren, jetzt sogar von der Kommandozeile aus. Eine völlig neue verwundbare Anwendung zum Spielen heißt NinjaDVA, die außer Anwendungsschwachstellen auch durch unsichere Umgebungen kennzeichnet.

In dem wohl am meisten technisch konzipierten Vortrag hat Sebastian Lekies eine Methode gezeigt, mit der er auch bei stark defensiven CSPs (Content Security Policies) mit der Einstellung „strict-dynamic“ diverse XSS Filters und Sanitizers umgehen konnte. Ein Angreifer könnte nämlich die DOM-Struktur der Seite so ändern, dass seine unkontrollierte Eingabe als Javascript Code ausgeführt wird. Dieser Code wird als Input für den sogenannten Gadget Script genutzt, dessen Aufgabe es ist, mit vordefinierten DOM-Selektoren beispielsweise Text Attribute zu extrahieren und zu interpretieren. Das Problem liegt darin, dass genau der erste Schritt – Injektion eines HTML Tags/Attributes den typischen Schutzmaßnahmen wie CSP, WAF oder XSS Filter meist nicht auffällt. Gadgets werden in allen modernen Javascript Frameworks unterstützt, deswegen ist es wenig überraschend, dass sie in jeder fünften Alexa TOP 5000 Webseite gefunden wurden. Und wie sollte man die Attacken gegen Gadgets abwehren? Statt problematischer Framework Patches empfiehlt der Autor im Browser voreingebaute Maßnahmen. Beispiele wären Precompiled  Templates (Angular 2) und bessere DOM und Origin Kontrolle.

Automatische Honeypots und mangelhafte Serverkonfigurationen

Dass Honeypots in ihrer Charakteristik zwischen aktiv und passiv zu unterscheiden sind, ist für die meisten keine neue Information. Viel interessanter ist: Wie könnten sie mit möglichst wenig Aufwand aufgebaut werden? In dem Vertrag von Martin Härterich und Marius Musch wurde die automatische Generierung von Honeypots präsentiert. Im ersten Schritt wird anhand der Charakteristik von realen Webanwendungen mittels Probing das Netzwerkprofil der getesteten Anwendung erstellt. Mithilfe von Templates kann dann ein Honeypot generiert werden, welcher der Anwendung weitgehend ähnelt. Um möglichst präzise Daten für die Templates zu haben, müssen die gleichen Requests auch mehrmals geschickt werden, so dass die Responses richtig ausgewertet werden können. So konnten Honeypots als die populären CMS Systeme Drupal oder Joomla verkleidet werden und die automatisierten Tools wie nmap haben dabei kaum einen Unterschied gemerkt.

CORS (Cross Origin Resource Sharing) wird seit einigen Jahren verwendet, um die strenge SOP (Same Origin Policy) zu lockern. So könnte eine freigeschaltete Domäne B eine Anfrage auf die Daten von der Domäne A erfolgreich ausführen. Diese Erlaubnis kommt in einem HTTP Header von dem Server der Domäne A. Die Analyse von Jens Müller hat auf die häufigsten Konfigurationsfehler hingewiesen. Neben den klassischen Fehlern beim Whitelisting mit Sternzeichen wurde z.B. auch vor dem null Wert im header gewarnt, der dazu führt, dass jeder IFrame doch den Zugriff bekommt. Als Tool bei der Auswertung der CORS Policy kann beispielsweise das Open-Source Tool CORStext verwendet werden.

Fazit

Der OWASP German Day war wieder eine gelungene Veranstaltung mit guter Teilnahme und hochwertigem Austausch und wir freuen uns schon auf das nächste Jahr!

 


Links:

German OWASP Day 2017: https://www.owasp.org/index.php/German_OWASP_Day_2017

OWASP Cheatsheet – DoS: https://www.owasp.org/index.php/Denial_of_Service_Cheat_Sheet

OWASP Proactive Controls Projekt: https://www.owasp.org/index.php/OWASP_Proactive_Controls

OWASP DefectDojo Projekt: https://www.owasp.org/index.php/OWASP_DefectDojo_Project

Privacy Testing: https://privacyscore.org/

Sigma Projekt (Logs Events Beschreibung): https://github.com/Neo23x0/sigma

Third-party Libraries von Android Anwendungen: https://github.com/reddr/LibScout

TLS Attacker – https://github.com/RUB-NDS/TLS-Attacker

OWASP Juice Shop – https://github.com/bkimminich/juice-shop

NinjaDVA – https://github.com/mgm-sp/NinjaDVA

XSS über Script Gadgets (Slides von Blackhat 2017) https://2017.appsec.eu/presos/Hacker/Don%E2%80%99t%20trust%20the%20DOM%20Bypassing%20XSS%20mitigations%20via%20Script%20gadgets%20-%20Sebastian%20Lekies,%20Krzystof%20Kotowicz%20and%20Eduardo%20Vela%20Nava%20-%20OWASP_AppSec-Eu_2017.pdf

Chameleon – automatic honeypot generation: https://www.owasp.org/images/4/47/GOD17-Chameleon.pdf

Analysis of CORS Misconfigurations https://www.owasp.org/images/c/c1/GOD17-CORS.pdf

CORStest https://github.com/RUB-NDS/CORStest

 Bild: ©iT-CUBE SYSTEMS AG 2017

Schreibe einen Kommentar