Table of Contents - Pages - Studentenportal
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Table of Contents - Pages
Crypto Strength
Physical Layer Security
Data Link Layer
OWASP
OWASP Compass
OWASP Tutorial
Data Leakage Prevention
Symantec Report
Anonymity / Tor
VPN
IKE
DNSSEC
NAC
Buffer Overflows
Smart Card
Platform Trust Service
WhiteHat Report
Alte Prüfungsfragen
Crypto Strength
Random Numbers
Tor
DNSSEC
VPN / IKE
NAC/TNC
Smart Card
Buffer Overflows
OWASP
TPM
Dirty Notiz-Export aus meinem OneNote (ohne Rechtschreibung/Layout). Keine Garantie
für Korrektheit, vor allem im Bereich CAK/SAK ist eh alles Quatsch was hier steht ;-)
fabio.scala@gmail.com / fscala
InfSi2_fscala Page 1
Crypto Strength
Freitag, 22. Februar 2013 08:14
W01 -
Crypto Str...
Audio recording started: 08:14 Freitag, 22. Februar 2013
Es ist wichtig das alle eingesetzten Crypto Algorithmen die gleiche Stärke besitzen.
Das Ganze ist nur so sicher wie das schwächste Glied.
Symmterisch 3DES-EDE 112
AES-128 128
CAMMELLIA-192 192
AES-256 256
Hash MD5 64 128 Kollisionsattacke
SHA-1 80 160 Kollisionsattacke in 2^60 möglich
SHA-2_224 112 224
SHA-2_256 128 256
SHA-2_384 192 384
SHA-2_512 256 512
SHA-3?
Key Exchange DH MODP-
DH ECP-192 96
DH ECP-224 112
DH ECP-256 128
DH ECP-384 192
DH ECP-521 560.5
Empfohlene Cryptostärke 2013
NSA Suite B CONFIDENTIAL 128 bit
Vertrauliche Dokumente
InfSi2_fscala Page 2
NSA Suite B CONFIDENTIAL
Vertrauliche Dokumente
NSA Suite B SECRET 192 bit und 256 bit bei Encryption (AES, AES-GCM)
Geheime Dokumente
Algorithm Key Size True Strength Bemerkung
Symmetric Encryption AES 128 bit 128 bit • 192/256 für paranoide
(CBC oder Counter) • Vermutung: Wahre Stärke von 256 bit eher gegen
192 bit
• Keine Attacke für AES bekannt (schneller als Bruce-
Force)
Data Integrity (Hash) SHA-256 256 bit 128 bit • Key Size / 2 = 2 Stärke für Kollisionsattacke
(SHA-2 oder SHA-3) • SHA-3 aka Keccak
• SHA-2 Schlüsselgrössen
• 223, 256, 384, 512
• 512 benutzt 64-bit-Operationen (dh schneller als
andere Sey Sizes auf 64-bit Systemen)
Key Exchange Peers Diffie Hellman 3072 bit 128 bit
Digital Signature RSA / DSA 3072 bit 128 bit 4096 bit für CA (root) Zertifikate
Vorlesung:
2048 bit
Public Key Encryption RSA / El Gamal 3072 bit 128 bit
Vorlesung:
2048 bit
User Password 13 char 78 bit Theoretisch 22 Zeichen (base64) für 128 bit
Sicherheit, jedoch schwer zu merken
Weiteres
• Twofish (war auch AES Kandidat)
• Blowfish (einiges schneller als AES)
• 3DES 112 bit stärke (Meet-in-the-middle Attacke)
• Camelia
• MD5 nicht verwenden
• SHA-1 2^80 bzw. 2^60 für kollision, nicht mehr verwenden
Elliptische Kurven
• Schwierig gute elliptische Kurven zu finden
• NIST Kurven sind public domain (patentfrei)
InfSi2_fscala Page 3
• NIST Kurven sind public domain (patentfrei)
• Es hat sich lange niemand gewagt elliptische Kurven einzusetzen da ein Unternehmen mehrere Patente darauf angemeldet hat.
Begriffe
ECDSA Elliptic Curve Digital Signature Algorithm
ECDH Elliptic Curve Diffie-Hellman
ECIES Elliptic Curve Integrated Encryption Scheme (public key encryption)
Motivation
• RSA ist relativ langsam:
Schlüssel Signaturen pro Sekunde Strength
RSA 3072 32 128
ECDSA 256 546 128
RSA 8192 1 192
ECDSA 384 233 192
(Intel Core2Duo T9400, one core, 32-bit Linux OS)
Authenticated Encryption with Associated Data (AEAD)
Galois/Counter Mode (GCM)
• Operation Mode für AES
• Authentizität (Integrity) und Confidentiality sichergestellt
• Parallelisierbar
• Auch Authenticated Encryption genannt
Wenn ohne Verschlüsselung : GMAC
Übung
• AES-128 etwa 12-13 Mal schneller als 3DES
• Performance von AES und Camellia proportional zur Anzahl Runden
• AES-NI Instruktionen neuerer CPUs Faktor 2-3 schneller
• SHA-2 384 Bit ist intern nichts weiter als 512 Bit Variante mit anderen IVs und truncated Output
• SHA-2 512 Bit Variante verwendete in der Übung intern 64 Bit Words und deshalb schneller auf x64 Platform als 256 Bit
Variante die mit 32 Bit Words arbeitet
• Keccak256 vs keccakc256
○ Keccak256 schnelelr und konstante kryptographische Stärke
• AES GCM overhead für Authentisierung (integrity) 8-10%
○ HMAC-SHA-256 overhead 70-90%, GCM aus Performancegründen!
• Exponent beim Entschlüsseln mit RSA ist häufig grösser und deshalb langsamer als Verschlüsseln
InfSi2_fscala Page 4
Physical Layer Security
Freitag, 1. März 2013 08:02
Voice Scrambling
Voice Pakete unterteilen (split) und deren Reihenfolge ändern..
Frequency Hopping
Änhlich wie bei vielen Wireless-Systemen (z.B. Bluetooth). Auf verschiedenen Frequenzen Senden.
• Früher oft in Militärsystemen (70er und 80er Jahre)
• Die meisten Schemas auf Layer 1 basieren auf "security by obscurity"
• Bietet heute kaum Sicherheit
Qutantenkryptographie
• Entangled Photons (verschränkte Photonen) sind sowohl vertikal wie horizontal polarisiert.
• Sowohl Alice wie Bob erhalten ein solches Photon. Diese sind "gekoppelt".
• Man wählt zufällig einen Filter aus Filter Sets und misst mit diesem zufällig entweder horizontal oder vertikal.
• Das gekoppelte Photon von Bob liefert bei Messung mit demselben Filter das gleiche Ergebnis.
• Man verwirft alle gemessenen Photonen bzw. deren Messung wo nicht derselbe Filter wie von der Gegenpartei verwendet wurde. Al so
ca 50% der Messungen/Photonen.
• Mit den Photonen wird lediglich der Schlüssel ermittelt. Die restliche Verschlüsselung läuft herkömmlich ab.
• Distanz dieses Verfahrens ist sehr limitiert (20-50km) nicht sehr Praxistauglich.
BB84 - Quantum Key Distribution Protocol
• Höhere Reichweite, durch Glasfaser limitiert. (über 140km mit decoys)
• Alice sendet immer wieder Photonen aus (entweder horizontal oder vertikal moduliert).
• Bob misst diese per Zufallsprinzip entweder horizontal oder vertikal
• Alice übermittelt Bob die Modulationsart der verschickten Photonen
• Bob übermitteln Alice die Messungsart der Empfangenen Photonen
• Beide verwerfen diejenigen Messungen die nicht auf derselben art erstellt/gemessen wurden
• Ca. 50% der Messungen bleiben übrig
• Photonen klonen (splitten) ist zwar nach der Messung (sniffen) möglich, doch Eve weiss nicht wie Bob messen wird/würde und so mit
würden ca. 50% der Photonen die bei Bob ankommen falsch sein.
• Falls zu viele solche "falschen" Photonen empfangen werden wird die Kommunikation über einen anderen Kanal neu initiiert da d ie
Sicherheit nicht gewährleistet werden kann.
Photon Splitting Attacks
• Bei BB84 wird mit 1 Photon pro Bit gerechnet
• Viele solche Laser verschicken aber häufig sehr kleine Mengen an Photonen
○ z.B. 0.2 pro Puls, oder 1 (gewünscht) oder manchmal auch 2 oder mehr
• Eve kann diejenigen mit 2 (oder mehr) splitten
○ Eines für sich behalt
○ Das andere an Bob weiterleiten
• Dann warten bis Alice die Modulationsart preisgibt und das behaltene Photon messen
Gegenmassnahme
InfSi2_fscala Page 5
Gegenmassnahme
• Alice verschickt absichtlich sogenannte decoy states mit mit einem anderen power level
• Eve weiss nicht welche Pulse decoys sind
• Alice verrät am Schluss welche Pulse decoys waren
• Die decoys geben dann Aufschluss darüber ob Photonen gesplittet wurden
Schlüsselmaterial / Random Numbers
TLS und MAC / HMAC
• Sicherstellung Authentizität (Integrity)
• Signatur
MAC Message Authentication Code
HMAC Keyed-Hash Message Authentication Code
• Sicherheit basierend auf verwendetem secret
• Secret sollte mindestens so lange wie hash value (z.B. 128 bit bei MD5, 160 bei SHA-1)
• Keinen Rückschluss auf Message möglich sofern keine Schwachstellen im Hash Algorithmus
Jede TLS Verbindung braucht zufälliges Schlüsselmaterial um eine möglichst hohe Entropie zu erreichen.
Pseudo Random Function anhand einer HMAC
PRF_MD5(secret, seed)
Secret
Seed Startwert, meist öffentlich
Sollte man mehr Schlüsselmaterial brauchen nimmt man den Output und verwendet es wieder als Seed
Schlussendlich wird nochmals gehasht um die internen Zustände nicht mehr nachvollziehen zu können und potentiell dasselbe
Schlüsselmaterial erneut generieren könnte.
"Verdünnen von Schlüsselmaterial", analog Kaffeemaschine/Kaffeepulver?
Wissen was eine PRF ist, die genauen Algorithmen nicht
TLS
InfSi2_fscala Page 6
immer 48 byte lang
Pre-Master Secret wird von Client generiert und via Server public-key (RSA) an den Server übermittelt
• Server entschlüsselt Pre-Master Secret mit seinem private Key
○ Mit DH: DH um Pre-Master Secret zu ermitteln
• Beide Parteien generieren mit PRF den Master Secret
Schlüsselmaterial
• Master Secret dient als Entropiequelle (sollten 48 bytes echte Entropie sein)
• Server und Client Random dienen als unverschlüsseltes Salt
Session Resumption
• Gleiches Master Secret verwenden
• Neue Client Random und Server Random (Server Hello, Client Hello) Werte verwendet um neues Schlüsselmaterial zu generieren.
Wahre Zufallszahlen
Key Stroke Timing • 1-2 Bit pro Tastaturschlag
• Die vom User eingetippten Tasten sind zwar nicht besonders zufällig und haben eine niedrige Entropie, doch der
Abstand zwischen den Tastenschlägen (in millisekunden oder genauer) ist relativ zufällig.
Mouse Movements • Entropie des Materials schwer abzuschätzen da potenziell immer die gleichen Bewegungen ausgeführt werden
Sampled Sound • Gefahr von Totalausfällen
Card Input • Mehrere LSB pro Abtastwert sind verrauscht und können verwendet werden
Air Turbulence in • Bis zu 100 Bit/min
Disk Drives • Sehr gute Quelle
RAID Disk Array • Timing Informationen
Controllers
Network Packet • 1-2 bit pro Packet
Arrival Times • Eher schlecht das diese von aussen durch Einspeisen von Paketen manipuliert werden könne
• Oftmals einzige Entropiequelle bei Disk- und Keyboardlosen Systemen (Firewalls, etc.)
Computer Clocks • Weniger Entropie als man denkt, da Clockregister nicht bei jedem Tick aktualisiert werden
Serial Numbers • Sollten nicht verwendet werden (Erraten, Brute-Force)
Linux nimmt verschiedene Quellen und mischt sie in den Entropie Pool /dev/random
Achtung: Man muss erkennen ob z.B. eine Soundkarte aktiviert ist, sonst liefer es immer 0 oder 1, dann hat man eine Nullentropie
Möglichst viele Quellen nehmen und diese hashen. Mach den Bias weg
Egal mit welcher Quelle, muss laufend eine Abschätzung des vorhandenen Entropiehaltes getätigt werden um Totalausfälle zu ver meiden!
Hashing erhöht verbessert statistische Eigenschaften, jedoch nicht die Entropie!
Hardware Based
Quanten oder Radioaktive Quellen • Meist gross und teuer
Thermal Noise Quellen (Sound)
InfSi2_fscala Page 7
Metastable Oscilliators • Neue Ivy Bridge Intel CPUs haben einen on-chip
• Gute Entropie
• evtl. Absprachen mit NSA?
• 500+ MB/s
• RDRAND Instruktion: (16, 32 oder 64 bit random value)
Lava Lampen • Periodisch Bilder der Lava Lampe erstellen
Übung
• RSA/ECDSA Schlüssel sind langlebig, volle Entropie ist zu empfehlen
• Für Key Exchange reicht ein guter PRNG
• Für Encryption mit AES-CBC 128 reicht ein PRNG, wobei vor allem der IV unvorhersehbar sein muss um Attacken zu verhindern
Tests zur Prüfung von Zufallsmaterial
FIPS Tests:
Monobit Tests • Anzahl 0 und 1 zählen, sollten ca. 50:50 sein
Poker Test • Zufallsmaterial in 4er Blöcke teilen, es müssten möglichst alle 4er (16 Bit Werte) in gleicher Anzahl vorkommen
Runs Tests • Lauter aufeinanderfolgende 0en oder 1en auf dessen Plausibilität prüfen (Wahrscheinlichkeit das dies eintrifft bei
gegebener Länger, wobei jedes weitere Bit die Wahrscheinlichkeit halbier)
Long Runs Tests • Es dürften nicht mehr als x (bestimmte) Anzahl aufeinanderfolgende 0en oder 1en vorkommen
Sagen nur etwas über die statistische Verteilung jedoch nichts über deren tatsächlichen Zufälligkeit aus
NIST 800-22 Test Suite Testsuite die mehrere Tests enthält
Ueli Maurer Universal Statistical Test
Quellen auf Linux:
/dev/random • Wahre Entropie aus verschiedenen Quellen
• Werden vor dem Einarbeiten in die Quelle XORed
• Bei der Herausgabe gehasht
/dev/urandom • Dasselbe wie random jedoch nicht blockieren (u=unblocked)
• Gibt auch Zufallsmaterial wenn die geschätzte Entropie auf Null fällt
Vorhandene Entropie kann via /proc/sys/kernel/random/entropy_avail abgefragt werden, ist jedoch nur eine Schätzung. Falls die se Schätzung
auf Null fällt blockiert /dev/random
Audioinput
• Audiobits direkt abgreifen mit Bias behaftet (z.B. mehr Nullen als Einsen)
• Bias kann mit John von Neumanns Methode beseitigt werden
○ 00 verwerfen
○ 11 verwerfen
○ 10 wird zu 1
○ 01 wird zu 0
• Alternativ Bias durch Hashing wegmachen
InfSi2_fscala Page 8
Data Link Layer
Freitag, 8. März 2013 07:29
Secure Device Identity (DevID)
Secure Device Identifier
Initial Device Identifier
Logically Significant Devide Identifier
Bereits mit der Hardware mitgeliefert (ROM) kann nicht überschrieben werden.
DevID Modul
• Hardware Modul welches die DevID Secrets, Credentials und Zertifikate bis zur Root speichert.
• Enthält einen starken Random Generator (RNG)
• Implementiert asymmetrische Verschlüsselung (2049 bit RSA und/oder 256 bit ECDSA)
• Implementiert SHA-256 Hash Funktion
• z.B. Anwendung bei EAP-TLS Authentisierung (nicht User sondern Device)
Slide 8
Media Access (MAC) Layer Security
• Verschlüsselung muss effizient sein aufgrund häufigem rekeying
• Benutzer werden in Gruppen (Connectivity Association) zusammengefasst
CAK Connectivity Assoiciation Key, statischer Key
CA Connectivity Association
InfSi2_fscala Page 9
CA Connectivity Association
SC Secure Channel
SAK Secure Association Key
SAKs wechseln häufig, pro Secure Channel.
• Channel sind gerichtet und jeder besitzt seinen eigenen Schlüssel
• Alle Pakete enthalten den Channel und den entsprechenden Schlüssel der zur Entschlüsselung
verwendet werden soll
• Wechsel zwischen Schlüssel ist overlapping, dh es sind kurzzeitig beide aktiv
○ Association Number (2 bit) gibt an ob der neue oder alte Schlüssel verwendet wurde
Connectivity Association bedeutet das jeder alle Pakete lesen kann?
Q: Warum besitzen CAK/SAK 128 bit?
A: AES Counter Mode
Sonderfall: Peer to Peer
MKA MACsec key Defined in IEEE 802.1X-2010, MKA is a key agreement protocol for discovering
agreement MACsec peers and negotiating the keys used by MACsec.
SAP Security Association This pre-standard key agreement protocol is similar to MKA.
Protocol
MSK Master session key Generated during the EAP exchange, the MSK is used to generate the CAK.
CAK Connectivity Derived from the MSK, the CAK is a long-lived master key that is used to
association key generate all other keys needed for MACsec.
InfSi2_fscala Page 10association key generate all other keys needed for MACsec.
SAK Secure association Derived from the CAK, the SAK is the encryption key used to encrypt traffic for
key a given session.
From
InfSi2_fscala Page 11OWASP
Sonntag, 4. August 2013 12:36
OWASP Open Web Application Security Project
• Non-Profit Organisation
• Teilnahme Kostenlos und offen für alle
WebScarab • Proxy für Pentesting Zwecke
• Erlaubt Abfangen/Umschreiben von HTTP und HTTPS Trafic
• Man In The Middle (MITM)
WebGoat • Absichtlich unsicher-programmierte Webappikation zu Übungszwecken
• J2EE
ESAPI
Was Wo Beschreibung
Clickjacking Browser • Links, Buttons etc werden überdeckt
• Veranlasst Benutzer Mausklicks und/oder Tastatureingaben durchzuführen
• Beispiel Flash Player Konfiguration überdecken und Benutzer veranlassen
Webcam und Mikrophon freizugeben
XSS Browser
CSRF Browser
Forged Token Auth Service
Direct Object Reference Access Control
Directory Traversal Webserver
SQL Injection Database
XML Injection Webservice
Packet Sniffing Kommunikation
Parameter Tampering Kommunikation
Insufficent Transport Layer Protection • Benutzer klickt immer "yes, continue.." • SSL/TSL/IPSEC verwenden
• Downgrade Attacks • Secure flag auf Session Cookies setzen
• MITM, Parameter so verändern das • Mixed SSL vermeiden (static Data ohne SSL)
schlechtere Cipher Suites vereinbart • Zertifikate sind:
werden • Nicht abgelaufen
• Danach brute-force Entschlüsseln • Korrekter CN
• Nicht revoked
• Rogue Administratoren • Trusted (CA)
• Verbindung zwischen eigenen • Evtl. EV für green bar in Browser
Servern/Physical tiers sichern • Min. 2048 bit für key exchange
• Min. 256 bit für Verschlüsselung
Häufigkeit
XSS 55%
InfSi2_fscala Page 12XSS 55%
Information Leakage 53%
Content Spoofing 36%
Insufficent Authorization 21%
CSRF 19%
Brute Force 16%
Predictable Resource Location 12%
SQL Injection 11%
Session Fixation 10%
Insufficent Session Expiration 10%
Window of Exposure 2010
• Finanzsektor und Banksektor
selten
• IT, Bildungssektor und Social
Networks sehr häufig
Repetition CIA
Beschreibung In Webapplikationen
Cofidentiality • Vertraulichkeit • Session Fixation: Login
• SQL Injection: Read/Dump
• SQL Injection: Bypass Auth
• XSS: Session Hijacking
Integrity • Echtheit • SQL Injection: Modify
• XSS: Modify
Availability • Verfügbarkeit • (D)DoS
• SQL Injection: Delete
• XSS: Redirect
Risk Rating
InfSi2_fscala Page 13OWASP Risk Rating Methode soll helfen den Schweregrad (severity) der Risiken abzuschätzen.
Es ist dabei sehr wichtig das Business gut zu kennen. Viele Risiken mögen aus technischer Sicht
extrem hoch und gefährlich erscheinen, haben jedoch minimalen impact auf das Business und
dessen Finanzen.
Threat Agent Individuum oder Gruppe welche eine Gefahr darstellen/ausnutzen könnten
Non-Target Specific Viren, Würmer, Trojaner, etc.
Employees Mitarbeiter, Reinigungs-/Sicherheits-/Wartungspersonal
Organized Crime Kriminelle die Geld machen wollen (Bankkonten, etc). Oft über Insider
Corporation Partner, Konkurrenz
Human Unintentional Unfälle, Unsorgfältigkeit
Human Intentional Insider, Outsider
Natural Flut, Brände, Stürme, Blitze, Meteoriten, Erdbeben, etc.
Threat Agent Factor • Skill Level: Wie hoch sind die Skills der Threat Agents?
1 Keine technischen Skills
3 Einige technische Skills
4 Poweruser
6 Programmier- und Netzwerkskills
9 Pentesting Skills
• Motiv: Wie motiviert sind die Threat Agents?
1 Kaum oder keine Belohnung
4 Mögliche Belohnung
9 Hohe Belohnung
• Opportunity: Welche Möglichkeiten/Gelegenheiten sind nötig?
0 Voller Zugriff oder teure Ressourcen nötig
4 Spezieller Zugriff oder Ressourcen nötig
7 Einige Zugriffe und Ressourcen nötig
9 Kein Zugriff oder Ressourcen nötig
• Size: Welche Grösse hat der Threat Agent?
2 Entwickler
2 System Administrator
4 Intranet Benutzer
5 Firmenpartner
6 Authentifizierte Benutzer
9 Anonyme Internet Benutzer
Vulerability Factors • Ease of discovery: Wie einfach ist es die Lücke zu entdecken?
1 Praktisch unmöglich
InfSi2_fscala Page 141 Praktisch unmöglich
3 Schwierig
7 Einfach
9 Automatisierte Tools stehen zur Verfügung
• Ease of exploit: Wie einfach ist es die Lücke auszunutzen?
1 Nur theoretische Attacke
3 Schwierig
5 Einfach
9 Automatisierte Tools stehen zur Verfügung
• Awareness: Wie Bekannt ist die Lücke?
1 Unbekannt
4 Versteckt
6 Offensichtloch
9 Öffentlich bekannt
• Intrusion detection: Wie wahrscheinlich ist eine Attacke auf das System zu bemerken?
1 Feststellung in Applikation
3 Logging und reviews dessen
8 Logging ohne reviews
9 Kein Logging
Impact Factors • Loss of confidentiality: Wieviel Daten werden preisgegeben und wie sensibel sind diese?
(Technical Impact) 2 Wenig nicht-sensible Daten
6 Wenig sensible/kritische Daten
7 Viel sensible/kritische Daten
9 Alle Daten
• Loss of integrity: Wieviel Daten werden beschädigt und/oder modifiziert?
1 Wenig leicht korrupte Daten
2 Wenig schwer korrupte Daten
5 Viel leicht modifizikorrupte erte Daten
7 Viel schwer korrupte Daten
9 Alle Daten komplett korrupt
• Loss of availability: Welche Dienste werden wie beeinträchtigt?
1 Wenig sekundäre Dienste
5 Wenig primäre Dienste
5 Viele sekundäre Dienste
7 Viele primäre Dienste
9 Alle Dienste
• Loss of accountability: Inwiefern sind die Handlungen und Threat Agents
nachvollziehbar/zurückverfolgbar?
1 Komplett zurückverfolgbar
7 Unter Umständen zurückverfolgbar
9 Komplett Anonym
Impact Factors • Financial damage: Wie hoch sind die Finanziellen Auswirkungen?
(Business Impact) 1 Kaum Auswirkung auf den Gewinn
2 Wenig Auswirkungen auf den Gewinn
7 Grosse Auswirkungen auf den Gewinn
9 Bankrott
• Reputation damage: Welche Auswirkungen gibt es auf das Image/Ruf?
1 Wenig Auswirklungen
4 Verlust vieler Kunden
5 Verlust des Firmenwerts (Goodwill?)
9 Schaden der "Brand" (Marke)
• Non-compliance: How much exposure does non-compliance introduce?
2 Minor violation
5 Clear violation
7 High profile violation
• Privacy violation: Wieviel persönlich identifizierbare/zuordenbare Daten werden preisgegeben?
3 Eine
InfSi2_fscala Page 155 Hunderte
7 Tausende
9 Milionen
Enterprise Security API (ESAPI)
OWASP Enterprise Security API ist eine open-source Library für Webapplikationen welche die
Entwicklung sicherer Applikationen erleichtern soll.
SDLC • Software Development Lifecycle
• Security Development Lifecycle
OWASP Testing Framework
Phase 0 • Sicherstellen das ein SDLC vorhanden ist das Wert auf Sicherheit legt
Vor der Entwicklung • Sicherstellen das Regeln/Grundsätze und Standards im Entwicklungsteam vorhanden sind
• Metriken und Kriterien festlegen (traceability sicherstellen)
Phase 1 & 2 • Sicherheitsanforderungen festlegen
Definition und Design • User management, Passwörter, Auth., Accountability, Session Management, TLS, etc.
• Design und Review der Architektur
• Design und Review von realistischen Angriffsszenarien
Phase 3 • Code Reviews
Während der Entwicklung • CIA
• OWASP Top 10
• BSI, etc.
Phase 4 • Pentesting
Während der Entwicklung • OWASP Testing Framework
Phase 5 • Review des Applikationsbetriebs
Wartung • Periodische "health checks" der Applikation
• Change verification sicherstellen (Änderungen an Applikationen ist genehmigt)
InfSi2_fscala Page 16OWASP Compass
Sonntag, 4. August 2013 14:23
InfSi2_fscala Page 17OWASP Tutorial
Donnerstag, 22. August 2013 18:35
Security Principles
Input is Evil • Benutzereingaben gelten generell als böse und sollte immer vor Weiterverarbeitung validiert
werden
TOCTOU • Time of Check vs. Time of Use
• Immer daran denken, dass obwohl die Benutzereingaben validiert wurden, diese evtl. erst zu
einem viel späteren Zeitpunkt verwendet werden. Falls der Benutzer in diesem Zeitintervall
Zugriff oder Kontroller über das Programm hat ist die Eingabe wieder potentiell gefährlich.
Dynamic • Die Welt ist dynamisch und nicht statisch. Sie ändern tagtäglich und es kann zu jederzeit eine
Threat neue Sicherheitslücke oder potentielle Gefahr enstehen.
Environmen • Nur weil ein System in der Vergangenheit einmal sicher war, heisst nicht dass dies jetzt noch
t der Fall ist.
A1 Injection
• Invalide Operationen werden nicht von validen unterschieden
Risiken
• Denial of Service
• Lack of Accountability
• Disclosing Sensitive Information
• Data Loss / Corruption
• Complete Takeover
• Nur durch Möglichkeiten des Parsers limitiert
Auftreten
• SQL, JavaScript/HTML. LDAP, XPath, XSLT
• Single Quote ' bei SQL
• \0 byte bei C-Style String
• < und > bei HTML, XML, SGML
• Semikolon ; in ALGOL und andere Programmiersprachen
Schutzmassnahmen
Block list • SQL Kommentare --, HTML Tags, etc. verbieten
Allow list • Nur GET wobei Parameter id eine Ganzzahl sein muss
• Optional negativ, nur 12 Zeichen, …
• Durch Regex einschränken
Escaping • Alle gefährlichen Zeichen escapen (z.B. < und > für HTML < >)
A2 Cross-Site Scripting (XSS)
Typen
Reflected • Injizierter Code ist in der URL in einem Parameter
• Server gibt diesen Parameter ohne validierung/escape auf der Seite wieder aus
• Präparierte URL weitergeben
• Oft bei Search Engines der Suchstring "Es gabt x Resultate für y:" wobei y reflektiert wurde
Persistent • Code wird in einer Datenbank perisitiert (z.B. ein Gästebucheintrag) und beim Aufruf wieder
InfSi2_fscala Page 18Persistent • Code wird in einer Datenbank perisitiert (z.B. ein Gästebucheintrag) und beim Aufruf wieder
ausgegeben
DOM-based • Code geht nicht über den Server sondern wird durch eine Lücke im Client-Code injiziert
• Ajax, JSONP/Webservices
• Referrer wird auf der Seite ausgegeben
• Browser-Lücken selbst
Schutzmassnahmen
Block list
Allow list
Escaping • Alle gefährlichen Zeichen escapen (z.B. < und > für HTML < >)
A3 Broken Authentication and Session Management
• Session IDs stellen halbwegs öffentliche Informationen dar und sollten bei Diebstahl kein grössere
Problem darstellen
Requirements
Credentials sind immer • Hash mit Salt
gschützt • Niemals Klartext speichern
• Evtl. sogar noch verschlüsseln
Starke Passwörter • Bestimmte Passwort-Komplexität voraussetzen
voraussetzen • z.B. mindestens 3 von 4 Merkmalen (Kleinbuchstaben, Grossbuchstaben,
Sonderzeichen, Ziffern)
• Mindestlänge
Session IDs nicht in der URL • Niemals Redirects mit Session ID in der URL
• Können via Referrer gelesen werden
Session IDs werden bei • Für jeden Login eine neue Session ID
Authentisierung neu • Verhindert Session Fixation Attacken wobei der Benutzer mit einer
erstellt präparierten URL aufgefordert wird eine Session ID zu Authentisieren die der
Angreifer zuvor erstellt hat und ihm somit bekannt ist.
Session ID kryptographisch • Kein erraten der Session IDs
zufällig
Session IDs nur von Cookies • Keine URL Session IDs
akzeptieren
Automatisches Logout nach • Nach längered Inaktivität die Session invalidieren
inaktivität
CAPTCHA verwenden • Gegen Brutce-Force/Bot Attacken auf Logins
• Person von Maschine unterscheiden
• z.B. nach 3 fehlgeschlagenen Logins zusätzlich ein Captcha anfragen
Schlechte Session IDs
In URL gespeichert
Persistente Cookie • Auch nach neustart des Browsers vorhanden
• Nichtpersistente werden vom Browser wieder gelöscht
Form Variablen • Können via JavaScript ausgelesen werden
Nicht HttpOnly Cookies • Können via JavaScript ausgelesen werden
Ausnahme Optimierung:
• Bei Hochskalierbaren Architekturen kann die zufällige Session ID durch ein verschlüsseltes Token
InfSi2_fscala Page 19• Bei Hochskalierbaren Architekturen kann die zufällige Session ID durch ein verschlüsseltes Token
errechnet aus diversen Faktoren (User ID, Timestamp, etc.) verwendet werden welches andere Server
ebenfalls entschlüsselt können.
A4 Insecure Direct Object References
• Server validiert nicht ob der Client Zugriff auf das Objekt (Link/URL) besitzt
○ Beispielsweise das Profil eines Benutzers lediglich durch Ersetzen eines ID Parameters in der URL
○ Files, Filenamen
○ Table Rows
○ …
A5 Cross-Site Request Forgery
• Benutzeraktion kann durch einen andere im Namen des ursprünglichen ausgeführt werden ohne das
die Webapplikation davor schützt
• Beispielsweise wird eine HTML E-Mail mit einem IMG Tag verschickt welches auf eine präparierte URL
zeigt die etwas im Namen (mit der Session) des Benutzers ausführen soll.
○ z.B.
Risiken
• Elevation of privilege
• Denial of Service
• Spoofing
• Tampering
• Repudiation (dict: Zurückweisung, Nichtanerkennung, Verstossung, Ableugnung, Ablehnung)
Schutzmassnahmen
Nonce • Nonce (Kryptographisch zufälliges Token) wird dem Client zurückgegeben
• Client muss sich beim nächsten Request wieder mit dieser ausweisen
• Bei jedem Request eine neue Nonce
• Nachteil: Alle Noncen müssen auf dem Client zwischengespeichert werden
HMAC • Verschlüsselter bzw. "keyed" Hash von einer Seite kombiniert mit der User ID/Session ID
• Sollte noch einen Timestamp enthalten damit bei Besuch derselben Seite nicht derselbe HMAC
entsteht und wiederverwendet werden kann
• Wie ein Salt muss auch der Timestamp auf dem Server Zwischengespeichert werden um einen
Vergleich zu ermöglichen
• Keine GET Parameter für Aktionen, Formulare etc. verwenden (erschwert CSRF erherblich)
• HMAC/Nonce ebenfalls nicht in der URL exposen
A6 Security Misconfiguration
• Fehlende Patches, Fixes, …
• Fehlkonfigurierte oder deaktivierte Sicheheitsfeatures (z.B. TLS)
• Default Account/Credentials
• Ungebrauchte Services/Features sind aktiv
• Administrative Backdoors
Schutzmassnahmen
• Alle verwendeten Komponenten untersuchen
○ Herstelleseite
○ Security-Seiten
Security Mailing Lists
InfSi2_fscala Page 20○ Security Mailing Lists
○ …
• Reviews der Konfiguration
• Reviews der laufenden Services und Features
• Prozess periodisch wiederholen oder wenn sich etwas am Deployment oder der Konfiguration ändert
A7 Insecure Cryptographic Storage
• Sensible Daten werden nicht verschlüsselt
• Unsalted Hashes
• Unsichere Schlüsselgenerierung
• Unsichere Schlüsselhaltung
• Schlüssel werden nicht rotiert
• Schlechte Kryptographie (schlechte oder eigene Algorithmen)
Schutzmassnahmen
• Komplexe Schlüssel
• Generierung mittels RNG mit hoher Entropie
• Speicherung in Datenbank, nicht im Code
• Mehrere Schlüssel verwenden, evt. aufteilen (Wieviel Daten kann ein einziger Schlüssel entschlüsseln?)
A8 Failure to Restrict URL Access
• Keine Zugriffskontrolle auf bestimmter URL
• Zugriffskontrolle via verstecken bzw. nicht preisgeben von URL
• Brute-Force
• Sniffing…
Risiken
• Funktionen und Services werden aufgerufen wofür sie nicht autorisiert sind
• Daten anderer Benutzer werden geleakt
• Sonstige privilegierte Aktionen werden ausgeführt
Schutzmassnahmen
• Für jede URL
○ Zugriff auf authentisierten und autorisierten Benutzer einschränken
○ User oder Rollenbasierte Permissions
○ Zugriff auf unautorisierte Seiten komplett/immer verbieten (Konfigurationen, Logfiles, Code, …)
• Architektur verifizieren
○ Auf jedem Layer einen Schutzmechanismus
○ Policy-basiert, keine Hardcodierten Dinge
• Implementation verifizieren
○ Testen durch Aufruf der URLs, Konfigurationen, etc.
A9 Insufficent Transport Layer Protection
• SSL/TLS wird nicht oder falsch/ungenügend sicher verwendet
• Sniffen von übertragenen Daten, Credentials, Session Ids
Schutzmassnahmen
• IPSec oder SSL/TLS verwenden
○ Und zwar überall wo nötig (Auth, oder so Session IDs/Cookies mitgegeben werden)
• Secure Flag bei Session ID Cookies setzen
• Mixed SSL vermeiden (Content sowohl von TLS wie auch Plaintext Sourcen)
InfSi2_fscala Page 21• Mixed SSL vermeiden (Content sowohl von TLS wie auch Plaintext Sourcen)
• TLS oder IPSec auch zur Kommunikation mit der Datenbank/Backend
• TLS Zertifikate sind gültig
○ Nicht abgelaufen
○ Korrekter CN
○ Nicht revoked
○ Trusted durch CA
• Optional Extended Validation Zertifikat (Bestätigt zudem die Person hinter der Seite statt nur die URL)
• Nur starke Algorithmen verwenden
○ 2048 Bit Key Exchange
○ 256 Bit Symmetrische Verschlüsselung
A10 Unvalidated Redirects and Forwards
• Unvalidierte Forwards erlauben das fälschen einer Seite.
• Redirect an externe/böse Seite nach einem erfolgreichen Login auf der korrekten Seite
• Phishing Seite leiten an echte Seite weiter für Login um dann wieder zur Phishing Seite zu Redirecten
via URL Parameter
Risiken
• Komplettes fälschen eine Seite für Phishing Attacken
• Bypassed authrozation checks durch redirection URL (falls diese nicht geprüft wird sondern einfach der
Content dahinter exposed wird)
Schutzmassnahmen
• Niemals "intern" redirects zulassen auf nicht autorisierte Inhalte
• Redirects zu statischen Locations (HTTP Redirect)
• Bei Redirects auf eine Seite die als Parameter mitgegeben wurde, diese immer erst validieren
• Lookup-Table mit Redirect ID/Action URL führen
InfSi2_fscala Page 22Data Leakage Prevention
Sonntag, 4. August 2013 14:23
Motivation
• No trust = no business
• Geschäftsgeheimnisse welche nicht durch Patente geschützt sind
• Bankgeheimnis
• Data Privacy
Egress und Usage Control
Egress Control • Ausgangskontrolle
Data Loss Prevention (DLP) • Kontrollieren was hinausgeht, die Grenzen überschreitet/verlässt
• Bsp.: Zoll, Quarantäne, Safe
Usage Control • Kontrollieren wie informationen verwendet werden
Information Rights Management (IRM) • Bsp.: DRM, Patente, Copyright
Egress Control
Beschreibung Beispielimplementation
Channel Protection • Alle für den Benutzer nicht relevanten Kommunikationskanäle blockieren • HTTPS/SSH verwenden
• Kanäle überwachen • Mail Traffic Monitoring
• Logging • Read-Only Internet
• Alarm bei Verdachtsfällen • Secure Mail (z.B. Verschlüsselung)
• Verschlüsselung der Kanäle
Endpoint Protection • Endpunkte verriegeln • Disk Verschlüsselung
• Verschlüsselung • Anti-Virus
• Ports deaktivieren • USB Ports deaktivieren
• Softwareinstallationen verhindert
• Schutz gegen externen Attacken
• Spam
• Viren
• Phishing
Document Protection • Unbefugter Zugriff verhindern • IRM
• Keine Produktionsdaten in Testumgebungen • Synthetische Daten in Testumgebung
• Inhalte Verschlüsseln • Zugriffsreche überprüfen/reviewen
• Inhalte Wasserzeichnen
Testdaten Anonymisierungstypen
Typ Beschreibung Beispiel
Productive Echte Produktionsdaten Fabio Scala
100'000 CHF
132-533-75
Pseudonym Anonymisiert mit Mappingtabelle Peter Heinzmann
100'000 CHF
132-533-75
Peter Heinzmann = Fabio Scala
Anonymized Anoymisiert, keine Mappings vorhanden Peter Heinzmann
100'000 CHF
132-533-75
Synthetic Erfundene Daten, komplett unkorreliert zu Produktionsdaten Chris Lee
123'456 CHF
123-456-789
Information Rights Management (IRM)
• Usage Control + Encryption
• Wer macht was mit welchen Informationen
InfSi2_fscala Page 23• Wer macht was mit welchen Informationen
Active Directory Rights Management Services (AD RMS)
• Microsoft IRM Lösung
• Word, Excel, PowerPoint, Outlook
• E-Mail dient als Identifikation
• Verschlüsselung und Zugriffkontrolle
○ 128 bit AES
○ 1024/2048 bit RSA
• Policy Enforcement
○ Keine Screenshots
○ Kein Copy & Paste
○ Kein Mail Forwarding
○ Kein Export
• Templates für Rechteverwaltung
• Super User kann alles entschlüsseln
Schwierigkeiten
Userakzeptanz • Unterstützung anderer Dateiformate
• Performance
• Anpassungen der bisherigen Geschäftsprozesse
Infrastruktur • Integration mit anderen Produkten
• Cloud
• Mobile
• Schützen der Keys um Verfügbarkeit der Dokumente auch nach Jahren zu Gewährleisten
InfSi2_fscala Page 24Symantec Report
Sonntag, 4. August 2013 17:04
Gründe für Data Leakage
Well-meaning insiders • Mitarbeiter welche unabsichtlich gegen Sicherheitsmassnahmen verstossen
• Macht den grössten Teil der Data Breaches aus
• Gestohlene/verlorene Laptops
• E-Mail/Webmail, Externe Speicher
• Partner (Third-Party) leaken informationen über einen
• Veraltete automatisierte Prozesse
Targetet attacks • Systemschwachstellen
• Schwache Credentials (Passwörter, veraltete ACL, Factory Defaults)
• SQL Injection
• Targeted malware
• Remote access tools (RAT) aka Trojaner
• Instant Messaging
• Benutzer mit Tricks zu Malware (z.B. Spyware) Download verlocken
The malicious insider • White collar crime
• Mitarbeiter stehlen absichtlich Daten (Eigennützig, verkaufen, etc.)
• Entlassene Mitarbeiter
• Rechts/Zugänge werden erst nach der Mitteilung entzogen
• In dieser "Window of Opportunity" ist Data Leakage möglich
• Verärgerte Mitarbeiter
• Daten für Privatzwecke
• Geschäftliche Daten (z.B. Codesnippets) werden zuhause für private Zwecke
(Wiederverwendung) aufbewahrt
• Sein Home System könnte gehackt werden
• Industriespionage
• Mitarbeiter unzufrieden
• Will zu Konkurrent wechseln oder sich selbstständig machen
• Kundendaten, etc. werden mitgenommen/gestohlen
Ablauf von Targeted Attacks
Phase 1 Incursion • Hacker verschafft sich Zugriff mittels Schwachstelle
• Default Passwörter
• SQL Injection
• Malware
•…
Phase 2 Discovery • Hacker sucht sich interessante Daten
• Automatischer Scan nach sensiblen Daten
InfSi2_fscala Page 25• Automatischer Scan nach sensiblen Daten
Phase 3 Capture • Daten durch well-meaning Insider werden sofort nach Aussen geleakt
• Sonst:
• root kits werden heimlich installiert
• Daten zusammensuchen/ablegen
Phase 4 Exfiltration • Sensible Daten werden nach aussen an den Hacker gesendet
• Entweder plain-text (Mail, etc.)
• Oder verschlüsselt bzw. in Archiven (ZIP, …) mit Passwörtern
Verhindern von Data Breaches
• Data Breaches können verhindert werden
○ In jeder der vier oben genannten Phasen
○ Lieber mehrere dieser Phasen absichern (sonst wäre es wie eine alles-oder-nichts Wette die früher oder später
versagt)
• Risiken reduzieren
• Herausfinden wer wo welche Daten wie verwendet (Wo sind Daten? Wo gehen sie hin)
• Mehrere Lösungsansätze kombinieren
1. Incursion durch targeted attacks verhindern
○ Systemsicherheit (Policies, Patches, Verschlüsselung, …)
○ Passwörter
○ SQL Injections
○ Malware
○ Intrusion Detection/Prevention Systeme
2. Real-time alerts durch globale Sicherheitssysteme/Firmen
3. Proaktiv Informatinen schützen
○ Define once, enforce everywhere Policies
○ Kommunikation überwachen (IM, Email, TCP, …)
○ Egress Kontrolle/Blockade (Speichermedien, Fax, Drucker, …)
4. Sicherheit "automatisieren" durch Standards
a. ISO-xy, HIPAA, COBIT, NIST, …
5. Daten Exfiltration verhindern
○ Kommunikation/Netzwerk überwachen (Monitoring)
○ Erkennung von dubiosen/unsicheren Verbindungen (Alerting)
6. Integrate prevention and response strategie into security operation (day-to-day operations of security team)
InfSi2_fscala Page 26Anonymity / Tor
Sonntag, 4. August 2013 18:14
• Surfen hinterlässt Spuren
○ Logs auf Webservern
○ Logs bei Mailservern
○ Logs beim ISP (alline schon gesetzlich)
○ Logs und Traffic Monitoring bei routern/gateway
• Wieso Anonymität?
○ Privatsphäre
○ Meinungsfreiheit
○ Verrat (Bsp. WikiLeaks)
○ Suche nach neuem Job, Partner, etc.
Pseudoanonyme Dienste
• Zwischendienst (meist Remailer)
• Entfernt persönliche Informationen und leitet die Nachricht weiter
• Antworten werden zurück an den Absender geleitet
• Wahre Identität ist nur dem (hoffentlich vertrauenswürdigen) Anoymisierungsdienst bekannt
Cascade of Mixes
Grundkonzept
• Netzwerk mit unabhängigen "Mixes"
• Kommunikation zwischen source und destination verschlüsselt
• Kommunikation zwischen Mixes verschlüsselt
• Einzelne Mixes sollten sich in verschiedenen juristischen Zonen (Ländern) befinden
○ Erschwert Rückverfolgung durch Gesetzgebung
Untraceability
• Jeder Mix kennt nur seinen direkten Vorgänger und Nachfolger in der Cascade
○ Untraceability ist gegeben solange nur ein einziger Unabhängig bleibt, auch wenn alle
andere "zusammenarbeiten"
Layered Encryption • Die public keys aller Mixes sind in einem trusted directory veröffentlich
• Alle Pakete werden immer auf dieselbe Länge gepadded um rückschlüsse
zu verhindern
• Entry Point packt Paket rückwärts ein (Verschlüsselt) und hängt die
Addresse des nächsten Mixes an
• Nach jeder Ankunft bei einem Mix, wird das Paket entschlüsselt und die
Addresse des nächsten Mixes entfernt. Diese wird ersetzt durch ein
wieteres Padding damit das Paket immer dieselbe Grösse hat und keine
Rückschlüsse auf die Position in der Cascade möglich sind
• Der Exit Point entschlüsselt das Paket komplett und entfernt jegliche
InfSi2_fscala Page 27• Der Exit Point entschlüsselt das Paket komplett und entfernt jegliche
Paddings bevor das Paket schlussendlich ans ursprüngliche Ziel
weitergeleitet wird
Weitere Konzepte
Drop message duplicates • Angreifer könnte durch Replay-Attacke und gleiches
ausgehendes Bitmuster den nächsten Mix eines
bestimmten Pakets herausfinden
• Jeder Mix muss eine Liste mit Hashes aller eingehenden
Pakete führen um Duplikate zu verwerfen
Decryption • Durch die Entschlüsselung des eingehenden Pakets wird
dessen Bitmuster verändert es sind somit keine
Rückschlüsse/Korrelationen zu einem ausgehenden
Paket möglich
Message re-sorting buffer • Um eine timing Analyse (erstes eingehendes wird erstes
ausgehende Paket sein) zu verhindern wird eine
bestimmte Anzahl Pakete gepufftert, umsortiert und
dann weitergeleitet
• Während Zeiten mit geringem Traffic kann es zu
Verzögerungen kommen, da erst der Puffer gefüllt
werden muss
Aus diesen Gründen ist ein hoher traffic von vielen unterschiedlichen Benutzern eine
Grundvoraussetzung für starke anonymität. Teilweise können auch dummy-Pakete eingeschleust
werden, was jedoch das Netzwerk nur unnötig belastet.
High-Latency • Grosser re-ordering Puffer resultiert in hoher Latenz
Anonymizers • + Hoher Anonymitätsgrad durch viele Mixes und einem grossen Puffer
• - Keine Echtzeitkommunikation möglich da zu hohe Latenz (dh kein
Surfen)
• - Mixes könnten offline sein bis das Paket endlich bei ihnen ankommt
Low-Latency • Kleiner oder kein re-ordering Puffer resultiert in tiefer Latenz
Anonymizers • + Geeignet für Echtzeitkommunikation wie Surfen, IM, etc.
• - Geringerer Anonymitätsgrad in low-traffic Zeiten
• Tor (The Second-Generation Onion Router)
• JAP (Java Anon Proxy)
Software
JAP • Tiefer Latenz
Java Anon Proxy • Fixe cascade von mixes
• - Nur Entry/Exit müssen überwacht werden
Tor • Bidirektionale TCP-Streams
The Second-Generation Onion Router • PFS durch DH key exchange
• ca. 500-700 gleichzeitig aktive Mixes (Onion Routers)
• Keine CA, Keys werden durch identity key signiert
Tor Paper
• Tor schützt nicht gegen Feinde mit "globaler" Sicht über das gesamte Netzwerk sondern gegen
Feinde die nur einen Ausschnitt des Netzwerks betrachtet können (traffic confirmation)
○ Passive Attacken durch Betrachtung beider Enden ist denkbar (timing und volume
patterns)
○ Aktive Attacken via gezieltem einschleusen von Paketen um distinkte Muster zu
erzwingen sind denkbar
• Tor soll gegen traffic analysis Attacken schützen wobei traffic patterns genutzt werden
InfSi2_fscala Page 28Tor Design
Onion • Host im Tor Netzwerk
Router (OR) • Entweder Relay (leitet weiter)
• Oder Exit Node (leitet zum Ziel weiter)
Onion • Onion Proxy, Client Software die als SOCKS Proxy dient
Proxy (OP) • Problem bei SOCKS ist die Namensauflösung (viele tunneln bereits den DNS Request,
andere machen dies selbst und geben nur die IP an)
• DNS Server weiss Bescheid über unsere Anfrage an xy Hostname
• Lösung für HTTP: Privoxy HTTP Proxy
Directory • Kleine Gruppe well-known OR
Server • Agiert als HTTP Server
• OR uploaden ihre eigene Sicht auf diese Directory Server
• OR wird nur in Directory Server aufgenommen wenn desse Identity Key anerkannt
wird (Verhindert das jemand tausende eigene OR aufsetzt und somit Teile des Tor
Netzwerks übernehmen kann)
• Tor Software ist mit Liste von Directory Servern preloaded für initialer Bootstrap
• Fallback auf manuelle (Menschenhand..) Lösung bei Problemen
Identity Key • Long term
• Zur Signierung von TLS Zertifikaten
• Zur Signierung von OR router descriptor (keys, addresses, bandwith, exit policy,
…)
Onion Key • Short term
• Zum Entschlüsseln von Requests der Benutzer (OP)
• Ciruits aufsetzen
• Ephemeral Keys austauschen
• Periodisch rotiert um Schaden eines kompromittierten Keys einzudämmen
Cells • Traffic wird in sog. Cells weitergeleitet (das Tor "Paket")
• Immer 512 Bytes
• Header und Payload
• Header beinhaltet Circuit ID welches den Circuit eindeutig identifiziert
• 128 Bit AES in Counter Mode verschlüsselt
Circuit • Im Prinzip der "Pfad" (Kaskade) zwischen OP bis hin zum Exit Node OP
• Mehrere TCP Streams pro Circuit möglich (multiplexing)
• Periodisch neue Circuits aufbauen
• Werden inkrementell aufgebaut
• OP verhandelt symmetrischen Schlüssel mit jedem OR, einen nach dem Anderen
• DH Handshake wird mit Onion Key von OR verschlüsselt (kein MITM möglich)
• OR antwortet mit Hash über dem entschlüsselten DH Key (Beweist man ist mit
dem richtigen OR verbunden)
• Einzelne Teile (eg nicht bis zum Schluss) eines Circuits können abgebaut und wieder
extended werden.
Exit Policy • Policy für Traffic definierbar um Missbrauch eigener Exit Nodes zu verhindert
(z.B. SMTP Port, …)
open exit Akzeptieren alles
middleman Niemals Exit Node, nur Relay OR
private exit Nur exit zu lokalem Host/Netzwerk, art VPN
restricted exit Spezielle Policy wie Ports, Hosts, oder benötigt Auth.
Rate Limiting • Bandwidth Limit auf Incoming Traffic setzbar
• Nur als durchschnitt, erlaubt dennoch kurzfristig höhere Bursts
• Interactive vs. Bulk Stream
• Heuristische Verfahren zur Unterscheidung (Pakete kommen öfters)
• Interactive werden dann mit höherer Priorität behandelt
• Solches Bevorzugen von Paketen elraubt evt. end-to-end Attacken
Congestion • Circuit-level throttling
Control • packaging window (wieviele kann der OR noch an den OP zurückleiten)
• delivery window (wieviele kann der OR noch weiterleiten)
InfSi2_fscala Page 29• delivery window (wieviele kann der OR noch weiterleiten)
• Stream-level throttling
DoS • eg zwingen CPU-intensive Operationen durchzuführen (kryptographische
operationen => TLS Handshakes, …)
• Attacken auf das Tor Netzwerk selbst (Hosts)
• Ist ein OR down gehen alle Circuits über diesen OR kaputt
Rendezvous Point / Hidden Services
Ermöglicht das Bereitstellen von Hidden Services wie z.B. einen Webserver ohne die eigentliche IP
bekannt geben zu müssen. Sowohl Client wie auch Server benötigen dafür jedoch Tor.
Ziele:
Access Control Bob will seinen Dienst schützen sodass nicht jeder darauf zugreifen oder diesen
mit Anfragen flooden kann
Robustness Bob sollte langfristig anonym bleiben können
Smear-resistance Es sollte nicht möglich sein bestimmte OR zum bereitstellen fragwürdiger
Inhalte zu zwingen
Application- Es wird spezielle Software benötigt, jedoch keine Modifikation der
transparency bestehenden Client und Server Software (Webserver, Browser)
1. Bob generiert langfristigen Public Key für seinen Dienst
2. Bob wählt einige ORs als Introduction Points aus
a. Bob veröffentlicht diese zusammen mit seinem Public Key in einem Lookup-Service
b. Bob baut ein Circuit zu allen Introduction Points auf
3. Alice hört von Bob's Dienst (oder es wird ihr mitgeteilt)
a. Alice verschafft sich mittels Tor via Looup-Service Informationen darüber
b. Alice wähle ein OR als Rendezvous Point aus und stellt ein Circuit dazu her
c. Alice übergibt dem Rendezvous Point ein "Rendervous Cookie" um Bob zu identifizieren
d. Alice eröffnet eine Verbindung zu eines von Bob's Introduction Points und übergibt
diesem eine mit Bob's Public Key verschlüsselte Nachricht mit Informationen über sich
und dem Rendezvous Cookie sowie dem DH Handshake-Start
e. Der Introduction Point sendet diese Informationen weiter an Bob
4. Wenn Bob mit Alice kommunizieren möchte baut er ein Circuit zum RP auf und sendet diesem
das Rendezvous Cookie sowie den zweiten Teil des DH Handshakes und einen Hash des
Session Keys welchen sie nun gemeinsam besitzen
5. Der RP verbindet Alice's und Bob's Circuits (der RP weiss jedoch nicht über Alice, Bob oder den
übermittelten Daten)
6. Alice senden relay begin und stellt somit einen anonymen Stream zu Bob's Webserver her
• Falls man den Zugriff auf den Webserver einschränken will, kann optional ein Authorization
Token bereits beim Verbinden von Alice mit dem Introduction Point mitgegeben werden
InfSi2_fscala Page 30Token bereits beim Verbinden von Alice mit dem Introduction Point mitgegeben werden
• Die Introduction Points sind typische DoS Ziele, aus diesem Grund muss Bob möglichst viele
Introduction Points besitzen und evtl. nicht alle publishen (oder einen Teil der öffentlichkeit,
den anderen an eine vertrauenswürdige Gruppe)
• Der Dienst erhält eine virtuelle URL mit der TLD .onion (authCookie.publicKeyHash.onion)
welche vom Tor Onion Proxy automatisch erkannt und aufgelöst wird.
Attacken
InfSi2_fscala Page 31VPN
Samstag, 10. August 2013 17:29
Layer 4 TLS (SSL)
Transport Layer
Layer 3 IPsec
Network Layer
Layer 2 PPTP, L2TP L2TP ist neuer
Data Link Layer IEEE 802.1X Auth: MSChapV2 (übel)
IEEE 802.1AE MPPE (absoluter Schrott)
IEEE 802.11i (WPA2)
Vorteile Nachteile
Layer 2 • Gleiches Auth. Verfahren wie PPP • Keine Security ohne IPSec
(L2TP) • Replay Attacken (MITM) bei nicht Authentisierten
Paketen
• Keine Verschlüsselung
Layer 3 • Starke Verschlüsselung/Authentisierung • Kein Tunneling von nicht-IP Protokollen
(IPSec) • Kann komplexe Policies Aushandeln und sicherstellen • Komplexer Verbindungsaufbau
(enforce) • PKI Management Overhead
• XAUTH/IKEv2-EAP bietet ähnliche Features wie PPP
Layer 4 (TLS) • Simpel, bruacht keinen speziellen Client (Browser) • Braucht teilweise spezielle Plugins
• Starke Verschlüsselung/Authentisierung
PPP
• Auth via:
○ PAP (Passwort)
○ CHAP (Challenge/Reponse)
○ EAP (Extensible Authentication Protocol mit Support für Token Cards etc.)
• Optionale Ecryption (ECP) mit preshared secrets
• Einzelne PPP Pakete nicht Authentisiert
○ Schwäche: MITM möglich (damals/früher nicht relevant da jeder seine eigene Leitung hatte)
PPP Encryption Control Protocol (ECP)
• Genau ein ECP Paket im PPP Information Field (= 0x8053)
• Ein Verschlüsseltes Paket ist im PPP Information Field enthalten (= 0x0053)
• Sollte Triple-DES verwenden (3DESE) DES-EDE3-CBC mit 168bit key.
PPP Extensible Authentication Protocol (EAP)
Layer 2 Tunneling Protocol (L2TP)
• UDP da 2xTCP (darunter, getunnelt) sicht "stören" könnten
• Keine Verschlüsselung und/oder Checksummen
• "Bic Mac" Situation, typisch bei Tunnelverfahren
InfSi2_fscala Page 32• IPv4 keine Sicherheitsfeatures (Source & Destination lesbar, etc.)
Compulsory Mode
• LAC - LNS = Virtueller Kupferdraht
Voluntary Mode
Mit IPSec
• Cheeseburger Situation? (Kleinerer Overhead)
TLS/SSL Tunnel
InfSi2_fscala Page 33TLS/SSL Tunnel
MPLS
• Label Based Switching
IPSec
• Datagrams (Pakete) sind:
○ Verschlüsselt (Privacy)
○ Authentisiert (Authenticity: kein Spoofing/Modifikation) @ Authentication Header AH
Authentication Header (AH)
Ohne AH (vorher) Mit AH (nachher)
• IP Protokoll Nummer 51
○ Nicht UDP/TCP sondern eigenständiges Protokoll
• Schutz vor Modifikationen mit MAC (Message Authentication Code)
• Nicht möglich mit NAT Router da Modifikation zu falscher MAC führen würde
• Jedes Protokoll kann via AH geschützt werden
○ Procotol field 51 und dann im "Next Header Field" die Angabe des originalen Protokolls
Encapsulating Security Payload (eSP)
• Hauptsächlich bei L2TP
• Paket ohne Header (dh geht über NAT Router)
• Checksumme Optional
○ Heute immer/meistens mit um Replay Attacken zu verhindern
• Jedes Protokoll kann via ESP geschützt werden
○ Procotol field 50 und dann im "Next Header Field" die Angabe des originalen Protokolls
Ohne ESP (vorher) Mit ESP (nachher)
InfSi2_fscala Page 34Ohne ESP (vorher) Mit ESP (nachher)
IPSec Tunnel Mode
• VPN/Kommunikation zwischen zwei Subnets (z.B. Enterprise Bereich) mit verschlüsseltem IPSec Tunnel
• Das was heute effektiv genutzt wird
• via L2TP (neuer) oder veraltetes PPTP
• Originaler IP Header verschlüsselt
InfSi2_fscala Page 35IKE
Donnerstag, 15. August 2013 19:12
Internet Key Exchange V1 (IKEv1)
Security Association (SA)
• ISAKMP SA (IKEv1) oder IKE SA (IKEv2) schützt die IKE Verhandlung/Austausch
• Separate IPsec SA notwendig für jedes Subnetz oder Host
• Separate IPsec SA notwendig für ein- und ausgehende Verbindung
• SAs haben einen Security Parameter Index (SPI) und werden in einer Datenbank gehalten
Negotiated Parameters
• Auth. Verfahren (Nur IKEv1 bei, pre-shared oder public key)
• Verschlüsselungsalgorithmus
• Hash Algorithmus
• PRF (Pseudo Random Function)
• Key Exchange mittels DH
• Schlüssel Lebensdauer (nur bei IKEv1)
IKEv1 Main Mode
• Bei IKEv1 müssen die Parameter auf beiden Enden übereinstimmen sonst kommt im Quick Mode keine
Verbindung zustande (Policy), dh kein Narrowing wie bei IKEv2 möglich
• Man legt fest was effektiv getunnelt werden soll
Mit Pre-Shared Keys
• 6 Pakete in Main Mode (Auth, Key Exchange, Optionen) wovon die ersten 4 Klartext sind
• Pre-Shared key als Teil eines Hashes
○ Teil des IKE Session Key
• Brute-force/Dictionary Attacken nicht möglich da Password ebenfalls in den Hash miteinfliesst. Ohne Passwort
kann der Hash nicht gelesen werden.
○ Problem: Im Named Modus müsste der Gateway alle Passwörter ausprobieren um den passenden
Benutzer zu finden.
Aggressive Mode mit Pre-Shared Keys
InfSi2_fscala Page 36Sie können auch lesen
