Existe alguma maneira de impedir um usuário de criar executáveis ​​e executá-los?

Os ataques de ransomware podem usar explorações de dia zero, mas geralmente um invasor engana um usuário crédulo para executar um executável fazendo o download e clicando em.

Suponha que temos um usuário ingênuo e queremos restringi-lo ao caminho normal. Existe alguma maneira de impedi-los de criar um arquivo com privilégio executável?

Ou, de maneira mais geral, existe alguma maneira de criar uma lista de controle de acesso e definir que esse usuário possa executar apenas arquivos nessa lista?

O ataque específico sobre o qual você manifestou preocupação é:

geralmente um invasor engana um usuário crédulo para executar um executável fazendo o download e clicando em.

Pelo menos no caso comum em que o arquivo é baixado em um navegador da web, isso já deve ser evitado no Ubuntu pela aderência do navegador à política Execute-Permission Bit Required . As partes mais diretamente relevantes dessa política são:

• Os aplicativos, incluindo áreas de trabalho e shells, não devem executar código executável a partir de arquivos quando ambos:

  • sem o bit executável
  • localizado no diretório inicial ou no diretório temporário de um usuário.

• Os arquivos baixados de um navegador da Web, cliente de email etc. nunca devem ser salvos como executáveis.

Portanto, se um usuário é instruído a baixar um programa em um navegador da Web, o faz e tenta executar o arquivo clicando duas vezes nele, ele não será executado. Isso se aplica mesmo que o arquivo baixado seja um shell script ou mesmo um arquivo .desktop. (Se você já se perguntou por que os arquivos .desktop em seu diretório pessoal precisam ser marcados como executáveis, mesmo que não sejam realmente programas, é por isso.)

É possível que os usuários alterem esse comportamento através de alterações na configuração. A maioria não, e enquanto aqueles que provavelmente não deveriam, não é com isso que você deve se preocupar. A maior preocupação é o ataque mais complexo com o qual acho que você já está preocupado, no qual uma pessoa (ou bot) maliciosa instrui o usuário a baixar um arquivo específico, marcá-lo como executável (por meio do navegador de arquivos ou com chmod) e depois execute.

Infelizmente, restringir a capacidade de um usuário definir o bit de execução em um arquivo ou executar arquivos diferentes daqueles em alguma lista de permissões não atenuaria visivelmente o problema. Alguns ataques já funcionarão, e os que não o fizerem poderão ser modificados trivialmente para que funcionem. A questão fundamental é que o efeito de executar um arquivo pode ser alcançado mesmo se o arquivo não tiver permissões executáveis .

Isso é melhor ilustrado pelo exemplo. Suponha que evilseja um arquivo no diretório atual que, se recebesse permissões executáveis ​​( chmod +x evil) e run ( ./evil), faria algo errado. Dependendo do tipo de programa, o mesmo efeito pode ser alcançado por um dos seguintes:

• . ./evilou source ./evilexecuta os comandos no evil shell atualmente em execução .
• bash ./evilcorre evilem bash.
• python3 evilcorre evilem python3.
• perl evilcorre evilem perl.
• ... e, em geral, interpreter evilé executado evilno intérprete interpreter .
• Na maioria dos sistemas, /lib64/ld-linux-x86-64.so.2 ./evil executa o executável binário evil .

Nenhum deles, nem mesmo o último, exige que o arquivo tenha permissões executáveis ​​ou que o usuário possa conceder permissões executáveis ​​ao arquivo.

Mas as instruções maliciosas nem precisam ser tão complicadas. Considere este comando não malicioso , que é uma das maneiras oficialmente recomendadas para instalar ou atualizar o NVM :

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

A razão pela qual não é malicioso é que o NVM não é malware, mas se a URL fosse para o script de alguém que faz mal ao executar, esse comando faria o download e executaria o script. Em nenhum momento qualquer arquivo precisaria receber permissões executáveis. Baixar e executar o código contido em um arquivo malicioso com um único comando como este é, acredito, uma ação bastante comum que os invasores induzem os usuários a executarem.

Você pode tentar restringir quais intérpretes estão disponíveis para os usuários executarem. Mas não há realmente uma maneira de fazer isso que não afete substancialmente as tarefas comuns que você presumivelmente deseja que os usuários possam executar. Se você estiver configurando um ambiente extremamente restrito no qual quase tudo o que um usuário pensa em fazer no computador é proibido, como um quiosque que executa apenas alguns programas, isso pode fornecer uma certa proteção significativa. Mas não parece que esse é seu caso de uso.

Portanto, a resposta aproximada à sua pergunta é "Não". A resposta mais completa é que você provavelmente conseguirá impedir que os usuários executem arquivos, exceto aqueles que você fornece em uma lista de permissões. Mas isso é no sentido estrito e técnico de "executar", que não é necessário para obter o efeito total da execução da maioria dos programas ou scripts. Para evitar isso , você pode tentar tornar a lista de permissões muito pequena, para não listar intérpretes, exceto aqueles que podem ser altamente restritos. Mas mesmo se você conseguisse isso, os usuários não poderiam fazer muito e, se você o tornasse tão pequeno que não se machucasse, provavelmente não poderia fazer nada. (Veja o comentário de Thomas Ward .)

Se seus usuários podem se machucar, eles podem ser enganados.

Você pode impedir que programas específicos sejam usados ​​ou se comportem de maneiras que possam ser prejudiciais e, se você observar padrões específicos que o ransomware tende a seguir, poderá evitar alguns casos comuns específicos. (Consulte AppArmor .) Isso pode fornecer algum valor. Mas isso não lhe dará nada perto da solução abrangente que você espera.

Quaisquer que sejam as medidas técnicas (se houver) que você acaba adotando, sua melhor aposta é educar os usuários. Isso inclui dizer a eles para não executar comandos que eles não entendem e não usar arquivos baixados em situações em que não poderiam explicar por que é razoavelmente seguro fazê-lo. Mas também inclui coisas como fazer backups, de modo que, se algo der errado (devido a malware ou outro), o dano causado será o mínimo possível.

SIM ^*

É chamado de shell restrito.

Você pode usar o /bin/rbashque já está disponível no Ubuntu e combiná-lo com uma variável PATH restrita . O rbashproibirá a execução de qualquer coisa que não esteja presente $PATH.

Adicione um usuário restrito:

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

Crie um novo diretório, no qual possamos vincular binários, ao qual o usuário será limitado a:

sudo mkdir /home/res-user/bin

Modifique o .profilearquivo:

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

Faça o .profile, bashrce .bash_profileimutável:

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

Agora, damos ao usuário a única coisa que ele poderá fazer, ou seja, abra o Firefox:

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

Agora, se fizermos login res-user, podemos apenas abrir o Firefox:

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

Não podemos escapar facilmente de nossa concha restrita:

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

O usuário restrito não pode tornar os arquivos executáveis ​​ou iniciá-los:

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

O usuário restrito não pode executar scripts maliciosos da Internet, porque o usuário não pode executar os comandos necessários:

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

^* _{Existem maneiras de romper conchas restritas , mas se o usuário for capaz disso, elas podem não ser tão ingênuas quanto você pensa.}