sudo : quels sont les problèmes de sécurité

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.

sudo : quels sont les problèmes de sécurité

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'

Problème de sécurité de sudo : ouvrir un shell en root

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

L'élévation de privilèges et accès root avec sudo

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.