22. Juni 2006

Aus Labor für Echtzeitsysteme

Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

[bearbeiten] Knacken von Passwörtern in gegebener passwd- und shadow-Datei

Ziel dieser Aufgabe war es, die Passwörter zu Benutzernamen in einer gegebenen shadow- und passwd- Datei zu knacken. Zur Vorgehensweise gab es keine weiteren Informationen und auch der Lösungsweg blieb freigestellt.

Zunächst wurden Informationen zur Vorgehensweise per Suchmachine aus dem Internet gesucht. Als Tool wurde schnell "John the Ripper" ausfindig gemacht.

Wie die meisten Programme lässt es sich mit

apt-get install john

wenn nicht schon geschehen, installieren.

Da sich die verschlüsselten Passwörter nicht mehr in der passwd Datei selbst befinden, sondern in der shadow-Datei ausgelagert sind, kann nur diese verwendet werden.

Zunächst muss aber das Verschlüsselungsverfahren der Passwörter herausgefunden werden. Hier wurde als erstes MD5 versucht und führte auch zum Erfolg (weitere mögliche Verfahren sind DES, BSDI, BF, AFS und LM). In den meisten Fällen ist unter Linux MD5 oder DES im Einsatz, wobei sich diese beiden Verfahren darin unterscheiden, dass DES nur die ersten acht Zeichen eines Passwortes verwendet, MD5 dagegen alle Zeichen.

Weiterhin ist es möglich, entweder alle Passwörter in der Shadow Datei zu knacken oder nur ein bestimmtes. Dies lässt sich über den Parameter

-user:xxx 

angeben, wobei xxx für den Benutzernamen steht. Gibt man diesen Parameter nicht mit an, wird versucht, alle im File hinterlegten Passwörter zu knacken. Der zugehörige Befehl lautet:

john -format:MD5 [-user:xxx] shadow

Sobald john ein Passwort gefunden hat, wird es ausgegeben. Das Programm merkt sich bereits geknackte Passwörter, sodass bei einem neuen Start diese nicht neu geknackt werden müssen. Bereits gefundene Passwörter lassen sich mit dem Befehl

john -show shadow 

erneut anzeigen.

Um den Prozess evtl. zu beschleunigen, ist es möglich, Wortlisten anzugeben, die dann zuerst durchprobiert werden. Dies erfolgt durch Angabe des Parameters

-wordfile:FILE 

Verschiedene Wordfiles können über den Befehl

apt-cache search wordlist

angezeigt und anschliessend mit

apt-get install WORDFILE 

installiert werden.

[bearbeiten] Netzwerkaufbau nach Anleitung der jeweils anderen Gruppe

[bearbeiten] Gruppe ohne Namen

Die aus fünf Personen (Andreas Rütten, Jens Nitschke, Christian Kaczynski, Jörg Fichtner, Stefan Hüskes) bestehende Gruppe ohne Namen versuchte, ein Netzwerk mit verschiedenene Diensten entsprechend der Anforderungen in Firewall.png (s. 01. Juni 2006) aufzubauen. Hierbei sollte sich die Gruppe auf die Dokumentation der Gruppe Firefuckers (s. 08. Juni 2006) stützen und deren Rechner (A3-4, B3-4) zu besagtem Netzwerk zusammenschließen.

Da die Aufgabe des Netzwerkaufbau von dieser Gruppe ganz anders angegangen worden ist (z.B.: mit NAT-Unterstützung), bedurfte es anfangs erst einmal einige Zeit zum Verständnis der dokumentierten Vorgehensweise.

Nach dem Zusammenschluss der einzelnen PCs und der Konfiguration der in der Aufgabenstellung gewünschten Dienste (lt. Dokumentation der Gruppe Firefuckers), konnte beispielsweise von jedem der im Netzwerk integrierten PCs per ssh auf einen anderen zugegriffen werden oder ein anderer PC angepingt werden.

Sobald das Skript, welches die Firewall-Konfiguration beinhaltete, gestartet wurde, konnten die laut Aufgabenstellung respektierten Verbindungen (z.B.: über ssh oder ping) nicht aufgebaut werden. Wurde das Skript zum Rücksetzen der Firewall-Konfiguration ausgeführt, funktionierte der Datenfluss wieder wie gewünscht.

Trotz intensiver Bemühungen, das uns vorgegebene Skript der Gruppe Firefuckers zu verstehen und zu analysieren, konnten keine genauen Ursachen für dieses Fehlverhalten der Firewall gefunden werden.

[bearbeiten] Gruppe Firefuckers

  • Alles TOP! Hat alles gefunzt!
  • Doku war in Ordnung, keine Probleme!
  • Firefuckers gratulieren ..... :-)

[bearbeiten] Beantwortung von Fragen zum Thema Honeypot

(muss noch vervollständigt werden)

Zu analysieren ist die Datei http://ezs.kr.hsnr.de/download_ezs/honeypot-log.tar.gz (md5sum 9d28c5ee9ce7b77e3099a07ad303811f, sha1sum 921090fe859feeeec9759a0fb11ec4cee7251c70)

Dazu sind die folgenden neun Fragen durch die Teams zu beantworten:

[bearbeiten] 1.) Was ist ein „binary log file“ und wie wird es erstellt?

Das Logfile ist im tcpdump binary format und wurde durch snort mit wahrscheinlich folgendem Befehl erstellt:

$snort -l /path/to/snortlog/logfilename -b

Eine andere Möglichkeit wäre, dass das Ausgabeformat direkt in der snort.conf entsprechend konfiguriert wurde (output log_tcpdump).

Das Logformat bietet einige Vorteile:

  • Eine exakte Kopie jedes Paketes.
  • Kann durch viele Programme zur weiteren Auswertung gelesen werden, beisplw. ethereal, tcpdump. Und sogar auch durch snort selber, dadurch können im nachhinein noch IDS Meldungen erstellt werden.

Durch folgende Befehle kann das Logfile in menschenlesbarer Form ausgegeben werden:

$snort -r binary.log
$tcpdump -n -e -ttt -r binary.log

Ebenfalls kann man das Binary LOG-File mittels ethereal oeffnen und analysieren.

Weiterführende Links:

[bearbeiten] 2.) Was ist MD5 und welchen Wert bietet es?

Weitverbreitete Hash-Funktion. Die errechneten MD5-Summen werden zur Integritätsprüfung von Dateien eingesetzt. Das heisst, man erstellt vor dem Übertragen einer Datei die zugehörige MD5-Summe und übeträgt anschliessend die Datei und den erstelten Hash-Wert. Die Gegenstelle kann nun durch erneutes Erstellen der MD5-Summe und dem Vergleich mit dem mitgeschickten Wert feststellen, dass es keine Übertragungsfehler gab und die Datei genau die ist, die Übertragen werden sollte.

[bearbeiten] 3.) Wie it die IP-Adresse des Angreifers?

192.168.0.9

evtl. spoofing Adressen: 192.168.0.199 , 192.168.0.254 , 192.168.0.1

[bearbeiten] 4.) Wie ist die IP-Adresse des Ziels?

192.168.0.99

[bearbeiten] 5.) Der Honeypot wurde mittels fünf verschiedener Methoden gescannt. Können Sie alle fünf Scan-Methoden identifizieren und beschreiben, wie jede dieser Methoden funktioniert?

Zum Verständniss der einzelnen Portscann-Methoden ist die man page von nmap sehr hilfreich, siehe hier.

[bearbeiten] 1. Methode: TCP SYN-SCAN

Die SYN-SCAN Methode basiert darauf, dass der Angreifer einen Verbindungsaufbau initialisieren (SYN-FLAG gesetzt) will.

  • Sendet der Server ein RST,ACK so ist dieser Port dicht.
  • Sendet der Server ein SYN,ACK weiß der Angreifer, dass dieser Port offen ist! Um das loggen eines Verbindungsaufbaus (Three-Way-Handshake) zu vermeiden, verzichtet der Angreifer darauf ein ACK zu senden.
Bild:syn_scan_open.jpg
Bild:syn_scan_close.jpg

[bearbeiten] 2. Methode: Null-Scan

Beim TCP-Null-Scan werden alle Flags (URG, ACK, PSH, RST, SYN und FIN) auf Null gesetzt und laut RFC 793 (TCP) muesste das Ziel-System einen RST fuer alle geschlossenen Ports zurueckschicken.

Bild:null_scan_open.jpg
Bild:null_scan_close.jpg

[bearbeiten] 3. Methode: Xmas-Scan

Beim Xmas Scan wird ein FIN-, ein URG- und ein PUSH-Paket zum Ziel-Port geschickt. Nach den Empfehlungen von RFC 792 (ICMP) muesste der Server ein RST fuer alle geschlossenen Ports zurueckgeben.

Bild:xmas_scan_open.jpg
Bild:xmas_scan_close.jpg


[bearbeiten] 4. Methode: Idle-Scan

Für den eigentlichen Scan braucht der Portscanner die aktuelle IPID des Zombies. Um die IPID herauszufinden, wird einfach eine TCP Verbindung halb geöffnet (wie beim SYN Scan) (1). Der Zustand des Ports spielt nur eine untergeordnete Rolle. Das Anwortpaket des Zombies enthält die aktuelle IPID (2).

Für den eigentlichen Portscan schickt der Angreifer ein gespooftes SYN Paket an das Ziel (3). Als Quell-IP-Adresse setzt der Angreifer die IP-Adresse des Zombiehosts. Falls der Port offen ist, sendet das Ziel ein SYN|ACK Paket an den Zombie (4a). Da er keine Verbindung geöffnet hat, schickt der Zombie ein RST Paket an das Ziel (4a). Dieses Reset wird mit einer IPID + 1 an das Ziel gesendet. Ist der Port geschlossen, sendet das Ziel ein RST Paket an den Zombie (4b). Dieses Paket wird vom Zombie einfach ignoriert. Nun fragt der Angreifer in gleicher Weise wie zu Begin nach der aktuellen IPID (5). Ist die IPID um 2 gestiegen, ist der Port offen. Ist die IPID nur um 1 höher, ist der Port geschlossen (6).

Bild:idle_scan.png

Die Informationen wurden dem Wikipedia entnommen! Siehe: Wikipedia/Idle-Scan

[bearbeiten] 6.) Welches Scanning-Tool wurde zum Scannen des Honeypots verwendet? Worauf können Sie Ihre Aussage stützen?

[bearbeiten] 7.) Was ist der Zweck von Port-Scanning?

Der Zweck des Port-Scannings ist der, so unbemerkt wie möglich einen anderen Rechner oder Server auf dessen offene Ports (laufende Dienste) hin zu untersuchen. Da jedem Dienst (z.B.: ssh, http, telnet,...) eine eigene Portnummer zugeteilt ist (well known numbers), kann der Angreifer mittels Portscannern die laufenden Dienste identifizieren.

[bearbeiten] 8.) Welche Ports sind auf dem Honeypot offen?

[bearbeiten] 9.) Bonus-Frage: Welches Betriebssystem verwendete der Angreifer?

Man kann das verwendete Betriebssystem anhand der initialen "windows size" Identifizieren. Initiale Windows Size ist abhängig vom Betriebssystem ...

-- Linux Kernel 2.4 / 2.6 5.840 Byte
-- Open BSD 3.6 16.382 Byte
-- Windows 2000 SP1, SP2 17.520 Byte
-- Windows 2000 SP3, SP4 65.535 Byte
-- Windows 2000, ab April 2005 17.520 Byte
-- Windows XP Prof., SP2 65.535 Byte

Initiale "windows size" bedeutet die Größe die vom Verbindungsaufbauenden vorgegebenen wird, die sich aber nach einiger Zeit anpassen kann. Die Window size ist daher dynamisch.


Bsp. 1

Zwei LinuxRechner verbunden mit SSH , initiale Windows Size 5.840, Wert nach einiger Zeit 
ca. 16.000


Bsp. 2

LinuxRechner (5.840) per BGP mit CiscoRouter (16.384) nach wenigen Minuten 16.616 auf beiden 
Seiten

Aus der analyse des Binary LOG-Files sind folgende Gößen hervorgegangen: 2048, 3072, 4096, 5840.


== -- Vermutung -- == Der Anfreifer benutzt: Linux Kernel 2.4 / 2.6

[bearbeiten] Lösungen anderer

Ergebnisse und Vorgehensweisen anderer können hier nachgelesen werden.

Persönliche Werkzeuge