THM-Steel_Mountain-CVE-2014-6287

Un write-up sur la machine Steel Mountain de TryHackMe.com et un exploit pour CVE-2014-6287

Crédits

Je ne prends aucun crédit pour la découverte originale et l'exploitation de cette vulnérabilité. Merci aux personnes suivantes !

Découverte :
Daniele Linguaglossa

Auteur du module Metasploit :
Muhamad Fadzil Ramli

Salle TryHackMe et auteur :
https://tryhackme.com/room/steelmountain
https://tryhackme.com/p/tryhackme

Références :
https://nvd.nist.gov/vuln/detail/CVE-2014-6287
https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/windows/http/rejetto_hfs_exec.rb
https://subscription.packtpub.com/book/networking_and_servers/9781786463166/1/ch01lvl1sec20/vulnerability-analysis-of-hfs-2-3 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6287 https://www.tutorialspoint.com/pascal/pascal_functions.htm

Si vous voyez quelque chose, dites quelque chose !

Je ne suis en aucun cas un professionnel de la sécurité aguerri. Cela signifie que je peux fournir des informations incorrectes. Si vous êtes un professionnel expérimenté / chercheur chevronné et que vous voyez quelque chose d'incorrect, veuillez m'en informer afin que je puisse revenir, étudier ce que j'ai mal compris et fournir les informations correctes. Cela est bénéfique pour moi ainsi que pour les autres chercheurs novices qui pourraient tomber sur ce write-up. Si vous trouvez de fausses informations que j'ai écrites, veuillez me contacter à [email protected] pour que je puisse les corriger. Merci !

Vulnérabilité

Rejetto file server (également connu sous le nom de HFS) est un programme de partage de fichiers utilisé pour publier et partager des fichiers sur un réseau. Dans la version 2.3, il existait une vulnérabilité qui permettait à un attaquant d'exécuter des commandes système en insérant un octet nul dans le paramètre de recherche, comme décrit dans CVE-2014-6287. Le code ne traite pas correctement un octet nul avec sa configuration regex (expression régulière) et conduit donc à une vulnérabilité d'exécution de code à distance.

La vulnérabilité se trouve dans la fonction findMacroMarker qui provient du fichier parserLib.pas. .pas est l'extension de fichier pour le langage de programmation Pascal. Au moment de la rédaction de ce document, je n'ai rien codé en Pascal. Jetons un coup d'œil à l'extrait de code et décomposons ce qu'il fait !

function findMacroMarker(s:string; ofs:integer=1):integer;  
 begin result:=reMatch(s, '\{[.:]|[.:]\}|\|', 'm!', ofs) end;

La première ligne de code est une déclaration d'une fonction appelée findMacroMarker qui prend deux paramètres. En Pascal, le type de données des paramètres doit être déclaré, donc s:string signifie que la variable s est une string. C'est également le cas pour la variable ofs avec un type de données integer. À droite des paramètres, nous voyons un caractère deux-points suivi de integer. C'est ce qu'on appelle le type de la fonction. Le point-virgule marque la fin de cette ligne de code. Le premier mot de la ligne suivante est begin. Cela indique au compilateur où commence la fonction. Ensuite, nous voyons une variable appelée result suivie de l'opérateur d'affectation :=. La variable result est assignée à la fonction reMatch. Je n'ai rien trouvé sur reMatch sur Internet, donc je suppose qu'il s'agit d'une fonction personnalisée écrite ailleurs dans HFS. Heureusement pour nous, la fonction est explicite. est clairement l'abréviation de "regular expression match" suivie du motif regex qu'elle recherche, ce qui est pris en compte dans les paramètres de la fonction ainsi que dans les paramètres initiaux de la variable définis dans la première ligne de code. À la fin de la deuxième ligne, le mot est utilisé pour définir la fin de la fonction pour le compilateur.

La vulnérabilité se trouve dans le motif regex comme décrit ci-dessus dans la fonction reMatch. L'expression régulière ne gère pas correctement un octet nul %00. Lorsque nous passons une commande système avec un octet nul préfixé, la fonction rencontre le bogue et exécute la commande sur l'ordinateur hôte. Pour exploiter cette vulnérabilité, il suffit de passer l'octet nul dans le paramètre de recherche d'une requête GET suivi de {.exec|code.} (code étant la commande que vous souhaitez exécuter) via l'URL de cette manière :
http://(Adresse-IP/NomDeDomaine)/?search=%00{.exec|CommandeIci.}.

Write-Up

Commençons par un scan de ports via rustscan. Je préfère rustscan pour avoir un aperçu rapide de la surface d'attaque.

Nous avons un nombre important de ports ouverts ici. Nous allons approfondir maintenant avec nmap et découvrir quels services écoutent sur cette gamme de ports pour trouver notre service exploitable.

Nous avons un service appelé Microsoft Windows RPC qui tourne sur les ports élevés. RPC signifie "Remote Procedure Call" (appel de procédure distante). Cela permet aux processus Windows de communiquer sur un réseau ou en interne au sein de l'ordinateur lui-même. Ensuite, nous avons plusieurs serveurs web différents sur les ports 80 et 8080. Sur les ports 5985 et 47001, Microsoft Httpapi Httpd est présent, ce qui permet aux applications de communiquer via HTTP sans avoir besoin de Microsoft IIS (Internet Information Server). Nmap détecte un serveur web potentiel sur le port 3389, mais je n'ai pas pu me connecter via HTTP ou SSL. Connectons-nous au serveur web sur le port 80 puisque c'est le port standard pour le protocole HTTP.

Sur le port 80, on nous présente une page web avec le logo de la société Steel Mountain et une photo étiquetée "Employé du mois". Si nous ouvrons les outils de développement web, nous pouvons voir que la photo est nommée BillHarper.png, ce qui nous donne la réponse à notre première question. Connectons-nous aux autres services d'écoute et voyons ce que nous pouvons trouver.

Lorsque nous nous connectons au service sur le port 5985, nous obtenons le code d'erreur HTTP 404. Le code d'erreur 404 signifie que le serveur ne peut pas trouver la ressource demandée. Rien d'intéressant ici. Passons au suivant.

OUI ! Maintenant, cela semble intéressant. Sur le port 8080, nous avons une sorte de service de partage de fichiers. Regardons autour pour voir si nous pouvons trouver plus d'informations sur ce service. Si nous regardons dans le coin inférieur gauche, nous pouvons voir un nom et ce qui ressemble à un numéro de version comme ceci : HttpFileServer 2.3. Allons plus loin.

Si nous cliquons sur le lien intitulé HttpFileServer 2.3, nous sommes redirigés vers une page web indiquant le nom du logiciel qui tourne sur le port 8080. Dans ce cas, nous avons Rejetto HFS HTTP File Server. Vérifions l'autre port sur 47001 pour couvrir toutes nos bases. Si nous ne trouvons rien d'utile, nous pourrons revenir à Rejetto et commencer à chercher des CVE connues.

On dirait que nous avons une autre erreur 404 sur le port 47001. Commençons à chercher des CVE pour Rejetto HFS 2.3.

Une recherche rapide révèle que nous avons une entrée CVE connue pour HFS 2.3. Nous allons nous écarter du guide THM et rester en dehors du Metasploit standard. J'ai codé un exploit qui nous donnera un shell. Pour l'utiliser, vous devez vous rendre sur revshells.com, entrer les informations réseau appropriées et sélectionner PowerShell #3 (Base 64). Une fois que vous avez le payload, copiez-le et collez-le dans la variable payload à la ligne 13, puis exécutez l'exploit. Un listener s'ouvrira automatiquement et vous devriez avoir accès au système. Note : Il peut être nécessaire d'exécuter l'exploit plusieurs fois pour récupérer le shell.

Boom ! Nous sommes dans le système et en prime, nous avons un shell PowerShell. Cela signifie que nous aurons accès aux cmdlets .NET. Nous pouvons être bien plus dangereux avec cela qu'avec l'invite de commande standard. Passons à l'élévation de privilèges. Le guide THM nous fournit un outil utile appelé PowerSploit qui dispose d'un outil pour énumérer la machine à la recherche de vecteurs potentiels d'élévation de privilèges. Nous allons déposer PowerUp.ps1 sur la machine et l'utiliser pour nous aider à prendre le contrôle de la machine.

D'abord, nous démarrons un simple serveur HTTP dans le répertoire contenant notre fichier PowerUp.ps1 sur notre système. Ensuite, sur notre système cible, nous utilisons le cmdlet Invoke-Webrequest pour récupérer le fichier depuis notre serveur vers la machine cible. Nous allons maintenant installer et exécuter l'un des cmdlets fournis avec PowerUp.

Pour installer PowerUp.ps1, exécutez cette commande : . .\PowerUp.ps1. Ensuite, nous devrons utiliser notre nouveau cmdlet Invoke-AllChecks. Après l'avoir exécuté, nous obtenons une multitude de résultats. Je les ai réduits à celui qui est important pour nous. Nous pouvons voir que PowerUp nous a indiqué que nous avons les permissions pour modifier le fichier. Vérifions les services en cours d'exécution pour pouvoir l'arrêter s'il tourne. Nous devons faire cela car nous ne pouvons rien faire avec le fichier s'il est utilisé par un service.

En utilisant le cmdlet Get-Service, nous obtenons une liste des services présents sur la machine. Comme notre service cible est en cours d'exécution, nous devrons l'arrêter afin de pouvoir modifier et écraser le binaire.

Pour arrêter le service, nous utilisons le cmdlet Stop-Service suivi du nom du service. Maintenant, nous devons vérifier que le service est bien arrêté avec le cmdlet Get-Service. Comme montré ci-dessus, nous pouvons confirmer que le service est bien arrêté. Déplaçons-nous dans le répertoire contenant notre binaire cible. Le répertoire est C:\Program Files (x86)\IObit\Advanced SystemCare.

Notez la taille du fichier du binaire, qui se trouve à gauche du nom du binaire dans la colonne la plus à droite.

Créez un payload meterpreter et hébergez-le avec le module de serveur web Python comme nous l'avons fait précédemment.

Démarrez un listener meterpreter en utilisant les mêmes informations réseau que celles utilisées pour créer le payload.

Utilisez le cmdlet Invoke-Webrequest pour récupérer notre payload meterpreter depuis notre machine vers le système cible. Assurez-vous de le nommer ASCService.exe afin de pouvoir exploiter les permissions de fichier faibles et écraser le binaire normal avec notre binaire malveillant.

Confirmez que le binaire a été écrasé en listant le répertoire et en vérifiant si la taille du fichier a changé. Dans ce cas, elle est passée d'un nombre à 6 chiffres à un nombre à 5 chiffres, ce qui confirme que nous avons bien téléchargé notre binaire malveillant !

Une fois que le binaire malveillant a remplacé le binaire normal, il suffit de redémarrer le service avec le cmdlet Start-Service. Lorsque nous faisons cela, la machine exécutera notre payload et nous donnera un shell meterpreter ! Nous pouvons exécuter getuid dans meterpreter pour vérifier si nous avons NT AUTHORITY/SYSTEM. Lorsque nous exécutons getuid, nous pouvons effectivement voir que nous avons pris le contrôle de cette machine ! Passez une excellente journée !