Table of Contents - Pages
Werbung
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 ;-) [email protected] / 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 Hash 256 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 MODPDH 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 Geheime Dokumente 192 bit und 256 bit bei Encryption (AES, AES-GCM) Algorithm Key Size True Strength Bemerkung Symmetric Encryption AES (CBC oder Counter) 128 bit 128 bit • 192/256 für paranoide • Vermutung: Wahre Stärke von 256 bit eher gegen 192 bit • Keine Attacke für AES bekannt (schneller als BruceForce) Data Integrity (Hash) SHA-256 (SHA-2 oder SHA-3) 256 bit 128 bit • Key Size / 2 = 2 Stärke für Kollisionsattacke • 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 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 Theoretisch 22 Zeichen (base64) für 128 bit Sicherheit, jedoch schwer zu merken • 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 192 1 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 Card Input • Gefahr von Totalausfällen • Mehrere LSB pro Abtastwert sind verrauscht und können verwendet werden Air Turbulence in Disk Drives • Bis zu 100 Bit/min • Sehr gute Quelle RAID Disk Array Controllers • Timing Informationen Network Packet Arrival Times • 1-2 bit pro Packet • 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 Lava Lampen • 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) • 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 agreement Defined in IEEE 802.1X-2010, MKA is a key agreement protocol for discovering 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 association key Derived from the MSK, the CAK is a long-lived master key that is used to generate all other keys needed for MACsec. InfSi2_fscala Page 10 SAK association key generate all other keys needed for MACsec. Secure association key Derived from the CAK, the SAK is the encryption key used to encrypt traffic for a given session. From <http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6638/deploy_guide_c17-663760.html> InfSi2_fscala Page 11 OWASP 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.." • Downgrade Attacks • MITM, Parameter so verändern das schlechtere Cipher Suites vereinbart werden • Danach brute-force Entschlüsseln • Rogue Administratoren • Verbindung zwischen eigenen Servern/Physical tiers sichern Häufigkeit XSS 55% InfSi2_fscala Page 12 • SSL/TSL/IPSEC verwenden • Secure flag auf Session Cookies setzen • Mixed SSL vermeiden (static Data ohne SSL) • Zertifikate sind: • Nicht abgelaufen • Korrekter CN • Nicht revoked • Trusted (CA) • Evtl. EV für green bar in Browser • Min. 2048 bit für key exchange • Min. 256 bit für Verschlüsselung XSS 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 13 OWASP 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 Threat Agent Factor Human Intentional Insider, Outsider Natural Flut, Brände, Stürme, Blitze, Meteoriten, Erdbeben, etc. • 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? Vulerability Factors 2 Entwickler 2 System Administrator 4 Intranet Benutzer 5 Firmenpartner 6 Authentifizierte Benutzer 9 Anonyme Internet Benutzer • Ease of discovery: Wie einfach ist es die Lücke zu entdecken? 1 Praktisch unmöglich InfSi2_fscala Page 14 1 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? Impact Factors (Technical Impact) 1 Feststellung in Applikation 3 Logging und reviews dessen 8 Logging ohne reviews 9 Kein Logging • Loss of confidentiality: Wieviel Daten werden preisgegeben und wie sensibel sind diese? 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? Impact Factors (Business Impact) 1 Komplett zurückverfolgbar 7 Unter Umständen zurückverfolgbar 9 Komplett Anonym • Financial damage: Wie hoch sind die Finanziellen Auswirkungen? 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 15 5 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 Vor der Entwicklung • Sicherstellen das ein SDLC vorhanden ist das Wert auf Sicherheit legt • Sicherstellen das Regeln/Grundsätze und Standards im Entwicklungsteam vorhanden sind • Metriken und Kriterien festlegen (traceability sicherstellen) Phase 1 & 2 Definition und Design • Sicherheitsanforderungen festlegen • User management, Passwörter, Auth., Accountability, Session Management, TLS, etc. • Design und Review der Architektur • Design und Review von realistischen Angriffsszenarien Phase 3 Während der Entwicklung • Code Reviews • CIA • OWASP Top 10 • BSI, etc. Phase 4 Während der Entwicklung • Pentesting • OWASP Testing Framework Phase 5 Wartung • Review des Applikationsbetriebs • Periodische "health checks" der Applikation • Change verification sicherstellen (Änderungen an Applikationen ist genehmigt) InfSi2_fscala Page 16 OWASP Compass Sonntag, 4. August 2013 14:23 InfSi2_fscala Page 17 OWASP 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 der Fall ist. t 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. &lt; und &gt; 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 18 Persistent • 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. &lt; und &gt; 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 gschützt • Hash mit Salt • Niemals Klartext speichern • Evtl. sogar noch verschlüsseln Starke Passwörter voraussetzen • Bestimmte Passwort-Komplexität 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 Authentisierung neu erstellt • Für jeden Login eine neue Session ID • Verhindert Session Fixation Attacken wobei der Benutzer mit einer 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. <img src="foo.bar.ch?action=delete&id=33" …> 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 22 Data 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 Data Loss Prevention (DLP) • Ausgangskontrolle • Kontrollieren was hinausgeht, die Grenzen überschreitet/verlässt • Bsp.: Zoll, Quarantäne, Safe Usage Control Information Rights Management (IRM) • Kontrollieren wie informationen verwendet werden • Bsp.: DRM, Patente, Copyright Egress Control Beschreibung Beispielimplementation Channel Protection • Alle für den Benutzer nicht relevanten Kommunikationskanäle blockieren • Kanäle überwachen • Logging • Alarm bei Verdachtsfällen • Verschlüsselung der Kanäle • HTTPS/SSH verwenden • Mail Traffic Monitoring • Read-Only Internet • Secure Mail (z.B. Verschlüsselung) Endpoint Protection • Endpunkte verriegeln • Verschlüsselung • Ports deaktivieren • Softwareinstallationen verhindert • Schutz gegen externen Attacken • Spam • Viren • Phishing • Disk Verschlüsselung • Anti-Virus • USB Ports deaktivieren Document Protection • Unbefugter Zugriff verhindern • Keine Produktionsdaten in Testumgebungen • Inhalte Verschlüsseln • Inhalte Wasserzeichnen • IRM • Synthetische Daten in Testumgebung • Zugriffsreche überprüfen/reviewen 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 Synthetic Peter Heinzmann 100'000 CHF 132-533-75 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 24 Symantec 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 26 Anonymity / 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 Anonymizers • Grosser re-ordering Puffer resultiert in hoher Latenz • + 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 Anonymizers • Kleiner oder kein re-ordering Puffer resultiert in tiefer Latenz • + 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 Java Anon Proxy • Tiefer Latenz • 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 28 Tor Design Onion • Host im Tor Netzwerk Router (OR) • Entweder Relay (leitet weiter) • Oder Exit Node (leitet zum Ziel weiter) Onion Proxy (OP) • Onion Proxy, Client Software die als SOCKS Proxy dient • 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 Server • Kleine Gruppe well-known OR • 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 Control • Circuit-level throttling • 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 Applicationtransparency Es wird spezielle Software benötigt, jedoch keine Modifikation der 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 30 Token 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 31 VPN Samstag, 10. August 2013 17:29 Layer 4 TLS (SSL) Transport Layer Layer 3 Network Layer IPsec 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 (L2TP) • Gleiches Auth. Verfahren wie PPP • Keine Security ohne IPSec • Replay Attacken (MITM) bei nicht Authentisierten Paketen • Keine Verschlüsselung Layer 3 (IPSec) • Starke Verschlüsselung/Authentisierung • Kein Tunneling von nicht-IP Protokollen • 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) • Starke Verschlüsselung/Authentisierung • Braucht teilweise spezielle Plugins 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 33 TLS/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 34 Ohne 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 35 IKE 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 36 Aggressive Mode mit Pre-Shared Keys • Hier wird anders die Identität offen (plaintext) übertragen • Hash kann gesnifft werden und dann offline via brute-force/dictionary attackiert werden ○ Bei schwachen Passwörtern ein grosses Problem • Im Aggressive Mode ist ein One-Time-Password Schema (z.B. SecureID) zu empfehlen • Lösung Cisco? Exteded Authentication Quick Mode • 3 verschlüsselte Pakete für Quick Mode (erstellung der IPSec SA, effektiver Tunnel) • UDP Port 500 • Im Quick Mode wird eine IPsec SA unter der Verwendung der vorherigen Verbindung (in Phase 1, Main Mode) IKMPK SA erstellt • Kann verwendet werden um eine IPSec SA zu erneuern die bald abläuft • ESP/AH Keys für IPSec werden vom Phase 1 Diffie Hellman Secret abgeleitet • Optional: Perfect Forwared Secrecy durch erneutem DH Key Exchange in jedem Quick Mode Internet Key Exchange V2 (IKEv2) • • • • Verbindungsaufbau mit nur 2 request/response Paaren Zusätzliche SAs benötigen nur noch ein weiteres request/response Paar EAP (One Time Password etc) wird unterstützt Ist nicht rückwärtskompatibel mit IKEv1 Motivation • • • • • IKEv1 über viele Standards/Dokumente verteilt Zu viele Nachrichten bei IKEv1 (6 im Main und 3 im Quick Mode) Zu viele Varianten (AH/ESP, transport/tunnel, Auth. Modus) Zu Komplex (und somit potenziell unsicher) Neue Features (NAT-T, Dead Peer Detection, …) • IKEv1 eher instabil wenn nicht alle Pakete ankommen ○ Verwendet kein Request/Reponse Verfahren wie IKEv2 Authentication - First SA InfSi2_fscala Page 37 Zusätzliche Child SAs • CREATE_CHILD_SA • Rekeying IKE_SA: ○ Suite Proposals ○ Initiator None ○ Initial public factor für DH für optionale PFS • Rekeying CHILD_SA: Gleich vie IKE_SA + ○ Initiator Traffic Selectors (Subnetze hinter dem Inititator) ○ Responder Traffic Selectors • Reauthentication ○ IKE_SA von vorne beginnen Schutz vor DoS • Mittels Cookie # strongswan.conf charon { dos_protection = yes cookie_threshold = 10 block_threshold = 5 } strongSwan # ipsec.cong # host carol # ipsec.conf # gateway moon conn home keyexchange=ikev2 left=%any leftsourceip=%config leftcert=carolCert.pem [email protected] leftfirewall=yes right=192.168.0.1 # gateway (moon) [email protected] rightsubnet=10.1.0.0/16 # subnetz "nach" auto=start conn rw keyexchange=ikev2 left=%any leftsubnet=10.1.0.0/24 leftcert=moonCert.pem [email protected] leftfirewall=yes right=%any rightsourceip=10.3.0.0/24 auto=add # subnetz "nach" Virtual Private Networks • Tunnel Windows 7 Agile VPN Client • Gateway Zertifikat muss host name oder IP und serverAuth extendedKeyUsage flag besitzen strongSwan Applet for Linux • Wenn CA gegeben muss Hostname/IP des Gateways im subjectAltName des vom Gateways erhaltenen Zertifikats enthalten sein InfSi2_fscala Page 38 sein VPN Features Extended Authentication • IKEv1 ○ XAUTH (eXtended AUTHentication) ○ Poprietär (Cisco, etc.) • IKEv2 ○ EAP (Extensible Authentication Protocol) ○ EAP-AKA, EAP-SIM, EAP-MSCHAPv2, EAP-MD5- EAP-GTC, EAP-TLS, … ○ Client initiiert EAP indem der AUTH Payload weggelassen wird ○ Server/Gateways muss als erstes public key AUTH Payload IPSec Passthrough • Transparent IPSec Connection • Leitet ESP und IKE Pakete an vorkonfigurierte Hosts hinter NAT Routern weiter • Nachteil: Jeder Router (Modell/Typ) wird anders konfiguriert, dh hoher Aufwand für einzelne Benutzer NAT Traversal • ESP in UDP Pakete • Typischer Szenario: Benutzer will von zuhause aus Arbeiten oder über gesicherte Verbindung (WLAN Hotspot, Hotel, etc.) zu Router verbinden. Dead Peer Connection • Polling • Paket (IKEv2 INFORMATIONAL) Request verschicken wenn nach längerer Zeit kein ESP/IKE Paket empfangen wird (dpddelay konfigurierbar, typie Werte zwischen 30-60s, bei MOBIKE 5min) • Wenn keine IKEv2 INFORMATIONAL Response erhalten wird wird der Request wiederholt. Nach etwa 5 versuchen über 2-3 Minuten wird die Verbindung als Tot deklariert, terminiert und alle SA/CHILD SA gelöscht. Übung IKE_SA_INIT • Request/Response im Klartext (2 Pakete) IKE_AUTH • Request/Response verschlüsselt (erstellt ersten CHILD_SA Tunnel zu Gateway) CREATE_CHILD_SA • Request/Response verschlüsselt für weitere CHILD_SA (Tunnel zu Netzwerk) Narrowing Gateway kann Client Zugriff einschränken auf bestimmtes Subnetz oder sogar Host OSCP • Online Certificate Status Protocol kann den Status von Zertifikaten in Echtzeit (bei jeder Connection) prüfen • Status 90 Minuten lang gültig (in Übung) und gecached ocspuri=http://intsec.hsr.ch:8880 • CRL (Certificate Revocation Lists) werden hingegen nur in bestimmten Abständen aktualisiert Virtuelle IP Adresse • Im Tunnel wird eine virtuelle IP vergeben • Damit das fremde Netz am anderen Ende wieder zum eigenen Host geroutet werden kann InfSi2_fscala Page 39 DNSSEC Freitag, 16. August 2013 11:03 DNS Resolution • IP Adressen der Root Server sind statisch/fix im Nameserver des ISP hinterlegt • Non-Authorative Answer Wurde von cache geholt, nicht direkt von einem autorisierten Nameserver Authorative Answer Antwort kommt direkt vom zuständigen Nameserver • Ablauf: 1. Anfrage für foobar.ch an ISP stellen 2. Anfrage weiterleiten an einen Root Server 3. Root Server gibt nächsten Nameserver zurück (z.B. SWITCH) 4. Anfrage an diesen Nameserver 5. Dieser gibt den endgültigen Nameserver für foobar.ch zurück 6. Endgültiger Nameserver wird angefragt 7. Dieser gibt die IP (Authorative Answer) zurück 8. Wir leiten diese an den ursprünglichen Requester weiter (als non-authorative Answer) Request Response DNS Cache Poisoning • Da das ganze nun über UDP läuft kann ein Angreifer den Requester einfach mit Response -Paketen flooden und eine falsche IP zurückgeben InfSi2_fscala Page 40 zurückgeben ○ Die QID sollte eigentlich die Anfrage identifizieren, diese wurde frühe einfach nur inkrementiert ○ Heute versucht ein solches Flooding einfachPakete mit allen möglichen QID zu senden, eine wird schon stimmen ○ Zudem muss der UDP Source Port stimmen Kaminsky Attack auf DNS Erlaubt es eine Domäne (z.B. auch .com) vollständig zu übernehmen. • • • • Im Prinzip dasaselbe wie oben, jedoch für den Nameserver selbst Erlaubt es somit eine komplette Domäne (eg .com) vollständig zu übernehmen Oben haben Pakete zwischen ISP Nameserver und dem authorisierten Nameserver gespooft Bei dieser Attacke hingegen übernehmen wir den Nameserver von foobar.ch (oder bankofsteve.com) indem bereits die Antwort für den entsprechenden Nameserver gepoisoned wird. • Lösung von Microsoft nach Publikation: Von Anfang an bereits 2500 UDP Ports öffnen ○ Dh 65k mögliche QIDs (16 bit) und 2500 Ports = 2500 * 2^16 = 163'840'000 nötige Pakete für einen 100% erfolgreichen Angriff DNSSEC • Chain of Trust ähnlich wie bei TLS ○ Nur eine root zone (zum glück), nicht so wie bei TLS x CAs existieren ○ Root Zone wird von ICANN signiert (mehrere Vertreter aus mehreren Ländern da sonst streit Internet Übernahme etc) • Root Key muss beim aufsetzen eines manuell importiert werden (der wichtigste überhazupt) KSK 257 • Key Signing Key • Mit diesem wird periodisch ein Arbeitsschlüssel signiert • Wird nur irgendwie alle 3 Monate aus dem Tresor genommen um den ZSK zu signieren (reduziert Risiko) • 2048 Bit, da eine Lebensdauer von einigen Jahren besitzen sollte ZSK 256 • Zone Signing Key • Arbeitsschlüssel der Root Zone • Mit diesem werden Zone Files signiert • Meistens 1024 Bit relativ schwach jedoch wird dieser alle 3 Monate neu signiert Aufteilkung in KSK/ZSK ein Taktisches Mittel damit der "oberste Key" (KSK) nicht "online" bzw. immer verfügbar sein muss sond ern die meiste Zeit eigesperrt bleiben kann. • Root Zone signiert ca. 300 Top Level Zonen • eg .ch wird von Root Zone signiert • Es wird ein Delegation Signing Record signiert (vertrauen zwischen .ch und root Zone herstellen) ○ SHA-1 oder SHA-256 Hash auf dem KSK der .ch Zone wird signiert ○ Wird von ZSK von Root-Zone signiert ○ .ch Zone generiert dann aus diesem KSK einen ZSK (Arbeitsschlüssel) womit dann wieder weitere Subzonen signiert werden (z.b. foobar.ch) • Es gibt immer nur 1 Signatur pro Set (z.B. Google hat mehrere Nameserver, werden alle zusammen signiert, nicht jeder einzeln) ○ Es gibt nur 1 einzige Signatur Signatur ist relativ gross InfSi2_fscala Page 41 ○ Signatur ist relativ gross • Nachteil: Es gibt keine Revocation List. Ist ein Problem bei kompromittierung. Abhilfe: Oft erneuern. Eher bei Caches ein Pri oblem. • Switch signiert natürlich mehrmals am Tag seine Zone neu da neue Einträge hinzukommen. DNSKEY • 256 = 256 ZSK RRSIG • Resource Record Signature • 172800 = Time To Live (TTL) - Wie lange cachen • Bis-gültig, ab-gültig (Expiration, Inception) • Signatur nur in diesem Zeitraum gültig • Signatur relativ "gross" • Signatur macht Kaminsky Attacke unmöglich da bei falscher Signatur die IP nicht akzeptiert wird • Key Tag gibt an wer Signiert hat DS • Delegation Signer • Signatur für den KSK der Subzone (KSK) NSEC • Next Owner Name • Als Antwort wenn die angefragte Domain nicht existiert • Stellt sicher, dass es keinen Domain zwischen merapi.switch.ch und mercury.switch.ch gibt • Für jeden Eintrag gibt es einen NSEC Eintrag • Erlaubt enumeration der gesamten Zone • Anfrage zwischen mercury. und etwas dazwischen was es nicht gibt = gibt nächsten NSEC Eintrag InfSi2_fscala Page 42 NSEC3 • Next Owner Name in Hashed Order • Dasselbe jedoch mit Hashes statt dem Domain Namen • Keine Enumeration der Daten Möglich • Dictionary Attacken möglich jedoch eher teuer • Alle Hashes Enumerieren • Brute-Force, alle "eher kürzeren" namen werden schnell herausgefunden • Heuristiken, Wörterbücher • Empfehlung: Mehrmals (z.B. 1000) mal Hashen, ist jedoch Zeitaufwändiger DANE • • • • DNS-based Authentication of Named Entities Relativ Neu Definiert neuen Resource Record (TLSA) Stellt sicher, dass man mit der entsprechenden Entity verbunden ist • Man kann gesamte Zertifikate oder den Public Key im TLSA Eintrag hinterlegen • Oder Hash über das Zertifikat oder Public Key hinterlegen • Abhilfe um die "CA-Zwischenfälle" zu verhindern ○ Wenn diese gehackt wird kann ein Zerifikat für z.B. hsr.ch generiert werden und die echte Seite gespooft werden (auf falsche Seite umleiten, die Vertrauenswürdig erscheint) • Erlaubt auch vertauenswürdige Self-Signed-CA ○ Self-Signed-CA Hash im Nameserver/Zone hinterlegen ○ Zertifikat via TLSA Record herunterladen ○ Check = Vertrauenswürdig über Chain of Trust von DNSSEC, statt TLS Chain of Trust ○ Nachteil: Belastet das DNS System (ganze Zerifikate herunterladen…) Root Zone Signing Process InfSi2_fscala Page 43 InfSi2_fscala Page 44 NAC Freitag, 16. August 2013 12:55 Traditionelle Strategie • Firewall verwenden um leigitmen Traffic von nicht legitimen Traffic zu trennen ○ Grund: Software ist scheisse entwickelt, sonst bräuchte es keine Firewall ○ Firewall ist eher eine Notlösung weil Software so schlecht ist • Grundprinzip/State of the Art • Beispiel: UDP blockieren ausser DNS • Last Resort um Firewall zu umgehen: Port 80/443 Outer Perimeter • DMZ (Demilitarisierte Zone) • Firerwall davor, jedoch von aussen erreichbar • Webserver, Mail, VPN, etc. Inner Perimeter • Intranet • Secure/Trusted Zone • Proxy Server oder Application Level Firewall dazwischen Internet • Insecure Zone Stateful Inspection Firewall • Statische Rules (z.B. UDP oder Port 23 ist verboten) sind stateless • Stateful hingegen besitzen einen State ○ z.B. SYN Pakete nur von innen nach aussen ○ Viele statische Rules erübrigen sich dadurch ○ Schliesslich kann man nicht "plötzlich" von aussen Pakete empfangen ohne erst einen Request nach aussen gemacht zu haben ○ Niemand darf von aussen eine Connection initiieren (TCP) ○ Bei UDP nur wenn davor auch ein Paket nach aussen verschickt wurde Paket Filter vs. Proxy Paket Filter InfSi2_fscala Page 45 Paket Filter Proxy • Proxy verhindert Exploits/Vulnerability Scanner und Brute-Force • Firewall ist somit nicht in DMZ, nicht "exposed* Network Access Control • Heutige Strategie • Problem ○ Man weiss nicht was auf den Clients installiert ist ○ BYOD: Bring Your Own Device Zusätzlich zur Authentication wird der "Gesundheitszustand" des Clients geprüft • Läuft der Antivirus • Sind die Antivirus Updates installiert/aufdatiert • Alle Patches installiert • Sind irgendwelche Security Policies enforced • etc… Diese Prüfungen müssen periodisch und nicht nur am anfang (beim Login) gemacht werden sonst könnte man: • Firewall einschalten • Torrents ausschalten • Login • Firewall wieder ausschalten • Torrents wieder einschalten • … Microsoft (Microsoft Network Access Protection - NAP) macht den Check ca. alle 20 Sekunden Trusted Network Connect (TNC) InfSi2_fscala Page 46 Drei Varianten: • Allow • Isolate • Block Metadata Access Point • Informationen Sammeln • Entscheidungen anhand dieser Informationen Beispiel: Herr Müller loggt sich in zwei (physischen) Räumen gleichzeitig ein, also stimmt etwas nicht (Passwort geklaut oder weitergegeben etc.) einer dieser Login versuche (oder gleich beide oder den Account) blockieren. Übung TNC Trusted Network Connect PEN Private Enterprise Number IMV Integrity Measurement Verifier IMC Integrity Measurement Collector MAP Metadata Access Point InfSi2_fscala Page 47 PDP • Policy Decision Point • Gibt Empfehlung • "evaluation" (compliant, non-compliant minor/major und recommendation = isolate) PEP • Policy Enforcement Point = VPN Gateway • Setzt Empfelung um (isolate, allow, block) • "capability" wird auf Gruppenzugehörigkeit (isolate, allow, block) gesetzt • Init - Server Working - Client Working - Server Working - Decided - End (I SCS DE) • Kriterien ○ Adressen/Gruppen ○ Offene Ports ○ OS Einstellungen InfSi2_fscala Page 48 Buffer Overflows Freitag, 16. August 2013 15:01 Begriffe Stack • Wird verwendet um Funktionsparameter zu übergeben • Beginng bei Liniux bei 0xC0000000 und "wächst" zu tieferen Adressen • Push aller Parameter vor dem Funktionsaufruf • In der Funktion werden alle wieder vom Stack gepoppt Heap • Dynamisch allozierte Strukturen (Objekte, malloc/free etc) • Wächst von tiefen zu höheren Adressen BSS • Enthält uninitialisierte globale oder statische Variablen z.B. static int array[512]; Data • Enthält initialisierte globale oder statische Variablen z.B. static int i = 0; Text • Enthält den Ausführbaren Code des Programms. • Üblicherweise als Read-Only markiert, jegliche Schreibzugriffe führen zu segfaults • Beginnt bei Linux bei 0x8048000 Pointer Instruction Pointer (IP, %eip) • Pointer auf nächste Instruktion • Wenn es gelingt diesen zu überschreiben ist es möglich eigenen (im Memory vorhandenen) Code auszuführen. Stack Pointer (SP, %esp) • Pointer auf Stack Base or Frame Pointer (BP, %ebp) Buffer Overflows InfSi2_fscala Page 49 • Userinput mit strcpy() in ein char array von 4 Zeichen kopieren wird bei mehr als 4 Inputzeichen zu einem Buffer Overflow führen. ○ IP wird überschrieben und zeigt auf eine potenziell ungültige Adresse was zu einem Segmentation Fault führt. ○ strncopy vwerwenden Rücksprungadresse ändern • ret = buffer + 60 ○ 48 Bytes für unseren Buffer ○ 8 Bytes werden von gcc freigehalten ○ 4 Bytes für den Base Pointer ○ 48 + 8 + 4 Execve • execve(char file[], char args[], char env[]) • Führt das angegebene File anstelle des eigenen Prozesses aus (der eigene Prozess wird mit dem neuen Programm vollständig ersetzt) • Der neue Prozess erbt alles (PID, Rechte, etc) vom ursprünglichen Prozess Adresse eines Strings im Memory herausfinden • Jump ans Ende des Strings • Adresse "notieren" • Vom Ende wieder an den Anfang Springen InfSi2_fscala Page 50 Null-Terminierter Shellcode • Sobald wir unseren Shellcode beisammen haben bleibt das Problem das diese womöglich 0x00en enthaltet was bei einem strcpy nicht den gesamten Shellcode nehmen würde. • Lösung: 0x00en Substituieren ○ NOPs Werden vor dem Shellcode angefügt um den Speichert vor dem Instruction Pointer zu überbrücken (z.B. den überschriebenen Buffer) 0x90 in Assembler, No Operation InfSi2_fscala Page 51 0x90 in Assembler, No Operation Buffer Overflow Schutzmassnahmen Es gibt einige Möglichkeiten um Buffer Overflows zu erschweren, keiner dieser Massnahmen bietet jedoch einen absoluten Schutz. Address Space Layout Randomization • Randomisierung der Basisadresse sowie Adresse von Libraries, (ASLR) Heap und Stack (-Anfangsadresse) im Adressraum • Es gibt Methoden um diese Schutzmassnahme zu umgehen Canaries Executable Space Protection (NX bit) • Vor den Pointern (BP, IP, etc) einen fixen Wert hinschreiben und vor dem Rücksprung prüfen ob dieser noch gleich ist Terminator Canaries • Bestehend aus NULL oder CR/LF • Bietet keinen Schutz gegen doubleoverflows (Canary einfach wiederherstellen) Random Canaries • Werden bei Programmstart generiert und in einer globalen Variable abgelegt • Kann vom Exploit gelesen und extrahiert werden falls dessen Adresse bekannt ist Random XOR Canaries • Random Canaries welche mit Kontrolldaten XOR'ed werden • Memory Regionen als nicht Ausführbar (non-executable) markieren. Versuch diese auszuführen führt zu segfault • Trennung von Daten/ausführbarem Code (weg von der von Neumann Architektur) • Sehr sicher, jedoch kein absoluter Schutz InfSi2_fscala Page 52 Smart Card Freitag, 16. August 2013 15:01 Typen • Sim Card • USB Token • Crypto Card • Memory Card • Java Card •… • Die meisten heute mit Prozessor • Viele mit on-chip RSA Encryption Contactless • RFID (Spannung von ausser, deshalb nahe genug) • Viele sowohl Contactless und Chip Proximity Card < 10cm Vicinity Card (selten) 10cm-1m Display Card • Mit Display • Für One-Time-Passwords (z.B. UBS Online Banking) • Lange Batterielaufzeit (> 3 Jahre) NFC • Near Field Communication • Mobile Devices • Für Zahlung, E-Tickets, Zugriffskontrolle, … Form-Faktor InfSi2_fscala Page 53 • Format (Kreditkartenformat) ist normiert (ISO) RSA • Können on-chip generiert und gespeichert werden • Oder auf den Chip heruntergeladen werden • Jedoch nicht mehr gelesen werden Chip nicht grösser als 2mm Kantenlänge weil es sonst im Portemonnaie bricht (Silizium ist spröde) Aus diesem Grund ist man relativ limitiert in der Funktionalität, Speicher, … ROM zwischen 8-200kb Betriebssystem dieser grösse eine grosse Herausforderung Muss auch high-seucrity sein, darf keine Lücken enthalten InfSi2_fscala Page 54 Platform Trust Service Freitag, 16. August 2013 15:01 Trusted Platform Module (TPM) Architektur RSA Key Pair Generator • 2048 (default) RSA Public und Private Key generierung • Verwendet den eigenen on-chip Random Generator für die Primzahlen Symmtetric Encryption Engine • Optional • Viele Hersteller implementieren AES Platform Configuration Registers • 160 bit geschützter Speicher zur Speicherung von Integritätswerten Endorsement Key (EK) • 2048 bit unlöschbares RSA Schlüsselpaar der den TPM Chip identifiziert • Der Hersteller sollte ein X.509 Zertifikat (Endorsement Credential - EC) mit dem Public Key enthalten und sicherstellen das der EK korrekt generiert wurde. Verwendung (Take TPM Ownership) • Im BIOS sollte ein Supervisor Passwort gesetzt werden • Security Chip auf Enabled setzen Man muss physisch Anwesend sein InfSi2_fscala Page 55 ○ Man muss physisch Anwesend sein • Verwendung des TPM im Betriebssystem aktivieren (z.B. TPM Management bei Windows) Storage Root Key (SRK) • Der SRK wird generiert sobald der TPM den Owner wechselt (take TPM Ownership) ○ Der Wechsel führt zur Löschung des SRK! • Tiefer der Hierarchie/Keys ist nur vom Speicher limitiert Hybride Dateiverschlüsselung mit Storage Keys Verschlüsselung • Dateien oder ganze Dateisysteme werden mittels einem symmetrischen Schlüssel welcher vom Random Number Generator RNG generiert wird und AES verschlüsselt. (SymK) • Der für die Verschlüsselung verwendete symmetrische Schlüssel wird mittels einem mit dem RSA Generator generiertem Schlüsselpaar bzw. dessen Public Key verschlüsselt (StorK_Pub) • Der Private Key wird mittels Public Key vom SRK verschlüsselt. (SRK_Pub) Entschlüsselung • Das Ganze in umgekehrter Reihenfolge ○ SRK_Priv verwenden um an StorK_Priv zu gelangen um an SymK zu gelangen um das File zu entschlüsseln • Die Entschlüsselung ist somit an den physischen TPM Chip (bzw. dessen SRK, welcher darin gespeichert ist) gebunden Attestation Identity Keys (AIK) • Alias für Plattform Identität (Endorsement Key) • Sollte verhindert das TPMs getrackt werden können (da AIKs generiert werden können, der EK jedoch nicht -> Tracking möglich) • Sind nicht migrierbar • TPM kann mehrere AIKs besitzen • Werden vom Owner generiert InfSi2_fscala Page 56 • Werden vom Owner generiert • Benötigen Zertifizierung einer Third-Party (CA) welche sicherstellt das der AIK von einem TPM generiert wurde Binding vs. Sealing Binding Sealing • Asymmetrische Verschlüsselung • Kann verwendet werden um Daten an TPM/Plattform zu binden • Wenn explizit nicht migrierbare Schlüssel verwendet werden • Üblicherweise kein binden an das TPM/Plattform • Keine Interaktion mit dem TPM nötig • Daten werden immer an TPM/Plattform gebunden • Funktioniert nur mit nicht-migrierbaren Schlüsseln • Konfiguration kann verifiziert werden • Ciphertext beinhaltet Zustand der Plattform zum Verschlüsselungszeitpunkt • Entschlüsselung kann auf bestimmte Konfiguration eingeschränkt werden • Zustand der Plattform muss stimmen (trusted) sonst wird nicht entschlüsselt Intel Trusted Execution Technology (TXT) TPM Verwendungstzwecke Authentisierung Email • Verschlüsselung mit TPM • Via PKCS#11 Smart Card Interface Multi-Factor Auth. • Ein TPM ist ebenfalls etwas was man "besitzt" VPN • Benötigt keine Smart Card ohne Hardware Tokens WLAN • Automatische Identifikation des Benutzers anhand des TPM (802.1x) Datenschutz Performance • Schnellere Verschlüsselung da direkt im Disk Controller integriert mit maximalen Speed. • CPU wird dafür nicht beansprucht (keine degradation der Performance) Starke Verschlüsselung • Keys verlassen die Hardware niemals • User-Auth. wird durchgeführt bevor der TPM zugänglich wird (OS abhängig) Tiefere Besitzerkosten • No modifications to the OS, applications or tools • Crypto erase provides instant repurposing / decomissioning TPM zur Verschlüsselung • BitLocker verwendet den TPM um die Schlüssel zu speichern Übung • TPM muss für neuen Owner deaktiviert/aktiviert (Take ownership) werden, Daten werden gelöscht, sonst kommt folgende Meldung beim init im OS • EK zehn Jahre lang gültig, Vertrauen durch VeriSign • File Sealing (an PCR Werte gebunden), File enthält ENC_DAT Mit AES-256-CBC verschlüsseltes File ENC_KEY Der dazu verwendete AES-256 Schlüssel, mit dem Public Key (2048 Bit) eines Storage Keys verschlüsselt TSS_KEY Der Private Key des Storage Keys, mit dem 2048 Bit Storage Root Key (SRK) verschlüsselt, kann nur vom TPM selbst entschlüsselt werden wenn die PCR Werte stimmen • TNC + TPM verringert Gefahr von "Lying Endpoints" ○ Identifikation ahand SHA-1 Fingerprint des AIK Public Keys ○ TNC basierend auf PCR Referenzwerten die anfänglich auf dem Server hinterlegt werden ○ Bei jedem Connect müssten diese nun wieder übereinstimmen ○ Client = Attetastion Integrity Measurement Collector Server = Attestation Integrity Measurement Verifier InfSi2_fscala Page 57 ○ Server = Attestation Integrity Measurement Verifier InfSi2_fscala Page 58 WhiteHat Report Freitag, 23. August 2013 18:18 • Verglichen zu Vorjahren stets sicherer ○ Weniger Lücken ○ Schneller gefixt (time to fix) ○ Mehr überhaupt gefixte (remediation rate) • Banking scheint am sichersten • Zahlen sind mit Vorsicht zu geniessen ○ Könnten auch schlichtweg weniger genau von den Organisationen ausgewertet/gemeldet worden sein ○ Report zeigt lediglich das die Webseitens MINDESTENS soviele Lücken besitzen • SQL Injection ist die beliebteste Vulnerability • Injection-Typen scheinen oft reopened zu werden (SQL Injection und XSS wurden 1/4 reopened) • Retail-Webseiten haben sich extrem verbessern Am langsamsten • Non-Profit • Financial Services, • Telecommunication Am meisten gefixt • Banking • Telecommunication • Manufacturing Am schnellsten • Banking • Am längsten mindestens eine ernste Lücke • Non-Profit • Eduction • Social Networking • OS Command Injectiona praktisch keine • SQL Injection Typen Unauthenticat • Braucht kein Login • Automatisiert ed Worms • Braucht kein Login • Automatisiert • Zielt nicht auf Extraktion ab sondern Infizieren von weiteren Benutzern welche die Webseite besuchen Sentinent • Extrahieren Daten Targeted • Meist mit Account • Ausfüllen von Formularen etc. • Web Application Firewall (WAF) kann grossen Unterschied bei XSS, SQL Injection, … machen ○ Patches/Daten von WhiteHat Sentinel ziehen = immer up to date • Target of opportunity • Wahl aufgrund von weniger Sichetheitsmassnahmen • Einfacher zu exploiten • etc … Target of choice • Gezielt • Besitzen meist wertvolle Informationen • Sollten ASAP gefixt werden InfSi2_fscala Page 59 • Information Leakage und XSS scheinen weit oben bei allen Industries • XSS neu Nummer 1 • Remediation rate ○ Niemand fühlt sich verantwortlich für den Code ○ Niemand kennt den Code ○ Features haben höhere Prio ○ Kein Budget ○ 3rd Party Software ○ Risiko wird akzeptiert ○ … • Time to fix • Window of exposure ○ Kombination aus (total vuln., time to fix, remediation rate) über Zeit ○ Jemand mit 100 Lücken über 10 Tage hat bessere Sicherheit als jemand mit 10 Lücken über 365 Tage ○ Hat sich in einem Jahr (2010 vs 2011) nur geringfügig verbessert (um 2 Tage, 233 vs 231) • Reopen Rates • Prioritäten auf schwächstes Glied setzen ○ Jemand der kaum neue Exploits einführt sollte sich auf den remediation Prozess konzentrieren uÄ ○ Jemand der täglich neue Exploits einführt sollte erst die offenen Probleme beheben (stop bleeding), Q&A, Entwickler Schulen, etc. • Einige Exploits sind schwieriger zu fixen als andere • Generell Exploits die mittels eines Frameworks (Core Komponente, Zentralisiert) veraltet werden können (SQL Queries, Input Validation etc) scheinen tiefere reopen Rate zu besitzen InfSi2_fscala Page 60 Alte Prüfungsfragen InfSi2_fscala Page 61 Crypto Strength Q Wie verhindert der Message Authentication Code (MAC), dass eine Drittperson ein durch einen MAC gesichertes Dokument oder Nachricht verändern kann? A • Der Absender bringt ein "Geheimnis" (Pre-Shared-Key) welches nur ihm und dem Empfänger bekannt ist in den Message Digest (Hash) mit ein. • Bei HMAC wird der Pre-Shared-Key als erster Block durch die Hashfunktion verarbeitet, sodass ein geheimer IV gebildet wird. Q Aus welchen zwei Gründen wird bei einem HMAC der MAC Wert oft durch Abschneiden (Truncation) aus dem endgültigen Hashwert gebildet? A • Durch Truncation wird der Overhead minimiert (16 statt 32 Bytes bei einem SHA-256_128_HMAC) • Durch Truncation wird nicht der gesamte letzte (interne) Zustand der Hashfunktion übertragen (und exposed) was Attacken auf den PSK erschweren kann. • Bei einem Hashwert der Länge m ist die Kollisionsresistent im Maximum m/2. Durch Truncation auf m/2 wird die Resistent einer Preimage-Attacke von m auch auf m/2 halbiert, sodass eine durchgehende Stärke von m/2 resultiert. Q Geben Sie je eine Kombination eines Verschlüsselungs- Hash und Schlüsselaustausch-Algorithmus an, die eine durchgehend homogene Stärke von a) 112, b) 128, c) 192 und d) 256 hat A a) 112 3DES-EDE + SHA-2_224 + DH ECP-224 b) 128 AES-128 + SHA-2_256 + DH ECP-256 c) 192 CAMELLIA-192 + SHA-2_512 + DH ECP-384 d) 256 AES-256 + SHA-2_512 + DH ECP-521 InfSi2_fscala Page 62 Q Welches der beiden Passwörter besitzt die höhere kryptographische Stärke? Die Blanks sind nicht Teil der Passwörter. • A572D 80CE3 6F4D9 BF138 FF27A 945DE • r91Lo FnpyT K/I8S vWIRk A • 30 Hex Nibbles * 4 Bit Entropie/Nibble = 120 Bit • 20 Base64 Symbole * 6 Bit Entropie/Buchstabe = 120 • Die Passwörter sind gleich Stark Q Erfüllen folgende zwei Passwörter mindestens 192 Bit Stärke? Begründen Sie Ihre Antwort • sNI0 3mss d+w7 ckzq +K3Z cEYs guo5 aNSJ • 09 c5 85 4b bc 02 48 de dc 24 10 23 ed 22 15 3f A • 32 Base64 Symbole * 6 Bit Entropie/Symbol = 192 Bit • 16 Bytes (Hex) * 8 Bit Entropie / Bate = 128 Bit Das zweite Passwort ist somit schwächer als die geforderten 192 Bit der Suite B. Q Welche IKEv2 Crypto Algorithmen wurden in folgendem Beispiel für Verschlüsselung, Datenintegrität, Key Exchange und Authentisierung verwendet? InfSi2_fscala Page 63 A Verschlüsselung AES-CBC mit 256 Bit Key Datenintegrität SHA-384 HMAC Key Exchange Elliptic Curve Diffie-Hellman (ECDH) mit 384 Bit Modulus Authentisierung Elliptic Curve Digital Signature Algorithm (ECDSA) mit 384 Bit Modulus Q Welche kryptographische Stärke wird mit der oben genannten Wahl angestrebt? A 192 Bit Q Mit welchen Crypto-Algorithmen werden die IP Pakete verschlüsselt und gegen Veränderung geschützt? Was ist zudem der grosse Vorteil an dieser Wahl? A • AES-GCM (Authenticated Encryption Algorithmus - AEAD) mit eingesetzt welches gleichzeitig verschlüsselt und eine kryptographische Checksumme generiert. • Durch AEAD wird eine Parallelisierung mit hohem Datendurchsatz möglich Q Alice und Bob möchten mittels Elliptic Curve Cryptography (ECC) ein gemeinsamen Diffie-Hellman Geheimnis erarbeiten. Die Parameter der Kurve sowie ein Kurvenpunkt P sind öffentlich bekannt. • Alice wähl eine zufällige geheime Zahl a = 300 und führt 299 Mal auf der Kurve eine Punktaddition von P mit sich selbst aus, sodass sich ein Bildpunkt Q_A ergibt welches über einen unsicheren Kanal an Bob übermittelt wird. • Bob wählt eine zufällige geheime Zahl b = 520 und führt 519 Mal auf der Kurve eine Punktaddition von P mit sich selbst aus, sodass sich ein Bildpunkt Q_B ergibt welches über einen unsicheren Kanal an Alice übermittelt wird. 1. Worauf beruht die kryptographische Stärke des Elliptic Curve Diffie-Hellman Schlüsselaustausches? 2. Wie bestimmten Alice und Bob das gemeinsamen Diffie-Hellman Geheimnis S, welches auch einen Bildpunkt der elliptischen Kurve darstellt? 3. Welche geometrische Beziehung besteht zwischen dem Diffie-Hellman Geheimnis S und dem öffentlichen Kurvenpunkt P? InfSi2_fscala Page 64 1 • Aus den Bildpunkten Q_A und Q_B kann nur mit riesigem Aufwand bestimmt werden, wieviele Punktadditionen (a-1) bzw. (b-1) auf P angewendet wurden um auf Q_A bzw. Q_B zu kommen. 2 • Alice führt auf der Kurve (a-1) Mal eine Punktaddition von Q_B mit sich selbst aus um den Bildpunkt S zu erhalten. S = aQ_B • Bob führt auf der Kurve (b-1) Mal eine Punktadditional von Q_A mit sich selbst aus um den Bildpunkt S zu erhalten. S = bQ_A 3 • Der Bildpinkt S kann durch (ab-1) = 155'999 Punktadditionen von P mit sich selbst erhalten werden. S = abP = 156'000P Q Generieren Sie ein Passwort mit den Ziffern 0..9 mit einer kryptographischen Stärke von ca. 100 Bit A • 100 Bit / 3.3 Bit Entropie/Symbol = 30 Ziffern • 683951949354872165421365459753 Q Eine auf einem HMAC-SHA256 basierte Pseudo Random Function (PRF) wird mit einem geheimen 256 Bit Schlüssel geladen der völlig zufällig von einer Quanten-Quelle generiert wurde. Initialisiert mit einem Seed von 512 Bit liefer t die PRF nun 1536 Bit Schlüsselmaterial, welche für zwei 256 Bit AES Sessionschlüssel und zwei 512 Bit HMACSHA512 Sessionschlüssel verwendet werden. Wie können alle vier Sessionschlüssel am effizientesten durch eine Brute-Force Attacke geknackt werden und wieviele Versuche braucht es im Worst-Case dazu? Begründen Sie Ihre Antwort. A • Die Brute-Force Attacke zielt auf die PRF mit 256 Bit Schlüssel da alle anderen Schlüssel davon abgeleitet sind und deshalb die 1536 Bit nicht mehr als 256 Bit Entropie besitzen. • Am besten wird bei jedem Versuch jeweils nur der erste 256 Bit AES Sessionschlüssel durch die PRF abgeleitet und durch die Entschlüsselung und Histogrammbildung getestet ob Plaintext resultiert. • Dazu sind im Worst-Case 2^256 = 1E77 nötig. InfSi2_fscala Page 65 Random Numbers Q Was können Sie über die Qualität folgender Zufallsquelle aussagen? A • Diese liefert scheinbar ständig und zuverlässig Zufallsinformationen • Der Wert logisch 1 tritt jedoch viel häufiger auf als 0, die Quelle ist somit mit einem Bias behaftet Q Was können Sie über die Qualität folgender Zufallsquelle aussagen? A • Diese liefert Zufallsinformationen mit einer guten statistischen Verteilung (0 und 1 gleichverteilt) • Jedoch treten immer wieder Aussetzer im Datenstrom aus, die Quelle ist somit sehr unzuverlässig Q Wie können nicht-ideale Zufallsquellen zum Bau eines guten True Random Generators verwendet werden? A • Die eingehenden Werte der Zufallsquellen mittels einer Hashfunktion in einen einzigen Entropie-Pool einarbeiten • Diese Pool kann dann als zufälligen Seed für einen guten Pseudo Random Number Generator verwendet werden Q Was halten Sie vom Ansatz die OpenSSL PRF welche z.B. für die Generierung von RSA Schlüsselpaaren verwendet wird mit der zufälligen 16 Bit langen Linux Prozess ID zu initialisieren? Hätte man nicht besser noch die Seriennummer der Intel oder AMD Prozessors dazugenommen? A • 16 Bit Entropie sind viel zu wenig um 1024-2048 Bit RSA Schlüssel (mit einer Entropie von 72-88 Bit) zu generieren. • Auch Seriennummern jeglicher Art erhöhen die Entropie nicht signifikant. Q Welche der folgenden zwei Zufallsquellen würden Sie zur Speisung des Entropie-Pools /dev/random auf einem Server verwenden? 1. Der interne, relativ ungenaue und schwankende Clock-Generator der CPU 2. Die Zugriffszeiten auf den RAID Festplatten Array A • Durch die chaotischen Luftwirbel verursachten Schwankungen in den RAID Zugriffszeiten ergibt sich ausgezeichnete Entropie • Obwohl die Frequenz von Clock-Generatoren einen hohen Zufallsgehalt hat ist häufig die Zeitauflösug grob, sodass zu Teil mehrmals der gleiche Tickwert zurückgegeben wird. Zudem ist der Clock kurzfristig sehr stabil, sodass wenig Entropie gewonnen werden kann. Q Welche der folgenden zwei Zufallsquellen würden Sie zur Speisung des Entropie-Pools /dev/random auf einem Server verwenden? Begründen Sie die Entscheidung. 1. Das Timing von akommenden Netzwerkpaketen 2. Die gesampelten LSBs auf der auf dem Motherboard vorhandenen 16 Bit InfSi2_fscala Page 66 2. Die gesampelten LSBs auf der auf dem Motherboard vorhandenen 16 Bit Soundkarte? A • Die verrauschten LSBs einer 16 Bit Soundkarte sind eine gute Entropiequelle und deshalb dem Paket-Timing vorzuziehen. • Die Ankunft von Netzwerkpaketen könnte gezielt von aussen (durch Einspeisen von Paketen) manipuliert werden. Q Worauf muss bei der Verwendung externer Entropiequellen wie CPU Clock-Generatoren, RAID-Controllern etc. besonders geachtet werden? A • Es muss eine fortlaufende Abschätzung des Entropiegehaltes vorgenommen werden um Totalausfälle (fehlende Zeitmessung der RAID Controller) oder wenig Entropie (zu grobe Auflösung des CPU Clock-Counters) erkennen und einen Alarm auslösen zu können. Q Bewerten Sie qualitativ die Ergiebigkeit (echte Zufallsbits pro Zeit) und die Qualität (Zufälligkeit der statistischen Verteilung) der folgenden Entropiequellen. 1. Timing von nacheinanderfolgenden Tastaturschlägen 2. Abtasten von Sounkarteneingängen 3. Zugriffszeiten bei Festplatten (Luftturbulenzen) 4. Abkunftszeiten von Netzwerkpaketen 5. Schwankungen des Rechnertakts A 1 • 1-2 Bit Entropie pro Tastenschlag • Gute Qualität 2 • Mehrere LSB pro Abtastwert sind verrauscht und können verwendet werden • Gefahr von Totalausfällen 3 • Sehr gute Quelle mit bis zu 100 Bit Entropie pro Minute 4 • Bei paranoiden Puristen eher verpönt da diese von aussen Manipuliert werden können 5 • Weniger als man denkt, da die Clockregister häufig nicht bei jedem Tick aufdatiert werden Q Ein militärischer VPN Gateway mit tausenden von gleichzeitigen Verbindungen benötigt sehr viel Entropie für die Generierung von Erneuerung aller Sessionschlüssel. Welche Hardwarelösung zur Generierung von Zufallsmaterial würden sie vorschlagen? A • Ein Quantum Random Number Generator welcher auf die Zufälligkeit von quantenmechanisch erzeugten Photonen beruht • Alternativ kann Radioaktiver Zerfall mit einem Geigenzähler gemessen werden Q Nach dem Start Ihres PCs wollen Sie gleich zwei mit je einem 128 Bit Session Key geschützte symmetrisch verschlüsselte Verbindungen zu den Servern jupiter und merkur aufbauen. Weiter werden je 160 Bit Schlüsselmaterial für die kryptographischen Checksummen (MACs) benötigt. Im Entropie-Pool Ihres PCs sind jedoch nur 300 Bit echte Zufallsinformationen vorhanden. Wie lösen Sie dieses Problem mit einer möglichst kleinen Sicherheitseinbusse sofort? A • 300 Bit echte Entropie werden als Seed für eine Pseudo-Random Function (PRF) verwendet. Mit dieser können dann 2 * 128 + 2 * 160 = 576 Bit Schlüsselmaterial erzeugt werden. Q Ein E-Banking Server baut pro Minute einige Tausend TLS Sessions auf und benötigt für den Diffie-Hellman Schlüsselaustausch entsprechend viel Zufallsmaterial. Welche Entropiequelle würden Sie empfehlen? A • Eine quantenmechanische Entropiequelle • z.B. Quantique kann 4-16 Mbit/s Zufallsmaterial liefern InfSi2_fscala Page 67 • z.B. Quantique kann 4-16 Mbit/s Zufallsmaterial liefern Q Auf einem PC leifert der Mikrofonausgang der Soundkarte folgenden Output: Wie kann die Statistik dieser Quelle verbessert werden, sodass diese aussieht alsob ein Affe eine Münze geworfen hätte? A • Hashen mittels einer Hash Funktion • Evt. mit John von Neumanns Anti-Bias Algorithmus Q Weshalb werden im folgenden Diagramm die HMAC Werte A(1), A(2), A(3), … nochmals gehasht bevor diese als pseudo-zufälliger Schlüsselstrom verwendet werden? A • Durch Kenntnis dieser internen Zustände sind sowohl der Input (Seed) wie auch der resultierende Output jeder HMAC Stufe bekannt. Obwohl zum heutigen Zeitpunkt keine Attacken bekannt sich, könnten dennoch Rückschlüsse auf den geheimen Schlüssel S erleichtert werden. Q Zählen Sie sechs Entropiequellen auf, welche auf einem vernetzten Desktop-PC meist vorhanden sind und bewerten Sie deren Ergiebigkeit und Qualität A Timing von Tastenschlägen • 1-2 Bit Entropie pro Tastenschlag • Gute Qualität Mausbewegung • Schnell viel Entropie • Gefahr von wiederholten (regelmässigen) Kreisbewegungen Abtasten von verrauschten Soundkarteneingängen • Mehrere LSB pro Abtastwert sind verrausch und können genutzt werden • Gefahr von Totalausfällen Zugriffszeiten bei Festplatten (Luftturbulenzen) • Sehr gute Quelle mit Entropierate von bis zu 100 Bit/Minute Ankunftszeiten von Netzwerkpaketen • Bei paranoiden Puristen eher verpönt, da die Ankunftszeiten von aussen manipuliert werden könnten Schwankungen des Rechnertakts • Weniger Entropie als man denkt, da die Clockregister häufig nicht bei jedem Tick aufdatiert werden InfSi2_fscala Page 68 häufig nicht bei jedem Tick aufdatiert werden Q Auf einem Linux System speisen eine defekte Soundkarte und ein Trusted Platform Module (TPM) Bitsequenzen in den Entropiepool von /dev/random. Die Bitstörme sehen über eine Dauer von 32 Bit wie folgt aus: Wieviele Bit Entropie enthält der Pool nach dem Einarbeiten diese Sequenzen, wenn er vor Beginn leer was? Begründen Sie Ihre Antwort. A • Die defekte Soundkarte liefert eine kontante Bitfolge von 0 1 mit Null Entropie während das TPM 32 echte Zufallsbits liefert • Aus diesem Grund enthält der Entropie Pool nach diesen zwei Sequenzen lediglich 32 Bit Entropie. InfSi2_fscala Page 69 Tor Q Weshalb werden nicht die Introduction Points für das Rendervouz verwendet, zu denen der anonyme Server ohnehin schon einen Circuit besitzt, sondern ein zufälliger gewählter Onion Router? A • Ein Introduction Point könnte rechtliche/ethische Probleme damit haben, als Rendezvous Point für zweifelhafte Dateien/Inhalte zu dienen • Ein jeweils zufällig ausgewählter Rendezvous Point hat keine Ahnung welche Transaktionen über ihn laufen und ist somit völlig unbelastet Q Welche drei Hauptdaten sendet ein Anonymer Client verschlüsselt mit dem Public Key des angebotenen Dienstes Introduction Point an den anonymen Server? A • Den Onion Router der als Rendezvous Point dienen wird • Ein Cookie welches auch am Rendezvous Point hinterlegt ist und dank dem der Tor Circuit des Servers mit dem bereits aufgebautem Tor Circuit des Clients im Rendezvous Point verbunden werden kann • Der öffentliche Diffie-Hellman Faktor der Clients für die verschlüsselte Client-Server Verbindung • Informationen über den Client Q Welche drei Hauptdaten sendet der anonyme Server an den Rendezvous Point, falls der Server entscheidet die Anfrage des anonymen Clients zu beantworten? A • Das vom Client erhaltene Rendezvous Cookie • Der öffentliche Diffie-Hellman Faktor des Server fürs die verschlüsselte Client-Server Verbindung • Ein Has über den aus dem Diffie-Hellman Austausch abgeleiteten Session Keys Q Wie wird gewährleistet, dass der Rendezvous Point passiv keinen Einblick in die zwischen Client und Server ausgetauschten Informationen erhält und nicht als Man-in-the-Midle auftreten kann? A • Durch den Diffie-Hellman Austausch ist die Client-Server Verbindung End-to-End Verschlüsselt • Der Hash über den Session Key ist der Beweis für den Client, dass er mit dem korrekten Server verbunden ist da der Client seinen Diffie-Hellman Faktor mit dem Public Key des Dienstes InfSi2_fscala Page 70 verbunden ist da der Client seinen Diffie-Hellman Faktor mit dem Public Key des Dienstes verschlüsselt hat und nur der Server diesen via Private Key entschlüsseln kann Q A Der NSA gelingt es in folgendem Netzwerk von anonymizing Mixes eine Benutzer/Server Beziehung aufzudecken. 1. Um welchen Benutzer und um welchen Server handelt es sich und wie konnte dies aufgedeckt werden? 2. Welche zwei Defizite weisen welche Nodes auf und welche Massnahmen müsste man dagegen unternehmen? 1 • Beziehung zwischen U2 und S3 via M2-M6-M5 • Die NSA speist aktiv das Paket VNF von U2 an M2 nochmals ein (replay) • Das Paket VNF wird immer zu RDX umentschlüsselt und kann somit von M2 zu M6 weiterverfolgt werden • Dasselbe wiederholt sich am Node M5 mit RDX auf FCI • Node M5 verwirft zwar dieses Duplikat, leitet jedoch das Paket HHM innerhalb einer Stunde als einziges an S3 weiter 2 • M2 und M6 akzeptieren Duplikate, entschlüsseln diese auf gleiche Art und weise und leiten diese weiter. Es kann durch diese Input/Output Korrelation auf den nächsten Mix geschlossen werden • Durch führen einer Hashtabelle alles eingehenden Pakete in einer Datenbank könnten Duplikate verworfen werden. • M3 und M5 leiten Pakete auch bei wenig Verkehr weiter sodass eine einzelne Nachricht weiterverfolgt werden kann. • Man müsste mehrere Pakete vor dem weiterleiten (in zufälliger Reihenfolge) zwischenspeichern. Dies führt jedoch unter Umständen zu hohen Latenzzeiten. Q Weshalb sind Pseudo-Anonyme Remailer fast von der Bildfläsche verschwunden? A • Als Single Point of Vulnerability erlauben diese das passives Sniffen von aussen das Korrelieren der ein- und ausgehenden Pakete • Zudem sind die Betreiber meist juristischem Druck ausgesetzt und es besteht die Gefahr von InfSi2_fscala Page 71 • Zudem sind die Betreiber meist juristischem Druck ausgesetzt und es besteht die Gefahr von Korruption/Bestechung Q Weshalb wird bei Chaum's klassischer "Cascade of Mixes" in jedem Mix eine Zwiebelschale entfernt und der damit freiwerdende Platz mit zufälligem Padding aufgefüllt? A • Garantiert die durchgehend gleich grösse aller Pakete um eine Korrelation zwischen ein- und ausgehenden Paketen aufgrund ihrer Grösse oder Bitmusters zu verhindern Q Weshalb verschlüsselt der Onion Proxy beim Aufbau einer Tor Verbindung der für einen bestimmten Onion Router bestimmten öffentlichen Diffie-Hellman Faktor mit dem Public Key des entsprechenden Hops, obwohl dieses kein Geheimnis darstellt? A • Dadurch werden MITM Attacken ausgeschlossen, da der entsprechende Hop sicher den passenden Private Key besitzen muss • Der korrekte Empfang und Entschlüsselung wird durch die Antwort mit einem Hash über das gebildete Diffie-Hellman Geheimnis quittiert. Q Wozu dient das Digest Feld im Tor Stream-Payload, welches einen vom Onion Proxy gebildeten Hashwert über das Klartext-Paket enthält? A • Ein Onion Router merkt nach dem entschlüsseln (entfernen einer Zwiebelschale) aufgrund der korrekten Checksumme/Hash das er auf den Klartext gestossen ist und somit als Exit-Point agieren muss. • Dadurch kann der Exit-Point dynamisch gewählt werden, ohne dass dieser wissen muss, dass er ein Exit-Point sein wird. Q Ein Netzwerksniffer überwacht einen Mixknoten und registriert folgende ein- und ausgehenden Datenpakete: Welche drei Defizite zeigt dieser Knoten einer High-Latency Anonymizer Kette? Begründen Sie Ihre Antwort. Defizit 1 Das Paket xczR0… wurde nicht umgeschlüsselt Defizit 2 Das Paket zx3RS… ist doppelt vorhanden und wird auch zwei Mal umgeschlüsselt als SpJsrh… weitergeleitet. Defizit 3 Alle Pakete scheinen ohne randomisierte Reihenfolge und nur mit minimaler Verzögerung den Mitknoten zu verlassen. Dies ist z.B. anhand von xczR0… und zx3RS… zu sehen. Q Die folgende Grafik zeigt den typischen Aufbau eines Mixnodes in einer Anonymisierungskette. Erläutern Sie den Nutzen der einzelnen Komponenten. InfSi2_fscala Page 72 Erläutern Sie den Nutzen der einzelnen Komponenten. A Database/Drop Duplicates • Um eine Korrelation zwischen Verschlüsselten Paketen und den ausgehenden umgeschlüsselten Paketen und deren Zieladresse zu verhindern wird eine Datenbank mit Hashes aller weitergeleiteten Pakete geführt und allfällige Duplikate verhindert. Es wird so verhindert das durch Einspeisen von Duplikaten via Replay (z.B. durch die NSA) auf den nächsten Hop geschlossen werden kann. Private Key/Decrypt • Dank der Zwiebelschalenprinzips und die umschlüsselung von Paketen an jedem Hop ist keine korrelation zwischen Ein- und Ausgehenden Paketen anhand der Bitmusters möglich. Zudem sollten alle Pakete, sei es durch zufällige Paddings, die gleiche grösse besitzen. Message Buffer/Resort • Ohne Randomisierung der Reihenfolge durch das Zwischenspeichern von Paketen wäre der nächste Hop aufgrund der Reihenfolge (FIFO) bekannt. Voraussetzung für einen guten Puffer ist ein grosses Verkehrsvolumen um die Latenz der Pakete möglichst gering zu halten. Q Weshalb bietet Tor den Exit Nodes die Möglichkeit eine Exit Policy zu definieren? A • Damit sich die Exit Nodes selbst vor Missbrauch wie versenden von Spam via SMTP Port 25 etc. schützen können. • Das Tor Netzwerk benötigt freiwillige Exit Nodes. Um solche zu gewinnen muss Ihnen diese Möglichkeit offen stehen. Q Wie können Exit Nodes ihre Position in einem Tor Netzwerk zu kriminellen Zwecken missbrauchen? A • Der Exit Node ist derjenige der potentiellen Klartext zum Endpunkt lesen und mithören kann. • Aus diesem Grund sollten möglichst nur verschlüsselte Protokolle wie HTTPS über Tor verwendet werden. Q Nennen Sie zwei Gründen weshalb der Anbieter von Hidden Services eine Reihe von Introduction Points wählt und nicht eifach direkt über einen Rendezvous Point (RP) veröffentlich. A • Der Rendezvous Point ist unter Umständen nicht mit dem Service bzw. dessen Content einverstanden • Der Rendezvous Point könnte durch Feinde des Hidden Service Betreiber durch DoS Attacken in die Knie gezwungen werden Q Der Anbieter eines Hidden Service generiert ein RSA Schlüsselpaar und hinterlegt den Public Key bei einer gewissen Anzahl von Introduction Points. Wozu dient dieser Public Key? A • Mit diesem Public Key kann jeder Client über den Introduction Point Kontakt mit dem Hidden InfSi2_fscala Page 73 A • Mit diesem Public Key kann jeder Client über den Introduction Point Kontakt mit dem Hidden Service aufnehmen und ihm Verschlüsselt Verbindungsdaten übermitteln. Q Der Client wählt zufällig einen Onion Router (OR) als Rendezvous Point (RP), baut ein Circuit zu dessen auf und übergibt ihm ein sogenanntes Rendezvous Cookie. Wozu dient dieses Cookie? A • Der Client übermittelt dieses Cookie zusammen mit dem Namen des RP via Introduction Point an den Hidden Service, welcher dann ein Circuit zum RP aufbaut. • Der Hidden Service identifiziert sich beim RP mittels Cookie und wird dadurch mit dem Circuit des Clients verbunden. Q Wozu dient der öffentliche Diffie-Hellman Faktor, den der Client bei der Verbindungsaufnahme mit einem Hidden Service via Introduction Point an den Hidden Service übermittelt? A • Der öffentliche DH Faktor des Clients wird für die End-to-End Verschlüsselung der Kommunikation zwischen Client und dem Hidden Service via dem Rendezvous-Point benötigt. • Der öffentliche DH Faktor des Hidden Service wird bei der Verbindungsaufnahme via RP an den Client übermittelt. InfSi2_fscala Page 74 DNSSEC Q Begründen Sie weshalb der Benutzer aufgrund folgendes Screenshots sicher sein kann, dass nicht einfach der Webserver down ist sondern dass die Domäne nicht existiert? A • Grünes Schlüsselsymbol des DNSSEC Validator Firefox Plugins visualisiert die signierte NSEC oder NSEC3 Antwort des .ch DNS Servers, dass kein Eintrag für die intsi1.ch Zone existiert. Q In folgendem Screenshot scheint die Chain of Trust nicht bis zur Root Zone zu reichen. Welcher Eintrag der Root Zone fehlt und mit welchem Schlüssel müsste er signiert werden? A • In der Root Zone fehlt der Delegation Signer (DS) Resource Record der .pl Zone • Diese müsste mit dem Zone Signing Key (ZSK) der Root Zone signiert werden Q Was was auf folgendem Screenshot los? InfSi2_fscala Page 75 A • Falsche RSA Signatur (RSIG) über den A Resource Record des baddata-A.test.dnssectools.org Zoneneintrag Q Was bedeutet das grüne Schlüsselsymbol welches durch das DNSSEC Validator Plugins angezeigt wird? A • Erfolgreiche Auslösung von www.cacert.org via DNSSEC Q Woraus besteht der DS Resource Record der folgenden DNSSEC Abfrage und wie genau wird das Vertrauen in die Signatur (RSIG Resource Record) über den DS Resource Record etabliert? A • Der Delegation Signer (DS) Resource Record besteht aus dem SHA-256 Hash des Key Signing Keys (KSK) der ch. Zone • Der DS Record der ch. Zone istz durch den ZSK der Root Zone signiert • Das Vertrauen in den ZSK der Root Zone wird durch den KSK der Root Zone hergestellt • Der KSK steht zuoberst (Wurzel) in der Hierarchie und muss explizit (manuell) in den DNS Server importiert werden Q Mit welchem Schlüssel wird der NS Resource Record der folgenden DNSSEC Antwort signiert? InfSi2_fscala Page 76 A • Der NS Record der switch.ch. Zone ist durch den Zone Signing Key (ZSK) der switch.ch. Zone signiert Q Wie wird das Vertrauen in den Zone Signing Key (ZSK) der ch. Zone etabliert? A • Der DNSKEY Resource Record, welcher den Public Key des ZSK und des KSK der ch. Zone umfasst wird vom KSK der .ch Zone signiert. Q Gegeben ist folgender Ausschnitt aus der ietf.org Zone welche DNSSEC unterstützt. 1. Geben Sie für jeden DNSKEY an, ob es sich um einen Key Signing Key (KSK) oder um einen Zone Signing Key (ZSK) handelt sowie mit welchen Keys die RRSets signiert wurden. 2. Worum handelt es sich bei den DS Resource Records E) und F) und durch welchen DNSKEY wurde das DS RRSet signiert? 1 2 Key Domain Typ Key Tag Signers A org. ZSK 53990 A&B B org. KSK 21366 A&B H ietf.org. ZSK 40452 H&I I ietf.org. KSK 45586 H&I • Delegation Signer Resource Records bestehen aus • SHA-256 bzw SHA-1 Hash InfSi2_fscala Page 77 • SHA-256 bzw SHA-1 Hash • Von ietf.org. KSK I) mit Key Tag 45586 • DS RRSet wurde durch .org ZSK A) mit Key Tag 53990 signiert InfSi2_fscala Page 78 VPN / IKE Q Gegeben seien folgende Konfigurationen für die IPSec Gateways moon, mars und sun. Zeichnen Sie die Netzwerktopologie mit den drei Gateways und allen Subnetzen auf. A Q Geben Sie an wer mit wem über oben aufgesetzten IPSec Tunnel kommunizieren kann. A InfSi2_fscala Page 79 A Q A Das LAN-Subnetz 10.1.0.0/60 soll über eine Kaskade von zwei VPN Tunnelverbindungen mit dem LAN-Subnetz 10.2.0.0/16 gekoppelt werden. Der VPN Gateway cat übernimmt hierbei die Rolle als vertrauenwürdiger Zwischenknoten. 1. Wie müssen die drei Linux strongSwan Gateways konfiguriert werden wenn left jeweils die lokale Seite und right die remote Seite darstellt? 2. Können mit diesem Setup die beiden Hosts 10.1.0.10 und 10.3.0.20 über den Tunnel zwischen dog und cat kommunizieren? Begründen Sie Ihre Antwort. 1 InfSi2_fscala Page 80 2 Q A • Nein, da die IPSec SA nur für IP Pakete im Transit zwischen den Subnetzen von dog (10.1.0.0/16) und mouse (10.2.0.0/16) gilt und deshalb die Pakete mit der Destination/Source 10.3.0.20 nicht getunnelt werden. Der Roadwarrior red baut mittels IKEv2 zwei IPSec Tunnel zum Gateway baran auf. In beiden VPN Endpunkten wird strongSwan mit folgender Konfiguration eingesetzt. 1. Die Hosts red, green und baran versenden nun ICMP Requests an verschiedene Destinationen gegeben durch die IP. Kreuzen Sie an, mit welcher IPSec SA die pink Pakete verschlüsselt oder im Klartext übertragen werden. 2. Welche IKE Messages werden beim Aufbau der beiden IPSec Tunnel mittels IKEv2 ausgetauscht. Wieviele IKEv2 Pakete sind es insgesamt? 1 InfSi2_fscala Page 81 A 1 2 • IKE_SA_INIT Request/Reply • IKE_AUTH Request/Reply • CREATE_CHILD_SA Request/Reply • 6 Pakete Q Zwischen zwei Subnetzen werde ein IPSec Tunnel aufgebaut welcher mit AES verschlüsselt wird. Mittels ping kann der Tunnel erfolgreich getestet werden. Als ein längerer FTP Download gestartet wird, kommen jedoch plötzlich keine TCP Pakete mehr durch den Tunnel und der Download stockt. Welches Problem könnte hier vorliegen und wie wird es behoben? A • Ping Pakete sind klein, der FTP Download benötigt jedoch Pakete die mit maximaler MTU abgefüllt sind. Werden diese getunnelt kommt der IPSec Header noch hinzu werden die Pakete aufgrund Überschreitung der MTU fragmentiert und somit häufig verworfen. • Die MTU muss manuell heruntergesetzt werden Q Welches sind die Vorteile eines durch einen Telecom Carrier betriebenen MPLS Netzwerks? 1. Der IP Verkehr wird nicht geroutet, sondern über eine optimale Route geschaltet 2. Das MPLS Label trägt Class of Service Informationen. Damit kann wichtiger oder zeitkritischer Verkehr bevorzugt behandelt werden. 3. Der Telecom Carrier garantiert die Sicherheit der Daten durch automatische und starke End-to-End Verschlüsselung und Authentisierung. A • 1 und 2 Q Zwischen den VPN Gateways fidel und castro werden mit Linux und strongSwan zwei IPSec Tunnel aufgesetzt. Die entsprechende ipsec.conf Datei für fidel sieht folgendermassen aus. InfSi2_fscala Page 82 1. Welche der folgenden ICMP Request/Reply Pakete werden mittels ESP getunnelt? 2. Wieviele IKE Nachrichten werden mit IKEv1 bzw. IKEv2 benötigt um die beiden Tunnel aufzusetzen? 3. Mit welcher ID identifiziert sich fidel gegenüber castro? A 1 2 3 Q A • Mit IKEv1: 6 + 3 + 3 = 12 • Mit IKEv2: 4 + 2 = 6 • Dem Distinguished Named (DN) aus der subject Zeilt des Zertifikats fidelCert.pem Erklären Sie weshalb die folgenden vier Punkte für das effiziente Betreiben grosser VPN Netzwerke wichtig sind und mit welchen Mechanismen diese realisiert werden können. 1. Automatische Zuweisung von virtuellen IP Adressen 2. Authentisierung basierend auf X.509 Zertifikaten 3. Sichere Aufbewahrung von RSA Authentisierungsschlüsseln 4. Implementierung von individuellen Zugriffsprofilen (User Access Control) 1 • Virtuelle IP Adresse erleichtern das Routen von IP Paketen durch den VPN Tunnel auf dem Rückweg zu den Remote Access Clients • Die automatische Vergabe der virtuellen IP Adresse entlastet den nicht-versierten Endbenutzer und verhindert Fehlkonfigurationen • Mechanismen zur Vergabe virtuelle IP Adresse sind L2TP, DHCP-over-IPSec oder IKE Mode Config 2 • Es müsste die potentiell unsichere IKE Aggressive Mode in Kombination mit XAUTH verwendet werden welches anfällig auf MITM und damit offline Dictionary und Brute-Force Attacken ist • Mittels PKI kann eine grosse Teilnehmerzahl mit X.509 Zertifikaten ausgerüstet werden, welche im Notfall mittels CRL gesperrt werden können. Damit ist IKE Main Mode bei dynamischen IP Adresse problemlos möglich. 3 • Bei Diebstahl oder Verlust des Notebooks können die auf der Disk gespeicherten RSA Schlüssel kompromittiert werden. Dasselbe gilt bei Netzwerkattacken auf stationäre Rechner. • Nur PIN geschützt Chipkarten oder USB Crypto Tokens gewährleisten, dass Authentisierungsschlüssel nicht kopiert werden können und sollten deshalb besonders bei Remote Access Clients eingesetzt werden. 4 • Bei eine grossen Anzahl Benutzer können Zugriffsprofile nur durch Benutzergruppen effizient realisiert InfSi2_fscala Page 83 4 • Bei eine grossen Anzahl Benutzer können Zugriffsprofile nur durch Benutzergruppen effizient realisiert werden. Dabei empfiehlt sich die Kopplung von VPN Authentisierung mit dynamischen Firewall-Regeln. • Dies kann beispielsweise über Wildcards in X.509 Zertifikaten, über mehrstufige Zertifikatshierarchien auf der Basis von X.509 Attributszertifikaten oder mittels Privilege Access Certificates (Kerberos Ticket Erweiterung von Microsoft) geschehen. Q Warum bringt bei vielen modernen Challenge/Response Anwendungen (IKE, SSL/TLS Handshake, …) der Initiator eine eigene Zufallszahl (Nonce) in das Protokoll ein, wo doch die zufällige Challenge des Responders zur Sicherstellung der Einmaligkeit ausreichen würde? A • Server könnte mit gezielt gewählten Challengewerten etwas "Böses" im Schilde führen • Durch Hinzufügen eines eigenen Zufallwerts in die Response kann dies der Client verhindern Q Welche Attacke wird möglich wenn der Server dieselbe Challenge mehrmals verwendet? A • Replay-Attacke wenn die frühener Logins durch den Angreifer gesnifft wurden • Session Hijacking da die zugehörige Response bekannt ist Q Warum wird eine Passwort-basierte Remote Access Client Authentisierung vorteilhaft mit einer IVEv2 EAP Methode durchgeführt statt mit der wesentlich effizienteren IKEv2 PSK Authentisierung? A • Bei IKEv2 PSK muss der VPN Client als erster seine potentiell schwachen Credentials schicken. Das PSK Verfahren ist also anfällig auf Man-in-the-Middle (MITM) Attacken • Bei IKEv2 EAP muss sich der VPN Gateways als erster mit seiner Zertifikat-basierten Signatur ausweisen. MITM Attacken werden so verhindert. Q Weshalb wird dem Remote Access Client durch den VPN Gateways eine virtuelle IP Adresse zur Verwendung im Inneren des IPSec Tunnels vergeben? A • Ohne diese würde im Tunnel die dynamische, durch den ISP vergebene Adresse verwendet werden. Liegen im Heimatnetzwerk der VPN und Default Gateway nicht im selben Netzwerkpfad wird die Antwort unverschlüsselt via Default Gateways an die äusserem IP des Remote Access Clients gesendet. • Ohne virtuelle IP Adresse würde im Inneren des IPSec Tunnels die private, durch den DHCP Servers des NAT Routers vergebene IP Adresse verwendet werden- Das viele das gleiche Routermodell besitzen kann es zu Konflikten beim Routen der Antwort kommen. InfSi2_fscala Page 84 NAC/TNC Q Welche zwei Hauptaufgaben hat das PB-TNC / IF-TNCCS 2.0 Protokoll, welches zwischen TNC Client und TNC Server läuft? A • Die PA-TNC Meldungen von und zu den einzelnen IMCs und IMVs werden durch den TNC Client/Server in PB-TNC Batches multiplexiert. • Informationsmeldungen (z.B. Language Preference), Fehlermeldungen sowie Resultate (Recommendation / Evaluation) werden über PB-TNC Batches zwischen TNC Server und TNC Client ausgetauscht. Q Welche Konsequenzen hat folgende Aktion des Policy Enforcement Points moon für den IPSec Remote Access Client dave? A • Der Remote Access Client dave wird über eine spezielle "isolate" IPSec Policy in ein Quarantäne-, Isolations- oder Remediation-Netzwerk verbannt, in dem er seinen Host aus "Vordermann" bringen kann. Q Welcher Unterschied betreffend benutzter Namespaces besteht zwischen dem ersten und dem zweiten PA-TNC Attribut? A • Das erste PA-TNC Attribut "Port Filter" gehört zum Standard IETF Namespace und ist im PA-TNC RFC spezifiziert. InfSi2_fscala Page 85 PA-TNC RFC spezifiziert. • Das zweite PA-TNC Attribute "Command" gehört zum proprietären ITA-HSR Namespace welche durch die Private Enterprise Number (PEN) 0x00902a aufgespannt wird. Q Was bedeuten diese IF-MAP Metadaten welche von einem VPN Gateways geliefert wurden? A • Ein Remote Access Client mit IPv4 Adresse 10.10.0.20 wollte eine Verbindung zum VPN Gateway "strongswan-home" aufbauen, wurde jedoch durch den Policy Enforcement Point (PEP) geblockt. InfSi2_fscala Page 86 Smart Card Q Ein Mitarbeiter gibt an einem Arbeitsplatz beim Login drein mal hintereinander eine falsche PIN ein und seine Firmenkarte wird dadurch blockiert. Welche zwei Möglichkeiten hat um die Karte wieder zu entsperren? A • Mittels PUK der Karte • Security Officer kann meist mit seiner PIN die PIN des Benutzers zurücksetzen Q Wie garantiert ein Chipkartenbetriebssystem, dass auf einer Telefonkarte ein Zähle für Gebühreneinheiten nicht durch missbäuchliche Manipulation wieder aufgeladen werden kann? A • Es wird nur eine decrease Funktionalität, jedoch keine increase Funktionalität implementiert. Der Zähler kann somit nur heruntergezählt werden. Q Weshalb sind Bank- und Kreditkarten, die auf dem EMV Standard basieren, wesentlich sicherer als herkömmliche Karten? A • Herkömmliche Karten speichern die Daten auf einem Magnetstreifen welche einfach zu kopieren sind. • EMV Karten hingegen speichern ihre Daten kopiergeschützt auf einem Chip. Q Welches Authentisierungsverfahren verwenden EMV Karten? A • EMV Karten verwenden eine RSA Public Key Authentisierung mit Schlüsseln zwischen 1024 und 1984 Bit Modulus • In Zukunft sind Elliptic Curve Keys vorgesehen. • Die RSA Keys authentisieren die Karten, nicht den Benutzer Q Wie weit sind EMV Karten bereits global eingeführt worden? A • Mit Stand 2010 wurden bereits 1000 Millionen Karten ausgegeben und es existieren 16 Millionen EMV-Fähige Terminals. Die globale Einführung ist somit bereits sehr fortgeschritten. Q Weshalb funktionieren kontaktlose Chipkarten wie LEGIC oder MIFARE nur auf einer Entfernung von maximal ca. 10m? A • Der Chip in der Karte wird über die in der Karte eingebaute Antenne durch das Lesegerät von aussen mit Spannung versorgt. • Da dies wie in einem Transformator über magnetische Kopplung (Induktion? Spulen?) geschieht darf die Distanz bei passiven Chipkarten nicht allzu gross sein Q Weshalb werden im Zahlungswesen (EMV - Europay, Mastercard, Visa) nur Karten der Klasse A (5V) eingesetzt, während es im Mobilfunkbereich (SIM) nur Karten der Klasse B (3V) oder C (1.8V) sind? A • Terminals für den Zahlungsverkehr sind meist an das Stromnetz angeschlossen, sodass eine höhere Leistungsaufnahme kein Problem darstellt dafür jedoch eine höhere Zuverlässigkeit erzielt werden kann. • SIM Karten werden vom Handy-Akku gespiesen was direkten Einfluss auf die Betriebszeit der Mobiltelefons (Akku) hat. InfSi2_fscala Page 87 Q Weshalb achten Chipkartenhersteller sehr darauf, dass der Stromverbrauch ihrer Karten im Betrieb über die Zeit möglichst konstant bleibt? A • Einzelne Mikroprozessoperationen können sonst über "Power and Timing" Analyse identifiziert werden und damit unter Umständen auf der in der Karte gespeicherte Wert/Schlüssel geschlossen werden Q Wie wird garantiert, dass ein Smartcard-Dieb sich nicht als der Besitzer ausweisen kann? A Um die Smartcard zu aktivieren wird ein geheimer PIN-Code benötigt. Q 1. Erklären Sie wie die Anwendung die vorhandene Zertifikatsdatei in der folgenden PKCS# 15 Topologie finden und mit welchem absoluten Pfad sie auf das Zertifikat zugreifen kann. 2. Geben Sie den absoluten Pfad auf diejenige PIN Datei an, mit dem die Zertifikatsdatei schreibgeschützt ist A Q A 1 • Die reservierte Datei /3F00/2F00 enthält einen Link auf das PKCS#15 Directory /3F00/5015 • Das PKCS#15 Directory 5015 besitzt ein Object Directory File (ODF) mit dem reservierten Dateinamen 5031 • Das Object Directory File (ODF) 5031 enthält einen Link auf das Certificate Directory File (CDF) /3F00/5015/4404 • Mit dem Pfad /3F00/5015/5501 kann die Anwendung direkt auf die Zertifikatsdatei zugreifen 2 • 3F00/0000 Alle Chipkarten mit einem Crypto Coprozessor bieten die Möglichkeit ein RSA Schlüsselpaar auf der Karte zu generieren. Nennen Sie je einen Vor- und Nachteil dieses Features bei der Erzeugung von Signaturschlüsseln. Vorteil • Der Private Key verlässt die Karte nie. Dies garantiert, dass nur eine Kopie existiert, was bei einer Digitalen Signatur von grösster Bedeutung ist. Nachteil • Der Anwender muss dem Chipkartenhersteller vertrauen, dass der Schlüssel auch wirklich zufällig ist und mit maximaler Entropie generiert wurde. InfSi2_fscala Page 88 wurde. Q In welchem Verzeichnis der abgebildeten PKCS#15 Topologie befindet sich die PIN welche den RSA Private Key schützt und welche Rechte hat der Benutzer nachdem er sich mit dieser PIN eingeloggt hat? A • Die PIN ist in der Datei 0000 im Unterverzeichnis 4B01 gespeichert • Nach einem Verify mit der PIN kann eine RSA Signatur oder eine RSA Entschlüsselung auf der Chipkarte getätigt werden. • Die PIN berechtigt jedoch nicht zum Extrahieren/Lesen des Private Keys, dieser kann nur gelöscht oder überschrieben werden. Q Nennen Sie zwei Vorteile, wenn wie bei Windows 8 vorgesehen, eine virtuelle Smart Card auf der Basis des TPM Storage Root Keys (SRK) zur Verfügung stehen wird, verglichen mit einer herkömmlichen Smart Card mit USB-Schnittstelle die an den PC angesteckt wird? A • Das nur der SRK auf dem TPM gesichert wird und die einzelnen dadurch gesicherten Private Keys (Storage Keys) auf der Festplatten sind, können beliebig viele Schlüssel und Zertifikate in der virtuellen Smart Card gespeichert werden. • Eine Smart Card wird vergessen oder verloren. Mit der durch den SRK PIN geschützten virtuelle Smart Card hat man sie immer mit dem PC dabei. InfSi2_fscala Page 89 Buffer Overflows Q Die Variable buffer wird mit 0xFF initialisiert. Ist bei folgendem, zur Laufzeit gemachtes Snapshot Sprung in den Stackbereich der Anwendung durch überschreiben von EIP möglich? A • Ja, da die randomisierung des Stackbereichs sowie andere Schutzmassnahmen ausgeschaltet sind Q Die Variable buffer wird mit 0xFF initialisiert. Ist bei folgendem, zur Laufzeit gemachtes Snapshot Sprung in den Stackbereich der Anwendung durch überschreiben von EIP möglich? A • Nein, es ist ein Canary gleich neben der buffer Variable vorhanden welches das Überschreiben verhindert • Das Canary besteht aus einem 0x00 vermutlich gefolgt von einer Checksumme kombiniert mit einem Zufallswert Q Die Variable buffer wird mit 0xFF initialisiert. Ist bei folgendem, zur Laufzeit gemachtes Snapshot Sprung in den Stackbereich der Anwendung durch überschreiben von EIP möglich? InfSi2_fscala Page 90 A • Nein, die Randomisierung des Stackbereichs ist eingeschaltet und unser Payload nicht direkt herausfinden kann wo dieser sich auf dem Stack befindet • Die Variation der Stackstartadresse von 8MB ist auch viel zu gross, als dass man diese durch NOPs auffüllen könnte Q Wie kann, falls es möglich ist den Stackbereich der Anwendung anzuspringen, dennoch verhindert werden, dass Schadcode ausgeführt wird? A • Durch setzen de NX (No eXecute) Bits in den Page Tables womit der Stackbereich als nichtausführbar deklariert wird • Wird durch 64 Bit Prozessoren und 32 Bit Prozessoren mit PAE (Physical Address Extension) unterstützt • Reine 32 Bit Betriebssysteme können das NX Bit Softwarebasierend emulieren Q Durch ein Refactoring in strongSwan wurde durch inkorrekte verwendung snprintf() eine potentielle Vulnerability eingeführt. Bei der Funktion dntoa() wird ein ASN.1 Codierter DN in einen lesbaren String um (z.B. C=CH, O=HSR, CN=Andreas Steffen). Die einzelnen Teile des DNs werden durch eine Enumerationsfunktion einzeln in String konvertiert und mittels snprintf() zusammengebaut. 1. Welche Vulnerability kann hier zu einem Buffer Overflow führen? 2. Durch welchen zusätzlichen Code könnte diese Lücke geschlossen werden? 3. Bei Fehlern gibt snprintf() einen negativen Wert zurück. Wie muss die Aufgabe 2 erweitert werden um dies zu berücksichten? 4. Die Enumerationsfunktion ersetzt bei der Konversion alle nicht ASCII Zeichen durch ein ?, was bedeutet dies für den potentiell gefährlichen Shell Code des Angreifers? InfSi2_fscala Page 91 1 • snprintf() gibt bei einem zu langen String die Anzahl zeichen zurück die geschrieben worden wären, falls buf gross genug gewesen wäre. • Die Variable written ist somit so lang wie der zu lange String, durch die Subtraktion wird len jedoch negativ • Da len als unsigned deklariert ist, resultiert ein extrem grosser, positiver Wert. • Alle darauf folgenden Teilstrings würden über den Buffer hinaus schreiben, da diese durch len limitert werden. 2 … int written = snprintf(pos, len, "%s", rdn); if(written >= len) { // check if too long pos[len - 1] = '\0'; // null-terminate break; // get out of the loop } pos += written; len -= written; … 3 • Rückgabewert von snprintf() muss auf negative Werte geprüft werden if(written < 0 && written >= len) { … } 4 • Shell Code besteht üblicherweise aus nicht druckbaren Zeichen, binären Maschineninstruktionen • Der Shell Code müsste deshalb in ein ASCII-Format konvertiert werden und einen in ASCII geschriebenen Konverter beinhalten um den Lauffähigen Shell Code wiederherzustellen. hex to dec und hex sub. Q Gegeben ist folgendes C Programm welches anfällig auf einen Buffer Overflow ist sowie GDB Output mit Informationen über Adressen und Pointer. 1. Wieviele Bytes (ohne terminierendes Null) muss der String mindestens besitzen um die Rücksprungadresse vollständig zu überschreiben. Machen Sie eine Skizze. 2. Aus Effizienzgründen wird auf den Frame-Pointer verzichtet, wie lang muss der String InfSi2_fscala Page 92 2. Aus Effizienzgründen wird auf den Frame-Pointer verzichtet, wie lang muss der String diesmal sein? 3. Weshalb unterscheiden sich die Startadressen der Stacks in Aufgabe 1 und 2 um über 240MB? A 1 • buffer[16] + BP[8] + IP[8] = 32 Bytes 2 • Wieder 32 Bytes, der Platz wird freigehalten wenn auch der Base Pointer nicht gespeichert wird 3 • Die Randomisierung des Stack-Adressraums durch den Linux Kernel bei jedem Programmaufruf soll Buffer-Overflows erschweren. • Da die Adresse der Buffers in einem so grossen Bereich schwankt ist diese nicht durch NOPs im Shellcode auszugleichen. Q Welche drei potentiellen Vulnerabilities weist folgende Funktion auf A • 4: strlen(default_entry) - Es ist nicht sichergestellt, dass default_entry NullTerminiert ist • 6: Es ist nicht sichergestellt, dass die grösse von table max_lines entspricht • 8: strncpy() - Es ist nicht sichergestellt, dass jede Zeile von table auch mindestens len Bytes alloziert hat InfSi2_fscala Page 93 Q A Q Beschreiben Sie die drei effektivsten Ansätze welche einen Buffler Overflow verhindern oder zumindest erschweren sollte. Address Space Layout Randomization (ASLR) • Die Startadresse von Libraries, Heap und Stack werden zufällig gewählt. Damit wird die Bestimmung von absoluten Speicheradressen erschwert. Canaries • Bestimmte Werte (Konstant, Zufällig, oder Berechnet) werden zwischen Puffer und der Rücksprungadresse eingefügt um Buffer Overflows detektieren zu können. Executable Space Protection (NX Bit) • Speicherbereiche wie Heap oder Stack werden als nichtausführbar markiert. Die Ausführung von Maschinen Code in diesem Bereich führt zu einem segmentation fault. Es wird ein Shellcode entwickelt, welcher einen Buffer Overflow einer instalierten Zielsoftware ausnutzen soll um die Kontrolle über den Host zum übernehmen. Nachdem auf dem Host jedoch Google Earth installiert wurde und somit die Pfadvariable erweitert wurde, scheint es nicht mehr zu funktionieren. 1. Aus welchem Grund funktioniert der Shellcode nicht mehr? 2. Durch welchen Trick kann dieses Problem gelöst werden? A 1 • Alle Umgebungsvariablen einer Shell sind schon vor dem Aufruf der Zielsoftware im Memory initialisiert. Aus diesem Grund verschiebt sich Beginn des freien Stacks nach unten. Da die überschriebene Rücksprungadresse auf den Anfang des in den Puffer kopierten Shellcodes zeigen muss, ist diese durch die Verschiebung nicht mehr korrekt. 2 Durch Anhängen von möglichst vielen NOP Instruktionen vor dem Shellcode (im Puffer) können Adressschwankungen in gewissen Massen in Grenzen gehalten werden. Q Das Einfügen eines Canary zwischen der gespeicherten Rücksprungadresse und den lokalen Variablen auf dem Stack erschwert das Überschreiben der Rücksprungadresse durch einen Buffer Overflow. Beschreiben Sie, welche Attacke möglich wäre, wenn in einem Funktionsaufruf durch das Hauptprogramm als Parameter ein Funktionspointer übergeben wird. A • Die Funktionsparameter sind unmittelbar unterhalb des Canary auf dem Stack und können deshalb durch einen Buffer Overflow überschrieben werden. • Durch den Buffer Overflow wird der Funktionspointer durch die Startadresse des Puffers ersetzt wo sich der bösartige Shellcode befindet. • Wird der Funktionspointer innerhalb der aufgerufenen Funktion ausgewertet (dh aufgerufen) wird statt der übergebenen Funktion der Shellcode ausgeführt. InfSi2_fscala Page 94 OWASP Q Geben Sie drei der OWASP Top 10 Web Application Security Risks an A • Cross-Site Scripting (XSS) • SQL Injection • Cross-Site Request Forgery (CSRF) https://www.owasp.org/index.php/Top_10_2013-Top_10 Q Beim Aufruf der Webseite www.einkauf.ch wird die Session ID in der URL übermitteln. Auf der Webseite ist ein Link auf www.sbb.ch hinerlegt. Beschreiben Sie wie der Administrator von www.sbb.ch die Session ID des Kunden einsehen kann, wenn dieser auf den Link klickt. A Über das Referrer Header Feld wird die vorherige URL mitgegeben. Da die Session ID in dieser enthalten war erscheint diese in den Web-Server Logfiles von www.sbb.ch Q Die Webseite www.einkauf.ch hat von Session ID in der URL auf Session Cookies umgestellt. Auf dieser Webseite gibt es ein verwundbares Gästebuch www.einkauf.ch/gast33.html. Beschreiben Sie im folgenden Sequenzdiagramm wie ein Angreifer das Cookie von www.einkauf.ch Kunden stehlen könnte. A Verhindern durch setzen von HttpOnly Cookie Flag. InfSi2_fscala Page 95 Q Ordnen Sie mit 1, 2, 3 diejenigen drei Software Security Best Pracises, welche typischerweise die höchste Effektivität betreffend Verbesserung der Sicherheit aufweisen • Abuse cases • Architectural risk analysis • Code Review • Penetration testing • Risk-based Security tests • Security operation • Security requirements A 1. Code review 2. Architectural risk analysis 3. Penetration testing Q Geben Sie an, welchen OWASP Top 10 Vulnerabilities folgende Beispiele entsprechen 1. Jemand der Zugriff auf die Datenbank des Online-Shop hat kann die Passwörter der Kunden im Klartext lesen 2. In einem Kunden-Forum innerhalb des Online-Shops kann beliebiger Textinhalt (HTML, JavaScript) eingetragen werden 3. Wenn man die URL zur Administrations-Oberflächer kennt, kann man administrative Aktionen ausführen ohne sich vorher einloggen zu müssen. A Q A Q 1 • Insecure Cryptofraphic Storage 2 • Cross-Site Scripting (XSS) 3 • Failure to Restrict URL Access Ein Online-Shop leider unter den folgenden OWASP Vulerabilities. Nennen Sie je ein Beispiel beim Vorgang "Waren bestellen" 1. Broken Authentication and Session Management 2. Insecure Direct Object Reference 3. Insecure Communications 1 • Es können Waren als anderer Benutzer bestellt werden 2 • Wenn man die ArtikelID kennt können Artikel bestellt werden die nicht im Sortiment aufgelistet sind • Zugriff auf Warenkorb anderer Benutzer via ID 3 Mit einem Sniffer könnten Daten der Bestellung (Artikel, Kreditkarte, Credentials, …) abgehört werden. Die Login-Seite einer Webapplikation prüft die Credentials mit folgendem SQL Query: 1. Was für ein Benuzternamen müsste man eingeben um sich ohne Passwort erfolgreich einzuloggen und wieso funktioniert dies? 2. Was für ein Benutzernamen müsste man eingeben um alle Rows der Tabelle anzuzeigen? A Q 1 • asteffen' -- %20 • Alles nach dem -- gilt als Kommentar und wir nicht geprüft 2 • ' OR 1=1 -- %20 • ' UNION SELECT * FROM users -- %10 Leider wird bei einer SQL Injection einer Detailansicht nur genau die erste Row des SQL Queries angezeigt, wie kann man dennoch an alle anderen Rows gelangen? InfSi2_fscala Page 96 A • Mit LIMIT eines nach dem anderen (LIMIT 0,1 dann LIMIT 1,1, …) • UNION und alles in eine Row konkatenieren Q Geben Sie drei grundsätzlich verschiedene Vorgehen an, falls die Anwendung keine Resultate beim versucht einer SQL Injection ausgibt. A • Fehlermeldung verursachen • Boolean based attacks (z.B. 1=1 AND 0=1 ist immer false) • Time based attacks, Redirecting output. Rechenaufwändige Aufgaben ausführen (z.B. eine Million MD5 Hashes) Q Auf einer Internet-Auktionsplatform gibt es für jeden Artikel eine Webseite. Diese besteht aus einer Beschreibung sowie einem Formular über welches nach Authentisierung an der Auktion teilgenommen werden kann. Die Artikelbeschreibung kann beliebigen HTML- und Scriptcode enthalten. 1. Sie möchten einen möglichst hohen Preis erzielen. Geben Sie die nötigen Schritte an um mittels XSS den Betrag um den Faktor 100 zu erhöhen (50 => 5000) 2. Eine andere Auktion wurde so manipuliert, dass die Formulardaten an einen Drittserver weitergeleitet werden (URL des Formulars) was muss getan werden damit diese den Betrug nicht entdecken. 3. Welche Massnahmen muss der Betreiber der Auktionsplatform treffen um XSS zu unterbinden? A 1 • In der Seite wird JavaScript eingeschleust welches den Wert des Betrages kurz vor dem Submit des Formulares mit dem Hundertfachen überschreibt. 2 • Das Skript auf dem externen Server muss wieder auf die ursprünglich aufzurufende Seite weiterleiten. 3 • Artikelbeschreibung muss geprüft und HTML Tags escaped werden. • Falls man dennoch formatierten Code wünscht müsste man eine Art WikiMarkup Sytnax implementieren. Q Beschreiben Sie was das "OWASP-Projekt" mit mindestens drei Schlagwörtern. A • Open Web Application Security Project • Soll helfen die Anwendungssicherheit zu verbessern • Bietet Tools wie Webscarab • Zudem eine absichtlich mit Lücken behaftete Trainingsanwendung (Webgoat) Q Ein Online Multiplayer Spiel besteht aus einem Server sowie einem Applet welches im Browser der Teilnehmer läuft und via UDP mit dem Server kommuniziert. Geben Sie für jedes der unten stehenden Probleme an, um welche OWASP Top 10 Schwachstelle es sich handelt. 1. Hacker fängt mittels Sniffer das Login Paket ab und kann sich selbst durch erneutes Senden dieses Pakets einloggen. 2. Irrelevant 3. Irrelevant 4. Irrelevant A 1 Broken Authentication and Session Management 2 Irrelevant 3 Irrelevant 4 Irrelevant InfSi2_fscala Page 97 InfSi2_fscala Page 98 TPM Q A Die Festplattenpartition auf dem sich das PC Betriebssystem und dessen Benutzerdaten befindet ist mit einem 128 Bit AES Schlüssel verschlüsselt. Dieser ist wiederum mit einem 2048 Bit RSA Storage Key gesichert und ebenfalls auf der Festplatte gespeichert. Der Storage Key sei über Sealing an einen gewissen Stand der TPM Platform Configuration Register 0..5, in die alle BIOS Messungen während des Bootvorgangs hineingehasht werden, gebunden. Der PC Benutzer fängt sich beim Surfen einen Trojaner ein, welcher sich als Root-Kit in das BIOS einnistet. 1. Beschreiben Sie in etwa drei Sätzen was genau passiert wenn der Benutzer das nächste Mal seinen PC bootet. 2. Wie kann dieses Problem behoben werden? 1 • Durch das Rootkit ändern sich einige der BIOS Messwerte welche ins PCR gehasht werden sodass diese von den vorherigen abweichen. • Aufgrund der geänderten PCR Werte und des Sealings kann der AES Schlüssel nicht entschlüsselt werden und der Zugriff auf die Festplattendaten nicht möglich. • Das Betriebssystem kann somit nicht durch den Bootloader geladen werden und der Bootvorgang bricht ab. 2 • Das BIOS Flash muss auf die Originalversion zurückgesetzt werden • Dies muss mit einer CD oder DVD geschehen da die Festplatte nicht zur verfügung steht. Q Microsoft führt mit Windows 8 einen "Secure Boot" Prozess ein, welcher die UEFI Version 2.3.1 bedingt. Wie verhindert das UEFI, dass im Gegensatz zum alten BIOS ein durch Malware verseuchter OS Loader ausgeführt werden kann? A • Der OS Loader muss durch den Hersteller (Microsoft, RedHat, …) signiert werden. • Der Public Key oder Zertifikat des OS Loader-Hersteller kann nur im UEFI gespeichert werden, wenn dieser mit dem Platform Key des OEM Hardware Herstellers signiert worden ist • Nur wenn diese Bedingunen erfüllt sind kann die Signatur-Verifikation erfolgreich durchgeführt und damit der OS Loader ausgeführt werden. Q Ist ein TPM Chip auf dem PC Motherboard vorhanden nimmt Windows 8 während des gesamten Boot-Prozesses Messungen an den Treibern, asugeführten Programmen, Liraries und geladenen Dateien vor und hash diese Messwerte in die PCR der TPM. Wozu werden diese durch das TPM abgesicherten Messwerte genau verwendet und worauf deuten falsche Messwerte hin? A • Die Messwerte werde für eine Prüfung gebraucht, bei der ein externer Policy Server den Gesundheitszustand des PC Client bestimmt • Alle erfassten Messwerte und die durch das TPM signierten und damit beglaubigten PCR Werte werden über ein Netzwerkprotokoll (TNC, NAP) angefordert. • Wenn die Messwerte nicht stimmen hat der Benutzer oder ein Rootkit entweder Secure Boot ausgetrickst oder es wurden zwar signierte aber veraltete Softwarekomponenten InfSi2_fscala Page 99 Boot ausgetrickst oder es wurden zwar signierte aber veraltete Softwarekomponenten geladen. Q Kann der 2048 Bit RSA Endorsement Key (EK) eines TPMs durch den Benutzer oder Systemadministrator gelöscht oder neu generiert werden? Begründen Sie Ihre Antwort. A Nein der EK dient zur eindeutigen Identifikation des TPM und wird deshalb durch den TPM Hersteller bei der Produktion generiert und unlöschbar im TPM gespeichert. Q Wozu dient ein von einem TPM generierter Attestation Idenntity Key (AIK) und das entsprechende durch eine Privacy CA ausgestellte AIK Zertifikat? A • Mit dem AIK Private Key kann eine TPM digital signieren. • Die Überprüfung der TPM AIK Signatur kann über das AIK Zertifikat vorgenommen werden, welches den AIK Public Key enthält und von einer vertrauenswürdigen Privacy CA signiert wurde. Q Wozu braucht es eine Privacy CA? A • Das AIK Zertifikat wird von der Privacy CA nur ausgestellt, wenn der AIK Certificate Request mit dem Endorsement Key der TPM signiert worden ist und die Request Signatur mit dem EK Zertifikat des TPM verifiziert werden konnte. • Dadurch kann via EK eine eindeutige Zuordnung zwischen AIK und TPM vorgenommen werden, welches jedoch nur der Privacy CA als "Trusted 3rd-Party" bekannt ist. InfSi2_fscala Page 100