Lade Inhalt...

Exploits und Exploit Kits für Angriffe auf Android OS

Projektarbeit 2016 120 Seiten

Informatik - IT-Security

Leseprobe

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Codefragmente

Gliederung

Zusammenfassung

1. Einleitung und Motivation

2. Grundlagen
2.1 Android OS
2.2 Exploits
2.3 Exploit Kits

3. Bedrohungsszenarien
3.1 Physische Angriffe
3.2 Angriffe auf drahtloser Kommunikationsebene
3.3 Angriffe auf Softwareebene

4. Konzeptionierung einer Schadsoftware für Android OS
4.1 Verbreitungswege von Schadsoftware
4.1.1 Google Play Store
4.1.2 Apps von alternativen Android Markets
4.1.3 Infizierte Webseiten oder Werbebanner
4.1.4 Vom PC aufs Smartphone
4.1.5 Von Smartphone zu Smartphone
4.1.6 Rogue Access Points
4.2 Rechteausweitung (Privilege Escalation)
4.3 Konfiguration und Infektion des Zielgeräts
4.4 Malware-Funktionalitäten
4.5 Zusammenfassung

5. Erstellung und Implementierung einer Schadsoftware
5.1 Einführung und Vorbereitung
5.1.1 Kali Linux
5.1.2 Metasploit Framework
5.1.3 Armitage
5.2 Erstellung eines Exploits
5.2.1 Meterpreter
5.2.2 Reverse-Shell-Payload
5.2.3 Erstellung eines benutzerdefinierten Android Package
5.3 Verbreitung
5.4 Rechteausweitung
5.5 Infektion
5.5.1 Kontaktaufnahme mit Opfersystem
5.5.2 Erlangen von notwendigen Berechtigungen
5.5.3 Erstellen einer persistenten Backdoor
5.6 Ausführung von Malware-Funktionalitäten

6. Gegenmaßnahmen

7. Fazit

Anhang

Abkürzungsverzeichnis

Glossar

Literaturverzeichnis

Abbildungsverzeichnis

Abb. 1: Weltweiter Marktanteil der Betriebssysteme am Absatz von Smartphones im Jahr 2016

Abb. 2: Architektur des Android-Betriebssystems

Abb. 3: Entwicklung des Android Market (Google Play Store)

Abb. 4: Android-Verbreitung (August 2016)

Abb. 5: Exploits - Ausnutzung von Sicherheitslücken

Abb. 6: Kritische Schwachstellen der in der BSI-Schwachstellenampel
erfassten Softwareprodukte

Abb. 7: Speicherinhalt und -aufteilung

Abb. 8: Die zehn führenden Kategorien von Schad-Webseiten

Abb. 9: Von der Veröffentlichung des Produkts über die Sicherheitslücke bis zur Problemlösung

Abb. 10: Android-Schwachstellen pro Jahr bis August 2016

Abb. 11: So viel sind die gefährlichsten Schwachstellen (Zero Day Exploits)
wert

Abb. 12: Die Entwicklung der Exploit Kits über die Jahre hinweg

Abb. 13: Verteilung der Exploit Kit-Angriffe

Abb. 14: Vier Phasen einer Exploit Kit-Infektionskette

Abb. 15: FROST Recovery-Image

Abb. 16: Repacking einer App

Abb. 17: Sicherheitseinstellung - Zulassen von App aus unbekannter Herkunft

Abb. 18: Entwickleroption - Zulassen von USB-Debugging

Abb. 19: Netzwerkeinstellung - Punkt-zu-Punkt-Kommunikation (NFC) mittels Android Beam

Abb. 20: Beispielhafte Apps mit Root-Exploits und integrierter Payload

Abb. 21: Summer Flashlight - Malware mit dem Godless-Schadcode

Abb. 22: Globale Verteilung der betroffenen Geräte

Abb. 23: Zusammenfassung des Vorgehens für einen Penetrationstest oder Angriff

Abb. 24: Metasploit-Konsole

Abb. 25: Benutzeroberfläche von Armitage

Abb. 26: Kommandozeilenoptionen von Msfvenom

Abb. 27: Reverse-Shell - Exploiting-Vorgang

Abb. 28: Reverse-Shell - Payload-Verbindung

Abb. 29: Auflistung der Systeminformation des Zielgeräts (sysinfo) sowie Prüfung auf Root-Rechte (check_root)

Abb. 30: Aufruf des Multi-Handler (Armitage)

Abb. 31: Aufruf der Meterpreter Shell

Tabellenverzeichnis

Tab. 1: Übersicht bekannter Root-Exploits

Tab. 2: Sicherheitsstufen von Berechtigungen

Tab. 3: Gefährliche Berechtigungen und Berechtigungsgruppen

Tab. 4: Beschreibung der Felder im Multi-Handler

Codefragmente

Listing 1: Starten der PostgreSQL-Datenbank

Listing 2: Erstellen eines benutzerdefinierten Android Package (Malware für LAN-Verbindung)

Listing 3: Erstellen eines benutzerdefinierten Android Package (Malware für WAN-Verbindung)

Listing 4: Aufruf des Multi-Handler (Metasploit Framework)

Listing 5: Skript für eine entfernungsresistente Installation (InstallwithPermissions.sh)

Listing 6: Ausführen des Skripts für eine entfernungsresistente Installation (InstallwithPermissions.sh)

Listing 7: Skript für eine persistente Backdoor (persistentBackdoor.sh)

Listing 8: Ausführung des Skripts für eine persistente Backdoor (persistentBackdoor.sh)

Listing 9: Audioaufname

Listing 10: Schnappschuss der ausgewählten Kamera

Listing 11: Livestreaming

Listing 12: Ortung des Smartphones

Listing 13: Abgreifen von Kontaktdaten

Listing 14: Abgreifen von SMS

Listing 15: Versenden von SMS

Listing 16: Abgreifen von personenbezogenen Daten

Gliederung

Kapitel 1: Einleitung und Motivation

Im ersten Kapitel wird die Problemstellung beschrieben und die Motivation der vorliegenden Arbeit erläutert.

Kapitel 2: Grundlagen

Im zweiten Kapitel werden die Grundlagen dieser Arbeit präsentiert und erläutert. Dazu gehören allgemeine Basisinformationen zum Smartphone- Betriebssystem Android und dessen Architektur sowie Grundlagen zu Exploits und Exploit Kits.

Kapitel 3: Bedrohungsszenarien

Im dritten Kapitel werden drei Bedrohungsszenarien beschrieben und mittels Beispielen erläutert. In den zwei anschließenden Kapiteln wird auf eines der drei Szenarien ausführlich eingegangen.

Kapitel 4: Konzeptionierung einer Schadsoftware für Android OS

Im vierten Kapitel wird ein Konzept erstellt, um einen Angriff auf Softwareebene durchzuführen. Dieses umfasst die Verbreitungswege, die anschließende Rechteausweiterung, die Konfiguration und Infektion und die Ausführung von Malware-Funktionalitäten.

Kapitel 5: Erstellung und Implementierung einer Schadsoftware

Im fünften Kapitel wird das zuvor im vierten Kapitel erstellte Konzept umgesetzt und implementiert. Anschließend werden mögliche Malware-Funktionalitäten aufgezeigt.

Kapitel 6: Gegenmaßnahmen

Im sechsten Kapitel werden Gegenmaßnahmen erläutert, die den SmartphoneNutzer vor Angriffen auf sein Smartphone schützen.

Kapitel 7: Fazit

Im siebten Kapitel wird ein Blick auf den Trend geworfen und die gewonnenen Kenntnisse dieser Arbeit zusammengefasst.

Zusammenfassung

Der Trend ein Smartphone zu besitzen steigt stetig an, da man mit diesem nahezu dieselben Funktionen wie bei einem klassischen Desktop-PC oder Laptop hat und dazu noch mobiler ist. So gut wie jedes Smartphone ist mit dem World Wide Web verbunden und bietet auf diesem Weg Angriffsflächen für Angreifer, egal für welchen Zweck, um sich einen privaten oder wirtschaftlichen Vorteil zu schaffen oder auch Dritten Informationen mitzuteilen, die man ihnen zum Schutz der eigenen Privatsphäre nicht freiwillig preisgeben würde.

In Deutschland besitzen im Jahr 2016 60 Prozent der Bevölkerung ein Smartphone, das über die Funktion von Telefonie und Kurznachrichten hinausgeht.[1] So kann beispielsweise der Kontostand unterwegs geprüft werden und Überweisungen getätigt werden. Des Weiteren sind auf Smartphones Daten, die nicht für Dritte gedacht sind wie Dokumente, Bilder oder weitere sensible Daten.

Der Grundgedanke sollte daher sein, je mehr Funktionen ein Smartphone besitzt, umso sicherer sollte es vor Angriffen geschützt sein. Das Problem ist jedoch, dass eine 100-prozentige Sicherheit nie erreicht werden kann, da Schwachstellen erst durch einen Patch geschlossen werden können, sobald dieser bekannt ist. Ein großes Problem in der Sicherheit der Smartphones ist, dass die Benutzer nie wissen, während sie im World Wide Web surfen, ob sie gehackt wurden und zum Beispiel Teil eines Botnetz sind, das für weitere Angriffe genutzt wird. Denn von den meisten Angriffen bekommen die Opfer gar nichts oder erst zu einem späteren Zeitpunkt etwas mit.[2]

Am interessantesten ist für die Angreifer das Android-Betriebssystem, das sich weiterhin an großer und steigender Beliebtheit erfreut. So beträgt der Marktanteil mittlerweile mehr als 84,1 Prozent[3] weltweit und das ist auch der Hauptgrund für die Angreifer. Sie entwickeln Schadsoftware primär für das am Markt präsenteste. Dies ist vergleichbar mit Microsoft Windows, das mit großem Abstand Marktführer, im Bereich der PC-Betriebssysteme ist.

Um Schwachstellen eines Android-Systems auszunutzen, wird ein Exploit von Angreifern benutzt. Bei der Verwendung des Exploits werden Sicherheitslücken zunutze gemacht. Dieses Vorgehen ist mit einem Einbruch eines Diebes vergleichbar. Nachdem ein Exploit-Angriff erfolgreich war, werden vom Angreifer Payloads in das System implementiert, die böswillige Funktionalitäten für Hacker bieten.

1. Einleitung und Motivation

Der Besitz von Smartphones auf Basis der Android-Plattform nimmt konstant zu. Durch die große Nachfrage an Smartphones mit dem Android OS steigt zudem die Entwicklung von Schadsoftware durch Hacker rapide an.

Die Android-Sicherheitsarchitektur versucht die Nutzer so gut es geht dagegen zu schützen. Sie besitzt ein umfangreiches Konzept in Bezug auf die Sicherheit einzelner Apps. Dabei soll gewährleistet werden, dass keiner unberechtigten Zugriff auf Apps eines Smartphones erhält oder die Sicherheit des Betriebssystems infrage stellt. Dennoch treten immer wieder Lücken im Android-System auf, die durch kleine Programmschnipsel ausgenutzt werden können. Diese Programmschnipsel, zum Ausnutzen von Sicherheitslücken, nennen sich Exploits, mit denen sich diese Arbeit, speziell im Android-Bereich, befasst.

Im ersten Kapitel dieser Arbeit werden die Grundlagen von Exploits und des Android-Betriebssystems Android OS vermittelt.

In den darauffolgenden Kapiteln wird auf die Bedrohungsszenarien eingegangen, um anschließend anhand eines Szenariums, ein Exploit mit einer inkludierten Payload zu konzeptionieren und zu implementieren. Abschließend werden mögliche Gegenmaßnahmen vorgestellt, die den Smartphone-Nutzer bestmöglich vor Angriffen schützen können.

2. Grundlagen

2.1 Android OS

Das Unternehmen Android Inc. entwickelte 2003 in Palo Alto das AndroidSystem. Die Entwickler waren Andy Rubin, Rich Miner, Nick Sears und Chris White, die bis 2005 unter Eigenregie entwickelten, bevor sie es anschließend an die Goolge Inc. verkauften.[4]

Das im Jahr 2007 von Google vorgestellte und seit 23.11.2008 verfügbare Android ist aktuell weltweit das am häufigsten verbreitete SmartphoneBetriebssystem, mit einem Marktanteil von 84,1 Prozent, gefolgt von iOS, mit 14,8 Prozent. Damit ist es nicht nur in Deutschland Marktführer, mit einem Marktanteil von 79,8 Prozent, sondern weltweit. [5] [6]

Ein wesentlicher Grund für diesen Erfolg ist der freie Quellcode, sodass alle Smartphone-Hersteller diesen ohne Lizenzgebühren an die Hardware ihres Systems anpassen können sowie der günstigere Einstiegspreis für Kunden gegenüber Apple Smartphones. Unternehmen und deren CIOs ziehen allerdings das Apple iOS dem Google-Betriebssystem vor, da es in Sachen Sicherheit einen besseren Ruf hat.[7]

Abbildung in dieser eseprobe nicht enthalten

Abb. 1: Weltweiter Marktanteil der Betriebssysteme am Absatz von Smartphones im Jahr 2016 [8]

Android basiert zu Beginn auf dem Linux-Kernel 2.6 und wurde von der Google Inc. gegründeten Open Handset Alliance entwickelt, die 2008 neben Google, 33 weitere namhafte Mitglieder innehatte. Der Quellcode wird von Google unter der Open Source Lizenz freigegeben. Die aktuellste Version ist Nougat (7.0), die wie alle Versionen ab Version 1.5 (Cupcake) eine Süßigkeit als Namen haben und im Alphabet aufsteigend verteilt werden.[9] [10]

Android-Architektur

Die Android-Architektur, die auch Software Stack oder System Stack genannt wird, lässt sich in fünf Schichten aufteilen.[11]

Abbildung in dieser eseprobe nicht enthalten

Abb. 2: Architektur des Android-Betriebssystems [12]

Im untersten Teil liegt bis Android-Version 4.0 der Linux Kernel 2.6.x mit rund 115 Patches grundlegender Systemfunktionen wie Prozessmanagement, Speicherverwaltung und Geräteverwaltung bereit. Darüber hinaus kümmert sich der Kernel um die Netzwerk- und Peripherieschnittstellen mit einer Vielzahl von Gerättreibern. Seit Android 4.0 wird der Linux Kernel der Serie 3.x genutzt.

Über dem Linux Kernel liegen eine Reihe an Bibliotheken, einschließlich der Open Source Web Browser Maschine WebKit, die Bibliothek libc, die SQLite- Datenbank, die eine nützliche Quelle für die Speicherung und den Austausch von Anwendungsdaten ist, Bibliotheken zum Wiedergeben und Aufzeichnen von Audio und Video sowie die SSL Bibliothek, die für die Internet-Sicherheit verantwortlich ist.

Die Android Runtime ist der dritte Abschnitt der Architektur. Dieser Abschnitt enthält eine Schlüsselkomponente namens Dalvik Virtual Machine, die eine Art von Java Virtual Machine ist und speziell für Android optimiert wurde.

Die Dalvik VM nutzt Linux Kernfunktionen wie Speicherverwaltung und MultiThreading, die inhaltlich der Java-Sprache ähnlich sind. Die Dalvik VM ermöglicht jeder Android-Anwendung in einem eigenen Prozess ausgeführt zu werden, mit jeweils einer eigenen Instanz der Dalvik Virtual Machine.[13]

Die Android Runtime bietet eine Reihe von Kern-Bibliotheken, die AndroidAnwendungsentwicklern ermöglicht, Android-Anwendungen mit der Programmiersprache Java zu schreiben.

Die Application Framework Schicht bietet viele übergeordnete Dienstleistungen für Anwendungen in Form von Java-Klassen. Den App- Entwicklern ist die Nutzung dieser Dienste in ihren Anwendungen gestattet.

In der Application Schicht sind die bereits von Android entwickelten Applikationen enthalten, wie zum Beispiel Anwendungen, die für folgende Bereiche bereitgestellt werden: Browser, Kamera, Email, Bildergalerie, Kontakte, Musikplayer und weitere Grundfunktionen. User können diese Schicht durch die Installation von Apps aus dem Google Play Store ergänzen.

Der heutige Google Play Store, der anfangs noch Android Market hieß, ist das Gegenstück zum App Store von Apple. Er bietet unzählige Apps an. Die Android-Nutzer können sich Spiele, Apps, Filme, Musik, Bücher oder Zeitschriften herunterladen. Seit 2009 haben Entwickler zusätzlich die Möglichkeit kostenpflichtige Apps anzubieten.

Seit Februar 2011 ist es Smartphone-Nutzern ermöglicht worden, Apps aus der Ferne per Browser zu installieren. Eine weitere Entwicklung gab es Ende 2011 mit der Möglichkeit des Kaufens von Musik über den Android Market.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3: Entwicklung des Android Market (Google Play Store) [14]

Der Verlauf des Android Market brachte viel Kritik mit sich: Kritik an nicht durchdachten Bezahlmöglichkeiten, Probleme beim Download oder am verfehltem Design. An diesen und weiteren Problemen hat Google gearbeitet, woraus der Nachfolger Google Play Store entstand, der fehlerfreier und benutzerfreundlicher als sein Vorgänger ist.

Der wesentliche Unterschied zwischen dem Android- und Apple-Marktplatz für Apps, liegt in der Sicherheit. Denn auf Android ist es möglich auch Anwendungen von Drittanbietern zu installieren. So zerlegten und dekompilierten kriminelle Entwickler beispielsweise beliebte Anwendungen wie Angry Birds und veröffentlichten kostenlose schädliche Versionen davon.[15]

Updatepolitik und Verbreitung der Android Versionen

Die Liste der Android-Versionen ist mittlerweile sehr lang. Beginnend mit Version 1.0 aus dem Jahr 2008 ist heute, acht Jahre später, Version 7.0 Nougat die aktuellste. In diesem Zeitraum hat sich im Android-System viel getan, zum einen in der Funktionalität aber auch in der Sicherheit. So wurden von Version zu Version immer neue Lücken geschlossen und Fehler behoben, womit das System weniger angreifbar gemacht wurde. Allerdings sind Angreifer täglich dabei neue Lücken zu finden, die ausgenutzt werden können, bis diese durch Updates oder einen Patch geschlossen werden.

Ebenfalls zu den neuen Versionen ändert sich das API-Level je Hauptversion oder teilweise schon bei Nebenversionen. Mit dem API-Level 24 sind Entwickler heute auf dem aktuellsten Stand. Das API-Level spielt für sie eine wichtige Rolle. Je höher der Entwicklungsstand ist, desto mehr Funktionen sind implementiert und können genutzt werden. So kann es vorkommen, dass bei der Nutzung einer Funktion aus einem höheren API-Level, die Anwendung nicht auf dem Gerät installiert werden kann, das auf einem niedrigeren API-Level basiert.

Die Updatepolitik bei Smartphones mit Android OS ist für viele Smartphone- Besitzer nicht die erfreulichste, denn jeder Hersteller hat leichte Modifizierungen in der Benutzeroberfläche oder in der Umsetzung der Funktionen. Von daher werden nur Smartphones, die direkt vom Hause Google kommen auf dem neuesten Stand gehalten, solange dies von Hardwareseite möglich ist. Die anderen Hersteller ziehen nur bei neueren Geräten nach, was um einiges länger dauert als bei Google-Geräten, da die Modifizierungen noch angepasst werden müssen. Da damit Kosten anfallen, die die Hersteller tragen, werden Updates auf Kosten der Sicherheit nicht über den gesamten Lebenszyklus eines Smartphones bereitgestellt.[16] Anders sieht dies beim Apple- Betriebssystem iOS aus. Hier wird bis zum iPhone 4s die aktuelle Version 9.3.5 als Update angeboten.

Somit ist Android 4.4. alias KitKat, die am meistverbreitete Android-Version, obwohl bereits Android-Version 6.0 auf dem Markt ist und Version 7.0 vor kurzem released wurde.[17]

Abbildung in dieser eseprobe nicht enthalten

Abb. 4: Android-Verbreitung (August 2016) [18]

Allgemeine Schwachstellen und Gegenmaßnahmen

Eine hundertprozentige Sicherheit wird es im Android-Betriebssystem nie geben. Dies betrifft nicht nur das Google Android OS, sondern auch alle anderen Betriebssysteme auf dem Markt, egal ob im Mobil- oder Desktopbereich.

„Android ist das Pendant zu Windows im mobilen Bereich“ [19]

In den letzten Jahren wurde von Google der Play Store sicherer gemacht und die Wahrscheinlichkeit ist gesunken, sich durch die Installationen einer App aus dem Store mit einem Virus zu infizieren.

Allerdings werden Apps auch von Drittanbieter-Seiten gedownloadet und installiert. Über diesen Weg besteht eine große Gefahr, denn die Entwickler von Schadsoftware nutzen das Vertrauen der User aus. Die angebotenen Apps lassen sich fehlerfrei installieren und ausführen. Zusätzlich wird ein Schadcode auf dem Smartphone des Nutzers implementiert, der selbst durch das Raster von Antiviren-Lösungen fallen kann.[20]

Sobald einer App das Geräteadministrationsrecht eingeräumt wird, kann die App andere Apps nachinstallieren und diese ausführen. Ist dies der Fall, kann ein Hacker zum Beispiel das Gerät über einen Proxy für weitere böswillige Angriffe ausnutzen.

Allgemeine Gegenmaßnahmen zum Schutz von Angriffen sind:

Das Installieren von Drittanbieter-Seiten zu vermeiden und ausschließlich Apps aus dem Play Store zu verwenden.

Bei jeder zu installierenden App die App-Berechtigungen auf Notwendigkeit prüfen.

Automatischen Download von MMS ausschalten (Stagefright-Lücke) [21]

Die Nutzung von Wi-Fi-Verbindungen sollte nur bei Netzwerken genutzt werden, den vertraut werden kann.

Das Modifizieren der Original Android-Rom sollte vermieden werden, da dadurch gerooteten Smartphones Administrationsrechte gewährt werden können, die die Hacker nach einem Angriff erben.

Die Installation einer Antiviren-Lösung kann den User vor Malware schützen.

Des Weiteren sollte das Smartphone immer auf dem aktuellsten Stand sein und verfügbare Updates installiert haben, womit Fehler und Sicherheitslücken geschlossen werden.[22] [23]

2.2 Exploits

Exploits sind von Malware zu unterscheiden. So ist Malware der Oberbegriff von Programmen wie Viren, Würmern, Trojanern, Spyware, Ransomware o.ä., die dafür entwickelt werden, um auf einem System schädliche oder vom User unerwünschte Funktionen auszuführen.

Ein Exploit kann ebenfalls als Oberbegriff gesehen werden, da es hierbei ebenso verschiedene Arten gibt, die nachfolgend vorgestellt werden. Ein Exploit ist ein kleines Stück Programmcode oder Skript, das eine Schwachstelle im Computer, Smartphone oder einem anderen IT-System ausnutzt, die bei der Entwicklung von Programmierern nicht geschlossen wurde. Nachdem die Schwachstelle erfolgreich ausgenutzt wurde und der Angreifer die Kontrolle über das betreffende System verschafft hat, wird eine Payload heruntergeladen und das System wird mit Malware infiziert. Tagtäglich werden IT-Systeme angegriffen und anschließend für Botnetze oder andere kriminelle Zwecke ausgenutzt.

Abbildung in dieser eseprobe nicht enthalten

Abb. 5: Exploits - Ausnutzung von Sicherheitslücken [24]

Programme, die anfangs sicher erscheinen, können schon nach einiger Zeit Sicherheitslücken aufweisen, die vorher nicht identifiziert wurden. Die von Angreifern entdeckten Lücken im Quellcode werden in den meisten Fällen durch die Zuhilfenahme von Exploit Kits, die mehrere Exploits beinhalten, aufgedeckt. Zum Teil werden Sicherheitslücken auch durch Zufall entdeckt.

Häufig genutzte Ziele sind, neben den Betriebssystemen, Sicherheitslücken im Adobe Acrobat Reader, dem Adobe Flash Player, der Java Runtime Environment, Microsoft Silverlight und dem Internet Explorer, wobei sich die Sicherheitslücken im Microsoft-Bereich 2014 nach dem Major Security Bulletin erheblich verbesserten.[25]

Abb. 6: Kritische Schwachstellen der in der BSI-Schwachstellenampel erfassten Software- produkte [26]

Es besteht grundsätzlich die Gefahr, dass Angreifer die Sicherheitslücken vor den Herstellern finden und diese ausnutzen. In diesem Fall kann die Lücke so lange ausgenutzt werden, bis den Herstellern die Sicherheitslücken bekannt sind und ein Update oder Patch veröffentlicht wird, solange die Anwendung oder das IT-System einen von Hersteller- oder Entwicklerseite Support erhält. Sollte die Supportzeit wie beispielsweise bei Microsoft Windows XP beendet werden, so empfehlen die Hersteller ein Nachfolgeprodukt oder verweisen auf ähnliche Produkte.[27]

Sobald Sicherheitslücken in einem System entdeckt werden, werden diese mit einer fortlaufenden CVE Nummer beschrieben, damit ein reibungsloser Informationsaustauch stattfinden kann.

Common Vulnerabilities and Exposures (CVE), zu Deutsch, verbreitete Sicherheitsrisiken und Sicherheitslücken ist ein Industriestandard, dessen Ziel die Einführung einer einheitlichen Namenskonvention für Sicherheitslücken und andere Schwachstellen in Computersystemen ist. Die CVE-Namenskonvention besteht aus dem Kürzel CVE, dem Jahr des Bekanntwerdens der Sicherheits- lücke und einer eindeutigen fortlaufenden Nummer. Dadurch ist ein reibungsloser Informationsaustausch zwischen den verschiedenen Datenbanken einzelner Hersteller möglich.[28]

Die einzelnen CVE können detailliert und chronologisch eingesehen werden: http://cve.mitre.org/

- http://www.cvedetails.com/
- https://portal.cert.dfn.de/adv/archive/ https://nvd.nist.gov/
- https://vuldb.com/
- http://androidvulnerabilities.org/

Angriffsarten von Exploits

Exploits werden aus zwei verschiedenen Gründen genutzt. Zum einen um einen Proof of Concept-Exploit auszuführen. Das ist ein Angriff auf ein Computersystem, Smartphone oder Netzwerk, das nur aus dem Grund ausgeführt wird, um darzustellen, dass die Möglichkeit besteht Schwachstellen auszunutzen. Diese dienen ausschließlich zu Demonstrationszwecken.

Der zweite Grund, weshalb Exploits genutzt werden, ist es Anderen zu schaden, auszunutzen oder zu beklauen. Das hat Auswirkungen auf die Vertraulichkeit, Integrität und Verfügbarkeit. So gibt es drei Angriffsziele, auf die die Angreifer aus sind.

- Erlangen von Informationen (Stehlen von Bildern, Videos, Dokumenten oder anderen Daten)
- Erlangen von Privilegien oder vielmehr erweiterte Berechtigungen (Installieren von Malware)
- Erlangen von Ressourcen (Einbinden in ein Botnetz)

Hierbei wird unterschieden über welchen Weg und mit welchen Mitteln der Angriff ausgeführt wird.

Lokale Exploits

Lokale Exploits werden durch das Öffnen von unauffälligen Dateien wie Bild, PDF-, Word- oder Excel Dateien aktiv. Dabei wird auf die Anwendung abgezielt, mit der die Datei geöffnet wird. Für eine PDF-Datei bietet sich beispielsweise der Adobe Reader an, da dieser auf vielen Systemen installiert ist und als Marktführer gilt.[29] Durch eine fehlerhafte Programmierung des Adobe Reader entsteht eine Sicherheitslücke, die durch den Angreifer genutzt werden kann. Ziel ist es durch Ausnutzen der Sicherheitslücke, erweiterte Rechte mit administrativen Berechtigungen zu erhalten. Die anschließende Aktion, das Einschleusen von Schadcode, die der Exploit ausführt, wird als Payload bezeichnet. Man findet ihn sowohl separat konfiguriert als auch fest im Exploit verankert. Der Exploit und die Payload werden somit lokal auf dem System des Opfers ausgeführt.

Remote Exploits sind Exploits, die über das Internet oder Netzwerk das Zielsystem angreifen. Der Angreifer sendet mehrere Exploits an den Webserver, bis ein Exploit erfolgreich ist. Anschließend werden über den nun kontrollierten Serverprozess präparierte Datenströme zum Angriffsziel geschickt und eigene Programme auf dem Zielsystem installiert.

(Distributed) Denial of Service Exploit

Ziel eines Denial of Service Exploit, kurz DoS-Exploit, ist es in erster Linie ein System zu überlasten und lahmzulegen, anstatt es mit einem eigenen Programmcode zu füllen. DoS-Angriffe haben immer das gleiche Vorgehen. So wird das System mit so vielen Anfragen bombardiert, bis dieses überlastet ist und keine Rückmeldung mehr geben kann. In den meisten Fällen werden dafür Botnetze genutzt. Diese Botnetze sind mehrere Systeme von Nutzern, die nicht einmal wissen, dass sie Teil eines Botnetz sind.

„Die Vorgehensweise ist vergleichbar mit einer Bushaltestelle. Wenn sehr viele Menschen sich zur Bushaltestelle drängeln, ist der Platz irgendwann voll und es gibt für kaum einen Menschen eine Möglichkeit in den Bus einzusteigen.“[30]

Distributed Denial of Service Angriffe sind DoS-Angriffe von mehreren Angreifern gleichzeitig, wodurch die Angriffe eine höhere Bandbreite bieten. Zusätzlich ist es für die Opfer schwieriger einzelne IP Adressen der Angreifer zu sperren. Um DDoS-Angriffe ausführen zu können, werden mehrere Endgeräte benötigt, die ebenfalls über Botnetze gesteuert werden.[31]

Buffer Overflows werden am häufigsten als Angriffsmethoden genutzt, um Schadsoftware in Fremdsystemen unterzubringen. Buffer Overflow ist der Oberbegriff für verschiedene Formen von Schwachstellen, so ist die spezielle Bezeichnung der Overflows Heap-Overflow, Stack-Overflow, Integer-Overflow oder String-Overflow.

Hierbei ist die Funktion bei allen vier Formen die Gleiche und nur der Ort des Overflows ist verschieden. Das Ziel ist es, größere Datenmengen an ein Programm zu senden als vorgesehen und verarbeitet werden können. Da der vorgesehene Speicherbereich nicht für die Daten ausreicht, wird der Speicherbereich überschrieben. Dies führt in den meisten Fällen zum Absturz des Programms. Buffer Overflows werden durch unzureichende Kontrolle von Eingabevariablen durch Programmierer zu einer Schwachstelle in einer Software.

Der bloße Absturz des Systems führt noch zu keiner Gefahr für den Benutzer. Erst wenn über manipulierte Daten zusätzlicher Programmcode gestartet wird, besteht Gefahr für den Benutzer und sein System. Dies kann beispielsweise durch manipulierte Office-Dateien geschehen.

Abbildung in dieser eseprobe nicht enthalten

Abb. 7: Speicherinhalt und -aufteilung [32]

Bei jedem Programmstart weist das Betriebssystem dem Programm einen bestimmten Speicherbereich zu. Ein Teil davon ist der eigentliche Programmcode (Code Segment), der geschützt ist und nicht geändert werden kann. Direkt darüber liegt der Heap, hier werden die globalen Variablen, Strings und Konstanten gespeichert. Über dem Heap liegt der Stack mit den lokalen Variablen, Parametern und den Rücksprungadressen von Unterprogrammen. Nach dem Overflow von beispielsweise lokalen Variablen kann im Stack die Rücksprungadresse überschrieben werden. Bei einer ungültigen Rücksprungadresse kommt es zum Programmabsturz. Hacker nutzen die Rücksprungadresse dazu, das Programm auf Programmsegmente mit einem Schadcode zu lenken.[33]

Backdoor

Backdoor ist eine Methode, die oft geheim und mit unberechtigtem Zugriff auf ein System zugreift. Dies ist machbar indem die Sicherheitsmechanismen umgangen werden und zwar durch eine Backdoor.

Häufig werden Backdoors mit Absicht von Herstellern in ein System oder eine Anwendung eingebaut, um Zugang zum System oder einer sonst geschützten Funktion einer Anwendung zu bekommen. Zum Beispiel Standard- oder Universalpasswörter, die im BIOS oder in Systemkonsolen genutzt werden.

Backdoors werden ebenfalls von Hackern genutzt. Meist wird nach erfolgreichem Hacken eines Systems eine Hintertür oder Rootkit installiert, die genutzt wird, um auf ein System ohne erneutes Hacken zuzugreifen.

Drive-by Exploits sind Exploits, die nicht aktiv vom Angreifer ausgeführt werden, sondern direkt vom Opfer des Angriffs selber. Denn durch den Download eines präparierten Programms, Besuch einer Webseite oder den bloßen Klick auf ein Popup-Fenster, werden die Sicherheitslücken auf dem PC oder Smartphone automatisiert ausgenutzt, um anschließend Schadsoftware zu installieren.

Nach einer Auswertung von Google lag der Anteil von Webseiten mit Drive-by- Exploits oder die darauf verweisen, deutschlandweit zwischen ein und zwei Prozent.[34]

Angreifer verwenden verschiedene Techniken, um den Schadcode zu verschleiern, sodass eine Antivirus-Lösung nicht in der Lage ist diesen zu erkennen.

Abbildung in dieser eseprobe nicht enthalten

Abb. 8: Die zehn führenden Kategorien von Schad-Webseiten[35]

Cross-Site Scripting (XSS)

Beim Cross-Site Scripting (XSS) werden Sicherheitslücken in Webanwendungen ausgenutzt. Dabei infizieren Angreifer Webseiten mit clientseitigen Skripten, die von Besuchern dieser Webseite aufgerufen werden.

Aufgrund des Defizits im Cross-Site Scripting hat der Angreifer die Möglichkeit an Daten zu gelangen, die zwischen dem User und der infizierten Website hin und her gesendet werden. Der versteckte Code auf dieser Website kann beispielsweise ein Formular anzeigen lassen, dass den User dazu verleitet seine Zugangsdaten oder andere persönliche Daten einzugeben.

Hackern ist es möglich den User durch das injizierte Skript auf eine von ihm kontrollierte Seite zu führen, die der manipulierten Webseite sehr ähnelt, um den User nicht zu verunsichern.

Sobald eine Webanwendung Daten entgegennimmt, diese allerdings nicht vor dem Weitersenden prüft, kann Cross-Site Scripting auftreten. Das ermöglicht dem Angreifer Skripte an das Opfer zusenden und so Schadcode auf dem Client ausführen.

Dabei wird häufig die Übertragung von Parametern an ein serverseitiges Skript manipuliert, das für eine energiegeladene Webseite sorgt, wie zum Beispiel das Eigenformular einer Internetseite von Webshops, Blogs und Foren. Sobald die Seite von dem User aufgerufen wird, werden die eingegebenen Daten der Webseite erneut als Seiteninhalt ausgegeben.

Solange dies zugelassen wird, können Angreifer über diesem Weg manipulierte Daten an die Opfer senden. In den meisten Fällen geschieht das über JavaScript.[36]

HTML-Injection-Exploit

HTML-Injektion ist ein Angriff, der eng mit Cross-Site Scripting (XSS) verwandt ist. Der Unterschied liegt nicht in der Verwundbarkeit, sondern in der Art des Angriffs. Während XSS Script-Tags verwendet, um JavaScript auszuführen, wird bei einer HTML-Injektion eine HTML-Seite für böswillige Gründe verändert.

Cross-Site-Request-Forgery

Cross-Site-Request-Forgery (XSRF oder CSRF) tritt meistens in Kombination mit Cross Site Scripting auf. Hierbei greift ein Hacker auf ein System zu und löst eine Transaktion in einer Webanwendung aus. Um dieses Verfahren durchzuführen, bedient sich der Angreifer an bereits angemeldeten Usern. Diese User bemerken den Angriff nicht, da ihnen ein http-Request angezeigt wird, der eine geschützte Webseite vorweist.[37]

SQL-Injection-Exploit

Ein SQL-Injection-Exploit bezieht sich auf einen Einschleuse-Angriff, bei dem ein Angreifer bösartige SQL-Anweisungen ausführt, die Datenbankserver einer Webanwendung steuern. SQL-Injection-Schwachstellen können auf jeder Website oder Webanwendung Auswirkungen haben, die eine SQL-basierte Datenbank verwendet. SQL-Injections sind die am weitesten verbreiteten und gefährlichsten Schwachstellen in Webanwendungen.

Durch die Nutzung einer SQL-Injection-Schwachstelle, kann ein Angreifer dies verwenden, um Authentifizierungs- und Autorisierungsmechanismen einer Webanwendung zu umgehen und den Inhalt einer gesamten Datenbank abzurufen. SQL-Injection können auch verwendet werden, um Datensätze in einer Datenbank hinzufügen, zu ändern, zu löschen und die Datenintegrität zu gefährden. In so einem Fall können SQL-Injection einem Angreifer unberechtigten Zugriff auf sensible Daten wie Kundendaten, persönliche Daten und weitere sensible Informationen, gewähren.

Damit SQL-Abfragen in einem Datenbank-Server ausgeführt werden können, wird vom Angreifer zuerst ein Eingang in der Webanwendung gefunden, der in einer SQL-Abfrage enthalten ist.

Um anschließend einen SQL-Injection-Angriff stattfinden zulassen, muss die gefährdete Website SQL-Anweisungen in einer Benutzereingabe bereitstellen. Der Angreifer kann dort anschließend die Payload integrieren, die als Teil der SQL-Abfrage im Datenbankserver ausgeführt wird.[38] [39] [40]

Command-Execution-Exploit

Für Command-Execution-Exploits muss es dem Angreifer gelingen, seinen eigenen Programmcode in das System einzuschleusen. Damit dieses Exploit erfolgreich genutzt werden kann, benötigt der Angreifer die Informationen über die Aufteilung des Speichers. Diese erhält der Angreifer entweder über einen öffentlich zugänglichen Quellcode der Software oder aber durch das bloße ausprobieren. Der Schadcode muss nun exakt platziert werden, damit dieser ausgeführt werden kann. Gefährlich wird es für die Opfer des Angriffes, wenn die Software, die angegriffen wird im Besitz von administrativen Rechten ist. Denn diese erbt der Schadcode in diesem Fall ebenfalls.[41]

Zero-Day-Exploit

Zero-Day-Exploits sind Exploits, die nach Veröffentlichung der Schwachstelle (Zero-Day) bis zur Installation eines Patches ausgenutzt werden. Von daher bleibt nur sehr wenig Zeit, um Gegenmaßnahmen einzuleiten. Da auch mehrere Schwachstellen gleichzeitig bekannt werden können, muss in kurzer Zeit eine Priorisierung vorgenommen werden, um zu bestimmen welche Sicherheitslücke zuerst geschlossen werden muss, um einen möglichst geringen Schaden zu erhalten. Für die Angreifer ist es von hoher Priorität, dass die Schwachstellen solange wie möglich geheim gehalten werden.[42]

Zero-Day-Exploits werden nicht ausschließlich für Angriffe genutzt. Sie dienen darüber hinaus den Angreifern als Möglichkeit von den Herstellern Geld zu verlangen, bevor sie ihnen die Schwachstelle aufzeigen. Auf der anderen Seite werden ebenfalls hohe Summen bereitgestellt, um diese geheim zu halten. Dies geschieht durch den Kauf von anderen Hackern oder Institutionen, um die Lücke weiter nutzen zu können.

Aber auch Softwarehersteller sind nach Release der Software auf der Suche nach Sicherheitslücken. Zusätzlich wird teilweise eine Belohnung ausgesetzt, falls eine Sicherheitslücke gefunden und diese dem Hersteller gemeldet wird. Dafür erstellen Unternehmen ganze Programme, wie zum Beispiel das Vulnerability Reward Programm (VRP)[43] von Google oder speziell für Android das Android Reward Program.[44]

Den Endanwendern wird eine Sicherheitslücke meist erst nach Veröffentlichung der Hersteller bekannt. Hersteller zögern mit der Bekanntgabe oft so lange, bis ein Patch entwickelt wurde oder bereits vorhanden ist. Da die Sicherheitslücke also schon vor der Bekanntmachung existierte, sollte ein Patch oder Update so schnell wie möglich installiert werden.

Abbildung in dieser eseprobe nicht enthalten

Abb. 9: Von der Veröffentlichung des Produkts über die Sicherheitslücke bis zur Problemlösung[45]

Für die Bewertung des Schweregrads einer Sicherheitslücke wurde 2005 ein Standard namens Common Vulnerability Scoring System, kurz CVSS entwickelt.[46]

Zu jedem CVE wird ein Exploitpreis definiert, einer zum Zero-Day, der Tag an dem die Sicherheitslücke entdeckt wurde und einen zum aktuellen Datum. Der Exploitpreis ist der Preis, für den die Interessengruppen wie Softwarehersteller Nachrichtendienst oder Kriminelle bereit sind zu bezahlen, um die Lücke schließen zu können oder für den Eigengebrauch zu nutzen.[47]

Die folgende Grafik verdeutlicht den aktuellen Stand von Exploits im Google Android OS. So sind aktuell circa 520 Exploits im Umlauf, die für das AndroidBetriebssystem gefährlich werden können. Im Jahr 2016 sind alleine 346 neue Exploits dazugekommen.

Abbildung in dieser eseprobe nicht enthalten

Abb. 10: Android-Schwachstellen pro Jahr bis August 2016 [48]

[...]


[1] Vgl. Bundesministerium für Verkehr und digitale Infrastruktur (BMVI): Anzahl der Smartphone-Nutzer in Deutschland in den Jahren 2009 bis 2015 (in Millionen). URL:

https://www.forschungsinformationssystem.de/servlet/is/450435/ (abgerufen am 06.09.2016)

[2] Vgl. Mosemann, Heiko/ Kose, Matthias, Android: Anwendungen für das Handy-Betriebssystem erfolgreich programmieren, Carl Hanser Verlag, München, 2009, S. XII

[3] Gartner Inc.: Gartner Says Worldwide Smartphone Sales Grew 3.9 Percent in First Quarter of 2016, 19.05.2016, URL: http://www.gartner.com/newsroom/id/3323017 (abgerufen am 06.09.2016)

[4] Vgl. Erdle, Frank/ WEKA MEDIA PUBLISHING GmbH: Android: Die Geschichte des Erfolgs, 02.04.2013, URL: http://www.connect.de/ratgeber/android-geschichte-des-erfolgs-1491130.html (abgerufen am 06.06.2016)

[5] Gartner Inc.: Gartner Says Worldwide Smartphone Sales Grew 3.9 Percent in First Quarter of 2016, 19.05.2016, URL: http://www.gartner.com/newsroom/id/3323017 (abgerufen am 06.09.2016)

[6] Kantar Worldpanel: Smartphone OS sales market share, 03.07.2016, URL: http://www.kantarworldpanel.com/global/smartphone-os-market-share/ (abgerufen am 06.09.2016)

[7] Vgl. Borbe, Andre/ NetMediaEurope Deutschland GmbH: CIOs bevorzugen iOS-Geräte, 07.01.2015, URL: http://www.silicon.de/41607476/cios-bevorzugen-ios-geraete (abgerufen am 02.07.2016)

[8] Gartner Inc.: Gartner Says Worldwide Smartphone Sales Grew 3.9 Percent in First Quarter of 2016, 19.05.2016, URL: http://www.gartner.com/newsroom/id/3323017 (abgerufen am 06.09.2016)

[9] Vgl. Google Inc.: Codenames, Tags, and Build Numbers, URL: http://source.android.com/source/build- numbers.html (abgerufen am 22.08.2016)

[10] Vgl. Erdle, Frank/ WEKA MEDIA PUBLISHING GmbH: Android: Die Geschichte des Erfolgs, 02.04.2013, URL: http://www.connect.de/ratgeber/android-geschichte-des-erfolgs-1491130.html (abgerufen am 14.07.2016)

[11] Vgl. Mosemann, Heiko/ Kose, Matthias, Android: Anwendungen für das Handy-Betriebssystem erfolgreich programmieren, Carl Hanser Verlag, München, 2009, S. 5ff

[12] Google Inc.: Android Interfaces and Architecture, URL: https://source.android.com/devices/ (abgerufen am 05.06.2016)

[13] Vgl. U.Nicola, Carlo/ IMVS Fokus Report 2009.: Einblick in die Dalvik Virtual Machine, URL: http://www.fhnw.ch/technik/imvs/publikationen/artikel-2009/einblick-in-die-dalvik-virtual-machine (abgerufen am 16.07.2016)

[14] Pochanke, Steffen/ STRÖER Media Brands AG: Play Store/Android-Market: Der Store im Lauf der Zeit, 24.04.2013, URL: http://www.giga.de/apps/android-market/news/play-storeandroid-market-der-store- im-lauf-der-zeit/ (abgerufen am 12.07.2016)

[15] Vgl. Roehlinger, Fabien/ Fonpit AG: Android Malware als Angry Birds getarnt und über den Android Market verteilt, 15.06.2011, URL: https://www.androidpit.de/Android-Malware-als-Angry-Birds-getarnt- und-ueber-den-Android-Market-verteilt (abgerufen am 22.01.2016)

[16] Peter Marwan/ NetMediaEurope Deutschland GmbH: Verbraucherschützer wollen durch Klage bessere Update-Politik erzwingen, 21.01.2016, URL: http://www.itespresso.de/2016/01/21/android- verbraucherschuetzer-wollen-durch-klage-bessere-update-politik-erzwingen/ (abgerufen am 09.05.2016)

[17] Vgl. Költzsch, Tobias/ Golem Media GmbH.: ANDROID-VERBREITUNG, URL: http://www.golem.de/news/android-verbreitung-marshmallow-verteilung-verdoppelt-sich-1603- 119645.html (abgerufen am 09.01.2016)

[18] Google Inc.: Dashboards - Platform Versions, URL:
http://developer.android.com/about/dashboards/index.html (abgerufen am 08.08.2016)

[19] Herrmann, Eric/ Fonpit AG: Die harte Realität: Darum wird Android nie sicher sein, 08.2015, URL: https://www.androidpit.de/android-als-zielscheibe-mobiler-malware (abgerufen am 15.02.2016)

[20] Vgl. Chris McCormack/ Sophos GmbH: Die fünf Phasen eines Web-Malware-Angriffs, URL: http://www.myitplace.de/Wissen/fuenf-phasen.pdf (abgerufen am 24.03.2016)

[21] Vgl. Fischl, Gabriele/ WEKA MEDIA PUBLISHING GmbH: Stagefright - so schützen Sie Ihr Android- Smartphone, 30.07.2015, URL: http://www.connect.de/ratgeber/mms-download-deaktivieren-android- stagefright-schutz-3191709.html (abgerufen am 06.09.2016)

[22] Vgl. Fuest, Benedikt/ WeltN24 GmbH: Diese Schadsoftware zerstört ihr Android-Smartphone, 08.11.2015, URL: http://www.welt.de/wirtschaft/webwelt/article148591985/Diese-Schadsoftware- zerstoert-ihr-Android-Smartphone.html (abgerufen am 14.02.2016)

[23] Vgl. Trend Micro Incorporated: 5 einfache Schritte zum Schutz Ihrer Android-basierten Smartphones, URL: http://www.trendmicro.de/media/misc/secure-your-android-based-smartphones-de.pdf (abgerufen am 15.02.2016)

[24] Ay, Cengiz: Exploits: Ausnutzung von Sicherheitslücken, URL: http://www.edv- lehrgang.de/exploits/malware (abgerufen am 14.02.2016)

[25] Vgl. Microsoft Corporation: Microsoft Security Bulletin Summary for November 2014, 11.11.2015, URL: https://technet.microsoft.com/en-us/library/security/ms14-nov.aspx (abgerufen am 14.02.2016)

[26] Bundesamt für Sicherheit in der Informationstechnik: Die Lage der IT-Sicherheit in Deutschland, S.10, URL: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Lageberichte/Lagebericht2015 .pdf;jsessionid=BB13990DCD5C9E432F73F7B5A5E6F0B6.2_cid294?__blob=publicationFile&v=4 (abgerufen am 14.02.2016)

[27] Vgl. Microsoft Corporation: Der Windows XP-Support wurde beendet, URL: http://windows.microsoft.com/de-de/windows/end-support-help (abgerufen am 15.02.2016)

[28] Vgl. The MITRE Corporation: About CVE, URL: https://cve.mitre.org/about/ (abgerufen am
15.02.2016)

[29] Vgl. Adobe Systems: Security Advisory for Adobe Reader and Acrobat, 06.12.2011, URL: http://www.adobe.com/support/security/advisories/apsa11-04.html

[30] Ay, Cengiz: Exploits: Ausnutzung von Sicherheitslücken, URL: http://www.edv- lehrgang.de/exploits/malware (abgerufen am 14.02.2016)

[31] Vgl. Ruef, Marc: Die Kunst des Penetration Testing, Computer & Literatur Verlag, Böblingen, 1.Auflage, 2007, S. 557ff

[32] Strobel, Stefan: Buffer Overflow - leichter als gedacht, URL: http://2014.kes.info/archiv/online/01- 05-6-overflow.htm (abgerufen am 23.02.2016)

[33] Vgl. Klein, Tobias: Aus dem Tagebuch eines Bughunters, dpunkt.verlag, Heidelberg, 1. Auflage, 2010, S. 169ff

[34] Vgl. Bundesamt für Sicherheit in der Informationstechnik: Die Lage der IT-Sicherheit in Deutschland 2014, S.17, URL: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Lageberichte/Lagebericht2014 .pdf?__blob=publicationFile&v=1 (abgerufen am 14.02.2016)

[35] Chris McCormack/ Sophos GmbH: Die fünf Phasen eines Web-Malware-Angriffs, URL: http://www.myitplace.de/Wissen/fuenf-phasen.pdf (abgerufen am 24.03.2016)

[36] Vgl. Ruef, Marc: Die Kunst des Penetration Testing, Computer & Literatur Verlag, Böblingen, 1.Auflage, 2007, S. 773ff

[37] Vgl. Ruef, Marc: Die Kunst des Penetration Testing, Computer & Literatur Verlag, Böblingen, 1.Auflage, 2007, S. 800ff

[38] Vgl. Ruef, Marc: Die Kunst des Penetration Testing, Computer & Literatur Verlag, Böblingen, 1.Auflage, 2007, S. 810ff

[39] Vgl. Anthony, Sebastian/ ExtremeTech: How the PlayStation Network was Hacked, 27.04.2011, URL: http://www.extremetech.com/gaming/84218-how-the-playstation-network-was-hacked/ (abgerufen am 16.06.2016)

[40] Vgl. The Code Curmudgeon: SQL INJECTION HALL OF SHAME, URL: http://codecurmudgeon.com/wp/sql-injection-hall-of-shame/ (abgerufen am 16.06.2016)

[41] Vgl. Ruef, Marc: Die Kunst des Penetration Testing, Computer & Literatur Verlag, Böblingen, 1.Auflage, 2007, S.759ff

[42] Vgl. Charlie Miller, PhD, CISSP Independent Security Evaluators: The Legitimate Vulnerability Market Inside the Secretive World of 0-day Exploit Sales, 06.05.2007, URL: http://www.econinfosec.org/archive/weis2007/papers/29.pdf (abgerufen am 04.03.2016)

[43] Vgl. Google Inc.: Google Vulnerability Reward Program (VRP) Rules, URL

https://www.google.com/about/appsecurity/reward-program/index.html (abgerufen am 05.03.2016)

[44] Vgl. Google Inc.: Android Security Rewards Program Rules, URL: https://www.google.com/about/appsecurity/android-rewards/index.html (abgerufen am 05.03.2016)

[45] Eigene Darstellung

[46] Vgl. FIRST.org, Inc.: Common Vulnerability Scoring System, V3 Development Update, 06.05.2007, URL: https://www.first.org/cvss (abgerufen am 12.03.2016)

[47] Vgl. Dressler, Nadine Juliana/ WinFuture.de: Hackerpreisliste: so viel zahlen NSA und Co für iOS-Zero- Day Exploit, 19.11.2015, URL: http://winfuture.de/news,89912.html (abgerufen am 16.03.2016)

[48] The MITRE Corporation: Google Android Vulnerability Statistics, URL: http://www.cvedetails.com/product/19997/Google-Android.html?vendor_id=1224 (abgerufen am 22.08.2016)

Details

Seiten
120
Jahr
2016
ISBN (eBook)
9783668455313
ISBN (Buch)
9783668455320
Dateigröße
2.1 MB
Sprache
Deutsch
Katalognummer
v366615
Institution / Hochschule
Fachhochschule Dortmund
Note
1,3
Schlagworte
Exploit Exploit Kit IT IT-Security Angriffe Android OS Android Google OS

Autor

Teilen

Zurück

Titel: Exploits und Exploit Kits für Angriffe auf Android OS