Deutschlands Bester Hacker - Lost Developer (Misc)

Disclaimer: Im August 2026 fand die Qualifikation für das Finale von Deutschlands Bester Hacker statt, welches ich auf Platz 1 abschließen konnte. Nur zwei Teilnehmer waren in der Lage, alle Challenges zu lösen. Dieses Writeup wurde mit KI auf Basis meiner Notizen erstellt und kann Fehler enthalten, bei Fragen bitte direkt an mich wenden im DBH-Discord.


Wettbewerb	Deutschlands Bester Hacker 2026 — Qualifikation
Kategorie	Misc
Punkte	316
Angriffsklasse	OSINT / Metadaten + Content Discovery + schwaches RSA

Die Challenge

Alex Carter ist Softwareentwickler und Fotograf. Er ist aus der Öffentlichkeit verschwunden und hat verstreute Spuren seiner Arbeit hinterlassen. Irgendwo dazwischen hat er etwas versteckt.

Aufklärung

Die Challenge-Website ist eine einfache Portfolio-Seite mit den Seiten index.html, about.html, blog.html, contact.html, social/github.html und social/twitter.html. In jeder Seite stecken HTML-Kommentare mit Hinweisen:

Seite	Kommentar
index.html	`TODO: Remove old development files before final deployment.`
about.html	`Old username used during development: lostdev`
contact.html	`Website migration completed. Check old backup files before removing.`
social/github.html	`Main project: portfolio, Important file: projecthint.jpg`
social/twitter.html	`Backup information: Check document metadata.`

Die robots.txt liefert weitere Hinweise:

# I have nice Projects
# Disallow: /exifisathing/
# sitemap: /old/sitemap.xml

exifisathing zeigt unmissverständlich auf EXIF-Metadaten als Informationsquelle.

Die Schwachstelle

resume.pdf — die PDF-Metadaten enthalten in den Keywords:

flag_location=/hiddden/
crypto=id_rsa.pub

Das verrät das Zielverzeichnis /hiddden/ (mit drei d) und dass eine RSA-Public-Key-Datei relevant ist.

projecthint.jpg — enthält einen JPEG-Kommentar:

wget me check me and find hidden places

Dazu EXIF-Daten: Artist=lostdev, Software=Photo Manager v1.4, XMP Description=Mountain trip archive.

Das Verzeichnis /hiddden/ war per nginx mit 403 Forbidden blockiert. Ein Scan mit Standardeinstellungen reichte nicht — entscheidend war ein rekursiver Scan mit erhöhter Tiefe und erweiterten Dateiendungen:

feroxbuster \
  --url <URL> \
  --wordlist SecLists/Discovery/Web-Content/common.txt \
  --depth 6 \
  --extensions html,txt,pdf,jpg,png,json,xml,pub,key,zip,bak,old,pem,env,conf \
  --status-codes 200 301 302 403

Neue Funde:

/assets/crypto — Verzeichnis mit verschlüsseltem Text
/check — gibt LOCKED zurück
/unlock — gibt Invalid token zurück, erwartet also einen Token

Der Angriff

Im /assets/crypto-Verzeichnis lagen die verschlüsselte Nachricht und der Public Key:

Ciphertext: 2655eacc028dfa8924e8223e39fad4b3

-----BEGIN RSA PUBLIC KEY-----
MBgCEQCeyf5W0WFpCSE7+2NzKY7vAgMBAAE=
-----END RSA PUBLIC KEY-----

Der RSA-Key ist nur 128 Bit groß — trivial faktorisierbar:

n = 211066833613043640897216781334063189743
e = 65537

Faktorisiert:

p = 11514676378748110951
q = 18330244521903886393

Damit lässt sich d berechnen und der Ciphertext entschlüsseln:

phi = (p - 1) * (q - 1)
d = pow(e, -1, phi)
m = pow(c, d, n)
# Ergebnis: UNLOCK-7F3A9C2D

Der Token wird an den /unlock-Endpunkt übergeben:

/unlock?token=UNLOCK-7F3A9C2D → "Archive unlocked. Access granted."

Anschließend ist /hiddden/ mit dem Token als Parameter zugänglich:

/hiddden/?token=UNLOCK-7F3A9C2D

Die Flag

Im freigeschalteten Verzeichnis liegt unter anderem die flag.txt mit der Flag im Format DBH{...}.

Was ich mitnehme

Scanner-Defaults reichen nicht. feroxbuster scannt standardmäßig nur bis Tiefe 3. Wichtige Pfade wie /assets/crypto und /unlock tauchten erst bei Tiefe 6 auf.
Erweiterte Extensions nutzen. .pub und .key sind in den meisten Scannern keine Standard-Endungen, waren hier aber entscheidend.
Metadaten sind eine eigene Angriffsfläche. Die robots.txt wies explizit auf EXIF hin, und die PDF-Keywords enthielten die zentralen Hinweise. Wer nur den sichtbaren Seiteninhalt liest, findet den Einstieg nicht.
Kleine RSA-Keys sind kein Schutz. Ein 128-Bit-Modulus fällt in Sekunden.