# Kioptrix: Level 1.2 (#3)

## Détails de la machine

**Nom :** Kioptrix: Level 1.2 (#3)\
**Date de sortie :** 11 Février 2011\
**Lien de téléchargement :** [http://www.kioptrix.com/dlvm/KVM3.rar](http://www.kioptrix.com/dlvm/KVM3.rar)\
**Niveau :** Facile\
**Objectif(s) :** obtenir un accès "root"\
**Description :**`It's been a while since the last Kioptrix VM challenge. Life keeps getting the way of these things you know.`\
`After the seeing the number of downloads for the last two, and the numerous videos showing ways to beat these challenges. I felt that 1.2 (or just level 3) needed to come out. Thank you to all that downloaded and played the first two. And thank you to the ones that took the time to produce video solutions of them. Greatly appreciated.`\
\
`As with the other two, this challenge is geared towards the beginner. It is however different. Added a few more steps and a new skill set is required. Still being the realm of the beginner I must add. The same as the others, there’s more then one way to “pwn” this one. There’s easy and not so easy. Remember… the sense of “easy” or “difficult” is always relative to ones own skill level. I never said these things were exceptionally hard or difficult, but we all need to start somewhere. And let me tell you, making these vulnerable VMs is not as easy as it looks…`\


## Reconnaissance

La machine étant en DHCP il me faut tout d'abord récupérer son adresse IP :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-Lqm4c1xG3Nubv0HjVSE%2F-Lqm6sV7-bYDAotPOCoc%2F2deb7203ebaf8282be37f5b5c566da05.png?alt=media\&token=ae2ba0cc-b439-4f55-9bd4-18d1db471acb)

Comme indiqué dans la consigne du challenge, la machine a besoin d'une résolution DNS avec le nom `kioptrix3.com`. Direction donc le fichier `/etc/hosts` :

```
192.168.56.53	kioptrix3.com
```

Le `nmap` habituel, afin de déterminer les services exposés par la machine :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-Lqm4c1xG3Nubv0HjVSE%2F-Lqm8AzGzaRw3EPe--QK%2F205a03d8a77e3eda16e25c1447f7583e.png?alt=media\&token=c590782e-0952-42c0-a736-516fd904cc41)

Peu de services puisque seul un service SSH et un serveur HTTP sont exposés.

### Service SSH

Pas de vulnérabilité notable pour cette version de SSH, ça ne sera sans doute pas ma porte d'entrée :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-Lqm4c1xG3Nubv0HjVSE%2F-Lqm9dh1zrZ1aUm18M1X%2F4aeb07eae3f4a5743e45a741ab7e1fe8.png?alt=media\&token=1d672d37-aa6c-42bb-9723-65eca63c728f)

### Serveur HTTP

Le `nmap` m'apprends que le serveur HTTP est un Apache 2.2.8 utilisant PHP en version 5.2.4. J'ajoute à cela les résultats d'un `nikto` :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LqmByFMBRlPysWE3OFV%2F-LqmC0KdDAnZ8RtWIveF%2Facba11cde47bf0cc7aa3a4b96d66634b.png?alt=media\&token=472dcae7-5a37-4cd6-b94e-810d3a0ed63f)

Le scan m'apprends la présence d'un phpMyAdmin. La consultation du fichier `changelog.php` m'indique son numéro de version :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LqmByFMBRlPysWE3OFV%2F-LqmD-KClpUijyXvk7gf%2F2545c9cd63d702ea68f6cc394345308a.png?alt=media\&token=89d8779a-9b26-495a-91a5-ee97acbacefd)

Je ne mets pas la sortie du `dirb` car cela ne donne pas grand chose.

Je passe maintenant à l'analyse des pages web hébergées par le service. Tout d'abord la page d'accueil :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LqmHSg9qSb6apz7ex44%2F-LqmHrowTsR4jh7bSyuB%2Fe3f3136cda2c6480eebe477ad90a07c9.png?alt=media\&token=34e1addd-e4b3-4dbb-abc6-d01c47f6b3b0)

La mire de login est intéressante car elle m'informe du CMS utilisé :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LqmHSg9qSb6apz7ex44%2F-LqmIEm_HBNwlLN_-YlA%2F7173a10a17abc6ab810f7da6a3bebd85.png?alt=media\&token=07b39341-29f9-45d8-b35f-7d982e5da7ad)

LotusCMS était un CMS open-source écrit en 2007/2008. Le code source est encore disponible sur [GitHub](https://github.com/kevinbluett/LotusCMS-Content-Management-System) (hébergé à l'origine sur [sourceforge](http://sourceforge.net/projects/arboroiancms/)).

Mon premier but était d'identifier la version utilisée, j'ai donc récupéré le code source afin de repérer les différents fichiers pouvant contenir cette information. Le titre du fichier `install.html` présent dans le répertoire `/style/comps/admin/` me rend ce service :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LqmHSg9qSb6apz7ex44%2F-LqmJ_mq1oXmwDnefz6B%2F0a7d7315353be9fb05d96c32190f0256.png?alt=media\&token=2a3f6dfe-d1b0-47e2-985e-513a27282c4a)

LotusCMS en version 3.0 possède une vulnérabilité de type LFI pouvant amener à une RCE ([CVE-2011-0518](https://www.cvedetails.com/cve/CVE-2011-0518/)). Pour faire court, le système de post de commentaires sur le blog permet en fait l'écriture de fichiers sur le disque, puis la faille LFI permet de les charger.

## Exploitation

### CVE-2011-0518

Un module `metasploit` existe concernant cette vulnérabilité :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LqmLviWa7kYOz-az-pE%2F-LqmNgCt196lxx47oMOm%2Fa1890c95c8818d0bf8cc7f3a7bc535ff.png?alt=media\&token=b25abc43-1580-49b5-873b-edbc2b8e6292)

L'exploitation sera donc plutôt aisée :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LqmLviWa7kYOz-az-pE%2F-LqmOXMjfUQaTHA4Jjxd%2F2988561f2435318f7427a3c3768b174c.png?alt=media\&token=921033c5-3ef3-4c59-a69b-d16fec63f439)

## Élévation de privilèges

La phase de reconnaissance permet de récupérer la liste des utilisateurs de la machine :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LqoYGiKb80wzwHKIaeA%2F-LqoYY1JYp9tdNCE4u36%2F2c3f30bda9d912122fe4e1957260e240.png?alt=media\&token=90c05e19-bca6-470f-a705-b32af37a3120)

Deux comptes sont des utilisateurs de la machine : **dreg** et **loneferret**. Après avoir fouillé dans le `/home` de **loneferret** :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LqoYGiKb80wzwHKIaeA%2F-LqoZAs8z9BDvEiVJAwV%2Fc5b0eda6c53681648b49e1c8f970edf3.png?alt=media\&token=b9bcba74-aee9-4c6e-95b3-d7d63a0be19e)

Le fichier `CompanyPolicy.README` (ainsi que le `.bash_history`) indique l'utilisation d'un programme nommé `ht`. Après quelques recherches, il s'agit d'un éditeur de texte. Chose intéressante, le binaire possède le **suid** à 1 :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LqoZTBDU00nICLPWxEr%2F-Lqo_6mB75e0zQ7m1AVk%2Fc5e239b32f7331685e26d9e96aa25bc0.png?alt=media\&token=bb7f4f7a-def1-482f-8d24-fa7925ac520d)

Je tente donc de lancer le binaire :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LqoZTBDU00nICLPWxEr%2F-Lqo_P-kLMKdpOeJdk_a%2F07676563dbfc28b8a2447d27aa1f7039.png?alt=media\&token=3723ffe8-28ef-4594-ae10-e15f479eacfa)

Je suis pas un grand connaisseur des erreurs XTERM et compagnie. Je tente un peu à l'aveugle quelques commandes trouvées ici et là, par exemple :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LqoZTBDU00nICLPWxEr%2F-Lqo_qsdVn_yCleME1ZS%2F00f9b4c7c13114c658f7c0f472698099.png?alt=media\&token=500fd192-1c17-4d73-8e5a-78e47429c659)

Cela améliore sensiblement les choses, à savoir que je peux maintenant lancer le binaire mais ce n'est toujours pas utilisable (la saisie de caractères écrit tout simplement sur l'interface) :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LqoZTBDU00nICLPWxEr%2F-LqoaCdOFzq8DIaXlD6Y%2F6b0c60d0c0bc18120c7c034dc721d701.png?alt=media\&token=1774bf5e-f99a-45fa-acae-d21ce08a0a32)

Après un certain temps à tourner en rond, j'ai décidé de rétropédaler et d'approfondir la reconnaissance du système.

Mon premier objectif est d'avoir accès à la partie administration de LotusCMS. Etant donné qu'il s'agit d'un CMS qui utilise seulement des fichiers plats, le mot de passe doit se situer dans un de ses fichiers de configuration.

Après quelques recherches il se trouve que le mot de passe est présent dans un fichier distinct pour chaque utilisateur. Dans mon cas il s'agit de l'administrateur :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-Lqol1gHmpgMxI68jxcQ%2F-LqolbWnO_cpGodInwBh%2F380aae7f14e17ac297e227f92c0780fe.png?alt=media\&token=ee80d4d1-a12a-4458-8f69-e53daed48103)

Après une lecture du code source, il se trouve que le mot de passe, avant d'être haché en SHA1, est tout d'abord concaténé avec un sel statique. Ce sel est présent dans le fichier /data/config/salt.dat :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-Lqol1gHmpgMxI68jxcQ%2F-Lqom1pdTgOfsFVja43b%2F5dd5d4f39ca30c4520b36b8e5b4b4381.png?alt=media\&token=f906834a-c718-4f82-8b63-5f2bd38a9fec)

John va m'aider à cracker ce mot de passe, mais il faut bien prendre en compte le sel utilisé. J'ajoute donc le hash dans un fichier sous le format `username:hash$sel` :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-Lqol1gHmpgMxI68jxcQ%2F-LqomMKSDYEiEyPmcL2R%2Fabdc00f93c7dbe14060e4aa7c4f3a9d4.png?alt=media\&token=eba0d96a-b9be-47b2-be67-734df7704c1f)

Il ne faut pas oublier d'indiquer le format (ici `dynamic_24`) dans la ligne de commande :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-Lqol1gHmpgMxI68jxcQ%2F-LqomdwMe89x6t7wAX8h%2Fa7299ae089a9a30c4ea1c1f906a66d21.png?alt=media\&token=25297d8d-34f7-4818-ae65-0497ee83af95)

Tout cela donne accès à la partie administration de LotusCMS :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-Lqol1gHmpgMxI68jxcQ%2F-LqomsI5qACpxfEABWu5%2Fe4c88163fa456c0f2fd3e190a8acc3fe.png?alt=media\&token=fa56176c-381c-4138-b91a-8b248c99002b)

Malheureusement, impossible d'aller plus loin dans la compromission de la machine par ce vecteur, je me penche alors sur l'accès shell.

La recherche de mot de passe en plaintext porte ses fruits au niveau du répertoire `/gallery` :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LqofmDrgcZ6ZSX4HN4r%2F-Lqog4VuOAiUJtk6NwYc%2F522a3d5f14bea3929868e3676a3f0935.png?alt=media\&token=0836de0a-b8e2-4a98-885e-8f89f3ca62a0)

Cela permet d'avoir accès à la base MySQL avec le compte root/fuckeyou. Pour une analyse plus facile du contenu de la base de données, je passe par le phpMyAdmin.

J'obtiens donc un premier mot de passe dans la table `gallarific_users` :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-Lqoh2vhIyyeFK7qOjc4%2F-LqohZv_BGVyVqWZ-FAA%2F395cef4fc251ed7ef313d36062b0da48.png?alt=media\&token=dcf6e4b7-6efd-4c3f-a431-b50962e77a90)

Et deux autres mots de passe (cette fois hashés) pour les utilisateurs **dreg** et **loneferret** dans la table `dev_accounts` :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-Lqoh2vhIyyeFK7qOjc4%2F-LqohzgbCV3cFpr9Up63%2F8b492cfedeb8f61b28c6978d024e7bda.png?alt=media\&token=2c40ca80-df94-4627-9899-106f5f661867)

Je tente de récupérer les mots de passe en clair :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-Lqoh2vhIyyeFK7qOjc4%2F-LqoiR1782vjK1VvasLY%2Fc1fce2e38ed6841b010536035e7fa937.png?alt=media\&token=9eb95d3c-0fa0-40a4-a007-6cae99c05d33)

Cela me permet de se connecter en SSH avec le compte de **loneferret** :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-Lqoh2vhIyyeFK7qOjc4%2F-Lqoih5E0YIdQgJSpDg6%2F6ac743790d4e460ef50b7b0661ceb8d5.png?alt=media\&token=6f738e84-83ba-4c38-9b8b-a2f494715786)

Etant donné que `ht` possède le bit suid à 1, il est possible d'éditer des fichiers avec les droits root. Je modifie alors le fichier `/etc/sudoers` :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LqojEWQ6D7_dE6OkYM3%2F-LqojUUsBcjNuH4X1TU_%2F0d7ea31987d0a4a1e312a93a5b4a5ca4.png?alt=media\&token=445283f2-4040-4c31-9240-b919b0cdff73)

afin d'ajouter le droit `su` à l'utilisateur **loneferret** :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LqojEWQ6D7_dE6OkYM3%2F-LqokiAoArKl9lH1lA1b%2F743a0c067215825e0d3a98017dd1b66b.png?alt=media\&token=3549c3c2-4336-4bda-919c-c3082f36c410)

Un petit `sudo su` plus tard, me voilà root :

![](https://1502624390-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LXA-aPG-dBFXBTzP1DC%2F-LqojEWQ6D7_dE6OkYM3%2F-LqoktYQD3d-4irvNMy5%2Ffa187d718ea2ce9be51246ea929a9e6b.png?alt=media\&token=bf71df04-7bb3-4ff4-b142-6d65d583b830)

## Conclusion

Très facile jusqu’à la récupération d'un shell, la machine se corse en ce qui concerne l'élévation de privilèges. J'ai passé un sacré bout de temps à tenter de faire fonctionner `ht` avec le compte **www-data** avant d'explorer d'autres solutions.

J'ai apprécié de pouvoir/devoir étudier le code source du CMS afin de connaitre les emplacements des données intéressantes et également son fonctionnement (notamment sur la façon de stocker ses mots de passe).

La leçon à retenir est de ne pas oublier d'explorer les autres pistes quand on est bloqué à une étape afin de collecter un maximum de données. Je m’aperçois que je dois fortement m'améliorer en ce qui concerne la phase de reconnaissance post compromission.
