Empêcher les logiciels malveillants de renifler le mot de passe sudo

J'entends souvent des gens citer sudocomme l'un des principaux obstacles aux logiciels malveillants infectant un ordinateur Linux.

L'argument le plus répandu semble aller dans le sens de: les privilèges root sont requis pour modifier la configuration du système, et un mot de passe est requis pour obtenir les privilèges root, de sorte que les logiciels malveillants ne peuvent pas modifier la configuration du système sans demander un mot de passe.

Mais il me semble que par défaut sur la plupart des systèmes, une fois que le logiciel malveillant a infecté un compte administrateur, l'escalade de privilèges est triviale - le logiciel malveillant n'a qu'à attendre que l'utilisateur s'exécute sudo.

Quelles méthodes existent pour que les logiciels malveillants obtiennent les privilèges root lorsque l'utilisateur s'exécute sudo, et comment pouvons-nous nous protéger contre eux?

Modifier: je suis particulièrement intéressé par la protection contre un compte administrateur compromis; c'est-à-dire un compte disposant de tous les privilèges root avec sudo(par exemple le compte de l'utilisateur sur un système de bureau typique).

Une fois qu'un logiciel malveillant a accédé au compte d'un utilisateur, il peut:

1. Créez un alias bash (dans le shell actuel et dans ~/.bashrc) à une commande qui simule l' [sudo] password for $USER:invite et vole le mot de passe de l'utilisateur.

alias sudo='echo -n "[sudo] password for $USER: " && \
            read -r password && \
            echo "$password" >/tmp/sudo-password'

2. De même, il peut placer un exécutable nommé sudodans ~/.binet modifier la PATHvariable pour obtenir le même effet:PATH="$HOME/.bin:$PATH"

3. Saisissez les pressions sur le serveur X, recherchez le mot sudo, puis essayez le texte entre les deux Entertouches suivantes comme mot de passe.

4. Une chose similaire peut être faite dans n'importe quel environnement (la console, Wayland , X) en utilisant par exemple $LD_PRELOAD.

5. Si un logiciel malveillant infecte un shell qui utilise sudoet sudomet en cache les informations d'identification, le logiciel malveillant peut continuellement vérifier s'il est possible sudosans mot de passe:

while : ; do
    echo | sudo -S echo "test" &>/dev/null && break
    sleep 10
done
sudo echo "We now have root access"

La prévention:

1 & 2. Utilisez \/bin/sudo. Le \ne tient pas compte des alias et /bin/…ignores $PATH. Vous pouvez également ajouter un alias tel que:, ssudo="\/bin/sudo"et toujours utiliser à la ssudoplace de sudo. Il semble peu probable qu'un virus soit suffisamment intelligent pour remapper cet alias.

3. Évitez de taper votre mot de passe lorsque vous utilisez X11. Utilisez plutôt une console virtuelle ou Weston .

5. Mettre timestamp_timeout=0en /etc/sudoers.

La seule façon d'éliminer complètement le risque de sudoreniflement du mot de passe semble être de l'éviter complètement. Au lieu de cela, connectez-vous en tant que root à une console virtuelle.

Selon Alexander Peslyak : "la seule utilisation sûre de su [et sudo] est de passer d'un compte plus privilégié à un compte moins privilégié ..."

Soit dit en passant, sudo a quelques contre-mesures:

• sudolit à la ttyplace de stdin, donc alias sudo='tee -a /tmp/sudo-password | sudo'interrompt sudo(mais capture le mot de passe).

Il n'y a pas de réelle protection.

L'accès protégé par mot de passe à sudo remonte à une époque antérieure aux environnements de shell complexes avec des commandes exécutées par des shims. Une fois le mot de passe soumis, il existe une fenêtre d'opportunité dans laquelle un shim peut exécuter des commandes via sudo, sans aucune notification et avec un contrôle complet du système.

Si j'avais l'intention d'accéder, je créerais un shim utile pour bash et zsh et fish, etc. Je surveillerais les commandes exécutées. Peu de temps après qu'un sudo soit revenu avec un état de zéro, je commencerais à émettre "sudo chmod + s / bin / sh" ou d'autres méchancetés.

Au moment où sudo a reçu un mot de passe satisfaisant et que vous avez des shells qui exécutent des commandes pour obtenir une invite, vous êtes potentiellement en difficulté. Il n'y a pas d'autre protection que l'optimisme.

D'autres réponses se sont concentrées sur la protection du mot de passe. En tant qu'agresseur, je ne m'en inquiéterais pas. Je me concentrerais sur la durée après que le mot de passe a été donné, quand un mot de passe n'est pas nécessaire. C'est le moment le plus risqué, lorsque l'attaquant doit faire le moins pour compromettre complètement le système.

Protéger contre cela? Vous devez protéger vos fichiers RC. Inspectez les cales ou autres commandes utilisées dans les invites de ligne de commande. Recherchez les co-processus connectés au shell et les outils utilisés pour maintenir l'environnement du shell. Les principales défenses seraient les outils d'intrusion de l'hôte, mais c'est après coup. Empêcher les attaques? N'utiliser que des shells simples sans configuration automatisée complexe et invites actives - c'est l'environnement pour lequel sudo a été développé.

J'avais l'habitude de jouer à des jeux avec d'autres développeurs (années 80) où nous essayions d'écrire des choses qui obtiendraient le terminal que l'autre développeur utilisait, pour insérer des commandes - c'est essentiellement le même problème. Et nous avons facilité l'intégration d'outils qui permettraient l'insertion de commandes sans trace visible. :)

Je ne suis pas sûr des méthodes permettant aux utilisateurs non autorisés d'obtenir des privilèges root, mais je sais quelque chose que vous pouvez faire pour rendre sudoun peu moins dangereux , si vous voulez dire cela. sudovous permet de configurer des autorisations granulaires, afin de définir des groupes d'utilisateurs avec des privilèges spécifiques et des commandes spécifiques que certains utilisateurs peuvent exécuter.

SUDO - CONTRÔLE GRANULAIRE

• Section utilisateur

  C'est là que vous pouvez configurer des groupes pour les utilisateurs pour lesquels vous spécifierez des commandes. Permet de configurer un groupe d'opérations;

  User_Alias  OPS = bob, jdoe 
  

  Cela crée le groupe OPS et place les utilisateurs nommés bob et jdoe dans le groupe

• Cmnd_Alias

  Ici, nous spécifions des jeux de commandes spécifiques. Vous devez spécifier le chemin d'accès complet et toutes les options de commande que vous souhaitez utiliser. Permet de configurer les commandes du groupe Opérations;

  Cmnd_Alias OPSCMD = /admin/bin/srvbkup, /admin/bin/test 
  

  Cela ajoute les trois commandes spécifiées au groupe de commandes OPSCMD.

• Spécification de privilège utilisateur

  C'est là que nous utiliserons les groupes que nous avons configurés jusqu'à présent;

  OPS  ALL=(root)  OPSCMD 
  

  La première chose que nous spécifions sont les utilisateurs, ici nous utilisons le groupe OPS que nous avons configuré. Ensuite, ALL signifie qu'il s'applique à tous les serveurs, cela n'est utile que si vous ou exécutez sudo sur plusieurs serveurs utilisant chacun le même fichier de configuration. Ensuite, nous spécifions l'utilisateur sous lequel le groupe Opérations exécutera les commandes spécifiées, dans ce cas, nous voulons qu'ils s'exécutent en tant que root. Enfin, nous spécifions les commandes que nous voulons que le groupe OPS puisse exécuter, en particulier nous utilisons le groupe OPSCMD que nous avons configuré. Si vous ne vouliez pas qu'ils entrent leur mot de passe à chaque fois qu'ils utilisent sudo, la spécification de commande serait plutôt NOPASSWD: OPSCMD.

Renforcez vos sudopolitiques autant que vous ne faites pas confiance à vos utilisateurs :)

Si vous êtes intéressé par un système qui, selon vous, pourrait être compromis, exécutez "Rootkit" et utilisez "Tripwire" pour vérifier l'intégrité du système de fichiers.

Je vous conseillerais également de durcir les privilèges sudo, comme si vous n'aviez pas besoin que tous les utilisateurs aient accès à toutes les commandes root plutôt que de donner accès à des commandes spécifiques via SUDO.

Jetez d'abord un coup d'oeil au /etc/sudoersdossier.

La syntaxe sera user MACHINE=COMMANDSformatée.

Par exemple, l'utilisateur root aura root ALL=(ALL) ALL Cela signifie que l'utilisateur root peut exécuter n'importe quelle commande (toutes) n'importe où.

Si votre entrée a également, ALL=(ALL)vous êtes presque égal à un utilisateur root. Si ce n'est pas le cas et que vous ne disposez que de certains privilèges limités, l'attaquant / programme malveillant ne peut faire autant que votre privilège sudo.

Conseils qui peuvent vous aider:

1. Examinez votre /etc/sudoersdossier.
2. Exécutez un scanner de sécurité comme chkrootkit, rootkit hunter, Config server Exploit scanner, snort etc.
3. Utilisez la visudocommande pour éditer et modifier les privilèges de votre fichier sudoers.
4. Exécutez à nouveau les scanners.

Référence: page de manuel Linux de sudoers et sudo man sudoers