Drop That Shell : It’s October

Bonjour à toutes et à tous !

Cela fait maintenant un bon moment que je n’avais plus continué mes Writeups de CTF. Maintenant que le confinement est prolongé, j’ai désormais plus de temps à consacrer afin de continuer mes expériences dans le domaine.

Je vous propose aujourd’hui de s’attaquer au CTF intitulé « It’s October » créé par Akanksha Sachin Verma. Cette VM est orientée vers les connaissances fondamentales plutôt que sur des exploits tout cuits. Durant ce challenge j’essayerai plutôt de me focaliser plus sur la démarche que sur les caractéristiques techniques des manipulations utilisées. (Si vous avez toutefois des questions, n’hésitez pas à me les poser)

Vous êtes chauds ? Alors, à l’attaque ! 😀

Writeup

Après avoir démarré la VM, notre première étape est de faire de la reconnaissance afin de se faire une idée de ce qui nous attend. La plupart des CTF basiques ne nécessitent pas d’une utilisation poussée de Nmap afin d’obtenir de bons résultats. Dans mon cas, en tant que bon gros bourrin, je lance un simple scan aggressif (-A) sur la VM.


Je remarque directement 2 ports intéressants: 80 et 8080. Ces ports sont connus pour y abriter des serveurs web. Le port 22 est commun sur ce genre de machines basées sous Debian et le port 3306 correspond sûrement à un serveur Mysql mal configuré.

Je jette alors un oeil sur le port 80 en HTTP.

Un simple blog qui semble être statique. Rien de bien ouf. Maintenant, le port 8080.

Une page de prise de note… Peut être une faille d’injection ? Je regarde alors comment la page est générée en affichant la source de cette page et là… un indice.

« mynote.txt »… Allons voir ce qui s’y cache !

Euuuh… presque trop facile ? :’D

Ces logins servent très probablement à ce se loger en tant qu’admin sur le CMS disponible sur le port 80. Je cherche alors l’interface d’administration en tapant sur « /login », mais rien ne se passe. « /register » ? Pareil.

Il est temps de passer à une autre étape de la reconnaissance: Dirb.

Je commence par lancer Dirb sur le port 8080 pour vite me rendre compte qu’il n’y a rien de plus à en tirer.

Je lance ensuite Dirb sur le port 80 et il me trouve très rapidement un « /backend » ainsi que beaucoup d’autres points d’entrées.

Je vais alors sur le « /backend » et me retrouve devant la page de login.

J’essaye alors les logins précédemment trouvés et… magie !

Je suis maintenant authentifié sur le CMS. Le but ici est de réussir à faire exécuter du code à ce dernier afin de gagner un shell.

J’ai donc fait une recherche rapide sur ExploitDB afin de voir si des exploits existaient déjà pour ce CMS. Je tombe directement sur plusieurs publications mentionnant une faille de bypass sur l’upload de fichiers. En effet, j’ai directement essayé de créer de nouveaux fichiers .php depuis l’interface web. Le CMS m’a gentiment envoyé boulet en me spécifiant que ce genre d’extensions n’est pas acceptée. J’ai donc essayé de créer un fichier en .php5 … Même résultat. J’essaye alors de créer un fichier .js et ensuite de le renommer en .php ou .php5 … Pareil.

Bon, la version de ce CMS doit être supérieure à la version affectée par ces bugs. Et oui, je n’ai pas trouvé d’informations concernant la version déployée sur la VM ! Cette étape est normalement cruciale lorsque l’on veut être précis dans son exploitation et dans sa méthodologie.

Après avoir même essayé de changer le type MIME de mes fichiers PHP en cours d’Upload, sans résultats, je décide d’explorer à fond l’intérieur du CMS. Rien de bien complexe pour le moment. Quelques pages de configuration mais rien touchant au code source du site ou des pages générées.

Je remarque tout de même que dans certains menus, je peux apercevoir des syntaxes de code ressemblant à du VueJS.

Je modifie alors ces templates de page et essaye d’exécuter du code, sans succès encore une fois.

Après toutes ces tentatives, je tombe sur une page d’administration intitulée « Updates & plugins ».

Je pense alors directement à développer un plugin custom afin de pouvoir mettre en place un webshell ou un reverse shell. Vu que je suis administrateur, je dois pouvoir installer de nouveaux plugins.

Dans ce menu, je me rend compte que je peux chercher des plugins en ligne et les installer en un clic. Hum… Je cherche alors le mot clé « Console ».

« PHP Sandbox » ! Ce plugin est sûrement ma solution pour pop un reverse shell ! Je l’installe et me retrouve devant cette interface.

Je créé alors un nouveau script et y colle le fameux PHP reverse shell de Pentest Monkey en y modifiant les valeurs requises. Je lance le script mais…

Le plugin ne veut pas utiliser la fonction PHP eval() afin d’éxecuter des commandes système depuis PHP… F*ck… Il faut que j’utilise autre chose. Peut être quelques chose de moins complexe ? Essayons de lancer juste un reverse shell via une simple commande bash.

Ce bout de code PHP va alors utiliser la fonction exec() afin de lancer bash et de le faire initier une connection TCP sur mon ordinateur et lui offrir une session bash interactive. Pratique non ? 🙂

Je lance le script PHP et… un shell pop ! Leçon à retenir: partir du plus simple pour ensuite se diriger vers une exploitation plus complexe, et pas l’inverse !

On a déjà fait un bon bout de chemin ! Nous voilà connectés sur la machine en tant qu’utilisateur www-data.  Cet utilisateur est utilisé très souvent pour faire tourner des services web et accéder à des bases de données. La dernière étape est de monter en privilège sur le système, car je suis très bridé par les droits de cet utilisateur de service. Pour cela, prendre ces marques est très important. Où suis-je ? Quels utilisateurs sont présents ? Quels programmes tournent ? Quelle est la version de l’OS ? Etc.

La première chose que j’ai vérifié est la version de l’OS.

Je suis sur une Debian 4.19. Très probablement vulnérable à Dirty Cow ! Mais je ne trouve pas gcc ni g++… F*ck. Je vais devoir me Privesc sans utiliser d’exploit en C. Va falloir fouiner un peu.

J’ai cherché des moyens afin de compiler un programme en C sans gcc mais n’ai rien trouvé de bien concluant. Je continue alors à fouiller la machine et trouve que l’utilisateur armour existe. Ce n’est pas un compte de service et son UID de 1000 indique que c’est sûrement l’utilisateur créé lors de l’installation de Debian.

Je garde ça de côté, on ne sait jamais. Peut être j’essayerai de bruteforce le mot de passe sur ce compte si je suis désespéré haha !

Je continue de chercher et décide de m’intéresser aux commandes que je pourrais exécuter en tant que root. J’essaye alors un « sudo -l » afin d’avoir plus d’informations.

Décidément, je suis bien bridé alors que je touche au but !

Même sans la commande sudo, je dois pouvoir trouver un moyen d’avoir une liste des programmes possédant le bit SUID. Pour ceux qui ne voient pas de quoi je parle, le SUID est un bit de permission sur les systèmes Linux qui permet à un programme d’être exécuter dans un contexte administrateur depuis un utilisateur quelconque. La commande suivante permet de lister les programmes disposant de ce fameux bit.

Je remarque directement que python est présent dans cette liste… Très intéressant ! Il doit y avoir un moyen d’exécuter un shell bash depuis Python en utilisant un contexte de lancement root !

Après quelques recherches sur un de mes sites préférés, GTFObins (<3), je tombe sur un paragraphe dédié à Python.

Cette astuces est très interressante. En effet, en lancant la commande suivante, nous lançons le programme sh en utilisant le bit SUID.

BINGO !

Shell root, et flag chopé ! PWNED ! 😀

Conclusion

Cette VM ne m’a pas pris plus d’une heure à terminer et je dois avouer que j’ai bien rigolé ! Il est vrai que le niveau de difficulté est modeste, mais permet tout de même de remettre le pied à l’étrier après un bon moment d’inactivité. Je pense refaire quelques VM dans ce genre d’ici les prochaines semaines si je trouve le temps.

Si vous avez des questions, suggestions ou alors que vous avez trouvé d’autres moyens de terminer ce challenge, n’hésitez pas à me le dire par Twitter, Telegram ou Matrix !

Sur ce, à bientôt pour de nouveaux articles ! :p