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 ne fera que tromper 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?

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

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 courant où le fichier est téléchargé dans un navigateur Web, cela devrait déjà être évité 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 les fichiers .desktop dans votre répertoire personnel doivent être marqués comme exécutables même s'ils ne sont pas vraiment des programmes, 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, de le marquer comme exécutable lui-même (via son navigateur de fichiers ou avec chmod), et puis lancez-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 obtenu même si le fichier n'a pas d'autorisations exécutables .

Ceci est mieux illustré par l'exemple. Supposons qu'il y evilait un fichier dans le répertoire courant qui, s'il recevait les autorisations exécutables ( chmod +x evil) et run ( ./evil), ferait quelque chose de mal. Selon le type de programme, le même effet peut être obtenu par l'un des moyens suivants:

• . ./evilou source ./evilexécute les commandes evil dans le shell en cours d'exécution .
• bash ./evilfonctionne evilen bash.
• python3 evilfonctionne evilen python3.
• perl evilfonctionne evilen perl.
• ... et en général, interpreter evils'exécute evildans l' interprète interpreter .
• Sur la plupart des systèmes, /lib64/ld-linux-x86-64.so.2 ./evil exécute l'exécutable binaire evil .

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 en mesure d'accorder des autorisations exécutables au fichier.

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 être autorisé à être exécuté. 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 incitent les utilisateurs à prendre.

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 environnement extrêmement 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, cela pourrait fournir une certaine 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 cela , vous pouvez essayer de rendre la liste blanche très petite, de sorte qu'elle ne répertorie aucun interprète, à l'exception de ceux qui pourraient ê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 le 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.

OUI ^*

Cela s'appelle un shell restreint.

Vous pouvez utiliser /bin/rbashce qui est déjà disponible dans Ubuntu et le combiner avec une variable PATH restreinte . La rbashloi interdira l'exécution de tout ce qui ne se trouve pas $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

Modifiez le .profilefichier:

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

Faites le .profile, bashrcet .bash_profileimmuable:

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, res-usernous 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 coquille restreinte:

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 existe des moyens de sortir des obus restreints , mais si votre utilisateur en est capable, ils pourraient ne pas être aussi crédules que vous le pensez.}