Sichere Implementierung Netzwerksicherheit I: Schwachstellen & Gegenmaßnahmen

Gruppenaufgaben: Terminplan UE/VL Tag Gruppe Thema VL Mi 4. 7. Marta Reyes Ojeda, Juan Manuel Leflet Estrada, Sergej Geger, Taras Iks GPU Implementations of ciphers or hash functions Marco Lutz, Stephan Müller Secret Sharing/Threshold Kryptografie Florian Kaase, Dirk Mattes, Clemens Peter Seibold, Alexander Bobach Keyboard Sniffer reloaded UE Kai Gärtner, Peter Witzel Analyse ChipTAN D. Sander, N. Beierle, Irina Glushanok, David Salomon, Philippe Lieser SSL Cert fetcher Mo 9. 7. Valerij Serediouk , Boris Zielinski , Uwe Reinbacher Static Analysis Bastian Hauda, Denis Allen Washington, Cavan King Sicherheit von Cloud-FS XtreemFS/Tahoe-LAFS Elias Rohrer, Florian Häber, Tom Grassmann, Christian Steinfeldt Advanced memory corruption techniques Daniel Hartmann, Jens Bork, Christopher Schiefer Sicherheit mobiler Plattformen Malte Schmidt, Tim Repke, Hendryk Köppel Christian Palatz , Tilman Stampe, Rico Weber, Moritz von Wedel-Parlow Dr. Wolf Müller

Prüfungstermine (August) Modul(e): VL IT-Sicherheit Grundlagen Prüfungstermin(e): Mi., 08.08.2012, Do., 09.08.2012 Prüfer/in: Dr. Wolf Müller Ort: Haus 3, Raum 327 Prüfungsart: mündliche Prüfung Anmeldung: Beginn: am 01.07.2012 bis 24.07.2012 bei: Name: Frau Albrecht/ Frau Schoch Raum-Nr.: Haus 3, R. 302 Sprechzeiten: 10 – 16 Uhr Abmeldung: unter: albrecht@informatik.hu-berlin.de Dr. Wolf Müller

Prüfungstermine (September) Modul(e): VL IT-Sicherheit Grundlagen Prüfungstermin(e): Mi., 12.09.2012, Do., 13.09.2012 Prüfer/in: Dr. Wolf Müller Ort: Haus 3, Raum 327 Prüfungsart: mündliche Prüfung Anmeldung: Beginn: am 06.08.2012 bis 28.08.2012 bei: Name: Frau Albrecht/ Frau Schoch Raum-Nr.: Haus 3, R. 302 Sprechzeiten: 10 – 16 Uhr Abmeldung: unter: albrecht@informatik.hu-berlin.de Dr. Wolf Müller

Internet Quelle: Wikipedia: Internet Dr. Wolf Müller

Internet-(Un)sicherheit IT in allen privaten und geschäftlichen Lebensbereichen präsent Zunehmende Vernetzung  zunehmende Abhängigkeit Fragen der Informationssicherheit immer wichtiger Bedrohungen: Unautorisiertes Lesen elektronischer Nachrichten Verändern gesendeter Daten Maskieren, Vortäuschen falscher Absenderidentität Zerstörung von Daten Erschleichung von Dienstleistungen Unterbrechung oder Störung der Kommunikation D(DOS) Dr. Wolf Müller

Internet: Historie ARPA, 70-er Jahre US-Verteidigungsministerium Protokolle: Internet Protocol (IP) Internet Control Message Protokoll (ICMP) Transport Control Protocol (TCP) am 1.1.1983 ins ARPA übernommen = Geburtsstunde des Internets Kommunikation zwischen Mainframes, später PC in Militär, Regierung, Forschung Begrenzter Teilnehmerkreis, Kooperativ Equipment teuer Übertragungssicherheit im technischen Sinne wichtig Dr. Wolf Müller

Internet: Historie (2) Weitere Netzwerkdienste: 1993 WWW, Mosaic, CERN für BSD UNIX entwickelt (Berkley University of Carlifornia) Telnet FTP E-Mail 1991 Gopher, erstmals GUI, Texte, Bilder, Ton 1993 WWW, Mosaic, CERN Internet öffnet sich für Massenbenutzerkreis Rascher Anstieg des Nutzerkreises, Etwa alle 12 – 15 Monate Verdopplung der Anzahl der angeschlossen Rechner seit 1993 Ursprung im wissenschaftlichen Bereich, Ziel flexible Nutzung  dezentrale Verwaltung Rasante Ausweitung, nahezu unbeschränkte Möglichkeiten, Rechner anzuschließen (zumindest mit IPv6) Keine Basis für Kontrollmöglichkeiten, die bei der verstärkten beruflichen und privaten Nutzung verstärkt erforderlich werden. Dr. Wolf Müller

Internet: Situation heute Öffnung für breite Anwenderschaft von Nichtspezialisten Rudimentäre Kenntnisse über Internet und damit verbundene Gefährdungen Anstieg der potentiellen Opfer von Computerkriminalität Zunehmende kommerzielle Nutzung Wachsende Abhängigkeit Wachsende Schadenshöhe bei erfolgreichen Angriffen Keine zentrale Kontrollinstanz zur Verhinderung von Missbrauch Kenntnisse des Nutzers unabdingbar Einsatz verfügbarer Softwareprodukte Dr. Wolf Müller

Einteilung von Netzwerken Firmennetzwerke Physisch absicherbar Eventuell WLAN? Netzwerke zwischen Standorten Kommunikationspartner kennen sich gegenseitig Provider sichert gewissen Schutz Eventuell Funkübertragung, LaserLink Virtuelle Private Netzwerke Internet Unvorhersehbares Routing Authentifizierung schwierig Keine Vertrauensbeziehungen Kein sicherer Kanal Dr. Wolf Müller

Sicherheit auf verschiedenen Netzwerkschichten Dr. Wolf Müller

Belauschen von Datentransfers Abhängig von der Topologie des Netzwerkes und von der Art des Routings Paketorientierte Netzwerke sind schwieriger abzuhören, da jedes Paket potenziell eine andere Route nehmen kann. Abhören an Knotenpunkten sinnvoll Abhören direkt am Sender oder Empfänger, weil nur eine Leitung vorhanden ist. Hub besser abhörbar als Switch Drahtlos besser abhörbar als Draht, Glasfieber WLAN ist Hub (insbesondere WEP) Dr. Wolf Müller

Physisches Abhören Abfangen der elektromagnetischen oder optischen Abstrahlung von Netzwerkkabeln Funknetzwerke Richtfunk Mobilfunk Dr. Wolf Müller

Frequency Hopping Frequency Hopping Sicherheit auf Layer 1 Häufiges Wechseln der Trägerfrequenz nach nur den Kommunikationspartnern bekanntem Muster, z.B. Pseudozufällig gewählt Abhörer kann nicht alle Frequenzen überwachen Dr. Wolf Müller

Wide Spectrum Spread Aufteilung des Signals auf ein breites Spektrum Signal geht im Rauschen unter Nur Empfänger kennt richtige Chipping Codes und kann durch „Aufintegrieren“ das Signal wieder lesbar machen Auch Code Division Multiplex genannt Dr. Wolf Müller

Was passiert beim Senden von Argon zu Neon? 128.143.71.21 im lokalen Netzwerk. Paket kann direkt gesendet werden. 128.143.71.21 nicht im lokalen Netzwerk. Packet muss über default gateway 128.143.137.1 gesendet werden. DNS: IP-Adresse von “neon.tcpip-lab.edu”? ARP: MAC-Adresse von 128.143.137.1?? ARP: MAC-Adresse von 128.143.137.1 ist 00:e0:f9:23:a8:20 ARP: MAC-Adresse von 128.143.137.1 ist 00:20:af:03:98:28 DNS: IP-Adresse von “neon.tcpip-lab.edu” ist 128.143.71.21 Das ist zu kompliziert -> muss Ordnung und Systematik reingebracht werden. Ohne sich auf den richtigen Kontext (=Layer) einzuschränken, werden in Diskussionen Konzepte oft durcheinandergebrahct, z.B. weil ähnliche Begriffe auf verschiedenen Ebenen wiederverwendet werden (z.B. Endpunkt) frame frame ARP: MAC-Adresse von 128.143.71.21? Dr. Wolf Müller

Bitübertragungsschicht Physical layer Herstellung einer physikalischen Verbindung zwischen zwei direkt verbundenen Kommunikationspunkten Übertragung von Bitströmen Medien: Koaxial, TP, Lichtwellenleiter, Funk, Licht Angriff: Jamming Dr. Wolf Müller

Sicherungsschicht Data link layer Bündelung der Bitströme der unteren Ebene zu Datenpaketen (frames) Aufteilung der Pakete der darüberliegenden Ebene in Datenpakete Kontrollinformation (Prüfsummen) Fehlerkorrigierende Verfahren Cyclic Redudancy Check (CRC) CRC ist kein MAC! Behebung, Erkennung von Übertragungsfehlern Behandlung beschädigter, duplizierter, verloren gegangener Frames Regelung des Medienzugangs Regulierung des Datenflusses Dr. Wolf Müller

Vermittlungsschicht Network layer Kontrollierte Verknüpfung von Netzwerkteilen Ende-zu-Ende Kommunikation zwischen Kommunikationspartnern Vermittlung möglich auch bei: Unterschiedlichem Addressierungsschemata, Verschiedenen Paketgrößen Heterogenen Protokollen ROUTING Dynamisch Statisch Zuständig für Accounting Dr. Wolf Müller

Transportschicht Transport layer Etablierung einer von höheren Schichten gewünschten Verbindung Abhängig von Datenaufkommen und Netzbelastung kann pro Wunsch eine logische Verbindung aufgebaut werden oder zur Kostenreduzierung mehrere Verbindungen in einem Kanal gebündelt werden (Multiplexing) Ermöglicht Ende-zu-Ende Kommunikation zwischen einzelnen Prozessen, Diensten (TCP) Realisierung von zuverlässigem paketorientiertem Ende-zu-Ende Protokoll (UDP) Darüberliegendes Protokoll macht Paketaufteilung, Reihenfolge und Quittung Flusssteuerung Verhinderung von Überlauf (Regulierung der Senderate) Dr. Wolf Müller

Präsentationsschicht Presetation layer Umwandlung der maschinenspezifischen Präsentation von Daten in einheitliche Netzwerkdarstellung (und umgekehrt) Fokus: Syntax und Semantik der Übertragenen Information Häufig Datenkompression, Verschlüsselung ASN.1 Serialization (Java, Objects) Dr. Wolf Müller

Anwendungsschicht Application Layer Vielzahl von Protokollen X.400, SMTP FATM, FTP HTTP, Pop Imap DNS Dr. Wolf Müller

Einordnung der Protokolle in Schichten Dr. Wolf Müller

Encapsulation and Demultiplexing Wenn sich die Daten den Protokollstack nach unten bewegen, fügt jedes Protokoll schichtabhängige Kontrollinformation dazu. Dr. Wolf Müller

Internet Architectur Definiert durch Internet Engineering Task Force (IETF) Sanduhr-Design Application vs Application Protocol (FTP, HTTP) FTP HTTP DNS TFTP TCP UDP IP … Ethernet X.25 ATM Dr. Wolf Müller

Netzwerkkomponenten (layer 1) Repeater Erhöhung der Signalreichweite, Verstärkung Vergrößerte Kollisionsdomäne bei Broadcastmedien Hub Multiportrepeater Verbindung mehrerer Netze Eingehende Signale werden aufbereitet und an alle aktiven Ports weitergeleitet Keine Kontrollfunktion Sniffen einfach, Ethernetzkarte im Promiscous-Mode (tcpdump, ngrep) Dr. Wolf Müller

Netzwerkkomponenten (layer 2) Bridge Verbindung von Netzen auf Data-Link Layer Weiterleitung von Datenframes an MAC-Addressen Verwaltet Tabelle über bekannte MAC-Addressen Kann unterschiedliche Medien verbinden. WLAN-Access Point Trennt Kollisionsdomänen, sonst aber nur begrenzte Kontrolle Weiterleitung von Broadcasts in angeschlossene Netzsegmente Switch Multiport Bridge Filterung der Pakete nach MAC-Adressen ARP Cache (Zuordnung IP – MAC) Datenpakete nicht generell als Broadcast Ziel: Erhöhung der Bandbreite Sniffen schwerer, aber nicht unmöglich Maskierungsangriffe auf ARP-Cache (Angreifer schickt ARP Nachricht an Sender, dass sich MAC von X geändert hat, gibt seine eigene MAC als neue an. Antworten auf ARP-Request für X mit eigener MAC Weiterleitung per IP-Forwarding an eigentlichen Zielrechner Fälschung der eigenen MAC ethercap Dr. Wolf Müller

Netzwerkkomponenten (layer 3) Router Verbindung von Netzen auf der Schicht 3 Wegewahl für Pakete der Ebene 3 (im Internetkontext IP) Können Kontroll- und Filterfunktionen wahrnehmen Einfache Paketfilter, Firewalls können durch Router realisiert werden Gatway Verbindung unterschiedlicher Typen IP mit GPRS Dr. Wolf Müller

Internet-Protokoll IP Aufgaben der Netzwerkschicht Paketvermittelnder, verbindungsloser Dienst Keine Bestätigung für Erhalt von Paketen Man spricht von unzuverlässigen Dienst Max. Länge 65.535 Byte Fragmentierung je nach Netzwerkinfrastruktur Ethernet 1.500 Byte Jedes Fragment besitzt IP-Header + Teil der ursprünglichen Daten Keine Maßnahmen für vollständigen Erhalt oder richtige Reihenfolge oder Erhalt überhaupt Dr. Wolf Müller

IP-Addresse, physikalische Addresse IP-Adresse 32-Bit: 141.20.20.55 Oft Domänenname verwendet: www.informatik.hu-berlin.de Zuordnung über DNS, hosts Physikalische Adressen (für Geräte aus 1. und 2. Schicht) Jedem Rechner / Netzwerkinterface physikalische Adresse zugeordnet 48 Bit (oft HEX 08:00:20:fa:03:e4) Erste 24 Bit Hersteller (Sun) Zuordnung eindeutig Aber leicht zu ändern (Driver ifconfig, Karten-Bios, Vmware, Hardwarebrücke) Dr. Wolf Müller

Aufbau eines IP-Pakets Dr. Wolf Müller

Format eines IP-Pakets Identifikation, Flags, Fragment-Offset Information zum Zusammensetzen des ursprünglichen Pakets Fragmentiertes Paket ist vom Aufbau mit unfragmentiertem identisch Identifikation: Nummerierung der Fragmente Flags: Legt fest, ob Fragmentierung erlaubt ist Fragment Offset: Information für korrekte Zusammensetzung, Position der Daten im Original-Datagramm Sende, Empfangs-Adresse IP-Optionen: 8 Bit Optionsfeld Durch Sysadmins benutzt, Test und Kontrolle von Verbindungen Loose Source Routing (Optionsnummer 3) Strict Source Routing (Optionsnummer 9) Dr. Wolf Müller

Transport-Kontrollprotokoll TCP Zuverlässiges verbindungsorientiertes Protokoll der Transporteben Datenstromorientiert aus Sicht höherer Schichten Logische Ende-zu-Ende Verbindung IP:port Prüfen der Ankunft von Datenpaketen+Reihenfolge Acknowledgement, sonst Retransmission Port: Ende-zu-Ende Verbindung IP:Port Port 16-Bit Well-known ports ≤ 256 für Standarddienste reserviert /etc/services UNIX: trusted Ports {0,…,1023}, nur Programme mit Superuser-Rechten Idee Zugriff auf vertrauliche Daten nur durch Root: rlogin 513 Kein Standard Jeder PC kann TCP-Pakete mit kleinen Nummern absenden Dr. Wolf Müller

TCP-Verbindungsaufbau TCP Paket enthält: 16-Bit Sende-, Empfangsport Zur Kontrolle der Reihenfolge: 32-Bit Sequenznummer, Gemäß TCP-Specifikation mit zufalligem Wert initialisiert, fortlaufen inkrementiert Empfänger bestätigt durch Zurückschicken eines eigenen Pakets, das Acknowledgenummer = Sequenznummer des letzten Pakets +1 Dr. Wolf Müller

3-Phasen Handschake Verbindung zwischen A und B A  B SeqA Connetion Request von A enthält: - IPB, PortB - generiert SeqA, löscht Acknowledgement-Bit Falls auf Zielmaschine Prozess am angegebenen Port lauscht: Empfang wird quittiert, Acknowledgement-Bit gesetzt, Antwortpaket mit neuer Sequenznummer SeqB generiert Bestätigung durch A Sender Empfänger IP-Paket enthält A  B SeqA B  A SeqS , Ack=SeqA+1 A  B Ack=SeqS+1 A  B Daten Dr. Wolf Müller

User Datagramm Protokol UDP Verbindungslos Erweiterung der Funktionalität von IP um Ports Keine Quittung von Paketen, keine Erkennung von Verlusten, falscher Reihenfolge Dr. Wolf Müller

DHCP Dynamic Host Configuration Protocol Dynamisch Zuordnung von IP-Addressen RFC 2131, 2132 Client fragt mit Broadcast nach eindeutiger IP Alle DHCP-Server, die diese Nachricht empfangen antworten mit Adressen-Angebot Client nimmt erstes Angebot, fordert über Request-Nachricht diese IP-Adresse an Vergebender Server macht dies durch Acknowledgment bekannt Lease nur beschränkte Zeit gültig Weitere Informationen zum Netzwerk können übermittelt werden. DNS Gateway Nextserver WINS Dr. Wolf Müller

Network Address Translation Protocoll NAT Auf Router oder Server wird NAT-Tabelle verwaltet Router oder Server ist Gateway zum Internet, hat eindeutige IP-Adresse Übersetzung eindeutig (IP,port)(IP,port) intern Sharing einer IP-Adresse zwischen mehreren Rechnern (privates Subnetz) Dr. Wolf Müller

Sicherheitsproblem: Spoofing Authentizität: Häufigste Angriffe: Address Spoofing Angreifer maskiert und unter falscher Identität Ansatzpunkt: MAC-, IP-Adressen in Ethernet-, IP-Paketen, insbesondere Absender, DNS-Namen Dr. Wolf Müller

ARP-Spoofing ARP-Spoofing nutzt Designschwäche ARP im ARP-Protokoll (zustandslos) Jeder Host hat eigenen ARP-Cache, wo (MAC,IP)-Adressenpaare verwaltet werden. ARP-Spoofing “vergiftet” diesen Cache durch Senden gefäschter ARP-Replies

ARP-Spoofing ??? Host A Host B 192.168.0.2 192.168.0.3 00-E0-F0-25-41-7E Host B 192.168.0.3 00-00-1C-9E-69-30 192.168.0.3 is at 00-00-1C-9E-69-30 192.168.0.4 is at 00-E0-DA-8B-B4-05 192.168.0.2 is at 00-E0-F0-25-41-7E 192.168.0.4 is at 00-E0-DA-8B-B4-05 ??? Attacker 192.168.0.4 00-E0-DA-8B-B4-05 192.168.0.2 is at 00-E0-F0-25-41-7E 192.168.0.3 is at 00-00-1C-9E-69-30

ARP-Spoofing Host A Host B 192.168.0.2 192.168.0.3 00-E0-F0-25-41-7E 00-00-1C-9E-69-30 192.168.0.3 is at 00-E0-DA-8B-B4-05 192.168.0.3 is at 00-00-1C-9E-69-30 192.168.0.4 is at 00-E0-DA-8B-B4-05 192.168.0.2 is at 00-E0-F0-25-41-7E 192.168.0.4 is at 00-E0-DA-8B-B4-05 Attacker 192.168.0.4 00-E0-DA-8B-B4-05 192.168.0.2 is at 00-E0-F0-25-41-7E 192.168.0.3 is at 00-00-1C-9E-69-30

ARP-Spoofing Host A Host B 192.168.0.2 192.168.0.3 00-E0-F0-25-41-7E 00-00-1C-9E-69-30 192.168.0.3 is at 00-E0-DA-8B-B4-05 192.168.0.4 is at 00-E0-DA-8B-B4-05 192.168.0.2 is at 00-E0-F0-25-41-7E 192.168.0.4 is at 00-E0-DA-8B-B4-05 Attacker 192.168.0.4 00-E0-DA-8B-B4-05 192.168.0.2 is at 00-E0-F0-25-41-7E 192.168.0.3 is at 00-00-1C-9E-69-30

ARP-Spoofing Host A Host B 192.168.0.2 192.168.0.3 00-E0-F0-25-41-7E 00-00-1C-9E-69-30 192.168.0.3 is at 00-E0-DA-8B-B4-05 192.168.0.4 is at 00-E0-DA-8B-B4-05 192.168.0.2 is at 00-E0-F0-25-41-7E 192.168.0.4 is at 00-E0-DA-8B-B4-05 Attacker 192.168.0.4 00-E0-DA-8B-B4-05 192.168.0.2 is at 00-E0-F0-25-41-7E 192.168.0.3 is at 00-00-1C-9E-69-30

ARP Spoofing Alle von A nach B gesendeten Pakete werden über den Angreifer geleitet, der sie an B weiterleitet. Rückweg kann in gleicher Weise manipuliert werden. Erlaubt „Man in the Middle Attack“ Kann lokal automatisch gestartet werden mit Tools wie: dsniff oder ettercap.

ARP Spoofing - Gegenmaßnahmen Statische Einträge in ARP-Cache beugen ARP-Spoofing vor Funktioniert nicht MS OS's (Wird „static” eingetragen, aber trotzdem durch Replies überschrieben) Netzwerk ist unflexibler, aber zumindest die MAC des Gateways sollte statisch funktionieren IDS (intrusion detection system): Angriffe dieser Art sind offensichtlich und leicht zu erkennen Tool: arpwatch

Sicherheitsprobleme von IP: Spoofing (2) Angreifer Rechner 10.0.42.1 gespoofter Rechner 141.20.20.2 141.20.20.2 141.20.20.131 … Absender Empfänger Router Internet interner Rechner 141.20.20.131 Dr. Wolf Müller

Beispiel 1: Trusted Hosts Unix (trusted host) ziel.de /etc/hosts.equiv, .rhosts: freund.de rlogin, rsh möglich ohne Passwort Rechner mit Berechtigungen für NFS-Freigaben Dr. Wolf Müller

Beispiel 2: DoS Denial of Service: Öffentliche Beachtung ab 2000, Angriffe auf Yahoo, Amazon, eBay Finanzielle Abhängigkeit von Erreichbarkeit Details: Zombie-Rechner unter vollständiger Kontrolle des Angreifers Bei Startkommando Angriff Auch DDoS genannt Abwehr: Ermittlung der Adressen aller Zombie-Rechner, blockieren jeglichen Verkehrs von diesen Abwehr zunehmend schwierig, da sehr dynamisch Dr. Wolf Müller

Beispiel 2.1: UDP-flood Angriff Basiert auf UDP-Diensten UDP-Paket mit gefälschter Absender-Adresse an Opfer Verbindung mit Dienst chargen, den das Opfer zur Zeichenerzeugung anbietet Opfer sendet nun Strom von Zeichen an gespooften Absender, beide werden gelähmt Dr. Wolf Müller

Beispiel 2.2: Smurf-Angriff Angreifer sendet Strom von ping Packeten (ICMP) mit gefälschter Absender-Adresse (alice.victim.com) an IP-Broadcast Adresse von stooge.com Alle Rechner aus dem Netz von stooge.com antworten an alice.victim.com Dr. Wolf Müller

Smurf-Angriff: Gegenmaßnahmen ICMP deaktivieren (nur bedingt möglich und sinnvoll) IP-Broadcast am Router deaktivieren Problem DDoS: nicht ein Angreifer sondern sehr viele Angreifer, die nicht Broadcast sondern verschiedene Rechner verwenden, oder Alice direkt angreifen Dr. Wolf Müller

Beispiel 2.3: SYN-flood-Angriff TCP 3-Wege Handshake zum Verbindungsaufbau SYN Flooding Solange „halboffene“ TCP-Verbindungen aufbauen, bis Ressourcen des angegriffenen Systems verbraucht sind Alice Bob Mallet Bob SYN SeqNr=x SYN SeqNr=x SYN SeqNr=y; ACK x+1 SYN SeqNr=y; ACK x+1 SYN SeqNr=z ACK y+1 SYN SeqNr=a Dr. Wolf Müller

SYN-Flood-Verletzlichkeit der Betriebssysteme Wiederholung von „verlorenen“ SYN Paketen: Exponential Backoff zur Berechnung der Wartezeit Linux und W2K (3s, 6s, 12s, 24s,....) BSD 6s, 24s, 48s, ....) Abbruch des Retransmit W2K nach 2 Versuchen (d.h. nach 9 Sekunden) Linux nach 7 Versuchen (d.h. nach 381 Sekunden) nach 75 Sekunden Minimale Anzahl von SYN Paketen für erfolgreichen DoS Quelle: [Chang 02] Dr. Wolf Müller

SYN-flood-Angriff: Gegenmaßnahmen Timer definieren Falls ACK nicht innerhalb dieser Zeitspanne erfolgt, Ressourcen wieder freigeben Nutzt nur bedingt Falls alle Ressourcen belegt zufällig eine halboffene Verbindung schließen Maximale Anzahl gleichzeitig halboffener Verbindungen pro Quell-Adresse festlegen Problem DDoS Prinzipielle Unterscheidung zwischen legitimer Nutzung und Angriff nicht möglich. Dr. Wolf Müller

Sicherheitsproblem: Vertraulichkeit Weder Nutzdaten noch Verwaltungsdaten (Header) eines IP-Pakets vor Übertragung verschlüsselt Liegen auf allen Kommunikationsverbindungen und in allen Vermittlungsstellen im Klartext vor Passworte für Remote-Login Vertrauliche Firmendaten Personenbezogene vertrauliche Daten Verkehrsflussanalysen (aus Sende- / Empfangsadressen werden Zugriffs- und Kommunikationsprofile erstellt. Keine Anonymität. Dr. Wolf Müller

Sicherheitsproblem: Integrität IP-Protokoll stellt keine Mechanismen wie Hashfunktionen oder Message Authentication Codes für Nutzdaten zur Verfügung Keine Möglichkeit, Modifikationen zu erkennen und derartige Angriffe abzuwehren. CRC nur für Bitübertragungsfehler, Angreifer kann korrekte CRC berechnen und in das Datenpaket integrieren Dr. Wolf Müller

Sicherheitsproblem: Verbindlichkeit Identifikation der Kommunikationspartner anhand der im IP-Paket eingetragenen, nicht fälschungssicheren IP-Adresse Keine weiteren Maßnahmen wie digitale Signaturen, um Daten den absendenden Prozessen oder Benutzern zuzuordnen Konsequenz: IP-basierte Aktionen sind ohne zusätzliche Maßnahmen nicht verbindlich! Dr. Wolf Müller

Beispiel 1: Routing Angriffe Zur Wegwahl Routing-Protokolle Meist symmetrisch Optionsfeld des IP-Pakets: Strict Source Routing (Sender trägt IP-Adressen alle Zwischenstationen in korrekter Reinfolge ein, diese müssen direkt verbunden sein) Kenntnisse über Netzinfrastruktur nötig Loose Source Routing (Sender trägt Zwischenstationen ein, diese müssen nicht direkt miteinander verbunden sein) Angreifer trägt eigene IP in die Route ein, damit zurückgesendete Pakete über seinen Rechner geleitet werden, Information extrahiert werden kann. Dr. Wolf Müller

Beispiel 1: Routing Angriffe (2) Routing Information Protocol (RIP) Propagiert Routing-Information im Netzwerk Typischer Weise überprüft Empfänger diese Information nicht Angreifer M kann Kommunikation zwischen A und B über eigene Maschine umleiten M simuliert A und sendet manipulierte RIP Pakete an B und an die zwischen M und B liegenden Gateways Darin werden B und alle Gateways aufgefordert, an A gerichtete Pakete zum Rechner M zu senden. Nach Auswertung durch M, Weiterleitung an A. Mit Option Source Routing kann M erreichen, dass auch Antwortpakete bei ihm vorbeikommen. Abwehr: Konfiguration der Router, so dass Änderungen von Routen nur unter speziellen Bedingungen möglich sind. Dr. Wolf Müller

Sicherheitsprobleme von ICMP Internet Control Message Protocol: Übermittlung von Fehler- und Statusmeldungen Fehler: Nichterreichbarkeit (destination unreachable) Aufforderung zur Fragmentierung (fragmentation needed) Status: Umleitung bei Stau ICMP-redirect Drosseln des Senderate des potentiellen Verursachers (ICMP-source quench) Dr. Wolf Müller

Angriffe mit ICMP Abbruch der Verbindung Erhöhung der Netzlast destination unreachable + Packet-Header des zu vermittelnden Pakets Sendestation erkennt, welche Verbindung terminiert werden soll (Port) Ältere Implementationen beenden alle Verbindungen Erhöhung der Netzlast fragmentation needed Gezielte Umleitung von Paketen redirect ping of death ICMP-Ping mehr als 65.510 Byte veraltet Dr. Wolf Müller

DNS Domain Name Service Abbildung von Namen auf IP-Adressen sar.informatik.hu-berlin.de -> 141.20.23.63 Reverse DNS Lookup = Abfrage in entgegengesetzter Richtung Warum Namen? Besser zu merken Strukturierung Länder .de .fr Art .com .biz .org .edu Abbildung ist nicht eineindeutig Aliases (mehrere Namen für eine IP-Adresse) Load-balancing, dyn-DNS: variable IP für festen Namen Dr. Wolf Müller

DNS Datenbanken DNS-Server verwaltet 2 Datenbanken Reverse-Zonen Datenbank Zuordnung IP-Adressen -> Domänennamen Verwendet bei rlogin, mount Forward-Zonen Datenbank Zuordnung Domänennamen -> IP-Adressen Verwendet zum Verbindungsaufbau Zur Erhöhung der Verfügbarkeit und Performance werden diese Datenbanken repliziert, es gibt jedoch „primären DNS-Server“ DNS-Anfrage (an Port 53) wird zum DNS-Server gesandt der diese aus der eigenen Datenbank, den Cache oder durch Weiterleitung beantwortet wird Angriffspunkt Dr. Wolf Müller

Sicherheitsprobleme von DNS DNS basiert auf unzuverlässigen, verbindungslosem UDP DNS-Spoofing: Angriffe, bei der Angreifer Zuordnung zwischen IP-Adresse und Domän-Namen fälschen. Caching-Problem Ältere Server akzeptieren auch nicht angeforderte Daten Dr. Wolf Müller

DNS Spoofing Ausnutzung von Schwachstellen im DNS Ziel: Angreifer A täuscht vor, ein bestimmter (Web-) Server zu sein. Opfer greift dann auf „Fälschung“ zu Dadurch können sensible Informationen beispielsweise Passwörter o. ä. Zugangscodes ermittelt werden Bsp.: DNS Spoofing eines Internetbanking Servers Idee: Einpflanzung einer falschen IP-Adressauflösung für einen bestimmten Hostnamen DNS-Anfrage für diesen Host liefert dann die falsche IP-Adresse (des Angreifers) zurück (bis DNS-Eintrag expired und die Tabelle wieder abgeglichen wird) Dr. Wolf Müller

DNS Spoofing (2) Möglich, weil: Adressinformationen nicht zentral, sondern verteilt gehalten und über Netzwerk ausgetauscht werden; Aufgelöste Adressen im Cache des DNS-Servers bzw. des Clients gehalten werden; erneute Zugriffe geben so weiterhin die Fälschung zurück; Authentizität der übermittelten Einträge nicht geprüft werden kann Dr. Wolf Müller

DNS Spoofing Dr. Wolf Müller

DNS Spoofing (2) Dr. Wolf Müller

DNS Spoofing (3) Dr. Wolf Müller

DNS-Cache-Poisoning DNS-Server1 DNS-Server1 DNS-Cache DNS-Cache www.x.com 1.2.3.4 2. Weiterleiten der Anfrage DNS-Server für www.k.de Request IP für www.k.de 3. Antwort www.k.de 5.6.7.8 www.x.com 5.6.7.8 Angreifer 5.6.7.8 Nutzer Dr. Wolf Müller

DNS-Cache-Poisoning (2) DNS-Server1 DNS-Server1 DNS-Cache DNS-Cache www.k.de 5.6.7.8 www.x.com 5.6.7.8 www.x.com 1.2.3.4 4. DNS-Server für www.k.de 6. Response 5.6.7.8 5. Request IP für www.x.com 7. Login www.x.com Benutzer Password Angreifer 5.6.7.8 Nutzer Dr. Wolf Müller

DNS: Fazit Authentifizierung mit IP-Adressen oder Domännamen ist unzureichend. Abwehr Signierte Antworten von DNS-Servern Problem: Verifikation, PKI nötig, Dezentralität noch umsetzbar? Speicherung der gestellten Fragen durch DNS-Server, exakter Abgleich mit eingehenden Antworten DNSSec http://www.dnssec.net/ Schutz gegen: Bösartige DNS-Administratoren Netzwerkprotokollangriffe DNS-Cache poisoning Sicherheits-Erweiterungen sind noch wenig verbreitet! Dr. Wolf Müller

NFS Network File System (NFS) 1984 durch Sun Microsystems entwickelt Client / Server –Modell In Version 2 und 3 zustandslos Version 2: UDP Version 3: Unterstützt TCP Weit verbreitet Erst Version 4: Von AFS beeinflusst, beinhaltet Sicherheitserweiterungen Dr. Wolf Müller

NFS (2) Server: /etc/exports legt fest, welche Rechner zugreifen dürfen, welche Zugriffe zulässig sind. /NETBOOT *(ro,no_root_squash,sync) /tmp a(rw,no_root_squash,sync) b(rw,no_root_squash,sync) exportfs –a exportiert die Verzeichnisse Client: showmount rechnername listet exportierte Verzeichnisse, diese werden z.B. mit mount –t nfs server:/tmp /my_tmp in das lokale Dateisystem eingebunden. Dr. Wolf Müller

NFS: Mounten NFS-Client NFS-Server nfsd mount mountd Anwen-dung 1. Mount-Anforderung mountd 4. Dateihandle übergeben 2. Dateihandle anfordern 3. Dateihandle Anwen-dung nfsd 5. Direkter Zugriff: - Lesen - Schreiben Dr. Wolf Müller

NFS: Zugriffskontrolle Unterscheidung zwischen Berechtigung zum Mounten und Zugriff auf einzelne Dateien innerhalb des Dateisystems (lesend, schreibend, ausführend) Client: Mount-Request Anhand der Mount-Beschränkungen prüft Server, ob Client zum Mounten berechtigt ist, erzeugt File Handle für Wurzelverzeichnis, sendet dieses zurück an Client. Kontrolle der tatsächlichen Dateizugriffe basiert auf der Zugriffskontrolle von UNIX (auf dem Client), und wird vom (uid,gid) realisiert, ein (Nutzer-) Password wird nicht gefordert! Inode spezifiziert Zugriffsrechte, falls Client berechtigt ist, erzeugt NFS-Server ein File Handle, danach wird Datei direkt geöffnet. Dr. Wolf Müller

NFS: Zugriffskontrolle (2) Server Z /etc/exports /usr Client 1 mout z:/usr /mnt Zugriffsrechte für /usr uid 0 rwx------ /usr Joe f /mnt /usr Joe f Mounten Zugriffsrechte für f uid 100 rwxr--r-- Dr. Wolf Müller

NFS: Sicherheitsprobleme Design & Implementierungsfehler Mount-Berechtigung: Protokoll erlaubt Mount, solange nicht explizit verboten (Widerspricht minimalen Rechtekonzept) Mount-Protokoll (manche Systeme): Prüfung nur zum Mount-Zeitpunkt of Client berechtigt ist, ohne Freigabe auch selbst wenn /etc/exports geändert ist, weiter nutzbar Zugriffskontrolle Designentscheidung, Zugriffskontrolle zentraler UNIX-Systeme auf verteilte Umgebung zu übertragen (Client prüft Nutzeridentität), uids fälschbar. Hier existieren weitergehende Ansätze: auth_sys, auth_kerb, auth_DH192, RPCSEC_GSS Besitzen zwar Schwächen, aber schon wesentliche Verbesserungen Zustandsloser Server: Keine Information über Clienten, Clienten verwalten Zugriffsausweise (File Handles). Diese werden zufällig erzeugt, aber sind statisch, werden unverschlüsselt übertragen. Dr. Wolf Müller

NFS: Sicherheitsprobleme (2) Administrative Fehler: Unbeschränkter Export eines Dateisystems: (.rhosts, .ssh) Schreibrechte (Trojaner, s-Bit, root-Shell) Zugriffskontrolle Name/IP-basiert fälschbar Dr. Wolf Müller

NFS: Version 4 Ziel: höhere Sicherheit Verbesserte Authentifikationsverfahren Firewall-kompatibel: fester Port 2049 In Version 2, 3 war über das Mount-Protokoll ein Austausch eines File Handles notwendig, Kommunikation über RPC ohne feste Portaddresse GSS-API: (Generic Security Services) Verwendet RPC-SEC_GSS (RFC 2203) GSS-API bietet darauf aufsetzenden Protokollen Sicherheitsdienste wie: (Integrität, Authentizität, Vertraulichkeit von Nachrichten) Authentifizierung über: Kerberos Version 5 Public Key Dr. Wolf Müller

NIS Network Information System / Yellow Pages Sun 80er Jahre Verteilte Password-Datenbank, auch Schlüsseldatenbanken für Kerberos- und Secure-RPC-basiertes NFS Zentrale Speicherung auf NIS-Master-Server Dr. Wolf Müller

NIS: Ablauf Client: Angabe der NIS-Domian + -Eintrag in /etc/passwd (+:Joe:*0:0:::) Bei Login für Joe zum Client wird Nachricht an NIS-Master gesendet, Passwortdatei angefordert Client führt Authentifikation auf dieser Basis durch. NIS kann falls Secure RPC verfügbar, verschlüsselt übertragen werden. Dr. Wolf Müller

NIS: Sicherheitsprobleme Datenbankzugriff NIS gewährt jedem System, das NIS-Domänennamen kennt Zugriff auf NIS-DB (Password-Crack möglich) Server-Maskierung Fehlende Authentifikation des NIS-Servers, Clients senden Anfragen unter Nutzung von RPC, Echtheit der Antwort kann nicht geprüft werden. Für Angreifer ausreichend, als erster zu antworten, weitere Antworten werden Verworfen (UDP-basiert) Portmapper Portmapper-Dämon wird verwendet, um RPC-Dienst zu binden, Annahme von „trusted Ports“ nicht gültig für alle Portmapper-Implementationen (Angreifer ersetzt RPC-Dienste durch eigene, z.B. Trojaner) Fazit: NIS für offene Umgebungen ungeeignet Dr. Wolf Müller

Probleme der Internetprotokolle Vertraulichkeit Authentizität der Absender / Empfänger Verbindlichkeit Datensicherheit Verfügbarkeit Fazit: Weitere Mechanismen zur Absicherung nötig. Dr. Wolf Müller

Gefährliche Protokolle: telnet rlogin rsh ftp http pop imap Dr. Wolf Müller

Werkzeuge ntop tcpdump, snoop nmap wireshark(ethereal), dsniff Statistik, Protokolle, Verbindungsdaten ntop -u wwwrun tcpdump, snoop Lauschen, Aufzeichnen von Paketen nmap Offene Ports / Protokolle erkennen wireshark(ethereal), dsniff Lauschen, Aufzeichnen, Inspektion des Paketinhalts Aber auch aktive Angriffe möglich Dr. Wolf Müller

Werkzeug: dsniff (1) Sammlung von Passwortsniffern und Spoofern ftp, telnet, smtp, nis ... http://naughty.monkey.org/~dugsong/dsniff (Etwas veraltet, schwer zu bauen.) arpspoof Manipulation des ARP-Caches von Switchen dnsspoof DNS spoofing dsniff Passwortsniffing filesnarf Ablauschen von Dateien beim NFS-Transport macof Fluten geswitchter Netze mit MAC-Adressen Dr. Wolf Müller

Werkzeug: dsniff (2) mailsnarf msgsnarf sshmitm sshow tcpkill tcpnice Speicherung übertragener Mails in Mailbox msgsnarf Belauschung von CHAT-Nachrichten sshmitm ssh „man in the middle“-Angriff sshow SSH[12]-Protokollanalyse (Passwortlänge,..) tcpkill Terminieren einer TCP-Verbindung tcpnice Bremsen von TCP-Verbindungen urlsnarf Protokoll aller HTTP-Requests webmitm WWW „man in the middle” Angriff mit dnsspoof webspy Anzeige von fremden WWW-Requests im eigenen Browser (FF) Dr. Wolf Müller

Log: dsniff wolftux:/home # dsniff -m dsniff: listening on eth0 11/02/07 09:32:15 tcp 192.168.5.185.12444 -> mail.informatik.hu-berlin.de.110 (pop) AUTH LOGIN d29sZm14 [wolfmx] VkxTZWMhMDc= [VLSec!07] 11/02/07 09:32:49 tcp 192.168.5.185.15495 -> mail.informatik.hu-berlin.de.143 (imap) LOGIN wolfmx VLSec!07 11/02/07 09:40:28 tcp 192.168.5.185.16419 -> sar.informatik.hu-berlin.de.80 (http) GET /teaching/2007-w%20Security%20Engineering%20(Basics)/slides/ HTTP/1.1 Host: sar.informatik.hu-berlin.de Authorization: Basic c2Fyc3R1ZDpzYXIhcGRmLzA3 [sarstud:sar!pdf/07] 11/02/07 10:26:10 tcp 192.168.5.185.10175 -> ftp.informatik.hu-berlin.de.21 (ftp) USER anonymous PASS wolfm@foo.de Dr. Wolf Müller

Demo: ntop -u wwwrun Dr. Wolf Müller

Demo: wireshark Dr. Wolf Müller