Security for Systems Engineering 2016 - VoWi · • Christmans Tree Paket (Flags) ... OS Detection, Vulnerability Scan nmap! • Scanning ist oft auffällig, daher Slow Scan oder

Franz Wilding | 23. Juni 2016

Security For Systems Engineering

Zusammenfassung Sommersemester 2016

SECURITY FOR SYSTEMS ENGINEERING | 2016 "1

Inhaltsverzeichnis

Inhaltsverzeichnis 2

Sichere Programmierung 3

Netzwerksicherheit 7

Web Application Sicherheit 12

Risikomanagement und IT-Grundschutz 15

Mobile Security 18

Intrusion Detection und Intrusion Prevention Systeme 21

Security und Usability 24


Sichere Programmierung Unsichere Software wegen • Inhaltliche Fehler durch Komplexität, Zeitdruck, PM-/Kommunikationsfehler, zu kleine

Testabdeckung

• Programmierfehler (Eingaben / Ausgaben Validierung, Hardcoding von sensiblen Informationen, …)

• Designschwäche in der Applikation / im Datenmodel

• Falsche Annahme im Bezug auf Sicherheit

Eingabe / Ausgabe Validierung • Ziel: Überprüfen von: Format, Datentyp, Wertebereich, Schadinformationen

• Zwei Möglichkeiten:

• Filtern: Blacklist / Whitelist Filter (Whitelisting ist besser)

• Sanieren: Escapen von Sonderzeichen (Datenintegrität darf nicht verloren gehen)

• Zeitpunkte:

• Client: Wegen Performance und Usability, kann aber umgangen werden!

• Server: Erfordert Systemresourcen, sicherheitstechnisch muss es aber am Server passieren

• Beispiele:

• Keine Validierung bei Logfiles: Input wird 1:1 in Logfiles geschrieben

• Best Practice:

• Verwendung von sicheren Funktionen und existierenden Frameworks / Bibliotheken

• Verwendung von statischen Codeanalyse-Tools (können unsichere Funktionen finden) (FindBugs, Checkstyle, SonarJ, …)

Exception Handling • Abarbeitung von nicht vorhergesehenen Softwareverhaltens

• Keine sensiblen Informationen preisgeben, wenn Exception auftritt!

• Nach der Exception-Behandlung muss System wieder in sicherem Status sein

• throw early & catch late

Logging


• Prinzipiell soll alles geloggt werden

• Best Practice:

• Verwendung von Logging-Frameworks

• Einheitlicher Aufbau von Log-Files (Bsp: Länge eines Eintrages)

• Mögliche Probleme & Lösungen:

• Was wird alles geloggt (Sensible Informationen, …)

• => Kein Hardcoding von sensiblen Informationen

• => Keine Speicherung von sensiblen Daten, wenn nicht mehr benötigt

• => Sensible Daten nur verschlüsselt/gehashed speichern

• => Sicheres Entfernen von solchen Daten von HDD und RAM

• Wo liegen die Logdateien

• Größe von Logdateien

• IDS & IPS

• Nichtabstreitbarkeit (Logfile lässt wenig Spielraum übrig, wer Schuld an einer Aktion ist)

Risiken bei Vererbung • Subklassen überschreiben Code der Superklassen

• => Relevante Methoden als final deklarieren

• => Privater Konstruktor für rein statische Klassen

• Superklassen können Subklassen beeinflussen

Programmauslieferung • Angriffe:

• Vertraulichkeit (Code Analyse, Informationen sammeln)

• Integrität (Code manipulieren, Schadcode einfügen, Konfiguration ändern)

• Authentizität (Manipulierten Code unter falschem Namen verteilen)

Code Obfuscation • Lesbarkeit des Codes und Aufwand des Dekompilierens wird erschwert

• Relativ guter Schutz gegen Reverse Engineering

• Einfach anzuwenden

• Für Bibliotheken und Frameworks (und allgemein Open Source) nur sehr beschränkt einsetzbar


• Sicherheit dadurch nicht garantiert!

• Layout Obfuscation

• Umbenennen von Variablen/Methoden/Klassen

• Löschen von Debug-Informationen

• Erschwert Lesbarkeit des Codes, aber Programmlogik bleibt erhalten

• Control Obfuscation

• Program-Control-Fluss wird geändert (z.B.: Neue ungültige Code-Abschnitte)

• Ändern des Programmablaufes

• Aber: Programm wird größer und langsamer und es können Fehler eingebaut werden

• Data Obfuscation

• Änderung der Vererbungsbeziehung

• Array-Restrukturierung

• Aufspalten der Variablen

• String-Manipulation

• Schwert die Nachvollziehbarkeit des Codes sehr stark

• Aber: Programm wird größer und langsamer

Code Encryption • Code von Manipulation schützen

• Dekompilieren nicht möglich

• Aber: Keine Garantie, dass der Code sicher ist & Geschwindigkeitsverlust beim Programmstart

• => Kaum eingesetzt

• Angriffe:

• Binärcode manipulieren (Ausnutzen externer VM, Schadprogramm übernimmt Interpretation des Codes)

• Quellcode manipulieren (Einfügen von Objekten, die dann Schadcode nachladen)

Code Signing • Integrität der Applikation

• Verhindern von Manipulation (Ist schnell und einfach zu entdecken)

• Eigentümer der Applikation festlegen

• Authentizität der Applikation wird sichergestellt


• Keine Garantie für guten Code

• Kein Schutz vor Dekompilierung und Modifikation des Benutzers

• => Gängige Praxis!

• Rechte Management (Bsp.: Java-Applets dürfen auf Filesystem zugreifen)

Encrypted Configuration • Angriffe:

• Informationen sammeln

• Konfigurationen manipulieren

• Beispiel: ASP.NET XML Konfiguration (Schlüssel wird bei Provider hinterlegt)

• Erschwert Manipulation der Konfiguration

• Aber: Wartung der Konfiguration wird aufwändiger & Kein Schutz vor Debugging

• Probleme: Wo wird der Schlüssel aufbewahrt?


http://asp.net

Netzwerksicherheit ICMP

• Header:

• Typen:

• 0 Echo Reply

• 3 Destination Unreachable

• 5 Redirect

• 8 Echo

• Angriffe:

• ICMP echo request / echo reply (Smurf-Attacke)

• Inverse Mapping

• Destination Unreachable, TTL Exceeded

• Route Redirect

• lt. Spezifikation zu große Pakete (Ping of Death)

• ICMP Flood


IP • Header:

• Logische Netzwerkadressen

• unzuverlässig, verbindungslos

• Angriffe:

• Ping o’ Death (Zusammengesetztes IP-Paket zu groß)

• Fragment Overlap Attack („Teardrop“):

• Tiny Fragment Attack (IP-Pakete werden fragmentiert versendet):

• IPv6:

• 128 Bit lang (340 Sextillionen Adressen)

• DHCPv6, ICMPv6, …

• IPv6 Multicast statt Broadcast


• Autoconfig von Hosts mit IP-Adressen

• Erweiterbarer IPv6-Header

• Kommt langsam

• Koexistenz von IPv4 und IPv6 Netzwerken möglich

• IPSec Unterstützung verpflichtend, aber nicht der Gebrauch

• DoS weiterhin möglich

• Es werden sicher in der Zukunft neue Angriffe kommen

DHCP • Vergibt IP Adressen im Netzwerk

• Angriffe:

• Race Condition

• Wurm mit eingebautem DHCP-Server

DNS • Probleme:

• Mitlesen / Verändern von DNS-Requests / Replies + erratbare ID eines DNS Requests

• Name Chaining, DoS, …

UDP • Header:

• Angriffe:

• Denial of Service (DoS) & Distributed Denial of Service (DDoS)

• UDP Packet Storm (chargen / echo) auch auf Broadcast Adresse möglich, da es bei UDP keinen Verbindungsaufbau gibt

• UDP Flood Attack


• NTP Amplification Attacks

• UDP-based Amplification Attacks

TCP • Header:

• Angriffe:

• Low-Rate DoS

• ACK senden bevor Daten empfangen wurden

• TCP Session Poisoning

• Christmans Tree Paket (Flags)

• TCP Sequence Number Prediction

• TCP Session Hijack

Netzwerkanalyse um Angriff vorzubereiten • Für verschiedene Angriffe unterschiedlich!

• Auf konkretes System: Host Scan, Port Scan, OS Detection, Vulnerability Scan nmap!

• Scanning ist oft auffällig, daher Slow Scan oder Stealth Scan oder Ablenkung


Physische und Logische Separation von Netzwerkteilen • Physischer getrennt: Aufbau mit: Hubs, Switches, völlig getrennte Netzwerke (Bsp.:

Produktion / Development)

• Logisch getrennt: Unterschiedliche IP-Adressbereiche, VLAN, Firewalls

• Zonen: Trennung des Netzwerkes in Zonen, je nach Schutzbedarf. Beispiel: Webserver vs. interner Fileserver, DeMilitarized Zone (DMZ)

• Firewalls:

• Ziel: Unterbindung von unerlaubtem Zugriff

• Arten: Paketfilter, Stateful Inspection, Proxy Firewall

• Wird an Grenzen zwischen bei Zonen aufgestellt (Bsp.: DMZ)

• Nutzung:

• Filtern des Traffics (ingress, egress)

• Fail Safe (Default Deny)

• Logging

• Angriffe auf Firewalls:

• HTTP Tunnel

• DNS

• Firewall ist auch nur Software -> Kann angegriffen werden


Web Application Sicherheit Komponenten einer modernen Web-Applikation

• Webserver

• Statische Web-Server: zeigen nur statische Inhalte an, ursprüngliche Idee von WWW

• Dynamische Web-Server: zeigen statische und dynamische Inhalte an

• Reverse-Proxy: Für mehrere Web-Server. Liegt zwischen Client und Server

• Beispiel: nginx, Apache HTTP Server, Apache Tomcat, Microsoft IIS

• URL (Uniform Resource Locator)

• HTTP

• HTML / CSS / JS

• Bilder, Videos, XML, …

• Browser (Chrome, Safari, …)

• Plugins

HTTP Request Header • GET / HTTP/1.1

• Host: security.inso.tuwien.ac.at

• User−Agent: Mozilla/5.0 (X11; Linux i686; rv:28.0)\

• Gecko/20100101 SeaMonkey/2.25

• Accept: text/html,application/xhtml+xml,\ a p p l i c a t i o n /xml ; q =0.9 ,∗/∗; q=0.8

• Accept−Language: en−us ,en;q=0.7,de;q=0.3

• Accept−Encoding: gzip , deflate DNT : 1

• Connection : keep−alive

HTTP Response Header • HTTP/1.1 200 OK

Date: Thu, 03 Apr 2014 16:30:17 GMT

• Server : Apache

• Last−Modified: Thu, 03 Apr 2014 06:19:05 GMT ETag: ”f−13df−4f61d60c74840”

• Accept−Ranges : bytes

• Content−Encoding : gzip


http://security.inso.tuwien.ac.at

• Content−Length : 2033

• Keep−Alive : timeout=5, max=100

• Connection : Keep−Alive

• Content−Type: text/html

HTTP-Request Methoden • GET: Parameter werden in URL angegeben

• POST: Parameter werden im HTTP-Payload übergeben

• PUT: Datenupload am Server (Semantisch: update)

• DELETE: Löschen von Server-Resourcen

• OPTIONS: Abfrage der erlaubten HTTP-Methoden

• HEAD: Gibt nur HTTP-Header zurück

• => Best Practice: Nicht verwendete HTTP-Methoden abschalten

HTTP-Basic-Authentifizierung • Benutzername und Passwort wird mit „:“ getrennt als String übertragen

• Verwendung von Base64-Encoding (Achtung: Keine Verschlüsselung!)

HTTP-Digest-Authentifizierung • Digesting der Credentials mittels MD5

• Server schickt Challenge (Optionen: qop, nonce, nonce-count, …)

HTTP-Session • HTTP ist stateless, deswegen Sessions

• Client-seitige Session vs. Server-seitige Session

• Cookies: Session-Daten sind Teil des HTTP-Headers

• URL-Parameter: Session-Daten werden als URL-Parameter angegeben

• Hidden-From-Fields

• Angriffe: Session-ID ausspionieren und/oder manipulieren

OWASP TOP 10 2013 • A1: Injection


• SQL / XPath / …

• Lösung: Input validieren, Prepared Statements

• A2: Broken Authentication and Session Management

• Gefahr: Session-Hijacking

• User-Accounts übernehmen

• Lösung: SSL, Gute, zufällige Session-IDs, richtiger Logout

• A3: Cross Site Scripting (XSS)

• A4: Failure to Restrict URL Access / Insecure Direct Object Reference

• Zugriff über vorhersehbare ID, Kontrolle nur in Presentation-Layer

• Lösung: Keine direkte Referenz auf Objekt, Verwendung von zufälligen Mapping-Values

• A5: Security Misconfiguration

• A8: Cross Site Request Forgery (CSRF)

• A10: Unvalidated Redirects and Forwards

• Lösung: Keine URLs bestehend aus User_innen-Parametern für den Redirect

Google Hacking • Über Google können mit speziellen Suchanfragen Websites mit Schwachstellen gefunden

werden

• Beipsiel:

• SQL Injection: inurl:"php?id" "You have an error in your SQL syntax"

• Jenkins mit offener Admin-Schnittstelle: intitle:"Dashboard [Jenkins]" intext:"Manage Jenkins"

Browser-Security • Sicherheitslücken durch Software (Patches, Plugins, …)

• Sicherheitsmechanismen von Browsern:

• Same-Origin

• Security Policies für Cookies

• Blocke von Ports (z.B.: Port 110)

• XSS-Schutz

• Sandboxen

• Zugriff auf lokale Files

• Bekommen immer mehr Funktionalität


Risikomanagement und IT-Grundschutz

Schutzziele und Sicherheitsbewusstsein • Identifikation des Umfeldes (Schutzgüter, Bedrohungen, Maßnahmen)

• Berücksichtigung der Schutzziele

• Definition von funktionalen und nichtfunktionalen Sicherheitsanforderungen

• Security-Awareness unter Devs

Risiko • Wortursprung: „Wagnis, Gefahr“

• BSI: Risiko ist die häufigkeit auf Berechnung beruhende Vorhersage eines möglichen Schadens im negativen Fall (Gefahr) und eines möglichen Nutzens im positiven Fall (Chance).

• IT: Risiko = Eintrittswahrscheinlichkeit * Schadenshöhe

• Risiken sind subjektiv

• Risikobewusstsein heißt Verantworungsbewusstsein

• Es gibt einen Haufen Standards und Normen

• Sind Bedrohungen, die sich nachteilig auf einen Betrieb, die Verfügbarkeit von Prozessen, eingesetzte Systeme bis zu einzelnen Daten auswirken können

• Risiken können nur entstehen, wenn eine Bedrohung auf ein Schutzobjekt wirkt und durch eine Schwachstelle zu einem Schaden führen kann

• Risikomanagement:

• Frühzeitige Erkennung solcher Bedrohungen, Erarbeitung von Gegenmaßnahmen

• Prozess (Wiederholter, immer wiederkehrender Durchlauf der Phasen):

1. Risikoidentifikation (Erkennung, eindeutige Beschreibung, Erfassung geplanter Maßnahmen). Methoden: Brainstorming, Angriffsbäume, Failure Modes and Effects Analysis (FMEA), Fault Tree Analysis (FTA)

2. Risikobewertung (Basiert auf Risiko Identif., Schätzung der Schwere und der Eintrittswahrscheinlichkeit in Klassen, Ergebnis: Risikolevel.)

3. Risikobehandlung / -steuerung (Akzeptanz, Vermeidung, Verminderung, Transferierung)

4. Risikokontrolle (Reporting, Dokumentation, Laufende Beobachtung)


• Informationssicherheitsprozess:

• Plan - Do - Check - Aact

IT Grundschutz • Herausgegeben vom Deutschen Bundesamt für Sicherheit und IT (BSI)

• Praktikable Durchführung von Sicherheitsanalysen

• Kosteneffektive Erhöhung des Sicherheitsniveaus

• Einfache Integration in den Sicherheitsprozess

• „Kochbuch“ für normales Schutzniveau (Baukastenprinzip):

• B1: Übergreifende Aspekte (z.B.: Datensicherungskonzept)

• B2: Infrastruktur (z.B.: Serverraum)

• B3: IT-Systeme (z.B.: Laptop, TK-Anlage, …)

• B4: Netze (WLAN, …)

• B5: Anwendungen (Webserver, Datenbank, …)

• => IT-Verbund: Abbildung der Bausteine auf reale Zielobjekte

• Kombination aus: Organisatorischen, Personellen und Infrastrukturellen und und Technishcen Maßnahmen

• Fragen:

• Welche Daten/Komponenten sind in meiner Organisation schu tzenswert?

• Welche Aspekte davon mu ssen geschu tzt werden?

• Wie werden Sicherheitsmaßnahmen umgesetzt?

• Wie erfahre ich dies effizient?

• Was ist Best-Practise?

• Wie sicher sind andere Systeme, mit denen ich zusammenarbeite?

• Wie weise ich anderen nach, dass meine Infrastruktur sicher ist?

• Es gibt Standards für IT-Sicherheit und den IT-Grundschutz

IT-Sicherheitsprozess (laut Grundschutz) • Initiierung: (Verantwortung der Leitungsebene, Konzeption und Planung, Einbeziehung

aller Mitarbeiter_innen)

• Erstellung eines Sicherheitskozeptes:

• Strukturanalyse,

• Schutzbedarfsaufstellung [„normal“, „hoch“, „sehr hoch“, …],


• Gruppierung von Objekten mit gleichem Schutzbedarf

• Netzplan kann als Grundplan für den Kommunikationsbereiches dienen

• Abhängigkeiten: Übertragung Anforderungen

• Maximumprinzip: Schutzbedarf aufgrund schwerwiegenster Auswirkung

• Kumulationseffekt: mehrere kleine Schäden führen zu einem Großen

• Verteilungseffekt: Aufteilung des Schutzbedarfs z.B.: Redundanzen

• Basis-Sicherheitscheck (Soll-Ist-Vergleich der Maßnahmen)

• Ergänzende Sicherheitsanalyse

• Umsetzung des Konzeptes

• Aufrechterhaltung und Verbesserung


Mobile Security Allgemein • Sensible Daten auf mobilen Geräten: SMS / Email, Geolocation, Kamera, Mikrofon,

Bankdaten, 2-Factor Auth, IoT-Steuerung

• Bedrohungen: Stehlen von diesen Daten, Durchführung von teuren Anrufen / SMS, Senden von Spam SMS, zweckloser Schaden, Erpressung

• Verbreitung:

• Repackaging: Beliebte AppStore-Apps werden mit bösem Payload manipuliert und in inoffiziellen App-Stores angeboten

• Update-Angriff: So ähnlich, aber statt bösartiger Code wird eine Update-Routine eingefügt, die dann den Code herunterläd

• Drive-by Download: Eher selten. Manuelle Installation und Fake Apps

Android Aufbau • 1. Schicht: Linux Kernel (Treiber und Services + Erweiterungen durch Android)

• 2. Schicht: Android Libraries (C/C++ Bibliotheken wie SQLite, WebKit, OpenGL, …)

• 2.5. Schicht: Android Runtime (JAVA VM führt Android-Applikations aus)

• 3. Schicht: Application Framework (Java Bibliotheken, die nicht Teil der VM sind. Basisklassen und Schnittstellen zum OS, die ich in meiner App verwenden kann)

• 4. Schicht: Applications: Kontakte, Telefon, Browser, Facebook, Angry Birds, …

Android-App Aufbau / Threat Model / Sandboxing • User hat unterschiedliches Vertrauen in verschiedene Apps (Game-App soll icht auf

Bankdaten oder das Mikrofon zugreifen können)

• Plan: Da jede App potentiell malizios ist, werden sie über Sandbox (Linux Prozess-Isolation) isoliert.

• Protected System API erfolgt über Berechtigungen: App definiert (AndroidManifest), welche Berechtigungen sie braucht. User_in muss das bei der Installation akzeptieren.

• Jede App wird von einem eigenen Linux-User ausgeführt und hat ein eigenes Verzeichnis (/data/data) und kann nur dort lesen und schreiben

• Android-App Komponenten: Activity, Service, BroadcastReceiver, ContentProvider


Android-App Inter Component Communication (ICC) • Asynchrones message passing System (Intents werden versendet)

• Intra- und Interapp Kommunikation

• Explicit Intent: wird an konkrete Komponente adressiert (besser, wenn möglich)

• Implicit Intent: An Komponenten, die spezielle Action erfüllt adressiert

• Komponente kann public sein (Muss im AndroidManifest angegeben werden und muss min. 1 Intent Filter deklarieren, sonst kann sie ja nie angesprochen werden)

• Angriffe:

• Confused Deputy Attack:

• 1. App mit Schadcode hat keine Permission (z.B.: Auf das Microphone).

• 2. App wird vertraut, ist aber verwundbar. Die Hat die Permission.

• 1. App sendet Intent an exportierte Komponente in 2. App und bekommt über die App Zugriff auf das Mikrofon

• Voraussetzung: 2. App hat Zugriff, ist verwundbar und es ist der Pfad durch die 2. App vom public entry point bis zur Ziel-Resource bekannt (Damit die 1. App zur Resource kommt)

• Beispiel: Facebook Information Disclosure

• Content Leak und Content Pollution

• Bei Android < 4.2 wurde ContentProvider EXPORT-Flag per Default gesetzt

• Sehr viele verwundbare Apps. Beispiel: Auslesen von SMS Nachrichten, Contacts, User Credentials, Veränderung von Blacklists, Blockiere Anrufe, SMS, DoS, …

• Unwirksame Gegenmaßnahme: Custom permission level „normal“, Überprüfung von Package-Name der sender App (Der kann mittels Spoofing geändert werden)

• Empfohlen: Nur Komponenten exportieren, wenn absolut notwendig. Custom permissions mit Level „dangerous“ oder „signature“, damit User gewarnt wird. Exportierte Komponenten wirklich nur extern verwenden und nicht intern

• Collusion-Angriffe

• Angreifer installiert mehrere Apps, die miteinander kommunizieren

• Die Apps sind unter der selben UID (sharedUserId) installiert und bekommen unterschiedliche Berechtigungen. (Wetter-App Geolocation, Recorder-App Microfon, …)

• Angreifer erhält so vereinigt mehrere Berechtigungen

• Injection-Angriffe via Intents

• SQL Injection

• Command Injection


• XSS attack (WebView)

• Maßnahmen bekannt: Inputvalidierung, Parametrisierte SQL-Queries

• Sonstige Angriffe:

• Broadcast Theft: Passive Eavesdropping

• Activity Hijacking: Starten von bösartiger Activity

• Service Hijacking: Android wählt passenden Intent-Empfänger randomisiert

• Intent Spoofing: Bösartiger Broadcast Intent (Starten von Activity)

Unsicherer Netzwerk-Traffic • Oft keine Verschlüsselung von sensiblen Daten

• Da App oft mit nur einem Backend-Server kommuniziert: SQQL Verschlüsselung mit Pinning des Server Public Keys

• Zoner SSL Vulnerability:

• SSL-Verbindung ohne Hostname Verfication

• MITM-Angriff -> Neue Virensignatur wird vom Backend heruntergeladen

• Integrität der Signatur nicht geprüft => Zoner löscht sich selber

Speicherung sensibler Daten • Shared Preferences: private Daten in Key-Value Storage

• Interner Speicher: private Daten im Gerätespeicher

• Externer Speicher: öffentliche Daten im geteilten Speicher

• SQLite Datenbank: strukturierte Daten in privater Datenbank

• Wichtig:

• MODE_WORLD_READABLE und MODE_WORLD_WRITEABLE bei SharedPreferences vermeiden!

• Externer Speicher ist vertrauenswürdig

• Design Prinzip: Keine sensiblen Daten auf mobilen Gerät speichern, wenn nicht anders möglich, dann verschlüsselt speichern.

• AccountManager oder KeyStore zum Speichern des Schlüssels verwenden


Intrusion Detection und Intrusion Prevention Systeme

Ziele von Angriffserkennung • Unterstützung der Aufrechterhaltung der IT-Sicherheit während des Betriebes

• Schadensreduzierung durch möglichst frühe und genaue Erkennung

• Erkennung von Fehlkonfiguration

• Abschätzen der Gefahrenlage für ein Unternehmen

• Abschreckung von Angreifer_innen (auch Mitarbeiter_innen!)

IDS / IPS • Intrusion Detection System: Erkennung von Angriffen anhand von Signaturen, Anomalien

und senden eines Alarms bei erkanntem Angriff

• Intrusion Prevention System: Automatische Ergreifung von Maßnahmen bei Erkennung (Bsp.: Firewall-Regel aktivieren)

• Gemeinsam: IDPS

• Aufbau:

• Ereigniskomponente: Sammeln von Daten über Sensoren

• Sucherungs- / Aufzeichnungskomponente: Ereignisse Loggen

• Analysekomponente: Analyse der Daten + ggf. Auslösung eines Alarms

• Monitor- und Aktionskomponente: Aufbereitung und Durchführung von Aktionen

• Host-based IDPS: Betrachtung eines einzelnen Hosts

• Direkt am Endsystem, hat dessen Sichtweise

• Beobachtet z.B.: Registry, Filesystem, Prozesse, Memory, Logs, …

• Network-based IDPS: Betrachtung des Netzwerkverkehrs und Netzwerksegmente oder Geräte, Analyse der Netzwerk-, Transport-, und Applikationprotokolle

• „Mitlauschen“

• Sichtweise des gesamten Netzwerkes

• Portscan, Hostscan, …

• End-2-End Verschlüsselung als Problem

• Abhängig vom Traffic hohe Last, welche zu Sicherheitsproblemen führen kann

• Passives NIDPS: Hängt am Switch


• Inline NIDPS: Hängt zwischen Firewall und Switch

• Network Behavior Analysis IDPS: Schaut im Netzwerk auf unerwartete Einflüsse

• Wireless IDPS: Betrachtet das WLAN-Netzwerk

Wie werden Angriffe erkannt? • Signature-based detection (Signaturen vergleichen)

• Signatur ist ein Pattern, das einen Angriff identifiziert

• Vorteil: Weit verbreitet, leicht zu implementieren

• Nachteil: Für jeden Angriff muss eine Signatur erstellt werden

• => Viele False Positives und False Negatives, wenn Signaturen nicht korrekt sind

• Anomaly-based detection (Aktivitäten beobachten)

• Jede Abweichung von einem erwarteten Verhalten von Usern und Systemen (nach einem Modell) wird als Angriff gewertet

• Vorteil: Erkennung von (bisher) unbekannten Angriffen möglich

• Nachteil: Oft hohe False Positive Rate, „normal“ ist schwer zu definieren, auch Angriffe können „normal“ wirken

• Beispiel: User-Login in der Firma erst um 18:00 und dann direkt Debugger starten ist eher ungewöhnlich

• Stateful-Protocol-Analysis

Angriffe auf IDPS • Netzwerk-Ebene: Tiny Fragment Attack, Fragment Overlap Attack, Stealth Scans

• Application-Ebene: Kleine Änderung, die inhaltlich keine Auswirkung haben aber Signatur ändern, Langsame kleine Änderungen. Beispiel: URL anders angeben

Maßnahmen bei einer Erkennung • Senden eines Alarms (Email, SMS, Slack…)

• Löschung von böswilligen Paketen

• Reset der Netzwerk-Verbindung

• Blockierung des gesamten Traffics

• Abändern von Paketen

TOP 5 IDS-Fehler


1. Das [N]IDS kann nicht den gesamten Traffic sehen

2. Niemand sieht nach den Alarmen

3. Es gibt keine IDS-Reaktionsregelung

4. Das IDS ist nicht auf seine Umgebung abgestimmt

5. NIDS-Beschränkungen werden nicht berücksichtigt

NIDPS Beispiel: SNORT • Aufbau: Sniffer » Preprozessor » Erkennungssystem » Alarm/Log

• Regeln:

• Zustand oder Bedingung in einem Netzwerk und eine Aktion

• Besteht aus: Header (Aktion, Pakettyp, …) und Option (Optionen zur Überprüfung des Pakets)

• Beispiel: action proto src ip src port … alert tcp $HOME NET any −> $EXTERNAL NET 80

• Andere Action: log, pass, drop, reject, …

• Optionen: msg (Titel der Rule im Log-Eintrag), offset (Durchsucht nach dem Offset), …

Honeypot und Honeynet • Ergänzende Sicherheitsmaßnahmen

• Kein Produktionssystem

• Kein legitimer Zugriff

• Leichtere Analyse von auftretendem Traffic

• Soll unerlaubte Angriffe anziehen

• Honeynet = Netzwerk von Honeypots

• Pots mit geringe Interaktivität => Simulation

• Pots mit hohe Interaktivität => reale Systeme

• Vorteile:

• Geringe Datenmenge mit hoher Bedeutung

• Erkennung neuer Werkzeuge + Ableitung neuer Signaturen

• Guter Einsatz in der Forschung

• Umleitung von verdächtigem Traffic aus Produktion in Honeypots

• Nachteile: Beschränkte Sicht, Risiko, Aufwand für Extraüberwachung

• Honeywall (so wie eine Firewall) leitet Anfrage in Honeynet um


Security und Usability Motivation • „90% - 95% der Sicherheitsfehler kommen von falscher Konfiguration.“ (Matt Bishop)

• Umfragen (Beispiel Kazaa) zeigen: sehr wenig User wissen überhaupt was sie einstellen, für wen sie Dinge veröffentlichen, …

• ca. 30% ignorieren SSL Cert not Trusted Warnung in Chrome 2015. Durch ein Redesign des Warning-Screens wurde der Wert verbessert! => Usability

• Unusable security führt zu:

• User_innen ignorieren Security Warning

• User_innen deaktivieren absichtlich oder unabsichtlich Security Systeme

• User_innen verstehen die Konsequenzen nicht

Usability Tools • User Research („Fail early, fail often“)

• Usability Ispections (Durch Expert_innen)

• Usability Tests (Durch User_innen)

• Heuristic Evaluation („Discount“-Methode)

• Cognitive Walkthrough (nur einzelne Tasks anschauen)

• User Testing (Mit echten User_innen in einer kontrollierten Umgebung testen)

• System Usability Scale („Quick & Dirty“ post-test, um Einschätzung zu finden)

Passwords & Authentication • Drei Ansätze: Was der_die User_in weiß (sectet) , besitzt (token), ist (biometric)

• Passphrase statt Password? User_innen nehmen leider nicht-random Phrases

• Passalgorithm: User_innen wählen Algorithmus (der ist Geheim) statt Passwort

• Graphical Password (Beispiel: Zeichnen Android)

• => „pass-objects“ müssen in einem Bild mit 1000 Objekten gefunden werden. User_in klickt in das Dreieck, das zwischen den drei Objekten aufgespannt wird. Dadurch ist es „Shoulder-Surfing resistant“

• Passfaces: Gesichter merken: Geht ganz gut, aber Reihenfolge der Gesichter nicht


Security Probleme • Security ist nicht das Hauptziel

• Security ist im Weg, User_innen möchten sich nicht damit beschäftigen

• Wenn Security zu schwierig ist, dann werden User_innen es nicht verwenden

• Security ist zu abstrakt für User_innen?

• „Barn door“ (Sobald ein Secret ungeschützt ist, müssen wir davon ausgehen, dass es bereits Angreifer_innen bekannt ist)

• User_innen müssen vor (teuren) Fehlern bewahrt werden

• Weakest link: Security ist nur so stark wie die unsicherste Stelle in einem System

Mobile Probleme • „First Connect“ - Wie wird das Gerät das erste mal mit dem Internet verbunden

• Bsp.: WLAN WPS (WiFi Protected Setup): PIN Methode, Push button Methode, NFC. Nicht sicher! WPS deaktivieren oder Timeout verwenden. Andere Probleme: Device Sticker mit WPS PIN, PIN Calculation mit MAC

• Bump-Methode: Sharing mittels physischem „Bump“.

• Probleme: Sensor nicht genau, ID spoofing, …

• Local User Authentication

• Biometric (Face unlock / Fingerprint)

• PIN & Password

• Security Gesture => Studie: 50% der Android User_innen verwenden weniger als 300 patterns!

• Knock to Unlock

• Mobile CAPTCHA

• Credential Recovery

• Installation von Applikationen

Usability Security Guidelines • Ziel: Sicherstellen, dass (Security)-Tasks einfach und richtig gemacht werden

1. Finde den angenehmsten Weg einen Task zu erledigen für den am wenigsten Rechte benötigt werden

2. Gib anderen Zugriff nur mit einer User-Action

3. Gib dem_der User_in um vorab erteilten Zugriff wieder einzuschränken


4. Zeige eine genaue Übersicht über erteilte Zugriffe dar

5. Zeige eine genaue Darstellung über die eigenen Rechte des_der User_in an

6. Beschütze den_die User_in vor Kommunikation mit gefährlichen Personen/Systemen

7. Ermögliche es dem_der User_in sichere Seucrity-Einstellungen vorzunehmen, auf eine Art, dass er_sie es auch bewältigen kann

8. …

Accessibility • Ein Subset von Usability

• Security für Menschen mit Einschränkungen…

Conclusio • Schlechtes Usability kann Security-Maßnahmen zerstören

• Gutes Usability kann auch zu schlechter Security führen

• Usability ist nicht auf UI beschränkt (Model, Context, …)


Documents

Security for Systems Engineering 2016 - VoWi · • Christmans Tree Paket (Flags) ... OS Detection, Vulnerability Scan nmap! • Scanning ist oft auffällig, daher Slow Scan oder