Impedindo que malware cheire a senha do sudo

Costumo ouvir pessoas citando sudocomo uma das principais barreiras ao malware que infectam um computador Linux.

O argumento mais comum parece seguir as seguintes linhas: Privilégios de root são necessários para modificar a configuração do sistema e uma senha é necessária para obter privilégios de root; portanto, o malware não pode modificar a configuração do sistema sem solicitar uma senha.

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 precisa apenas aguardar a execução do usuário sudo.

Quais métodos existem para que os malwares obtenham privilégios de root quando o usuário executa sudoe como podemos proteger contra eles?

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

Depois que um malware obtém acesso à conta de um usuário, ele pode:

1. Crie um alias do bash (no shell atual e no ~/.bashrc) para um comando que falsifica o [sudo] password for $USER:prompt 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 nomeado sudoem ~/.bine modificar a PATHvariável para obter o mesmo efeito:PATH="$HOME/.bin:$PATH"

3. Pressione as teclas pressionadas no servidor X, preste atenção na palavra sudoe tente o texto entre as próximas duas Enterteclas pressionadas 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 infecta um shell que usa sudoe sudoarmazena em cache credenciais, o malware pode verificar continuamente se é possível sudosem 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 e 2. Use \/bin/sudo. O \ignora aliases e /bin/…ignora $PATH. Como alternativa, adicione um alias como: ssudo="\/bin/sudo"e sempre use em ssudovez de sudo. Parece improvável que um vírus seja inteligente o suficiente para remapear esse apelido.

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

5. Coloque timestamp_timeout=0dentro /etc/sudoers.

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

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

Em uma nota lateral, o sudo tem algumas contramedidas:

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

Não há proteção real.

O acesso protegido por senha ao sudo remonta a uma era anterior a ambientes complexos de shell com comandos executados por shims. Depois que a senha é enviada, 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 a intenção de acessar, criaria um calço útil para o bash, zsh e fish, etc. 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 outras maldades.

No momento em que o sudo recebeu uma senha satisfatória e você possui shells que executam comandos para obter um prompt, você está com problemas. Não há proteção, além de otimismo.

Outras respostas se concentraram em proteger a senha. Como agressor, eu não me preocuparia com isso. Eu focaria na duração após a senha ter sido fornecida, quando uma senha não for necessária. Esse é o momento mais arriscado, quando o invasor precisa fazer menos para comprometer completamente o sistema.

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

Eu costumava jogar com outros desenvolvedores (década de 1980), onde tentávamos escrever coisas que obtivessem o terminal que o outro desenvolvedor estava usando, para inserir comandos - este é essencialmente o mesmo problema. E facilitamos muito a incorporação de ferramentas que executariam a inserção de comandos sem rastreamento visível. :)

Não tenho certeza sobre nenhum método para usuários não autorizados obterem privilégios de root, mas sei algo que você pode fazer para tornar sudoum pouco menos perigoso , se quiser dizer isso. sudopermite 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

• Seção Usuário

  É aqui que você pode configurar grupos para os usuários para os quais especificará comandos. Permite configurar um grupo de operações;

  User_Alias  OPS = bob, jdoe 
  

  Isso cria o grupo OPS e coloca os usuários chamados bob e jdoe no grupo

• Cmnd_Alias

  Aqui nós especificamos conjuntos de comandos específicos. Você deve especificar o caminho completo e todas as opções de comando que deseja usar. Permite configurar os comandos do grupo Operações;

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

  Isso inclui os três comandos especificados no grupo de comandos OPSCMD.

• Especificação de privilégios de usuário

  É aqui que vamos usar os grupos que configuramos até agora;

  OPS  ALL=(root)  OPSCMD 
  

  A primeira coisa que especificamos são os usuários, aqui usamos o grupo OPS que configuramos. Então o ALL significa que se aplica a todos os servidores; isso é útil apenas se você ou executando o sudo em vários servidores, cada um usando o mesmo arquivo de configuração. Em seguida, especificamos o usuário no qual o grupo Operações executará os comandos especificados, pois nesse caso queremos que eles sejam executados como root. Por fim, especificamos os comandos que queremos que o grupo OPS possa executar, especificamente estamos usando o grupo OPSCMD que configuramos. Se você não deseja que eles digitem suas senhas cada vez que usaram o sudo, a especificação do comando seria NOPASSWD: OPSCMD.

Apenas reforce suas sudopolíticas tanto quanto você não confia em seus usuários :)

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

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

Primeiro de tudo, dê uma olhada no /etc/sudoersarquivo.

A sintaxe será o user MACHINE=COMMANDSformato.

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ê é quase igual a um usuário root. Se esse não for o caso e você tiver apenas alguns privilégios limitados, o invasor / malware poderá fazer apenas o mesmo que seu privilégio sudo.

Dicas que podem ajudá-lo:

1. Examine seu /etc/sudoersarquivo.
2. Execute um scanner de segurança como chkrootkit, rootkit hunter, scanner de exploração do servidor Config, snort etc.
3. Use o visudocomando para editar e modificar os privilégios do seu arquivo sudoers.
4. Execute os scanners novamente.

Referência: página de manual do Linux de sudoers e sudo man sudoers