DIF_GruppeD_Logbuch/06.04.2023 - Übung 3/Logbuch - Übung 3.md

382 lines
16 KiB
Markdown
Raw Normal View History

# Logbuch für die Durchführung der Übung 3
### Aufgabe 1:
System: Für diese Übung verwenden wir Kali Linux.
Bearbeitungsschritte:
1. Verwendung der U2.img-Datei aus Übung 2.
2. Mounten der U2.img-Datei und Extraktion der Dateien.
3. Versuch, die extrahierten Dateien zu öffnen.
4. Untersuchung der Dateien mit einem Hex-Editor.
5. Ermittlung der möglichen Dateiformate der untersuchten Dateien.
6. Ermittlung der gängigen Signaturen (Magic Numbers) der gefundenen Dateiformate.
7. 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:
2023-04-11 15:10:57 +02:00
```
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"
```
---
2023-04-11 15:10:57 +02:00
**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)](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/
```
2023-04-11 15:10:57 +02:00
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.
2023-04-11 15:10:57 +02:00
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.
2023-04-11 15:10:57 +02:00
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
```
2023-04-11 15:10:57 +02:00
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.
---
2023-04-11 15:10:57 +02:00
**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.
---
2023-04-11 15:10:57 +02:00
**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:
2023-04-11 14:35:25 +02:00
**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](https://anakin.informatik.hs-mannheim.de/downloads/image.zip)**
```
$ /home/GruppeD/DIF/Uebung3
$ ls
> image.zip
```
2023-04-11 14:32:53 +02:00
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
```
2023-04-11 14:35:25 +02:00
2023-04-11 15:14:47 +02:00
Die Partitionstabelle zeigt, dass die Image-Datei eine Partition enthält: ```image.img```.
2023-04-11 15:14:47 +02:00
Als nächstes verwenden wir das Tool ```mmls``` aus dem Paket 'sleuthkit', um die Partitionstabelle der Image-Datei zu überprüfen:
2023-04-11 14:32:53 +02:00
```
$ sudo mmls image.img
```
2023-04-11 15:14:47 +02:00
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:
2023-04-11 15:14:47 +02:00
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-11 14:35:25 +02:00
```
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
```
---
2023-04-11 15:14:47 +02:00
**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-11 14:35:25 +02:00
```
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
```
2023-04-11 15:14:47 +02:00
Auffällig sind die Dateien ```./home/dif/Pictures/schuhschnabel.webp``` und ```./home/dif/Pictures/schuhschnabel.png```, eine png und eine webp Datei.
2023-04-11 14:35:25 +02:00
[schuhschnabel.png](./schuhschnabel.png)
2023-04-11 15:14:47 +02:00
2023-04-11 14:35:25 +02:00
[schuhschnabel.webp](./schuhschnabel.webp)