Evitar que malwares cheirem a senha do sudo

Question

Muitas vezes ouço as pessoas citando sudo como uma das principais barreiras ao malware que infecta um computador Linux.

O argumento mais comum parece seguir os seguintes passos: privilégios de raiz são necessários para modificar a configuração do sistema, e uma senha é necessária para obter privilégios de root, assim o malware não pode modificar a configuração do sistema sem solicitar uma senha. p>

Mas parece-me que, por padrão, na maioria dos sistemas, uma vez que o malware infectou uma conta de administrador, a escalação de privilégios é trivial - o malware só precisa esperar que o usuário execute sudo .

Quais métodos existem para o malware obter privilégios de root quando o usuário executa sudo e como podemos protegê-los?

Editar: estou especificamente interessado em proteger contra uma conta de administrador comprometida; isto é, uma conta que tenha privilégios totais de root com sudo (por exemplo, a conta do usuário em um sistema típico de desktop).

    

Answer 1

Quando um malware acessa a conta de um usuário, ele pode:

1. Crie um alias bash (no shell atual e em ~/.bashrc ) para um comando que falsifica o prompt [sudo] password for $USER: e rouba a senha do usuário.

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

2. Da mesma forma, ele pode colocar um executável chamado sudo in ~/.bin e modificar a variável PATH para obter o mesmo efeito: PATH="$HOME/.bin:$PATH"

3. A tecla Catch pressiona o servidor X, observa a palavra sudo e, em seguida, tenta o texto entre as duas próximas teclas Enter como senha.

4. Uma coisa semelhante pode ser feita em qualquer ambiente (o console, Wayland , X) usando por exemplo $LD_PRELOAD .

5. Se o malware infectar um shell que usa sudo e sudo armazenar em cache as credenciais, o malware poderá verificar continuamente se é possível sudo sem uma senha:

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

Prevenção:

1 & 2. Use \/bin/sudo . O \ ignora os aliases e /bin/… ignora $PATH . Como alternativa, adicione um alias como: ssudo="\/bin/sudo" e use sempre ssudo em vez de sudo . Parece improvável que um vírus seja esperto o suficiente para fazer o remapeamento desse pseudônimo.

3. Evite digitar sua senha ao usar o X11. Em vez disso, use um console virtual ou Weston .

5. Defina timestamp_timeout=0 em /etc/sudoers .

A única maneira de eliminar completamente a chance de a senha sudo ser detectada parece ser evitá-la completamente. Em vez disso, faça login como root em um console virtual.

De acordo com Alexander Peslyak : "o único uso seguro para o su [ e sudo] é mudar de uma conta mais privilegiada para uma menos privilegiada… "

Em uma nota lateral, o sudo tem algumas contramedidas:

• sudo lê tty em vez de stdin , então alias sudo='tee -a /tmp/sudo-password | sudo' quebra sudo (mas captura a senha).

Answer 2

Não há proteção real.

O acesso protegido por senha ao sudo retorna a uma era anterior a ambientes complexos de shell com comandos executados por shims. Uma vez que a senha foi submetida, há uma janela de oportunidade na qual um shim pode executar comandos via sudo, sem qualquer notificação, e com controle total do sistema.

Se eu tivesse intenção de acessar, criaria um shim útil para bash e zsh e fish, etc. Eu monitoraria os comandos executados. Logo após um sudo retornar com um status zero, eu começaria a emitir "sudo chmod + s / bin / sh" ou outros mal-intencionados.

No momento em que o sudo recebe uma senha satisfatória, e você tem shells que executam comandos para obter um prompt, você está potencialmente em apuros. Não há proteção, além do otimismo.

Outras respostas se concentraram em proteger a senha. Como agressor, eu não me preocuparia com isso. Eu me concentraria na duração após a senha ter sido dada, quando uma senha não é necessária. Esse é o período mais arriscado, quando o invasor precisa fazer o mínimo para comprometer completamente o sistema.

Protegendo-se disso? Você teria que proteger seus arquivos RC. Inspecione quaisquer calços ou outros comandos usados em prompts de linha de comando. Procure por co-processos conectados ao shell e ferramentas usadas para manter o ambiente do shell. As defesas principais seriam ferramentas de invasão de host, mas isso é depois do fato. Prevenindo ataques? Apenas usando shells simples sem configuração automatizada complexa e prompts ativos - esse é o ambiente para o qual o sudo foi desenvolvido.

Eu costumava jogar jogos com outros devs (1980's) onde nós tentávamos escrever coisas que pegariam o terminal que o outro dev estava usando, para inserir comandos - este é essencialmente o mesmo problema. E facilitamos a incorporação de ferramentas que fazem a inserção de comandos sem rastreio visível. :)

    

Answer 3

Não tenho certeza sobre quaisquer métodos para usuários não autorizados obterem privilégios de root, mas sei que você pode fazer algo para tornar sudo a menos perigoso , se quiser dizer isso. sudo permite configurar permissões granulares, para definir grupos de usuários com privilégios específicos e comandos específicos que determinados usuários podem executar.

SUDO - CONTROLE GRANULAR

• User Section

  This where you can setup groups for the users you will specify commands for. Lets setup an Operations group;

  User_Alias  OPS = bob, jdoe 
  

  This creates the OPS group and puts the users named bob and jdoe into the group

• Cmnd_Alias

  Here we specify specific command sets. You must specify the full path and any command options you want used. Lets setup the Operations group commands;

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

  This adds the three specified commands to the command group OPSCMD.

• User Privilege Specification

  This is where we will use the groups we have setup so far;

  OPS  ALL=(root)  OPSCMD 
  

  First thing we specify are the users, here we use the OPS group we setup. Then the ALL means that it applies to all servers, this is useful only if you or running sudo over multiple servers each using the same configuration file. Next we specify the user that the Operations group will run the specified commands as, in this case we want them to run as root. Lastly we specify the commands that we want the OPS group to be able to run, specifically we are using OPSCMD group we setup. If you did not want them to enter their password each time they used sudo, then the command specification would rather be NOPASSWD: OPSCMD.

Apenas endureça as políticas de sudo da mesma forma que não confia em seus usuários :)

    

Answer 4

Se você estiver interessado em um sistema que acredita estar comprometido, execute o "Rootkit" e use o "Tripwire" para verificar a integridade do sistema de arquivos.

Também aconselharia você a endurecer os privilégios sudo, como se você não precisasse que todos os usuários tivessem acesso a todos os comandos root, em vez de dar acesso a comandos específicos através do SUDO.

    

Answer 5

Antes de tudo, dê uma olhada no arquivo /etc/sudoers .

A sintaxe será user MACHINE=COMMANDS format.

Por exemplo, o usuário root terá root ALL=(ALL) ALL Isso significa que o usuário root pode executar qualquer (todos) comandos em qualquer lugar.

Se a sua entrada também tiver ALL=(ALL) , você será quase igual a um usuário raiz. Se esse não for o caso e você tiver apenas alguns privilégios limitados, o invasor / malware poderá fazer o máximo que o seu privilégio sudo puder fazer.

Dicas que podem ajudar você:

1. Examine seu arquivo /etc/sudoers .
2. Execute um verificador de segurança como o chkrootkit, o rootkit hunter, o servidor de configuração Exploit scanner, snort etc.
3. Use o comando visudo para editar e modificar os privilégios de seu arquivo sudoers.
4. Execute os scanners novamente.

Referência: man page do Linux de sudoers e sudo man sudoers