Tech Blog: Potentielle Angriffsvektoren

Angriffspotential über IPv6 wird oft übersehen

23.04.2018, München Trustwave | Autor: Herbert Wieler

Security Policies auch für IPv6 anwenden

Das SpiderLabs Team von Trustwave führt regelmäßig zahlreiche Pen-Tests bei Unternehmen durch. Dabei ist aufgefallen, dass man in den IPv4-Infrastrukturen durchaus eine robuste Sicherheitslage vorgefunden hat, indem gefährliche Dienste gesperrt wurden, Host-basierte Firewalls eingesetzt und auch den Best-Practice-Sicherheitsrichtlinien gefolgt wurde. Allerdings stellte sich auch heraus, dass den meisten Organisationen die potentiellen Gefahren bei IPv6 noch nicht bewusst waren. In den meisten Fällen wurde IPv6 zwar nicht explizit verwendet, allerdings war es auf fast allen modernen Systemen standardmäßig aktiviert. Bei Nichtbeachtung kann dies zu ungewollten Angriffsvektoren führen.

Um auf die Gefahren und Auswirkungen hinzuweisen, die entstehen können, wenn nicht alle Endpunkte vollständig getestet werden, zeigen die Security Experten folgendes reales Beispiel auf.

Beispiel:

Hier hat SpiderLabs die Port-Scan-Ergebnisse von einem Linux-System unter der Adresse 192.168.9.19 aufgezeigt, das von einem Host im selben physikalischen Netzwerk gescannt wurde:

• Nmap scan report for 192.168.9.19
• Host is up, received arp-response (0.0021s latency).
• Scanned at 2018-04-04 10:28:36 +0630 for 105s
• Not shown: 65532 filtered ports
• Reason: 65532 no-responses
• PORT STATE SERVICE REASON VERSION
• 22/tcp open ssh syn-ack ttl 64 OpenSSH 7.5p1 (protocol 2.0; HPN-SSH patch 14v12)
• 25/tcp open smtp syn-ack ttl 64 Postfix smtpd
• 5666/tcp open tcpwrapped syn-ack ttl 64
• MAC Address: 00:80:10:22:38:66 (Commodore International)

Normalerweise aktivieren moderne Betriebssysteme standardmäßig IPv6 mit automatisch konfigurierten Adressen. Im Gegensatz zu IPv4 betreibt IPv6 das Internet Protocol im Layer 2 des OSI-Modells, anstatt ein separates Protokoll wie ARP im Fall von IPv4 zu verwenden. Wenn ein IPv6-fähiges System mit einem Netzwerk verbunden ist, konfiguriert es sich daher mit einer Layer 2-Adresse im fe80::10-Adressbereich, basierend auf seiner MAC-Adresse und hört die standardmäßigen IPv6-Multicast-Adressen ab (ff02::/10) für Router, die ihre Anwesenheit ankündigen, ab. Eine spezielle Multicast-Adresse ist ff02::1, die für alle IPv6-fähigen Knoten gilt, die an das lokale Netzwerksegment angeschlossen sind. Wenn nun ICMP-Echoanforderungen an diese Adresse gesendet werden, sollte theoretisch jeder IPv6-Rechner im lokalen Netzwerk darauf antworten, auch wenn IPv6 nicht explizit konfiguriert wurde:

• ping6 ff02::1%eth0
• PING ff02::1%eth0(ff02::1%eth0) 56 data bytes
• 64 bytes from fe80::280:10ff:fe22:3866%eth0: icmp_seq=1 ttl=64 time=0.031 ms
• 64 bytes from fe80::250:56ff:fe8c:3172%eth0: icmp_seq=1 ttl=64 time=1.82 ms (DUP!)
• 64 bytes from fe80::250:56ff:fe8c:478c%eth0: icmp_seq=1 ttl=64 time=3.03 ms (DUP!)
• 64 bytes from fe80::80b1:c330:51b8:5a22%eth0: icmp_seq=1 ttl=64 time=3.08 ms (DUP!)
• 64 bytes from fe80::ec4:7aff:fe42:2b90%eth0: icmp_seq=1 ttl=64 time=3.63 ms (DUP!)

Basierend auf der ping6-Ausgabe gibt es also 5 IPv6-fähige Geräte im lokalen Netzwerk, einschließlich des Geräts, von dem aus gepingt wurde. Man kann auch ein Gerät mit IPv6-Adresse fe80::280:10ff:fe22:3866 sehen. Das entspricht der MAC-Adresse 00:80:10:22:38:66, die der zuvor gescannten IPv4-Adresse zugeordnet worden ist. Folgend wird ein Portscan für diese IPv6-Adresse durchgeführt, um zu sehen, was gerade abgehört wird:

• Nmap scan report for fe80::280:10ff:fe22:3866
• Host is up, received echo-reply ttl 64 (0.0033s latency)
• Scanned at 2018-04-04 10:32:47 +0630 for 22s
• Not shown: 65530 closed ports
• Reason: 65530 resets
• PORT STATE SERVICE REASON VERSION
• 22/tcp open ssh syn-ack ttl 64 OpenSSH 7.5p1 (protocol 2.0; HPN-SSH patch 14v12)
• 25/tcp open smtp syn-ack ttl 64 Postfix smtpd
• 5666/tcp open tcpwrapped syn-ack ttl 64
• 3128/tcp open http-proxy syn-ack ttl 64 Squid http proxy 3.4.8
• 6379/tcp open redis syn-ack ttl 64 Redis key-value store
• MAC Address: 00:80:10:22:38:66 (Commodore International)

Dabei sind die gleichen Ports, die man beim Scannen des IPv4-Adressports gesehen hat, geöffnet – 22/25/5666 – und sie scheinen auch genau dieselben Dienste zu betreiben. Aber während die IPv4-Adresse andere Ports gefiltert hat, werden alle nicht verwendeten Ports an der IPv6-Adresse als geschlossen angezeigt, was bedeutet, dass das System Verbindungsversuche aktiv zurückweist, anstatt sie zu ignorieren.

Die meisten Betriebssysteme lehnen die Versuche, sich mit nicht verwendeten Ports zu verbinden, ab, während die meisten Host- und Netzwerk-basierten Firewalls so konfiguriert sind, dass sie solche Versuche ignorieren. Das Vergleichen von abgelehnten Verbindungsversuchen mit stillschweigend ignorierten Verbindungsversuchen hilft oft bei der ersten Angriffserkundung.

Ein weiteres interessantes Ergebnis ist, dass beim IPv6-Scan zwei zusätzliche Ports angezeigt wurden, die an der IPv4-Adresse nicht vorhanden waren, ein Squid-Proxy an Port 3128 und eine Redis-Instanz an Port 6379. Anbei ein tieferer Blick auf diese Redis-Instanz.

Die Redis-Sicherheitsdokumentation unter redis.io besagt, dass Redis für die Leistung und nicht für die Sicherheit optimiert ist und dass entsprechende Firewall-Regeln verwendet werden sollten, um den Zugriff auf den eigenen Netzwerkdienst zu beschränken. In diesem Fall hat der Administrator dieses Hosts, genau das getan. Die IPTables-Regeln auf dem Host wurden so konfiguriert, dass der Zugriff von überall auf die Ports 22, 25 und 5666 möglich ist, der Zugriff auf Port 6379 von einigen bestimmten Adressen aus ermöglicht wird und der gesamte übrige Verkehr gelöscht wird. Da dies jedoch nur mit IPTables und nicht mit dem IPv6-Gegenstück, den IP6Tables geschehen ist, erstrecken sich diese Zugriffskontrollregeln nicht auf IPv6. Daher war es möglich, sich ohne Authentifizierung über IPv6 mit der Redis-Instanz zu verbinden:

• redis-cli -h fe80::280:10ff:fe22:3866%eth0 -p 6379
• [fe80::280:10ff:fe22:3866%eth0]:6379> echo test
• "test" – [fe80::280:10ff:fe22:3866%eth0]:6379

Fazit

In diesem Fall haben sich die Administratoren sehr bemüht, die lokalen Firewall-Regeln zu konfigurieren, um den Zugriff auf potenziell anfällige Dienste wie Redis zu beschränken. Sie haben jedoch, möglicherweise aufgrund mangelnder Aufmerksamkeit, nicht auf das Vorhandensein von IPv6 im System geachtet. Viele System- und Netzwerkadministratoren haben noch wenig Erfahrung mit IPv6 und tendieren dazu, sie vollständig zu ignorieren. Wenn entweder IPv6 oder IPv4 für die automatische Konfiguration eingerichtet ist, aber kein Konfigurationsserver im Netzwerk vorhanden ist, sind andere Angriffe möglich, indem Rogue-Server zur Beantwortung dieser Konfigurationsanforderungen eingeführt werden. Moderne Betriebssysteme bevorzugen IPv6 gegenüber herkömmlichem IPv4 und verwenden standardmäßig eine Rogue-IPv6-Verbindung, falls eine verfügbar ist. Auf diese Weise kann ein Angreifer die DNS-Lookups übernehmen. Tools und Write-Ups zum Ausnutzen dieses Konfigurationsangriffs sind bereits auf Github verfügbar und werden daher in diesem Beitrag nicht ausführlicher behandelt.

Eine schnelle Lösung für solche Probleme wäre zunächst die Deaktivierung von IPv6. Dies wird jedoch aus verschiedenen Gründen nicht empfohlen. IPv6 ist die Zukunft und viele modernen Systeme und Software sind darauf ausgelegt. Einige Anwendungen würden dadurch nicht mehr ordnungsgemäß funktionieren, wenn IPv6 deaktiviert ist. Auch wenn das Unternehmen IPv6 noch nicht offiziell einsetzt, ist es nur eine Frage der Zeit, bis es erforderlich ist. Daher ist es sinnvoll, sich so früh wie möglich vorzubereiten und Erfahrungen zu sammeln.

Anstatt IPv6 zu deaktivieren, sollten man eher das Vorhandensein von IPv6 in Betracht ziehen und sicherstellen, dass alle Sicherheitsregeln, die mit IPv4 verwendet werden, auch auf IPv6 repliziert werden. IPv6-Dienste sollten genau wie IPv4 überwacht werden, und das Vorhandensein von Rogue-Servern sollte entsprechend identifiziert und behandelt werden.