IT-Sicherheit WS 2013/14. Übung 11. zum 30. Januar 2014

Transkript

1 Prof. Dr. C. Eckert Thomas Kittel IT-Sicherheit WS 2013/14 Übung 11 zum 30. Januar 2014 Institut für Informatik Lehrstuhl für Sicherheit in der Informatik 1 SSL/TLS in VoIP In Voice-over-IP (VoIP) Kommunikation kann das Session Initiation Protocol (SIP) verwendet werden, um den Aufbau bzw. Abbau von IP-Telefonverbindungen zu steuern. Der grobe Verlauf eines Verbindungsaufbaus (genannt Signalisierung) zwischen den IP- Geräten A und B über die Proxy-Server P A und P B ist im folgenden Bild dargestellt: Abbildung 1: Session Aufbau bei SIP Die Spezifikation von SIP lässt unter anderem TCP und UDP als Transportprotokolle zur Übertragung von SIP-Nachrichten zu. 1

2 a) Beschreiben Sie die Vor- und Nachteile von UDP bzw. TCP als Transportprotokolle für die Übertragung von SIP-Nachrichten? UDP bringt bei der Übertragung von VoIP Verkehr mehrere Vorteile: Bessere Skalierbarkeit der Proxy Server, da diese nicht noch zusätzlich zu den Nutzdaten den Zustand einzelner Benutzer-Sessions verwalten müssen (ein Paket vs. drei Pakete + Zustand im Server). Bessere Übertragungsqualität: Bei Audioübertragungen ist es unter Umständen besser ein Paket zu verlieren, als es verzögert zu übertragen und wiederzugeben (Congestion Control, Slow Start,...). Dahingegen die Vorteile von TCP: Garantierte Übertragung der Daten Durch das halten eines Zustands ist der Client beim Server automatisch abgemeldet, sobald die Verbindung abbricht. b) An welch(er/en) Stelle(n) kann die Signalisierung mittels SSL/TLS geschützt werden? Wie verteilen sich dann die Rollen des Clients und des Servers aus dem SSL/TLS- Protokoll auf die Objekte aus dem oberen Bild? Die Übertragung der Daten kann in jedem Schritt mit SSL/TLS abgesichert werden. Dies ist insbesondere dadurch gewährleistet, dass das SIP Protokoll an das HTTP Protokoll angelehnt ist. Dabei ist jeweils die anfragende Partei der Client und die angefragte Partei der Server. Da die Proxyserver jeweils für ihren Bereich zuständig sind, sollten sie die Zertifikate ihrer Benutzer kennen und diese daher überprüfen können. Der Benutzer hingegen kennt das Zertifikat seines lokalen Proxyservers. Die Proxyserver (eingehende Gateways der SIP Betreiber) sollten mit echten (nicht selbst signierten) Zertifikaten bestückt sein, so dass diese gegenseitig überprüft werden können. Die Übertragung der eigentlichen Nutzdaten (Audio und Videoübertragung) zwischen den beiden Telefonen sollte statt dem standardmäßig verwendeten RTP (Real- Time Protocol) das sichere SRTP verwenden. c) Was muss für den Einsatz von SSL/TLS in Bezug auf die Wahl des unterliegenden Transportprotokolls beachtet werden? Es muss TCP verwendet werden. 2

3 d) Alternativ zu SSL/TLS wurde im SIP Standard die Verwendung von IPsec zur Sicherung der Daten vorgesehen. In welchen Szenarien ist die Verwendung von IPsec gegenüber SSL/TLS von Vorteil? Die Verwendung von SSL/TLS und IPsec zur Sicherung der Kommunikation der SIP Nachrichten wurde innerhalb der Arbeitsgruppe lange diskutiert. SSL ist auf Endsystemen wie PCs oder Smartphones leichter verwendbar: IPsec erfordert komplexe Konfiguration. Dank dem bereits integriertem Browser ist ein SSL Stack meitst vorhanden. Kann unanhängig von der verwendeten Netzwerkinfrastruktur verwendet werden (NAT, Firewalls,...). Trotzdem bietet IPsec einige Vorteile beim Einsatz in Corporate Netzwerken: Beim Einsatz von IPv6 ist das vorhandensein eines IPsec Stacks zwingend vorgeschrieben. Es wird kein weiterer SSL Stack benötigt. Die meist ressourcenschwachen Geräte benötigen daher keine zusätzliche Software zur Absicherung. Die Absicherung findet schon auf der ISO/OSI Schicht 3 statt, was die Paketverarbeitung vereinfacht. Zur Datenübertragung kann UDP verwendet werden. Einfachere Konfiguration wenn es auf dedizierten Computern (IP-Telefone), unter Umständen in eigenen VLANs verwendet wird. e) Welches Problem kann bei der alternativen Verwendung von SSL/TLS und IPsec im SIP Standard entstehen? Wie kann dies gelöst werden? Durch die alternative Verwendung können zwei unabhängige SIP Wolken entstehen, welche nicht miteinander kommunizieren können. Diese Inkompatiblität wurde in einem weiteren Standard behoben. Für einen Provider (z.b. SIP Proxy P B ) wird vorgeschrieben, dass er zwar intern IPsec verwenden kann, jedoch zur Kontaktaufnahme von und nach außen auch SSL/TLS unterstützen muss. f) Abwehr von Angriffen - Beschreiben Sie warum SSL/TLS von folgenden Sicherheitsrisiken schützt bzw. nicht schützt: Brute-Force Angriffe Nein Wörterbuch Angriffe Nein Replay Angriffe Ja, wegen der Noncen beim Verbindungsaufbau und der Sequenznummer in jedem Paket Man-in-the-Middle Angriffe Ja, wenn beide Seiten sich mit einem Zertifikat authentifizieren 3

4 Abhören von Passwörtern Ja, da die gesendeten Nachrichten verschlüsselt sind IP-Spoofing Nein, es wird zwar die authentifikation geprüft, nicht jedoch die verwendeten IP-Adressen IP-Hijacking Nein, es können dann jedoch keine Daten aus dem Stream extrahiert werden, da der Schlüssel nicht bekannt ist. SYN-Flooding Nein, hier schaffen die SYN-Cookies abhilfe. g) Angriffe auf SSL/TLS - Im folgenden sollten einige Angriffe auf SSL/TLS besprochen werden. Die drei wichtigsten davon sind BEAST, CRIME und BREACH. Wie funktionieren diese Angriffe und wie kann man Sie umgehen? Das Ziel aller dieser Angriffe ist Teile des Plaintexts von verschlüsselten Nachrichten erraten zu können. BEAST (2011): Hintergrund: Innerhalb von SSL/TLS werden Blockcipher (AES, 3DES) im CBC Modus verwendet um die schwächen des ECB Modus zu umgehen. Normalerweise verwendet man bei CBC für jede Verschlüsselung einen neuen IV zufälligen IV. Innerhalb von SSL/TLS (bis TLS 1.0) wird jedoch der Ciphertext des letzten Blocks einer Nachricht als IV für die nächste Nachricht verwendet. Bereits in 2004 wurde ein möglicher Angriff bekannt a. Wenn ein Angreifer es schafft eine Nachricht einzuschleusen, kann er unter Umständen den Inhalt eines vorher gesendeten Blocks erraten. Angenommen er kennt den Cipherblock C_i und rät den zugehörigen Klartext P. Zusätzlich kennt der Angreifer den letzten gesendeten Ciphertextblock C_n = X. Da dieser Block als IV der nächsten Nachricht verwendet wird, kann nun folgende Nachricht vom Angreifer eingebracht werden: X C_i 1 P. Dieser Block wird mit dem IV verknüpft, es wird folgender Block verschlüsselt: C_i 1 P. Falls der Angreifer P richtig geraten hat, wird der Block wieder zu C_i verschlüsselt. Hier muss jedoch immer ein kompletter Klartextblock geraten werden. Obwohl der Angriff nicht rentabel ist, wurde er bereits in TLS 1.1 (2006) gefixt. BEAST: Der BEAST Attack verbessert diesen Angriff insofern, dass nur ein einzelnes Byte geraten werden muss (256 Möglichkeiten) und dass der Angriff im Zusammenhang mit WebSockets praktisch verwendbar wird. Die generelle Idee dabei ist, dass ein Passwort oder ein Cookie im Header immer ein bekanntes Prefix hat und manuell ein Padding im Header eingefügt werden kann. Abhilfe: Man kann entweder den IV für jede Nachricht neu wählen oder im Falle von TLS ein leeres TLS Record vor jede Nachricht anhängen. a bodo/tls-cbc.txt 4

5 CRIME (2012): Um Bandbreite zu sparen verwendet TLS für Nachrichten auch Kompression. Normalerweise wird hierfür der DEFLATE Algorithmus verwendet. Die Länge einer Nachricht ist also auch abhängig von der Qualität der Kompression. Die Idee bei der DEFLATE Kompression ist, sich wiederholende Zeichenfolgen (innerhalb eines Fensters) durch Referenzen auf vorherige vorkommen zu ersetzten. Dadurch verringert sich die Länge der Nachricht. Ein Angreifer kann nun zum Beispiel Cookies oder CSRF Token erraten, indem er zeichenweise selbst Inhalt in ein gesendetes Paket einfügt. Sobald er richtig geraten hat. Verringert sich die Länge der Nachricht, im Vergleich zu den falschen Versuchen. So kann iterativ geraten werden. Dieser Angriff kann nur verhindert werden, wenn die TLS Kompression deaktiviert wird. BREACH (2013): BREACH verfolgt grundsätzlich die gleiche Idee wie CRIME, setzt aber auf der HTTP Kompression auf. 2 IPSec a) Warum werden in IPSec Message-Authentication-Codes statt digitaler Signaturen verwendet? MACs sind deutlich schneller, da keine assym. Kryptograhpie MACs sind kürzer (128 bis 256 Bit), Signaturen min Bit lang. Die MACs werden außerdem auf 96 Bit gekürzt, was bei Signaturen nicht möglich wäre. b) Eine direkte Verbindung zwischen A und B soll mittels IPSec Integrität, Authentizität und Vertraulichkeit gewährleisten. Welche Möglichkeiten gibt es, diese Ziele zu erreichen? Nennen Sie jeweils die benötigten SAs und skizzieren Sie den Aufbau der tatsächlich übertragenen Pakete schematisch. ESP im Tunnel-Modus: IP-neu ESP IP-ori Daten ESP-trail 2 ESP-SAs (Senden und Empfangen), Tunnel-SAs AH + ESP im Transport-Modus: IP-ori AH ESP Daten ESP-trail 2 AH-SAs (Senden und Empfangen) 2 ESP-SAs (Senden und Empfangen) alle 4 SAs sind Transport-SAs Beliebige weitere Kombinationen sind möglich. c) Erklären Sie die Funktionsweise von Cut-and-Paste-Angriffen auf IPSec. Welche technischen Voraussetzungen muss eine angreifbare IPSec-Verbindung aufweisen? Welche Möglichkeiten muss ein Angreifer für eine erfolgreiche Attacke besitzen? 5

6 Technische Voraussetzungen: Host-basierte Verschlüsselung (z. B. VPN-Gateways zwischen zwei Netzen) kein AH, ESP ohne Integritätskontrolle Blockchiffre im CBC-Modus Voraussetzungen für Angreifer: Abhören verschlüsselter Pakete eigener Zugang (d. h. Login-Account) zum VPN Notation: L: angegriffener Benutzer X: Angreifer A B: Paket von Host A zu Host B : verschlüsselt Verschlüsselte Daten entschlüsseln: 1. Von X abgehörte Daten: L : A B: IP ESP TCP Secret X : A B: IP ESP UDP any data 2. Von X wiedereingespielte Daten: X : A B: IP ESP UDP TCP Secret Checksummen sind bei UDP/IPv4 optional, bei UDP/IPv6 verpflichtend; falls sie verwendet werden, sind bei 16-Bit-Checksummen im Schnitt 2 15 Versuche nötig, um CRC zu korrigieren. 3. X erhält als Ergebnis: IP UDP XXX Secret (TCP-Header ist nun verändert) Daten in Session einspielen:: 1. Von X abgehörte Daten: L : A B: IP ESP TCP Data X : A B: IP ESP UDP CBC-Pad rm -rf / 2. Von X wiedereingespielte Daten: L : A B: IP ESP TCP CBC-Pad rm -rf / CRC-Fix CRC-Fix ist nötig, um Checksumme im TCP-Header zu korrigieren, benötigt im Schnitt 2 15 Versuche. 3. L erhält als Ergebnis: IP TCP XXX rm -rf / CRC-Fix (CBC-Pad ist nun verändert) 6