¿Hay alguna forma de evitar que un usuario cree ejecutables y los ejecute?

Los ataques de ransomware podrían usar exploits de día cero, pero a menudo un atacante engañará a un usuario crédulo para que ejecute un ejecutable al descargar y hacer clic.

Supongamos que tenemos un usuario ingenuo y queremos restringirlo a la ruta normal. ¿Hay alguna forma de restringirlos para que no creen un archivo con privilegio ejecutable?

O, de manera más general, ¿hay alguna forma de crear una lista de control de acceso y definir que este usuario solo puede ejecutar archivos en esta lista?

El ataque específico por el que has expresado preocupación es:

a menudo, un atacante engañará a un usuario crédulo para que ejecute un ejecutable descargando y haciendo clic.

Al menos en el caso común en el que el archivo se descarga en un navegador web, esto ya debería evitarse en Ubuntu por la adhesión del navegador a la política de bit de permiso de ejecución requerido . Las partes más directamente relevantes de esa política son:

• Las aplicaciones, incluidos los escritorios y los shells, no deben ejecutar código ejecutable desde archivos cuando ambos son:

  • sin el bit ejecutable
  • ubicado en el directorio de inicio de un usuario o directorio temporal.

• Los archivos descargados de un navegador web, cliente de correo, etc. nunca deben guardarse como ejecutables.

Entonces, si se le dice a un usuario que descargue un programa en un navegador web, lo hace e intenta ejecutar el archivo haciendo doble clic en él, no se ejecutará. Esto se aplica incluso si el archivo descargado es un script de shell o incluso un archivo .desktop. (Si alguna vez se ha preguntado por qué los archivos .desktop en su directorio de inicio deben marcarse como ejecutables aunque en realidad no sean programas, es por eso).

Es posible que los usuarios alteren este comportamiento a través de cambios de configuración. La mayoría no lo hará, y aunque los que lo hacen probablemente no deberían, eso no es realmente de lo que deba preocuparse. La mayor preocupación es el ataque más complejo que creo que ya le preocupa, en el que una persona maliciosa (o bot) le indica al usuario que descargue un archivo específico, lo marque como ejecutable (a través de su buscador de archivos o con chmod), y entonces ejecútalo.

Desafortunadamente, restringir la capacidad de un usuario para establecer el bit de ejecución en un archivo o para ejecutar archivos que no sean los de alguna lista blanca no mitigaría notablemente el problema. Algunos ataques ya funcionarán, y los que no pueden modificarse trivialmente para que lo hagan. El problema fundamental es que el efecto de ejecutar un archivo se puede lograr incluso si el archivo no tiene permisos ejecutables .

Esto se ilustra mejor con un ejemplo. Supongamos que evilhay un archivo en el directorio actual que, si se le otorgan permisos ejecutables ( chmod +x evil) y run ( ./evil), haría algo malo. Dependiendo de qué tipo de programa sea, uno de los siguientes puede lograr el mismo efecto:

• . ./evilo source ./evilejecuta los comandos evil en el shell actualmente en ejecución .
• bash ./evilcorre evilen bash.
• python3 evilcorre evilen python3.
• perl evilcorre evilen perl.
• ... y en general, interpreter evilcorre evilen el intérprete interpreter .
• En la mayoría de los sistemas, /lib64/ld-linux-x86-64.so.2 ./evil ejecuta el ejecutable binario evil .

Ninguno de ellos, ni siquiera el último, requiere que el archivo tenga permisos ejecutables o que el usuario pueda otorgarle permisos ejecutables.

Pero las instrucciones maliciosas ni siquiera tienen que ser tan complicadas. Considere este comando no malicioso , que es una de las formas recomendadas oficialmente para instalar o actualizar NVM :

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

La razón por la que no es malicioso es que NVM no es malware, pero si la URL fuera en lugar del script de alguien que hace mal cuando se ejecuta, ese comando descargaría y ejecutaría el script. En ningún momento ningún archivo necesitaría permisos ejecutables. Descargar y ejecutar el código contenido en un archivo malicioso con un solo comando como este es, creo, una acción bastante común que los atacantes engañan a los usuarios para que tomen.

Puede pensar en restringir qué intérpretes están disponibles para que los usuarios los ejecuten. Pero no hay realmente una manera de hacer esto que no afecte sustancialmente las tareas ordinarias que presumiblemente desea que los usuarios puedan hacer. Si está configurando un entorno extremadamente restringido en el que se prohíbe casi todo lo que un usuario pensaría hacer en una computadora, como un quiosco que solo ejecuta un par de programas, entonces esto podría proporcionar alguna medida de protección significativa. Pero no parece que sea su caso de uso.

Entonces, la respuesta aproximada a su pregunta es "No". La respuesta más completa es que probablemente podría evitar que los usuarios ejecuten cualquier archivo, excepto los que proporciona en una lista blanca. Pero eso es en el sentido estricto y técnico de "ejecutar", que no es necesario para lograr el efecto completo de ejecutar la mayoría de los programas o scripts. Para evitar que , se podría tratar de hacer la lista blanca muy pequeña, por lo que no incluyó ningún intérpretes excepto aquellos que podrían ser muy restringidas. Pero incluso si lograste eso, los usuarios no podrían hacer mucho, y si lo hiciste tan pequeño que no podrían lastimarse, probablemente no podrían hacer nada. (Ver el comentario de Thomas Ward ).

Si sus usuarios pueden lastimarse a sí mismos, pueden ser engañados para lastimarse a sí mismos.

Es posible que pueda restringir el uso de programas específicos o comportarse de otra manera de una manera que pueda ser dañina, y si observa patrones específicos que el ransomware tiende a seguir, puede evitar algunos casos comunes específicos. (Ver AppArmor .) Eso podría proporcionar algún valor. Pero no le dará nada parecido a la solución integral que espera.

Cualesquiera que sean las medidas técnicas (si las hay) que termine tomando, su mejor opción es educar a los usuarios. Esto incluye decirles que no ejecuten comandos que no entienden y que no usen los archivos descargados en situaciones en las que no podrían explicar por qué es razonablemente seguro hacerlo. Pero también incluye cosas como hacer copias de seguridad, de modo que si algo sale mal (debido a malware o no), el daño causado será lo menos posible.

SÍ ^*

Se llama un shell restringido.

Puede usar /bin/rbash, que ya está disponible en Ubuntu y combinarlo con una variable PATH restringida . La rbashvoluntad prohibirá la ejecución de cualquier cosa que no esté dentro $PATH.

Agregar un usuario restringido:

sudo adduser --shell /bin/rbash res-user

Cree un nuevo directorio, en el que podamos vincular binarios, en el que el usuario estará limitado a:

sudo mkdir /home/res-user/bin

Modificar el .profilearchivo:

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

Hacer el .profile, bashrce .bash_profileinmutable:

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

Ahora le damos al usuario lo único que se le permitirá hacer, es decir, abrir Firefox:

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

Ahora, si iniciamos sesión ya res-userque solo podemos abrir Firefox:

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

No podemos escapar fácilmente de nuestro shell restringido:

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

El usuario restringido no puede hacer que los archivos sean ejecutables o iniciarlos:

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

El usuario restringido no puede ejecutar scripts malvados desde Internet, porque el usuario no puede ejecutar los comandos necesarios:

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

^* _{Hay formas de salir de los caparazones restringidos , pero si su usuario es capaz de eso, es posible que no sean tan crédulos como cree.}