DefCon Toronto Galahad - Vulnhub - Level: Easy - Bericht

Easy

Verwendete Tools

arp-scan
vi (Texteditor)
gobuster
Webbrowser (Manual Analysis)
Binär-zu-ASCII Decoder
Hex-zu-ASCII Decoder
ROT13 Decoder (CyberChef)
wget
Base64 Decoder
nikto
nmap
steghide
cat

Inhaltsverzeichnis

Reconnaissance

┌──(root㉿cyber)-[~] └─# [arp-scan -l]
192.168.2.111	08:00:27:65:8f:a6	PCS Systemtechnik GmbH

Analyse: Scan des lokalen Netzwerks mittels ARP zur Host-Entdeckung.

Bewertung: Host `192.168.2.111` identifiziert. MAC-Adresse (`08:00:27:65:8f:a6`) deutet auf VirtualBox hin.

Empfehlung (Pentester): Ziel-IP `192.168.2.111` für weitere Aktionen verwenden.
Empfehlung (Admin): Standard-Netzwerkerkennung.

┌──(root㉿cyber)-[~] └─# vi /etc/hosts
 [Inhalt der /etc/hosts Datei nach der Bearbeitung]
 192.168.2.111    toronto.vln
                    

Analyse: Die lokale `/etc/hosts`-Datei wird bearbeitet, um den Hostnamen `toronto.vln` der IP `192.168.2.111` zuzuordnen.

Bewertung: Notwendig, um den Webserver unter dem Hostnamen ansprechen zu können.

Empfehlung (Pentester): Hostnamen `toronto.vln` verwenden.
Empfehlung (Admin): Clientseitige Konfiguration.

Web Enumeration & Flag 1

Analyse:** Der Webserver wird untersucht, beginnend mit Verzeichnis-Enumeration.

┌──(root㉿cyber)-[~] └─# gobuster dir -u http://toronto.vln -x [...] -w "/usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt" -b '403,404' -e --no-error
[...]
http://toronto.vln/index.html           (Status: 200) [Size: 1269]
http://toronto.vln/staff                (Status: 301) [Size: 310] [--> http://toronto.vln/staff/]
http://toronto.vln/robots.txt           (Status: 200) [Size: 31]
[...]
                    

Analyse: `gobuster dir` wird verwendet, um Verzeichnisse und Dateien auf dem Webserver zu finden. Statuscodes 403 und 404 werden ignoriert.

Bewertung: Findet die Startseite `index.html`, das Verzeichnis `/staff` (mit Redirect) und eine `robots.txt`.

Empfehlung (Pentester): Untersuche `index.html`, `robots.txt` und das Verzeichnis `/staff`.
Empfehlung (Admin): Stelle sicher, dass keine ungewollten Verzeichnisse oder Dateien exponiert werden.

Analyse:** Manuelle Untersuchung der Startseite `index.html`.

[Manuelle Analyse von http://toronto.vln/index.html] └─#
[...]
01010111 01100101 01101100 01100011 01101111 01101101 01100101 [...]
01010100 01101000 01101001 01110011 00100000 01101001 01110011 [...]
[...]
01000100 01000011 00110100 00110001 00110110 00100000 01010100 [...]
[...]
01101110 01101111 00100000 01100110 01101100 01100001 01100111 [...]

[...] audio autoplay src="ob.js" img src="nsa.png" [...]
[Externe Dekodierung des Binärcodes] └─# Binary to ASCII Converter
Welcome

This is where the adventure begins -.-

DC416 Team

btw

no flag here;(
                     

Analyse: Der Quelltext der `index.html` enthält einen langen Binärcode, eine JavaScript-Datei (`ob.js`), die per Audio-Tag eingebunden wird, und ein Bild (`nsa.png`). Der Binärcode wird extern dekodiert.

Bewertung: Der dekodierte Binärcode enthält eine Willkommensnachricht und den Hinweis "no flag here". Die Dateien `ob.js` und `nsa.png` sind die nächsten interessanten Punkte.

Empfehlung (Pentester): Lade `ob.js` und `nsa.png` herunter und analysiere sie.
Empfehlung (Admin): Verstecke keine Hinweise in obfuskierten Formaten wie Binärcode im HTML.

[Analyse von http://toronto.vln/ob.js] └─#
var _0x4c9e=[
  "\x44\x43\x34\x31\x36",                                           // Hex: DC416
  "\x73\x79\x6E\x74\x31\x7B\x7A\x30\x30\x61\x70\x34\x78\x72\x7D",    // Hex: synt1{z00ap4xr}
  "\x4E\x6F\x6E\x65",                                           // Hex: None
  "\x70\x61\x72\x61\x74\x75\x3A",                               // Hex: paratu:
  "\x6C\x6F\x67"                                                // Hex: log
];

var CTF=_0x4c9e[0]; // CTF = "DC416"

if(CTF == _0x4c9e[0]){ // Wenn CTF == "DC416" (ist immer wahr)
  FLAG= _0x4c9e[1]    // FLAG = "synt1{z00ap4xr}"
} else {
  FLAG= _0x4c9e[2]    // FLAG = "None"
};

console[_0x4c9e[4]](_0x4c9e[3]); // Führt console.log("paratu:") aus
console[_0x4c9e[4]](FLAG)         // Führt console.log("synt1{z00ap4xr}") aus
                     
[Externe Dekodierung der Hex-Strings & Analyse des JS-Codes] └─#
Hex-Strings dekodiert:
  "\x44\x43\x34\x31\x36" -> DC416
  "\x73\x79\x6E\x74\x31\x7B\x7A\x30\x30\x61\x70\x34\x78\x72\x7D" -> synt1{z00ap4xr}
  "\x4E\x6F\x6E\x65" -> None
  "\x70\x61\x72\x61\x74\x75\x3A" -> paratu:
  "\x6C\x6F\x67" -> log

JavaScript Logik:
  Der Code weist der Variable FLAG den Wert "synt1{z00ap4xr}" zu.
  Er gibt "paratu:" und den Wert von FLAG in die Browser-Konsole aus.
                     
[Externe Anwendung von ROT13 auf den Flag-String] └─# CyberChef / ROT13 Decoder
Input:  synt1{z00ap4xr}
Output: flag1{m00nc4ke}

Analyse: Der Inhalt der JavaScript-Datei `ob.js` wird analysiert. Sie enthält ein Array mit Hex-kodierten Strings. Die Logik des Skripts weist einem `FLAG`-Variablenwert einen dieser Strings zu (`synt1{z00ap4xr}`) und gibt diesen in die Browserkonsole aus. Dieser String wird anschließend mit ROT13 dekodiert.

Bewertung:** **Flag 1 gefunden!** Durch Analyse des obfuskierten JavaScript-Codes und anschließende ROT13-Dekodierung wird die erste Flag `flag1{m00nc4ke}` enthüllt.

Empfehlung (Pentester):** Flag notieren. Untersuche `robots.txt` und das `/staff`-Verzeichnis.
Empfehlung (Admin):** Verstecke keine Flags oder sensiblen Daten in JavaScript-Code, auch nicht obfuskiert. ROT13 ist keine Verschlüsselung.

Staff Verzeichnis Enumeration

[Analyse von http://toronto.vln/robots.txt] └─#
User-agent: *
Disallow: /staff
                     

Analyse: Inhalt der `robots.txt`-Datei.

Bewertung: Verbietet Suchmaschinen das Crawlen des `/staff`-Verzeichnisses, das aber von Gobuster bereits gefunden wurde.

Empfehlung (Pentester): Untersuche `/staff` manuell.
Empfehlung (Admin): `robots.txt` bietet keine echte Sicherheit für Verzeichnisse.

┌──(root㉿cyber)-[~] └─# wget http://toronto.vln/staff/s.txt
[...]
Länge: 766 [text/plain]
Wird in 's.txt' gespeichert.
[...]
's.txt' gespeichert [766/766]
                     
[Analyse von http://toronto.vln/staff/s.txt] └─#
MTIzNDU2
MTIzNDU2Nzg5
cGFzc3dvcmQ=
YWRvYmUxMjM=
MTIzNDU2Nzg=
cXdlcnR5
YmVzaW5hbAo=
YjF0Y2gzcwo=
[...]
cGFzc3BocmFzZTplZHdhcmQ=  <-- Interessant!
[...]
YXplcnR5
[Externe Dekodierung der Base64-Strings (Beispiel)] └─# Base64 Decoder
Input:  cGFzc3BocmFzZTplZHdhcmQ=
Output: passphrase:edward
                     

Analyse: Im `/staff`-Verzeichnis wird eine Datei `s.txt` gefunden und heruntergeladen. Die Datei enthält eine lange Liste von Base64-kodierten Strings.

Bewertung: Die dekodierten Base64-Strings ergeben eine Liste von Wörtern, hauptsächlich Passwörter aus gängigen Listen oder einfache Zeichenketten. Ein Eintrag ist besonders auffällig: `cGFzc3BocmFzZTplZHdhcmQ=` dekodiert zu `passphrase:edward`. Dies ist ein starker Hinweis auf eine Passphrase für einen Schlüssel oder ein anderes Geheimnis.

Empfehlung (Pentester):** Behalte die Passphrase `edward` im Hinterkopf. Sie könnte später für `steghide` (wie gesehen) oder SSH-Keys benötigt werden. Untersuche auch die anderen Dateien im `/staff`-Verzeichnis (`index.html`, `nsa.jpg`).
Empfehlung (Admin):** Speichere keine Passwortlisten oder Passphrasen, auch nicht kodiert, in öffentlich zugänglichen Web-Verzeichnissen.

[Gobuster-Ergebnisse für /staff/ (impliziert)] └─#
http://toronto.vln/staff/index.html           (Status: 200) [Size: 256]
http://toronto.vln/staff/s.txt                (Status: 200) [Size: 766]
http://toronto.vln/staff/nsa.jpg              (Status: 200) [Size: 218866]
                      

Analyse: Auflistung der Dateien im `/staff`-Verzeichnis (vermutlich durch manuelles Browsing oder einen gezielten Gobuster-Scan).

Bewertung: Bestätigt `s.txt` und findet eine `index.html` (wahrscheinlich uninteressant) und das Bild `nsa.jpg` (bereits auf der Startseite gesehen, aber hier nochmals relevant).

Empfehlung (Pentester):** Lade `nsa.jpg` aus diesem Verzeichnis herunter (falls noch nicht geschehen) und analysiere es mit `steghide` unter Verwendung der Passphrase `edward`.
Empfehlung (Admin):** Keine Aktion.

Port Scan

Analyse:** Durchführung von Nikto und Nmap zur umfassenden Port- und Diensterkennung.

┌──(root㉿cyber)-[~] └─# nikto -h 192.168.2.111
- Nikto v2.5.0
[...]
+ Server: Apache/2.2.15 (CentOS) <-- Hinweis: Ältere Apache/OS Version als zuvor von Nmap auf Port 80 angenommen!
[...]
+ Apache/2.2.15 appears to be outdated [...].
+ OPTIONS: Allowed HTTP Methods: GET, HEAD, POST, OPTIONS, TRACE .
+ /: HTTP TRACE method is active [...].
+ /admin/: This might be interesting.
+ /staff/: This might be interesting.
+ /icons/: Directory indexing found.
+ /icons/README: Apache default file found. [...]
+ /admin/index.html: Admin login page/section found.
+ /#wp-config.php#: #wp-config.php# file found. <-- Hinweis auf WordPress, obwohl nicht primär gefunden.
[...]
                    

Analyse: Nikto wird erneut ausgeführt, diesmal ohne Portangabe (Standard: Port 80).

Bewertung: Interessanterweise meldet Nikto hier Apache 2.2.15 (CentOS), eine deutlich ältere Version als die zuvor auf Port 80 von Nmap gemeldete (2.4.25 Debian). Dies könnte auf unterschiedliche Konfigurationen, einen Fehler im Scan oder eine absichtliche Täuschung hindeuten. Es findet potenzielle `/admin`- und `/staff`-Verzeichnisse und einen Hinweis auf eine WordPress-Konfigurationsdatei, obwohl WordPress sonst nicht prominent war.

Empfehlung (Pentester):** Die widersprüchlichen Versionsinformationen sind merkwürdig. Konzentriere dich auf die bereits gefundenen verwertbaren Informationen (`ob.js`, `s.txt`, `nsa.jpg`).
Empfehlung (Admin):** Stelle sicher, dass Server-Banner und Versionen konsistent und aktuell sind. Entferne unnötige Verzeichnisse wie `/admin`, falls nicht verwendet.

┌──(root㉿cyber)-[~] └─# nmap -sS -sC -sV -T5 -A 192.168.2.111 -p- | grep open
22/tcp    open  ssh        penSSH 5.3 (protocol 2.0)
80/tcp    open  tcpwrapped
50000/tcp open  ibm-db2?
                    
┌──(root㉿cyber)-[~] └─# nmap -sS -sC -sV -T5 -A 192.168.2.111 -p-
Starting Nmap 7.94 ( https://nmap.org ) at 2023-06-29 17:42 CEST
Nmap scan report for toronto.vln (192.168.2.111)
Host is up (0.00028s latency).
Not shown: 65483 filtered tcp ports (no-response), 49 filtered tcp ports (host-prohibited)
PRT      STATE SERVICE    VERSIN
22/tcp    open  ssh        penSSH 5.3 (protocol 2.0)
| ssh-hostkey:
|   1024 d9:64:ce:0f:3a:ed:9b:1b:c6:e2:91:85:4e:84:8c:c8 (DSA)
|_  2048 66:95:e5:42:59:d5:88:57:85:0b:c5:f4:08:0d:2b:0d (RSA)
80/tcp    open  tcpwrapped
|_http-title: DC416
|_http-server-header: Apache/2.2.15 (CentS) <-- Bestätigt ältere Version
| http-robots.txt: 1 disallowed entry
|_/staff
| http-methods:
|_  Potentially risky methods: TRACE
50000/tcp open  ibm-db2?
| fingerprint-strings:
|   GetRequest, ibm-db2-das:
[...]
1 service unrecognized despite returning data. [...]
MAC Address: 08:00:27:65:8F:A6 (racle VirtualBox virtual NIC)
Warning: OSScan results may be unreliable [...]
Running (JUST GUESSING): Linux 2.6.X|3.X|4.X (94%)
[...]
Network Distance: 1 hop
[...]
                     

Analyse: Ein umfassender Nmap-Scan wird durchgeführt.

Bewertung: * **Port 22 (SSH):** OpenSSH 5.3. Dies ist eine sehr alte Version mit bekannten Schwachstellen. * **Port 80 (HTTP):** Wird als `tcpwrapped` identifiziert, aber die HTTP-Skripte laufen trotzdem und bestätigen Apache/2.2.15 (CentOS) und den Titel "DC416". * **Port 50000:** Offen, aber der Dienst wird nicht eindeutig erkannt (`ibm-db2?`). Die Fingerprint-Strings sind ungewöhnlich. Die Diskrepanz zu den ersten Nmap/Nikto-Scans (die Apache 2.4.25 Debian meldeten) ist signifikant. Es ist möglich, dass der erste Nmap-Scan gegen eine andere Maschine lief oder dass die Konfiguration geändert wurde. Dieser Scan (Apache 2.2.15, OpenSSH 5.3) scheint relevanter für die gefundenen Hinweise zu sein.

Empfehlung (Pentester):** Konzentriere dich auf SSH (Version 5.3 ist sehr alt) und Port 80/50000. Der Fokus bleibt jedoch auf den bereits gefundenen Web-Hinweisen (`ob.js`, `s.txt`, `nsa.jpg`).
Empfehlung (Admin):** **Dringend OpenSSH und Apache aktualisieren!** Untersuche den Dienst auf Port 50000 und schließe ihn, wenn nicht benötigt. Kläre die widersprüchlichen Versionsinformationen.

Steganografie & Flag 2

┌──(root㉿cyber)-[~] └─# steghide extract -sf nsa.jpg
Passwort eingeben: edward [Passworteingabe aus s.txt]
Extrahierte Daten wurden nach "flag2" geschrieben.
                    
┌──(root㉿cyber)-[~] └─# cat flag2
flag2{M00nface}

/cgi-bin/vault.py?arg=message
                    

Analyse: Das Steganografie-Tool `steghide` wird verwendet, um versteckte Daten aus der Datei `nsa.jpg` (heruntergeladen aus `/staff/` oder vom Root) zu extrahieren. Die zuvor aus `s.txt` (via Base64) dekodierte Passphrase `edward` wird verwendet.

Bewertung:** **Flag 2 gefunden!** `steghide` extrahiert erfolgreich Daten in eine Datei namens `flag2`. Diese Datei enthält die zweite Flag `flag2{M00nface}` und einen Hinweis auf ein CGI-Skript: `/cgi-bin/vault.py?arg=message`.

Empfehlung (Pentester):** Notiere Flag 2. Untersuche das CGI-Skript `/cgi-bin/vault.py`, indem du es mit dem Parameter `arg=message` aufrufst.
Empfehlung (Admin):** Verstecke keine Informationen mittels Steganografie in öffentlich zugänglichen Bildern, besonders wenn die Passphrase ebenfalls auffindbar ist.

CGI Script & Flag 3

Analyse:** Versuch, das gefundene CGI-Skript aufzurufen.

[Aufruf von http://toronto.vln/cgi-bin/vault.py?arg=message] └─#
Access denied
not nsa.gov
                    

Analyse: Das Skript `/cgi-bin/vault.py` wird mit dem Parameter `arg=message` aufgerufen.

Bewertung: Der Zugriff wird verweigert mit der Meldung "not nsa.gov". Dies deutet darauf hin, dass das Skript prüft, ob der aufrufende Hostname (im HTTP-Request-Header) `nsa.gov` ist.

Empfehlung (Pentester):** Füge den Hostnamen `nsa.gov` zur lokalen `/etc/hosts`-Datei hinzu (neben `toronto.vln`) und rufe das Skript erneut auf, entweder über den Browser (der dann den korrekten Host-Header sendet) oder mit `curl` und manuellem Setzen des Host-Headers (`curl -H "Host: nsa.gov" http://192.168.2.111/cgi-bin/vault.py?arg=message`).
Empfehlung (Admin):** Implementiere keine sicherheitsrelevanten Prüfungen basierend auf dem vom Client gesendeten Host-Header, da dieser leicht manipulierbar ist. Verwende stattdessen IP-basierte oder Authentifizierungs-basierte Kontrollen.

┌──(root㉿cyber)-[~] └─# vi /etc/hosts
[Inhalt der /etc/hosts Datei nach der Bearbeitung]
192.168.2.111    toronto.vln nsa.gov
                    

Analyse: Die lokale `/etc/hosts`-Datei wird aktualisiert, um `nsa.gov` ebenfalls auf die Ziel-IP `192.168.2.111` zu mappen.

Bewertung: Notwendiger Schritt, um die Hostname-Prüfung des CGI-Skripts zu umgehen.

[Erneuter Aufruf von http://nsa.gov/cgi-bin/vault.py?arg=message] └─#
flag{f0urd1g1tz}

Analyse: Nach der Anpassung der `/etc/hosts`-Datei wird das CGI-Skript erneut aufgerufen (diesmal implizit über den Hostnamen `nsa.gov`).

Bewertung:** **Flag 3 gefunden!** Das Skript gibt nun die dritte Flag `flag{f0urd1g1tz}` zurück.

Empfehlung (Pentester):** Notiere Flag 3. Die Herausforderung scheint abgeschlossen.
Empfehlung (Admin):** Hostname-Prüfung als Sicherheitsmechanismus entfernen oder durch robuste Methoden ersetzen.

Abschließende Bemerkung des Pentesters (aus Originaltext): "Die Box ist ein einziges Rätsel , es ist eine Webchallenge ohne System Hacking, gerade nicht mein Model!" - Diese Einschätzung trifft zu. Der Fokus lag auf Web-Enumeration, dem Lösen von Rätseln und dem Finden versteckter Informationen, nicht auf traditioneller Exploit-Entwicklung oder Privilege Escalation.

Flags

Flag 1 (aus ob.js via ROT13)
flag1{m00nc4ke}
Flag 2 (aus nsa.jpg via steghide)
flag2{M00nface}
Flag 3 (aus vault.py CGI)
flag{f0urd1g1tz}