RootMe App-Script/Bash-System-1

As a newcomer to the cybersecurity industry, I'm on an exciting journey of continuous learning and exploration. Join me as I navigate, sharing insights and lessons learned along the way
Search for a command to run...

As a newcomer to the cybersecurity industry, I'm on an exciting journey of continuous learning and exploration. Join me as I navigate, sharing insights and lessons learned along the way
No comments yet. Be the first to comment.
Ce lab a pour but de concevoir et déployer une infra sécurisée et segmentée sur Google Cloud Platform (GCP) en utilisant Terraform et Ansible. Bonne lecture :) Composants Voici les différentes technologies et composants du projet. Infrastructure Te...
Cet article présente la mise en place d’un environnement de détection, combinant Zeek, Suricata avec la stack ELK (Elasticsearch, Logstash, Kibana). Il permet de mettre en avant la gestion des logs avec ELK, l’analyse réseau avec Zeek et Suricata, pu...

Dans cet article, on va déployer une application Python Flask sur Kubernetes. Un premier article montrant les premiers pas avec Kubernetes et Minikube est disponible ici Kubernetes: Simplifying Container Orchestration Pré-requis Docker: pour créer l...

Kubernetes ou K8s est une plateforme open-source utilisée pour automatiser le déploiement et la gestion des applications conteneurisées. Une application conteneurisée est une application qui fonctionne à l’intérieur d’un conteneur, un environnement l...

Lien : https://www.root-me.org/fr/Challenges/App-Script/ELF32-System-2 On veut pouvoir lire le mot de passe du fichier .passwd mais il n’est lisible que par le propriétaire du fichier app-script-ch12-cracked. Le code source de ch12.c utilise la fonc...

Lien: https://www.root-me.org/fr/Challenges/App-Script/Bash-System-1
Pour ce challenge, il faut lire le fichier .passwd dans le répertoire de l’utilisateur avec lequel on est connecté.

Ce fichier est détenu par app-script-ch11-cracked, qui a le droit de lire, et il appartient aussi au groupe app-script-ch11. Le fichier ch11 est un exécutable en C, qui utilise la fonction system pour lister contenu de .passwd. Et vu que .passwd est un fichier et non un dossier, lorsqu’on l’exécute il affiche juste le nom sans lire le contenu.

Par contre, on voit que le fichier ch11 a le bit SUID défini, indiqué par le s dans les permissions à la place du x pour l’exécution. Cela signifie que lorsqu’il est exécuté, c’est avec les privilèges du propriétaire, soit app-script-ch11-cracked.
La faille ici se trouve au niveau du ls qui est appelé au niveau de la fonction system. Le programme appelle ls sans spécifier où le trouver. En principe, on devait avoir system("/bin/ls /challenge/app-script/ch11/.passwd") pour indiquer le chemin absolu de la commande ls sur le système. Lorsque la commande est exécutée, le shell regarde dans la variable d’environnement appelée PATH, qui contient la liste de répertoires où il cherche ses commandes. Si on arrive à modifier le PATH, pour le pointer vers un autre répertoire, on peut modifier l’exécution du ls qui sera remplacée par une autre commande, vu que la vraie commande ls (/bin/ls) n’est pas spécifiée au niveau de la fonction system. Notre fausse commande ls sera ensuite exécutée avec les privilèges de app-script-ch11-cracked car le fichier ch11 a le bit suid.
Pour créer la fausse commande ls, on créé un répertoire qui va contenir un script nommé ls. On peut créer ce script dans un répertoire /tmp/script.
#!/bin/bash
cat /challenge/app-script/ch11/.passwd
Il s’agit d’un shell (#!/bin/bash) qui va lire et non lister le contenu du fichier avec cat au lieu de ls. Il faut ensuite rendre ce script exécutable avec la commande suivante
chmod +x /tmp/script/ls
Il faut maintenant modifier la variable PATH pour que /tmp/script soit le premier endroit où le shell cherche les commandes.
export PATH=/tmp/script:$PATH
Avant l’exécution de cette commande, le PATH était probablement /usr/local/sbin, mais une fois qu’on l’exécute, le PATH débute par /tmp/script. Quand il voit à partir de là, une commande ls, il exécute donc /tmp/script/ls et non /bin/ls.
