18 KiB
Logbuch für die Durchführung der Übung 3
Aufgabe 1:
System: Für diese Übung verwenden wir Kali Linux.
Bearbeitungsschritte:
- Verwendung der U2.img-Datei aus Übung 2.
- Mounten der U2.img-Datei und Extraktion der Dateien.
- Versuch, die extrahierten Dateien zu öffnen.
- Untersuchung der Dateien mit einem Hex-Editor.
- Ermittlung der möglichen Dateiformate der untersuchten Dateien.
- Ermittlung der gängigen Signaturen (Magic Numbers) der gefundenen Dateiformate.
- Vergleich der Dateisignaturen (Magic Numbers) mit den tatsächlichen Signaturen und gegebenenfalls Änderung der Bytes zur Wiederherstellung der Dateien.
Dokumentation:
RecoverMe01:
Schritt 1: Öffnen der Terminalfenster und Navigation zum Verzeichnis, in dem sich die Datei “U2.img” aus Übung 2 befindet.
2023-04-08 00:46:32 $ cd /home/GruppeD/DIF/Uebung2
Schritt 2: Mounten und extrahieren der U2.img-Datei
2023-04-08 00:48:53 $ fdisk -l U2.img mnt
2023-04-08 00:49:35 $ sudo mount -o ro U2.img mnt
Dadurch wird die U2.img-Datei in das Verzeichnis “/mnt” gemountet.
Schritt 3: Navigiere zum “/mnt”-Verzeichnis und verwende den Befehl “ls”, um eine Liste der Dateien und Verzeichnisse anzuzeigen.
2023-04-08 00:49:43 $ cd mnt
2023-04-08 00:49:47 $ cd ls -la
Ausgabe:
Schritt 4: Untersuchen der Datei mit einem Hex-Editor und xxd
2023-04-08 00:50:39 $ hexeditor RecoverMe01
2023-04-08 00:53:19 $ xxd RecoverMe01 | head
hexeditor RecoverMe01
xxd RecoverMe01 | head
Schritt 5: Ermittlung der Dateiformat mit dem folgenden Befehl
2023-04-08 00:55:03 $ binwalk RecoverMe01
Ausgabe:
Beschreibung: image data
Schritt 6: Um die gefundenen Dateien zu reparieren, war es notwendig, die Signaturen der Dateiformate zu überprüfen und gegebenenfalls anzupassen. Bei einer der Dateien handelte es sich um eine beschädigte JPEG-Datei, deren magische Zahl, siehe https://de.wikipedia.org/wiki/Magische_Zahl_(Informatik) im Hex-Editor als 0x0FFD8FF statt 0xFFD8FF angezeigt wurde, siehe Abbildung “Hexeditor RecoverMe01”. Um die Datei zu reparieren, musste diese magische Zahl auf 0xFFD8FF geändert werden. Da die Datei jedoch zuvor gemounted wurde und somit nur lesbar war, musste sie zuerst in einen anderen Ordner kopiert werden, um die nötigen Änderungen durchführen zu können, siehe Schritt 7.
Hexeditor RecoverMe01
Schritt 7: Um die entsprechenden Bytes zu ändern und die Datei wiederherzustellen, muss die betreffende Datei zuerst in einen schreibbaren Ordner kopiert werden. Dazu kann ein neuer Ordner mit dem Befehl mkdir erstellt werden, und die Datei kann dann mit dem Befehl cp in den neuen Ordner kopiert werden. Anschließend können die entsprechenden Bytes im Hex-Editor geändert werden, um die Datei wiederherzustellen.
2023-04-08 00:56:11 $ cd ..
2023-04-08 00:56:23 $ mkdir extracted
2023-04-08 00:56:39 $ cp mnt/RecoverMe01 extracted/
Um die Image-Datei zu reparieren, müssen wir nun in den "extracted" Ordner wechseln. Dazu verwenden wir den Befehl "cd ..", um in den übergeordneten Ordner zu gelangen, und anschließend "cd extracted", um in den Zielordner zu navigieren.
Nachdem wir in den "extracted" Ordner gewechselt sind, können wir Schritt 4 erneut durchführen und die betroffene Datei in einem Hex-Editor öffnen. Hier können wir die entsprechenden Bytes von 0x0F auf 0xFF ändern und die Änderungen mit "^X" speichern und den Editor verlassen.
Nachdem die Reparatur der Magischen Zahl erfolgreich durchgeführt wurde, konnten wir die Datei in einem Hex-Editor erneut überprüfen und die Bytes von 0x0F zu 0xFF ändern. Anschließend haben wir die Datei gespeichert und den Hex-Editor verlassen. Mit dem Befehl 'xdg-open RecoverMe01' konnten wir die reparierte Image-Datei öffnen, da wir zuvor mit dem Befehl 'binwalk RecoverMe01' herausgefunden hatten, dass es sich um eine Image-Datei handelt. Diesmal haben wir den Befehl 'xdg-open' verwendet, um die Datei mit dem Standardprogramm für das jeweilige Dateiformat zu öffnen.
2023-04-08 00:57:33 $ xdg-open RecoverMe01
Ausgabe: Anschließend konnte die reparierte JPEG-Datei mithilfe eines Image Viewers geöffnet werden und es war deutlich erkennbar, dass es sich um die Hochschule Mannheim, Gebäude H handelte.
RecoverMe01 - Image Viewer
RecoverMe02:
Schritt 1: Nach erfolgreicher Reparatur der RecoverMe01-Datei können wir nun ähnlich vorgehen, um auch die RecoverMe02-Datei zu reparieren. Dazu müssen wir zunächst die RecoverMe02-Datei in den "extracted" Ordner kopieren, um sie bearbeiten zu können.
2023-04-08 15:28:46 $ cd /home/GruppeD/DIF/Uebung2
2023-04-08 15:29:05 $ cp mnt/RecoverMe02 extracted/
Schritt 2: Bevor wir jedoch die Datei reparieren können, müssen wir zunächst herausfinden, um welches Dateiformat es sich handelt. Hierfür können wir den Hexeditor verwenden, um uns die Datei im Binärformat anzusehen und anhand bestimmter Merkmale wie der Magischen Zahl oder anderen Signaturen das Dateiformat zu identifizieren.
2023-04-08 15:33:50 $ cd extracted
2023-04-08 15:33:58 $ hexeditor RecoverMe02
Nachdem wir die Datei im Hexeditor geöffnet haben, konnten wir feststellen, dass die ausgegebene magische Nummer 0x89504E470D0A1A0A nicht korrekt ist. Wir haben erkannt, dass anstatt des erwarteten Wertes 0x89504E770D0A1A0A, ein Fehler unterlaufen ist. Deshalb werden wir als nächstes die Zahl "47" zu "77" ändern, um die Datei zu reparieren.
Schritt 3: Nachdem wir die Datei im Hexeditor geöffnet haben, ändern wir die "77" zu "47", speichern die Änderungen mit "^X" und verlassen den Editor.
Schritt 4: Nach der erfolgreichen Reparatur der Zahl können wir wie in Schritt 7 beschrieben die reparierte Datei mithilfe des Befehls "xdg-open" öffnen.
2023-04-08 15:46:45 $ xdg-open RecoverMe02
Ausgabe: Anschließend konnte die reparierte Datei mithilfe eines Image Viewers geöffnet werden und es war deutlich erkennbar, dass es sich um das Logo der Hochschule Mannheim handelte.
RecoverMe02 - Image Viewer
Aufgabe 2:
Schritt 1: Um die Fragen des Rechts zu beantworten, laden wir die Image-Datei über den folgenden Download-Link für U3 herunter: https://anakin.informatik.hs-mannheim.de/downloads/image.zip
$ /home/GruppeD/DIF/Uebung3
$ ls
> image.zip
Wir erzeugen nun kryptographische Hashwerte des Image.zips unter Verwendung von shasum und md5sum, wobei sowohl SHA1 als auch MD5 eingesetzt werden.
$ shasum image.zip
> 33685e37574d2dfc7d88acb72d566fc085561f9e image.zip
$ md5sum image.zip
> 8186f3686926e8366936873859debf01 image.zip
Durch die Verwendung des Befehls 'shasum image.zip' wurde der SHA1-Hashwert des Image.zip-Archivs berechnet und zusammen mit dem Dateinamen 'image.zip' ausgegeben. Die Ausgabe '33685e37574d2dfc7d88acb72d566fc085561f9e image.zip' bedeutet, dass der SHA1-Hashwert des Image.zip-Archivs '33685e37574d2dfc7d88acb72d566fc085561f9e' lautet. Ebenso wurde der MD5-Hashwert des Archivs durch Verwendung des Befehls 'md5sum image.zip' berechnet, und die Ausgabe '8186f3686926e8366936873859debf01 image.zip' gibt den MD5-Hashwert des Image.zip-Archivs an. Wenn diese Hashwerte mit denen des ursprünglichen Archivs verglichen werden und sie identisch sind, bedeutet dies, dass das Archiv unverändert geblieben ist und keine Daten manipuliert oder hinzugefügt wurden.
Nachdem die Hashwerte der Datei berechnet wurden, kann auf die Image-Datei zugegriffen werden, indem das Zip-Archiv mithilfe von '7z e' extrahiert wird. Der Befehl lautet wie folgt:
$ 7z e image.zip
> image.img
Schritt 2: Ermitteln der Image-Datei enthaltenen Partitionen. Hierzu verwenden wir die Softwaretools fdisk und mmls und vergleichen die Ausgaben beider Tools.
Zunächst führen wir den Befehl “fdisk -l Image.img” aus, um die Partitionstabelle der Image-Datei anzuzeigen:
$ sudo fdisk -l image.img
Ausgabe:
Die Partitionstabelle zeigt, dass die Image-Datei eine Partition enthält: image.img.
Als nächstes verwenden wir das Tool “mmls” aus dem Paket “sleuthkit”, um die Partitionstabelle der Image-Datei zu überprüfen:
$ sudo mmls image.img
Die Ausgabe von fdisk und mmls zeigen, dass es in der Image-Datei eine einzige Partition gibt, welche als "EFI System Partition" bezeichnet wird. Beide Tools haben die gleiche Anzahl von Partitionen angezeigt, was darauf hinweist, dass sie in diesem Fall übereinstimmende Ergebnisse liefern.
Schritt 3: Ermitteln der Dateisystem in der Image-Datei:
Durch Ausführen des Befehls lsblk -f konnten wir das Dateisystem in der Image-Datei ermitteln. Die Ausgabe des Befehls zeigte uns, dass das Image-Datei mehrere Dateisystemtypen enthält, nämlich vfat, ext4 und swap.
$ lsblk -f
Ausgabe:
Schritt 4: Um den größten Partitionsbereich aus der Image-Datei zu extrahieren, kann man den Befehl dd verwenden. Die Optionen notrunc, sync und noerror sind optional, aber empfohlen, um sicherzustellen, dass das Extrahieren reibungslos verläuft und keine Daten verloren gehen.
Der Befehl sieht folgendermaßen aus:
2023-04-08 17:19:46 $ dd if=image.img of=linux.img skip=1054720 count=40886272 conv=notrunc,sync,noerror
40886272+0 records in
40886272+0 records out
20933771264 bytes (21 GB, 19 GiB) copied, 270.211 s, 77.5 MB/s
Die Hashwerte der extrahierten Partition sind:
2023-04-08 17:27:05 $ md5sum linux.img
7b71af7946b69ab49ec7a127c1b3d01a linux.img
2023-04-08 17:28:17 $ shasum linux.img
d03b6db5a233851aa94cedacd563bfe70664b03c linux.img
Schritt 5: Nun können wir die extrahierte Partition mounten um Zugriff auf die enthaltenen Daten zu bekommen. Dazu erstellen wir erst das neue Verzeichnis ./mnt und nutzen dann den Befehl mount mit dem parameter -r um die Partition schreibgeschützt einzuhängen:
2023-04-08 17:29:45 $ mkdir mnt
2023-04-08 17:30:43 $ sudo mount -r linux.img mnt
Schritt 6: Jetzt können wir den Benutzer des zu untersuchenden Systems aus der Datei /etc/passwd auslesen. Nutzeraccounts auf Linuxsystemen haben meist eine UserID von 1000 oder höher und nutzen normalerweise entweder bash, zsh oder fish als Shell. Mit dem folgenden Befehl können wir uns einen schnellen Überblick über die Nutzer des Systems verschaffen:
2023-04-08 17:31:27 $ cat mnt/etc/passwd | grep sh
root:x:0:0:root:/root:/bin/bash
dif:x:1000:1000:DIF,,,:/home/dif:/bin/bash
Der Primäre nutzer des Systems hat also den Namen dif.
Schritt 7: Erstellen der Passwordliste:
Laut Aufgabe soll nun eine Passwortliste mit Passwörtern im Format [0-4][0-4][d-i][d-i][d-i][0-4][0-4] erstellt werden. Wir nutzen dafür crunch:
2023-04-08 17:32:42 $ crunch 7 7 defghi A 01234 + -t %%@@@%% > wordlist.txt
Crunch will now generate the following amount of data: 1080000 bytes
1 MB
0 GB
0 TB
0 PB
Crunch will now generate the following number of lines: 135000
Die Passwortliste hat 135000 Einträge:
2023-04-08 17:35:39 $ wc -l wordlist.txt
135000 wordlist.txt
Schritt 8: Herausfinden des Passwortes:
Da die gehaschten Passwörter in der Datei /etc/shadow gespeichert werden, können wir nun versuchen das Passwort des Nutzers dif mit Hilfe der Passwortliste zu finden.
Erst schreiben wir den Passworthash in eine neue Datei:
echo -n "$1$Al1JOy/e$nSQ5CgVYrz2WTfoeXQwH11" > hash.txt
Danach können wir hashcat nutzen, um das Passwort zu cracken:
2023-04-08 17:44:51 $ time hashcat -m 500 hash.txt wordlist.txt
hashcat (v6.2.6) starting
OpenCL API (OpenCL 3.0 PoCL 3.1+debian Linux, None+Asserts, RELOC, SPIR, LLVM 14.0.6, SLEEF, DISTRO, POCL_DEBUG) - Platform #1 [The pocl project]
==================================================================================================================================================
* Device #1: pthread-haswell-Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz, 2857/5778 MB (1024 MB allocatable), 4MCU
Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 256
Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 1
Optimizers applied:
* Zero-Byte
* Single-Hash
* Single-Salt
ATTENTION! Pure (unoptimized) backend kernels selected.
Pure kernels can crack longer passwords, but drastically reduce performance.
If you want to switch to optimized kernels, append -O to your commandline.
See the above message to find out about the exact limits.
Watchdog: Temperature abort trigger set to 90c
Host memory required for this attack: 1 MB
Dictionary cache built:
* Filename..: wordlist.txt
* Passwords.: 135000
* Bytes.....: 1080000
* Keyspace..: 135000
* Runtime...: 0 secs
$1$Al1JOy/e$nSQ5CgVYrz2WTfoeXQwH11:22dif04
Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 500 (md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5))
Hash.Target......: $1$Al1JOy/e$nSQ5CgVYrz2WTfoeXQwH11
Time.Started.....: Sat Apr 8 17:45:11 2023 (7 secs)
Time.Estimated...: Sat Apr 8 17:45:18 2023 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Base.......: File (wordlist.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........: 8582 H/s (7.21ms) @ Accel:64 Loops:250 Thr:1 Vec:8
Recovered........: 1/1 (100.00%) Digests (total), 1/1 (100.00%) Digests (new)
Progress.........: 65792/135000 (48.73%)
Rejected.........: 0/65792 (0.00%)
Restore.Point....: 65536/135000 (48.55%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:750-1000
Candidate.Engine.: Device Generator
Candidates.#1....: 22dhi21 -> 22edg31
Hardware.Mon.#1..: Temp: 45c Util: 97%
Started: Sat Apr 8 17:45:09 2023
Stopped: Sat Apr 8 17:45:20 2023
real 0m10.436s
user 0m31.037s
sys 0m0.390s
Zusätzlich haben wir den befehl time genutzt, um die genutzte Zeit zu messen.
Das Passwort lässt sich mit dem --show Parameter anzeigen:
2023-04-08 17:45:20 $ hashcat -m 500 hash.txt wordlist.txt --show
$1$Al1JOy/e$nSQ5CgVYrz2WTfoeXQwH11:22dif04
Das Passwort ist also 22dif04 und das Cracken hat 31 Sekunden gedauert.
Schritt 9: Welche Dateien hat der Nutzer erzeugt?
Wir nutzen den Befehl find mit dem Parameter -user dif um alle Dateien des Nutzers zu finden. Erst müssen wir jedoch chroot nutzen, um unser root Verzeichnis zu dem des zu untersuchendem Systems zu ändern:
2023-04-08 18:22:24 $ sudo chroot mnt bash
Außerdem nutzen wir zusätzlich den Parameter -type f um unsere Suche auf Dateien zu beschränken und -printf "%T+ %p\n" um das letzte Änderungsdatum jeder Datei anzuzeigen. Mit dem Befehl sort können wir die Dateien nach Datum sortieren und mit grep -v '.config\|.cache\|snap\|.local' blenden wir versteckte Verzeichnisse aus.
root@kali:/# find . -user dif -type f -printf "%T+ %p\n" | sort | grep -v '.config\|.cache\|snap\|.local'
2022-04-23+14:20:40.7738655050 ./home/dif/.bash_logout
2022-04-23+14:20:40.7738655050 ./home/dif/.bashrc
2022-04-23+14:20:40.7738655050 ./home/dif/.profile
2022-04-23+14:44:16.4352436550 ./home/dif/Pictures/schuhschnabel.webp
2022-04-23+14:46:33.7877701540 ./home/dif/.sudo_as_admin_successful
2022-04-23+14:46:41.2756637240 ./home/dif/Downloads/firefox.tmp/tmpaddon
2022-04-23+14:46:53.4235105960 ./home/dif/.bash_history
2022-04-23+14:47:42.5311171350 ./home/dif/.gnupg/pubring.kbx
2022-04-23+14:47:42.5311171350 ./home/dif/.gnupg/trustdb.gpg
2022-04-23+14:48:08.8230391480 ./home/dif/Pictures/schuhschnabel.png
Auffällig sind die Dateien ./home/dif/Pictures/schuhschnabel.webp und ./home/dif/Pictures/schuhschnabel.png, eine png und eine webp Datei.
