web-dev-qa-db-fra.com

Existe-t-il un moyen d'empêcher un utilisateur de créer des exécutables et de les exécuter?

Les attaques de ransomwares pourraient utiliser des exploits zero-day, mais souvent un attaquant trompera simplement un utilisateur crédule en exécutant un exécutable en téléchargeant et en cliquant.

Supposons que nous ayons un utilisateur naïf et que nous voulions le restreindre au chemin normal. Existe-t-il un moyen de les empêcher de créer un fichier avec des privilèges exécutables?

Ou, plus généralement, existe-t-il un moyen de créer une liste de contrôle d'accès et de définir que cet utilisateur ne peut exécuter que les fichiers de cette liste?

permissionssecurityexecutablerestricted-access
31
Dov

L'attaque spécifique dont vous avez exprimé votre inquiétude est:

souvent, un attaquant va simplement tromper un utilisateur crédule en exécutant un exécutable en téléchargeant et en cliquant.

Au moins dans le cas commun où le fichier est téléchargé dans un navigateur Web, cela devrait déjà être empêché dans Ubuntu par l'adhésion du navigateur à la politique Execute-Permission Bit Required . Les parties les plus directement pertinentes de cette politique sont:

  • Les applications, y compris les bureaux et les shells, ne doivent pas exécuter de code exécutable à partir de fichiers lorsqu'ils sont tous les deux:

    • sans le bit exécutable
    • situé dans le répertoire personnel d'un utilisateur ou dans un répertoire temporaire.
  • Les fichiers téléchargés à partir d'un navigateur Web, d'un client de messagerie, etc. ne doivent jamais être enregistrés comme exécutables.

Donc, si un utilisateur est invité à télécharger un programme dans un navigateur Web, le fait et tente d'exécuter le fichier en double-cliquant dessus, il ne s'exécutera pas. Cela s'applique même si le fichier téléchargé est un script Shell ou même un fichier .desktop. (Si vous vous êtes déjà demandé pourquoi . Fichiers de burea dans votre répertoire personnel doivent être marqués comme exécutables même s'ils ne sont pas des programmes vraiment, c'est pourquoi.)

Il est possible pour les utilisateurs de modifier ce comportement en modifiant la configuration. La plupart ne le feront pas, et alors que ceux qui le font probablement ne devraient pas, ce n'est pas vraiment ce dont vous devez vous inquiéter. La plus grande préoccupation est l'attaque plus complexe qui, je pense, vous inquiète déjà, dans laquelle une personne malveillante (ou un bot) demande à l'utilisateur de télécharger un fichier spécifique, marquez-le comme exécutable lui-même ( via leur navigateur de fichiers ou avec chmod ), puis exécutez-le.

Malheureusement, restreindre la capacité d'un utilisateur à définir le bit d'exécution sur un fichier ou à exécuter des fichiers autres que ceux de certaines listes blanches n'atténuerait pas sensiblement le problème. Certaines attaques fonctionneront déjà, et celles qui ne le sont pas pourraient être modifiées de manière triviale pour qu'elles le fassent. Le problème fondamental est que l'effet de l'exécution d'un fichier peut être atteint même si le fichier ne dispose pas d'autorisations exécutables .

Ceci est mieux illustré par l'exemple. Supposons que evil est un fichier du répertoire en cours qui, s'il dispose d'autorisations exécutables (chmod +x evil) et courir (./evil), ferait quelque chose de mal. Selon le type de programme, le même effet peut être obtenu par l'un des moyens suivants:

Aucun de ceux-ci, pas même le dernier, ne requiert que le fichier dispose d'autorisations exécutables ou même que l'utilisateur soit capable pour accorder au fichier des autorisations exécutables.

Mais les instructions malveillantes n'ont même pas besoin d'être aussi compliquées. Considérez cette commande non malveillante, qui est l'un des moyens officiellement recommandés pour installer ou mettre à jour NVM :

wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh | bash

La raison pour laquelle ce n'est pas malveillant est que NVM n'est pas un logiciel malveillant, mais si l'URL était plutôt le script de quelqu'un qui fait du mal lors de son exécution, cette commande téléchargerait et exécuterait le script. À aucun moment, aucun fichier ne devra recevoir d'autorisations exécutables. Télécharger et exécuter le code contenu dans un fichier malveillant avec une seule commande comme celle-ci est, je crois, une action assez courante que les attaquants trompent les utilisateurs.

Vous pourriez penser à essayer de restreindre les interprètes disponibles pour les utilisateurs. Mais il n'y a pas vraiment de moyen de le faire qui n'ait pas d'impact substantiel sur les tâches ordinaires que vous attendez vraisemblablement des utilisateurs. Si vous configurez un extrêmement environnement restreint dans lequel presque tout ce qu'un utilisateur penserait à faire sur un ordinateur est interdit, comme un kiosque qui n'exécute que quelques programmes, alors cela pourrait fournir une certaine mesure de protection significative. Mais cela ne semble pas être votre cas d'utilisation.

La réponse approximative à votre question est donc "non". La réponse la plus complète est que vous pourriez probablement réussir à empêcher les utilisateurs d'exécuter des fichiers à l'exception de ceux que vous fournissez sur une liste blanche. Mais c'est dans le sens technique strict de "exécuter", ce qui n'est pas nécessaire pour obtenir le plein effet de l'exécution de la plupart des programmes ou scripts. Pour éviter ça, vous pouvez essayer de réduire la liste blanche très petite, donc elle ne répertorie aucun interprète à l'exception de ceux qui peuvent être très restreints. Mais même si vous y parveniez, les utilisateurs ne pouvaient pas faire grand-chose, et si vous étiez si petit qu'ils ne pouvaient pas se blesser, ils ne pourraient probablement rien faire. (Voir Commentaire de Thomas Ward .)

Si vos utilisateurs peuvent se blesser, ils peuvent être trompés en se faisant du mal.

Vous pouvez être en mesure d'empêcher certains programmes spécifiques d'être utilisés ou de se comporter d'une manière susceptible d'être nuisible, et si vous examinez des modèles spécifiques que le ransomware a tendance à suivre, vous pourrez peut-être empêcher certains cas courants spécifiques. (Voir AppArmor .) Cela pourrait apporter une certaine valeur. Mais cela ne vous donnera rien de proche de la solution globale que vous espérez.

Quelles que soient les mesures techniques (le cas échéant) que vous finissez par prendre, votre meilleur pari est d'éduquer les utilisateurs. Cela inclut de leur dire de ne pas exécuter de commandes qu'ils ne comprennent pas et de ne pas utiliser les fichiers téléchargés dans des situations où ils ne pourraient pas expliquer pourquoi il est raisonnablement sûr de le faire. Mais cela inclut également des choses comme faire des sauvegardes, de sorte que si quelque chose ne va pas (à cause d'un malware ou autre), le mal causé sera le moins possible.

50
Eliah Kagan

[~ # ~] oui [~ # ~] *

Cela s'appelle un Shell restreint.

Vous pouvez utiliser /bin/rbash, qui est déjà disponible dans Ubuntu et combinez cela avec une variable PATH restreinte . rbash interdira l'exécution de tout ce qui n'est pas dans $PATH.

Ajoutez un utilisateur restreint:

Sudo adduser --Shell /bin/rbash res-user

Créez un nouveau répertoire, où nous pouvons lier les binaires, dans lequel l'utilisateur sera limité à:

Sudo mkdir /home/res-user/bin

Modifier le .profile fichier:

Sudo vim /home/res-user/.profile

if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then
        . "$HOME/.bashrc"
    fi
fi

readonly PATH=/home/res-user/bin
export PATH

Faire le .profile, bashrc et .bash_profile immuable:

Sudo chattr +i /home/res-user/.profile
Sudo chattr +i /home/res-user/.bashrc
Sudo chattr +i /home/res-user/.bash_profile

Maintenant, nous donnons à l'utilisateur la seule chose qu'il sera autorisé à faire, c'est-à-dire ouvrir Firefox:

Sudo ln -s /usr/lib/firefox/firefox /home/res-user/bin/

Maintenant, si nous nous connectons en tant que res-user nous ne pouvons ouvrir que Firefox:

res-user@localhost:~$ /home/res-user/bin/firefox --version
Mozilla Firefox 68.0.1

Nous ne pouvons pas facilement échapper à notre Shell restreint:

res-user@localhost:~$ export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
-su: PATH: readonly variable

L'utilisateur restreint ne peut pas rendre les fichiers exécutables ou les démarrer:

res-user@localhost:~$ chmod +x script.sh 
Command 'chmod' is available in '/bin/chmod'
res-user@localhost:~$ bash script.sh 
Command 'bash' is available in '/bin/bash'
The command could not be located because '/bin' is not included in the PATH environment variable.
bash: command not found

L'utilisateur restreint ne peut pas exécuter de scripts malveillants à partir d'Internet, car l'utilisateur ne peut pas exécuter les commandes nécessaires:

res-user@localhost:~$ wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh | bash
Command 'wget' is available in '/usr/bin/wget'
The command could not be located because '/usr/bin' is not included in the PATH environment variable.
wget: command not found
Command 'bash' is available in '/bin/bash'
The command could not be located because '/bin' is not included in the PATH environment variable.
bash: command not found

*Il y a façons de sortir des shells restreints , mais si votre utilisateur en est capable, alors ils pourraient ne pas être aussi crédules que vous le pensez.

11
Robert Riedl