Veranstaltung: Bachelor-Seminar Netz- und Datensicherheit

Nummer:
143241
Lehrform:
Seminar
Medienform:
rechnerbasierte Präsentation
Verantwortlicher:
Prof. Dr. Jörg Schwenk
Dozent:
Prof. Dr. Jörg Schwenk (ETIT)
Sprache:
Deutsch
SWS:
3
LP:
3
Angeboten im:
Wintersemester und Sommersemester

Termine im Wintersemester

  • Vorbesprechung: Dienstag den 09.10.2018 ab 14:15 im ID 04/413
  • Seminar Dienstags: ab 14:15 bis 16.45 Uhr im ID 04/413

Termine im Sommersemester

  • Beginn: Dienstag den 10.04.2018 ab 15:00 im ID 03/471
  • Seminar Dienstags: ab 15:00 bis 16.45 Uhr im ID 03/471

Prüfung

Seminarbeitrag

studienbegleitend
Prüfungsanmeldung: Direkt bei der Dozentin bzw. dem Dozenten

Ziele

Die Teilnehmer können technische und wissenschafltiche Literatur finden, beschaffen verstehen und auswerten.

Inhalt

Ausgewählte Themen der IT-Sicherheit mit Bezug zur Netz- und Datensicherheit werden von den Studierenden eigenständig erarbeitet. Soweit möglich werden Themen in Anlehnung an eine gerade laufende Wahlpflichtveranstaltung gewählt, um didaktische Synergieeffekte zu nutzen.

Voraussetzungen

keine

Empfohlene Vorkenntnisse

Grundlegende Kenntnisse der Kryptographie

Materialien

Folien:

Musterlösungen:

Sonstiges

Diese Veranstaltung wird im Block angeboten.

Vorläufige Termine/Meilensteine

  • Vorbesprechung und Themenvergabe 10.04.18 15:00 Uhr
  • Bewerbung mit einem Exposee 24.04.18
  • Acceptence notification 30.04.18
  • Abgabetermin einer Preversion der schriftlichen Ausarbeitung 25.06.18
  • Präsentationen wird per Doodle Umfrage festgelet
  • Abgabetermin der finalen Version der schriftlichen Ausarbeitung 20.07.18
  • Bekanntmachung des AwardGewinners/Meldung der Ergebnisse an das Prüfungsamt: ab Anfang des folgenden Semesters

Hinweis: Es werden keine Teilnahme-/Leistungsscheine ausgestellt. Die Ergebnisse werden direkt an das Prüfungsamt gemeldet.

Fragen (Kontakt): Sebastian Lauer (vorname.nachname[at]rub.de)

Ausarbeitungen: Beispiele: http://nds.rub.de/teaching/BestStudentPaperAward/ Vorlage: http://nds.rub.de/teaching/theses/seminar/

Anmerkungen:

Ziel des Seminars ist die Vorstellung einer wissenschaftlichen Veröffentlichung. Hierzu werden bereits veröffentliche Artikel zur Auswahl angeboten.

Die Seminarteilnehmer sollen die Veröffentlichung im Rahmen des Seminars verständlich erarbeiten und evtl. benötigte Grundlagen kurz und präzise einführen.

Vor der Zuteilung des vorausgewählten Seminarthemas ist von allen Kandidaten für das Seminarthema ein zweiseitiges Exposee beim jeweiligen Betreuer einzureichen. Dieser wählt anhand der Exposees den Kandidaten aus der das Seminarthema bearbeitet.

Die Ausarbeitung sollte einen Umfang von ca. 15 Seiten haben, Ausnahmen oder Abweichungen sind mit dem jeweiligen Betreuer abzustimmen. Vor dem Präsentationstermin muss dem Betreuer eine Preversion der schriftlichen Ausarbeitung vorliegen. Diese wird durch den jeweiligen Betreuer einmalig korrigiert. Die Korrekturen sind in die finale Version der Ausarbeitung einzuarbeiten.

Ein Seminarvortrag umfasst üblicherweise 20-30 Minuten, einschließlich einer anschließenden Fragerunde. Das Foliendesign sowie die Vortragssprache (deutsch, englisch) sind freigestellt. Bitte reichen Sie Ihre Ausarbeitung und Präsentation im PDF Format ein. Fragen und Korrekturen durch die Betreuer sind während des Vortrags möglich, sofern Nachbesserungs- oder Klärungsbedarf besteht.

Anwesenheitspflicht: Am Ende des Semesters werden die Vorträge innerhalb eine Blocktermins abgehalten (KEINE WÖCHENTLICHEN TERMINE!). An diesem Termin besteht Anwesenheitspflicht

free TBA

Riding out DOMsday: Toward Detecting and Preventing DOM Cross-Site Scripting

Cross-site scripting (XSS) vulnerabilities are the most frequently reported web application vulnerability. As com- plex JavaScript applications become more widespread, DOM (Document Object Model) XSS vulnerabilities—a type of XSS vulnerability where the vulnerability is located in client-side JavaScript, rather than server-side code—are becoming more common. As the first contribution of this work, we empirically assess the impact of DOM XSS on the web using a browser with taint tracking embedded in the JavaScript engine. Building on the methodology used in a previous study that crawled popular websites, we collect a current dataset of potential DOM XSS vulnerabilities. We improve on the methodology for confirming XSS vulnerabilities, and using this improved methodology, we find 83% more vulnerabilities than previous methodology applied to the same dataset. As a second contribution, we identify the causes of and discuss how to prevent DOM XSS vulnerabilities. One example of our findings is that custom HTML templating designs—a design pattern that could prevent DOM XSS vul- nerabilities analogous to parameterized SQL—can be buggy in practice, allowing DOM XSS attacks. As our third contribution, we evaluate the error rates of three static-analysis tools to detect DOM XSS vulnerabilities found with dynamic analysis techniques using in-the-wild examples. We find static-analysis tools to miss 90% of bugs found by our dynamic analysis, though some tools can have very few false positives and at the same time find vulnerabilities not found using the dynamic analysis.

http://www.cs.cmu.edu/~anupamd/paper/ndss2018.pdf

Betreuer: Christopher Späth <christopher.spaeth@rub.de>

[name]
free TBA

Security Keys : Practical Cryptographic Second Factors for the Modern Web

“Security Keys” are second-factor devices that protect users against phishing and man-in-the-middle attacks. Users carry a single device and can self-register it with any online service that supports the protocol. The devices are simple to implement and deploy, simple to use, privacy preserving, and secure against strong attackers. We have shipped support for Security Keys in the Chrome web browser and in Google’s online services. We show that Security Keys lead to both an increased level of security and user satisfaction by analyzing a two year deployment which began within Google and has extended to our consumer-facing web applications. The Security Key design has been standardized by the FIDO Alliance, an organization with more than 250 member companies spanning the industry. Currently, Security Keys have been deployed by Google, Dropbox, and GitHub. An updated and extended tech report is available at https://github.com/google/u2f-ref- code/docs/SecurityKeys_TechReport.pdf.

https://pdfs.semanticscholar.org/b674/1f7862be64a5435d2625ea46f0508b9d3fee.pdf

Betreuer: Christopher Späth <christopher.spaeth@rub.de>

[name]
free TBA
JavaScript Zero: Real JavaScript and Zero Side-Channel Attacks

Abstract: Modern web browsers are ubiquitously used by billions of users, connecting them to the world wide web. From the other side, web browsers do not only provide a unified interface for businesses to reach customers, but they also provide a unified interface for malicious actors to reach users. The highly optimized scripting language JavaScript plays an important role in the modern web, as well as for browser-based attacks. These attacks include microarchitectural attacks, which exploit the design of the underlying hardware. In contrast to software bugs, there is often no easy fix for microarchitectural attacks. We propose JavaScript Zero, a highly practical and generic fine-grained permission model in JavaScript to reduce the attack surface in modern browsers. JavaScript Zero facilitates advanced features of the JavaScript language to dynamically deflect usage of dangerous JavaScript features. To implement JavaScript Zero in practice, we overcame a series of challenges to protect potentially dangerous features, guarantee the completeness of our solution, and provide full compatibility with all websites. We demonstrate that our proof-of-concept browser extension Chrome Zero protects against 11 unfixed state-of-the-art microarchitectural and sidechannel attacks. As a side effect, Chrome Zero also protects against 50% of the published JavaScript 0-day exploits since Chrome 49. Chrome Zero has a performance overhead of 1.82% on average. In a user study, we found that for 24 websites in the Alexa Top 25, users could not distinguish browsers with and without Chrome Zero correctly, showing that Chrome Zero has no perceivable effect on most websites. Hence, JavaScript Zero is a practical solution to mitigate JavaScript-based state-of-the-art microarchitectural and side-channel attacks.

http://wp.internetsociety.org/ndss/wp-content/uploads/sites/25/2018/02 /ndss2018_07A-4_Melicher_paper.pdf

Betreuer: Marcus Niemietz <marcus.niemietz@rub.de>

[name]
free TBA

Game of Missuggestions: Semantic Analysis of Search-Autocomplete Manipulations

Abstract: As a new type of blackhat Search Engine Optimization (SEO), autocomplete manipulations are increasingly utilized by miscreants and promotion companies alike to advertise desired suggestion terms when related trigger terms are entered by the user into a search engine. Like other illicit SEO, such activities game the search engine, mislead the querier, and in some cases, spread harmful content. However, little has been done to understand this new threat, in terms of its scope, impact and techniques, not to mention any serious effort to detect such manipulated terms on a large scale. Systematic analysis of autocomplete manipulation is challenging, due to the scale of the problem (tens or even hundreds of millions suggestion terms and their search results) and the heavy burdens it puts on the search engines. In this paper, we report the first technique that addresses these challenges, making a step toward better understanding and ultimately eliminating this new threat. Our technique, called Sacabuche, takes a semantics-based, two-step approach to minimize its performance impact: it utilizes Natural Language Processing (NLP) to analyze a large number of trigger and suggestion combinations, without querying search engines, to filter out the vast majority of legitimate suggestion terms; only a small set of suspicious suggestions are run against the search engines to get query results for identifying truly abused terms. This approach achieves a 96.23% precision and 95.63% recall, and its scalability enables us to perform a measurement study on 114 millions of suggestion terms, an unprecedented scale for this type of studies. The findings of the study bring to light the magnitude of the threat (0.48% Google suggestion terms we collected manipulated), and its significant security implications never reported before (e.g., exceedingly long lifetime of campaigns, sophisticated techniques and channels for spreading malware and phishing content).

http://wp.internetsociety.org/ndss/wp-content/uploads/sites/25/2018/02 /ndss2018_07A-1_Wang_paper.pdf

Betreuer: Marcus Niemietz <marcus.niemietz@rub.de>

[name]
free TBA

SYNODE: Understanding and Automatically Preventing Injection Attacks on NODE.JS

Abstract: The Node.js ecosystem has lead to the creation of many modern applications, such as serverside web applications and desktop applications. Unlike client-side JavaScript code, Node.js applications can interact freely with the operating system without the benefits of a security sandbox. As a result, command injection attacks can cause significant harm, which is compounded by the fact that independently developed Node.js modules interact in uncontrolled ways. This paper presents a large-scale study across 235,850 Node.js modules to explore injection vulnerabilities. We show that injection vulnerabilities are prevalent in practice, both due to eval, which was previously studied for browser code, and due to the powerful exec API introduced in Node.js. Our study suggests that thousands of modules may be vulnerable to command injection attacks and that fixing them takes a long time, even for popular projects. Motivated by these findings, we present Synode, an automatic mitigation technique that combines static analysis and runtime enforcement of security policies to use vulnerable modules in a safe way. The key idea is to statically compute a template of values passed to APIs that are prone to injections, and to synthesize a grammar-based runtime policy from these templates. Our mechanism is easy to deploy: it does not require any modification of the Node.js platform, it is fast (sub-millisecond runtime overhead), and it protects against attacks of vulnerable modules, while inducing very few false positives (less than 10%).

URL: http://wp.internetsociety.org/ndss/wp-content/uploads/sites/25/2018/02 /ndss2018_07A-2_Staicu_paper.pdf

Betreuer: Marcus Niemietz <marcus.niemietz@rub.de>

[name]
free TBA

Cure53 Browser Security White Paper Chapter 5. Security Features of Browser Extensions & Plugins - Seite 68 bis 215

Security Features of Browser Extensions & Plugins This chapter takes a closer look at security topics linked to browser extensions and plugins. As with other aspects of our daily lives, we have very much gotten used to the idea of customization when it comes to our browsing experience. This approach is conveyed in browser development, as all vendors allow users to modify and personalize their navigation tools through the possibility of installing Add-Ons. There is a plethora of reasons that can inspire a given browser addition. [...] The extensibility of Add-Ons is a double-edged sword. On the one hand, a browser certainly wants the users to be satisfied with its offer of an enriched browsing experience. Security-wise, on the other hand, we cannot just pretend that extensions come scot-free. Therefore, a browser - when it comes to Add-ons, must find a balance between user-experience and keeping a close eye on the security impact of extensions. At all cost, browsers must have contingency plans regarding trust and potential for the extensions to be either vulnerable or just simply rogue.

https://github.com/cure53/browser-sec-whitepaper/

Betreuer: Dominik Noß <dominik.noss@rub.de>

[name]
free TBA

Cure53 Browser Security White Paper Chapter 6. UI Security Features - Seite 216 bis 280

The Graphical User Interface (GUI) is what most users employ to interact with the browser. This interface is not only necessary for rendering webpages, but it also informs users about errors and security incidents. A lot of browsers share similar UI elements, and what first comes to mind are an address bar or tabs. Yet they also have distinctive elements, especially when it comes to presenting security- relevant information. [...] Some have attempted to measure the outcomes and strategic choices in a scientific way and arrived at reasonable conclusions. As it is a much contested area, other studies responded with details on users reacting to the information given by certain parts of the UI, like the SSL lock, and SSL warnings. We do not set out to find an antidote to this push and pull climate, but rather want to make the readers aware of this background. We will also focus on a selection of the most relevant developments in the UI realm.

Betreuer: Dominik Noß <dominik.noss@rub.de>

[name]
free TBA

Measuring the Insecurity of Mobile Deep Links of Android

Mobile deep links are URIs that point to specific locations within apps, which are instrumental to web-to-app communications. Existing "scheme URLs" are known to have hijacking vulnerabilities where one app can freely register another app's schemes to hijack the communication. Recently, Android introduced two new methods "App links" and "Intent URLs" which were designed with security features, to replace scheme URLs. While the new mechanisms are secure in theory, little is known about how effective they are in practice. In this paper, we conduct the first empirical measurement on various mobile deep links across apps and web-sites. Our analysis is based on the deep links extracted from two snapshots of 160,000+ top Android apps from Google Play (2014 and 2016), and 1 million webpages from Alexa top domains. We find that the new linking methods (particularly App links) not only failed to deliver the security benefits as designed, but significantly worsen the situation. First, App links apply link verification to prevent hijacking. However, only 194 apps (2.2% out of 8,878 apps with App links) can pass the verification due to incorrect (or no) implementations. Second, we identify a new vulnerability in App link’s preference setting, which allows a malicious app to intercept arbitrary HTTPS URLs in the browser without raising any alerts. Third, we identify more hijacking cases on App links than existing scheme URLs among both apps and websites. Many of them are targeting popular sites such as online social networks. Finally, Intent URLs have little impact in mitigating hijacking risks due to a low adoption rate on the web.

https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-liu.pdf

Betreuer: Vlasdislav Mladenov <vladislav.mladenov@rub.de>

[name]
free TBA

FP-STALKER: Tracking Browser Fingerprint Evolutions Along Time

Browser fingerprinting has emerged as a technique to track users without their consent. Unlike cookies, fingerprinting is a stateless technique that does not store any information on devices, but instead exploits unique combinations of attributes handed over freely by browsers. The uniqueness of fingerprints allows them to be used for identification. However, browser fingerprints change over time and the effectiveness of tracking users over longer durations has not been properly addressed. In this paper, we show that browser fingerprints tend to change frequently—from every few hours to days—due to, for example, software updates or configuration changes. Yet, despite these frequent changes, we show that browser fingerprints can still be linked, thus enabling long-term tracking. FP-STALKER is an approach to link browser fingerprint evolutions. It compares fingerprints to determine if they originate from the same browser. We created two variants of FP-STALKER, a rule-based variant that is faster, and a hybrid variant that exploits machine learning to boost accuracy. To evaluate FPSTALKER, we conduct an empirical study using 98, 598 fingerprints we collected from 1, 905 distinct browser instances. We compare our algorithm with the state of the art and show that, on average, we can track browsers for 54.48 days, and 26 % of browsers can be tracked for more than 100 days.

https://csdl.computer.org/csdl/proceedings/sp/2018/4353/00/435301a054.pdf

Betreuer: Jens Müller <jens.a.mueller@rub.de>

[name]
free TBA

Tracking Ransomware End-to-end

Ransomware is a type of malware that encrypts the files of infected hosts and demands payment, often in a cryptocurrency such as Bitcoin. In this paper, we create a measurement framework that we use to perform a large-scale, two-year, end-to-end measurement of ransomware payments, victims, and operators. By combining an array of data sources, including ransomware binaries, seed ransom payments, victim telemetry from infections, and a large database of Bitcoin addresses annotated with their owners, we sketch the outlines of this burgeoning ecosystem and associated third-party infrastructure. In particular, we trace the financial transactions, from the moment victims acquire bitcoins, to when ransomware operators cash them out. We find that many ransomware operators cashed out using BTC-e, a now-defunct Bitcoin exchange. In total we are able to track over $16 million in likely ransom payments made by 19,750 potential victims during a two-year period. While our study focuses on ransomware, our methods are potentially applicable to other cybercriminal operations that have similarly adopted Bitcoin as their payment channel.

https://csdl.computer.org/csdl/proceedings/sp/2018/4353/00/435301a773.pdf

Betreuer: Jens Müller <jens.a.mueller@rub.de>

[name]