16 KiB

Raw Blame History

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

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

Schritt 5: Ermittlung der Dateiformat mit dem folgenden Befehl

2023-04-08 00:55:03 $ binwalk RecoverMe01

Ausgabe:

DECIMAL     HEXADECIMAL     DESCRIPTION
__________________________________________________________
12          OxC             TIFF image data, little-endian offset of first image directory: 8
26331       0x66DB          Copyright string: "Copyright (c) 1998 Hewlett-Packard Company"

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. 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.

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.

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.

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.

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

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

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.

schuhschnabel.png

schuhschnabel.webp

16 KiB Raw Blame History