Bei der Verwendung von TCPDump stellt der Benutzer nach einer Weile fest: “permission denied” Und das immer wieder. Der Benutzer kann sich unter Ubuntu Server 9.04 LTS und in der Version 10.04 LTS recht viel Frustration mit aa-enforce und aa-complain sparen. Oft wird das Problem an der falschen Stelle gesucht, meist ist alles in Ordnung und korrekt installiert und auch libpcap tut, was es soll. Das bei der Eingabe von tcpdump in vielen Fällen ein “permission denied” erscheint hat etwas mit dem Sicherheitskonzept von Ubuntu zu tun. So sieht das bei vielen aus:

# tcpdump -v -s 1800 -w ausgabe.pcap host 192.168.42.1 and tcp port 22
tcpdump: ausgabe.pcap Permission Denied

Zur Lösung:

Die Einstellungen für tcpdump müssen in AppArmor geändert werden. Dies funktioniert so:

# aa-complain /usr/sbin/tcpdump - Dies ändert die Stufe auf "complain".
# aa-enforce /usr/sbin/tcpdump - Dies aktiviert die Änderungen im Profil von AppArmor für tcpdump

Nun läuft tcpdump wieder wie gewohnt. Falls diese Änderungen nicht durchgeführt werden, ist standardmäßig das Verzeichnis /root freigegeben.

Ein IPIP Tunnel ist so ziemlich der einfachste Tunnel, den Linux bereits seit einer langen Zeit beherrscht. Hierbei werden verschiedene IP Packete, die zu verschiedenen Verbindungen gehören können in weitere IP Pakete verpackt und zwischen zwei Endpunkten versendet. Schon fertig ist der Tunnel. Hierbei wird der Tunnel allerdings nicht verschlüsselt.

Das Internet Protocol (IP) ist stellt die Grundlage des Internets dar. Im Internet wird nicht, wie im LAN mit MAC adressiert, sondern mit IP Adressen. Daher stellt eine IP Adresse das Ziel eines Paketes im Internet dar, nicht wie im LAN letztendlich die MAC Adresse. Bei IP handelt es sich um die Implementierung der Internetschicht des TCP/IP-Modells bzw. des Network Layers des OSI-Referenzmodels.

IP ist ein unsicheres Protokoll, beschädigte Packete werden einfach verworfen. Die höheren Schichten sorgen für das Nachsenden der verlorengegangenen Pakete. So sorgt sich der IP Tunnel in keiner Weise um beschädigte Pakete. Was ankommt, ist da. Mehr nicht. Über ein TAP Device, einer virtuellen Netzwerkkarte, werden die Daten eingepackt und durch den erzeugten Tunnel gesendet. Das Zielsystem empfängt diese Pakete und entfernt den IP Header des Tunnels und wirft das Paket entsprechend auf dem TAP Device wieder heraus. Dort kümmern sich dann andere Komponenten um die Daten.

Nun, wie wird unter Linux ein IPIP Tunnel eingerichtet? Im wesentlichen werden hierzu zwei kernel-Module benötigt. ipip.o und new_tunnel.o.

Ein praktisches Beispiel dazu. Zwei Rechner sollen miteinander einen Tunnel aufbauen. Diese sind mit dem Internet verbunden. Das Internet wird mal Wolke A genannt. Das Netzwerk des ersten Rechners Wolke B und das Netzwerk des zweiten Rechners Wolke C.

Wolke A: Internet
Wolke B: Netzwerkadr. 192.168.10.0; Netmask. 255.255.255.0;
Gateway. 192.168.10.254; Gateway (Internet). 172.16.23.42
Wolke C: Netzwerkadr. 192.168.20.0; Netmask. 255.255.255.0;
Gateway. 192.168.20.254; Gateway (Internet). 172.18.42.64

So gehts weiter. Als erstes Prüfen, ob die Module geladen worden sind. Der Befehl insmod zeigt an, ob das Modul bereits geladen wurde oder ob es korrekt nachgeladen worden ist.

# insmod ipip.o
# insmod new_tunnel.o

Der Rechner in Wolke B wird folgendermaßen eingerichtet.

# ifconfig tunl0 192.168.10.254 pointopoint 172.18.42.64
# route add -net 192.168.20.0 netmask 255.255.255.0 dev tunl0

Der Rechner in Wolke C wird folgendermaßen eingerichtet.

# ifconfig tunl0 192.168.20.254 pointopoint 172.16.23.42
# route add -net 192.168.10.0 netmask 255.255.255.0 dev tunl0

Fertig. Nun sollten die beiden Netze miteinander verbunden sein. Wenn der Tunnel nicht mehr benötigt wird, wird der Befehl

# ifconfig tunl0 down

den Tunnel beenden.

Das war schon der ganze Zauber. Einige Kleinigkeiten müssen noch erwähnt werden. Es handelt sich um einen IPIP Tunnel. Das bedeutet, das IPv6 nicht einfach so durchflutscht. Genauso werden auch Broadcasts nicht geroutet. Für eine verschlüsselte Verbindnung kann OpenVPN verwendet werden. Genaues steht entsprechend im RFC2003 – IP Encapsulation within IP, auch als Plaintext.

Written on September 29th, 2010 , Interessantes, Technik Tags: , , , , , ,

Bei Ettercap handelt es um ein recht mächtiges Werkzeug, mit welchem ein Angreifer in der Lage ist eine Man-in-the-Middle-Attack (MITM) durchzuführen. Hierfür muss natürlich der Datenstrom erst mal zum Angreifer umgeleitet werden. Dazu sind andere Tools vorhanden, die diese Aufgabe durchführen können. Auf diese Weise können auch Verbindungen in einem geswitchten LAN angegriffen werden.

Meist interessiert sich der Angreifer für Passwörter. Schließlich möchte er Zugang zu persönlichen geschützten Bereichen erlangen, die ihm so erst mal verwehrt sind. Einfaches Mitschneiden der Datenverbindung ist auch eine durchaus lohnenswerte Angelegenheit, jedoch werden Kennwörter sehr häufig mithilfe SSL verschlüsselt übertragen. Und genau an dieser Stelle kommt der Angreifer mit beispielsweise Wireshark vorerst nicht so weit. Es muss also eine Möglichkeit geschaffen werden, sich genau dazwischen zu setzen, so dass die SSL Verbindung beispielsweise durch den Computer des Angreifers durch geschleift wird. An dieser Stelle wiederum, lässt sich das Kennwort einfach auslesen und der Zugriff auf die Daten wird im späteren Fall möglich. Dazu kann einfach der verschlüsselte Datenstrom mitgelesen werden, sollte sich der Angreifer nur die übertragenen Daten interessieren. Mit Ettercap kommt der Angreifer seinem gewünschten Ziel soweit recht nahe.

Wir gehen davon aus, dass der Angreifer sich Zugriff auf das Netzwerk des Opfers verschafft hat. Gerade in der heutigen Zeit, wo viele Benutzer WLAN nutzen, lässt sich oft ein Einfallstor finden, bzw. mit etwas Aufwand aufhebeln. Einige Nutzer schützen ihr WLAN gar überhaupt nicht mit einer Verschlüsselung (WEP, WPA oder WPA2) oder verwenden nur einen MAC-Filter, der sich auch recht leicht austricksen lässt. Der Angreifer muss also das Opfer dazu bewegen seine Verbindungen nicht zum Zielsystem aufzubauen, sondern zum Angreifer. Wurde die Verbindung zum Angreifer aufgebaut, wird sie entsprechend weitergeleitet zum eigentlichen Zielsystem. Und schon hängt der Angreifer dazwischen und kann Daten entsprechend ausspähen.

Eine Methode, um Verbindungen zu einem anderen Ziel-Host zu leiten kann das DNS-Spoofing sein. Wer zuerst antwortet, wird erhört, so ungefähr. Der Angreifer fälscht DNS Antworten (Spoofing) und sendet entsprechend eine Antwort, die auf seine dortige IP-Adresse verweist. Das Opfer baut nun eine Verbindung zum Angreifer auf. Antworten lokale DNS Server im LAN zu schnell, können diese mit einer DOS Attack entsprechend ausgebremst werden.

Eine weitere Möglichkeit ist das ARP Spoofing. Hier genauer ARP Cache Poisoning. Im LAN und auch genauso natürlich im WLAN werden Computer nicht direkt über IP adressiert, sondern über die MAC Adressen. Jeder Host, also angeschlossener Netzwerkcomputer jeder Art, besitzt einen kleinen Puffer, in dem er die Verknüpfung zwischen IP Adresse und MAC Adresse abspeichert. Ist die MAC Adresse bereits im Puffer so braucht das System keinen ARP Request zu senden und kann gleich loslegen. Existiert die MAC Adresse noch nicht, so fragt das System mit einem Broadcast nach. Dieser Broadcast wird von allen Maschinen empfangen und die Maschine, die gemeint ist, antwortet entsprechend. Das erste einlaufende Antwortpacket wird wieder genommen und entsprechend wird die Tabelle im Hostsystem erweitert. Dieser ARP Cache wird oft auch dann aktualisiert, wenn kein Request vorher abgesendet worden ist. Die Implementierungen variieren an dieser Stelle.

So sendet der Angreifer einfach gefälschte ARP Antworten des Zielsystems und schon wird entsprechend nach einiger Zeit der Cache des Opfersystems mit der Angreifer MAC Adresse vergiftet. Baut das System nun eine Verbindung zum Zielsystem auf, so werden die Pakete zur MAC Adresse des Angreifers gesendet. Wie bereits erwähnt wird in LANs mit MAC adressiert und nicht über IP. Somit empfängt der Angreifer die Daten. Der Angreifer wird somit zu einer Art Proxy Server. Diese kann er wiederum einfach nur mit Wireshark aufzeichnen und entsprechend einfach an den ursprünglichen Host weiterleiten oder er kann mit Ettercap entsprechend eine MITM Attack fahren.

Natürlich möchte der Angreifer möglichst etwas verschlüsseltes lesen, sonst könnte auch Wireshark einfach eingesetzt werden. Dazu erzeugt der Angreifer sich ein neues SSL Zertifikat. Das sollte natürlich möglichst so aussehen, wie das Zertifikat des zu fälschenden Zielsystems. Ettercap wird dieses nun verwenden, um die SSL Verbindung entsprechend entgegen zu nehmen. Damit wird sozusagen der SSL Datenstrom aufgebrochen und die entschlüsselten Daten werden ausgelesen. Also tippt der Angreifer in seiner Linux Konsole (Backtrack oder GRML sind als Live CD sehr empfehlenswert) folgendes ein: ettercap –newcert.

Beim Start von ettercap wird zunächst automatisch das Netzwerk nach vorhandenen Host abgesucht. Wenn dieser Vorgang abgeschlossen ist, zeigt Ettercap eine zweispaltige Tabelle jeweils mit allen gefunden Hostcomputern an. Der Angreifer wählt nun in der linken Spalte den anzugreifenden Client aus und in der rechten Spalte den entsprechenden anzugreifenden Server. Nun wählt der Angreifer die Schaltfläche ARP Sniff. Damit wird das ARP Poisoning eingeleitet und alle verschlüsselten Verbindungen lassen sich nun mitschneiden.

Das Opfer testet nun mithilfe der Shell mit arp -a (Windows Shell), ob das ARP Poisoning geklappt hat. Taucht die Angreifer MAC Adresse in Verbindung mit der Ziel IP des Fremdsystems auf, so hat das ARP Cache Poisoning geklappt. Nun entsprechend den Server mit einer SSL Verbindung ansprechend und sich dort einloggen. Da oft der Angreifer keine erweiterten Möglichkeiten hat, wird der Webbrowser sich beklagen, dass das Zertifikat nicht verifiziert werden kann, bzw. dem Zertifikat nicht vertraut wird. So kann das Opfer diesen Angriff alleine an dem nicht ganz korrekten Zertifikat erkennen. (Es sei denn der Angreifer lässt das Zertifikat von einem Trustcenter entsprechend korrekt signieren oder manipuliert die Root Zertifikate im Opferwebbrowser und signiert selbst)

Was kann das Opfer tun, um diese Manipulation zu erkennen? Erstens kann das Opfer prüfen, ob die URL mit der URL im Zertifikat übereinstimmt. Zweitens kann das Opfer überprüfen, ob die Chain of Trust verletzt wurde oder nicht. Also, ob das Zertifikat von einer autorisierten Stelle zertifiziert wurde. Der erste Punkt wird vom Angreifer korrekt erfüllt, da der Client davon ausgeht, dass er direkt mit dem Server kommuniziert. Die IP Adressen werden bei diesem Angriff nicht verändert. Der zweite Punkt allerdings ist schon weitaus schwerer. Aus diesem Grund sollte jeder Nutzer Warnungen dieser Art von seinem Browser sehr ernst nehmen.

Projekt: Neurodump is proudly powered by WordPress and the Theme Adventure by Eric Schwarz
Entries (RSS) and Comments (RSS).

Projekt: Neurodump

Gedankenauszüge eines Datenreisenden