sudo (substitute user do) est un programme conçu pour permettre à un utilisateur d’exécuter une commande sous un autre.
Il est installé par défaut dans la plupart des distributions Linux afin d’éviter d’utiliser le compte root.
Mais sudo est-il sûr ? quels sont les risques de sécurité d’utiliser sudo ?
Dans ce tutoriel, je vous montre comment on peut utiliser sudo pour gagner frauduleusement un accès root.
Comment il peut poser des problèmes de sécurité pour un hack et notamment d’élévation de privilèges.
Table des matières
Quels sont les problèmes de sécurité de sudo
Les exploits
sudo est un utilitaire, comme tout programme, il peut comporter un défaut de conception dit bug. Parmi ces derniers, on trouve les bugs de sécurité.
Ainsi, des vulnérabilités et failles logiciels peuvent permettre une élévation de privilèges.
Pour cela, l’attaquent utilise un exploit.
Un petit tour sur le système de tracking des paquets Debian pour avoir un aperçu des vulnérabilités touchant sudo : https://security-tracker.debian.org/tracker/source-package/sudo
Vous avez un exemple avec CVE-2021–3156 (~ mai 2021), sudo_inject, etc.
Bon ici, rien de vraiment anormal, la mise à jour du système corrigeant ces problèmes de sécurité.
Les shells dans les commandes
Mais le problème principal de l’utilisation de sudo ne réside pas dans sudo lui même mais dans les utilitaires GNU disponibles dans Linux.
En effet, beaucoup des commandes par défaut de Linux donnent accès à un shell.
Or si vous exécutez celle-ci avec sudo, cela donne accès à un shell root.
Prenons, exemple de vim, un éditeur texte.
Il suffit d’utiliser l’option -c qui permet d’exécuter une commande. On peut exécuter bash afin d’obtenir un shell en root via sudo :
sudo vi -c '!bash'
Même chose depuis l’interface vim direct, il est possible d’ouvrir un shell bash.
Par exemple, l’utilisateur exécute vim avec sudo :
sudo vim /tmp/demo.txt
Puis utilisez la commande suivante pour ouvrir un shell en root :
:shell
C’est aussi le cas de la commande man qui peut paraître inoffensif, pourtant, elle permet d’accéder aussi à un shell.
sudo man more
Depuis l’interface, on peut utiliser une commande grâce au caractère !.
Par exemple pour exécuter ls :
!ls
A partir de là, on peut ouvrir un shell en root :
!bash
Ici cela vient du fait que man utilise la commande less pour afficher le contenu de l’aide.
Ainsi, cette exemple !bash fonctionne tout autant avec less.
Un dernier exemple avec la commande awk qui permet d’ouvrir un shell :
sudo awk 'BEGIN {system("/bin/bash")}'
Utiliser les chemins transversaux
Sudo, à travers son fichier de configuration sudoers permet d’affiner les autorisations.
Par exemple, vous pouvez restreindre l’exécution d’une commande à un chemin.
Prenons cet exemple où la commande nano et ls sont restreint au home de l’utilisateur démo.
demo ALL=/usr/bin/nano,/usr/bin/ls /home/demo/*
Si on tente d’accéder au home via sudo, cela fonctionne, mais si on tente d’accéder au /, uin message d’erreur indique que cela n’est pas autorisé.
Juste que là tout est normal.
Mais il est possible de contourner ces restrictions grâce aux chemins transversaux.
Par exemple, on peut lister le contenu de / comme ceci :
sudo ls /home/demo/../../
On peut alors exploiter cela, grâce à l’éditeur de texte pour modifier la configuration de sudoers et se donner plus de droit.
sudo nano /home/demo/../../etc/etc/sudoers.d/vim
Se faire passer pour sudo
Enfin un attaquant peut aussi installer un script se faisant passer pour sudo afin de récupérer le mot de passe utilisateur
L’idée est de remplacer l’exécution du binaire sudo par un script qui va se faire passer pour sudo, tout en récupérant le mot de passe saisie par l’utilisateur.
Vous avez un exemple sur cette page : Setting up a fake sudo
On peut par exemple créer un alias pour exécuter le script.
Conclusion
sudo a été conçu pour prévenir et limiter de l’utilisation de root.
Malheureusement de part la conception des systèmes Linux, il est assez difficile de sécuriser totalement son utilisation.
Lorsque vous donnez un accès à une commande via sudo, il faut être conscient que celle-ci peut potentiellement donner un accès shell.
La solution pour limiter ces problèmes est de configurer une surcouche MAC (Mandatory Access Control) comme Apparmor et SELinux.
Mais cela est compliqué et de plus, vous n’êtes pas certains de protéger à 100% le système.
En clair donc, il n’y a pas vraiment de solution miracle si ce n’est abandonné sudo.
Mais déjà en être conscient est un bon début.
A noter que les logs sudo par défaut n’aident pas beaucoup, car sudo ne log que l’exécution des commandes.
Ainsi, l’obtention du shell par les paramètres de la commande sera visible dans les journaux, par exemple :
Dec 15 11:05:35 : mak : TTY=pts/0 ; PWD=/home/mak ; USER=root ; TSID=0A ; COMMAND=/usr/bin/vi -c !bash
Si l’accès se fait depuis l’interface de la commande comme avec vim ou man, cela ne sera pas visible dans les logs de sudo.
Vous pouvez corriger cela en activant les journaux d’entrée et de sortie en ajoutant cela dans sudoers :
Defaults log_input, log_output
Ces nouveaux journaux s’enregistrent dans /var/log/sudo-io.
A partir de là, il est possible de détecter l’ouverture d’un shell et les commandes utilisées dans ce dernier.
Par exemple dans le fichier log, vous pouvez consulter les fichiers ouverts.
log.json donne encore plus d’informations.
Liens
- Sudo : comment utiliser le configurer sudoers sur Linux (Debian, Ubuntu, Mint …)
- Erreur “n’apparaît pas dans le fichier sudoers”
- sudo : quels sont les problèmes de sécurité
- 15 exemples utiles de Sudoers pour configurer sudo sur Linux
- Utilisateur et groupes Ubuntu : comment ajouter, supprimer
- Ubuntu : comment passer un utilisateur en administrateur
- Comment utiliser la commande su avec des exemples sur Linux
- Gérer les utilisateurs/groupes sur linux en ligne de commandes (adduser, addgroup, usermod, passwd, …)