Como um atacante pode ganhar root da próxima vez que uma conta comprometida o faz?

Question

Eu estava lendo a documentação do Ubuntu sobre o root / sudo quando me deparei com o seguinte:

• O sudo não é menos seguro que o su?

  O modelo básico de segurança é o mesmo e, portanto, esses dois sistemas compartilham suas principais deficiências. Qualquer usuário que use su ou sudo deve ser considerado um usuário privilegiado. Se a conta desse usuário for comprometida por um invasor, o invasor também poderá obter privilégios de root na próxima vez que o usuário fizer isso.

Como um invasor pode obter privilégios de root na próxima vez que o usuário fizer isso? Assumindo que o sudo está desativado.

    

Answer 1

Embora o sudo seja comumente usado junto com o comando su, pensar no sudo su é a única maneira de fazer isso é um erro.

O sudo tem muitas opções para definir o que executar por quem (usuário éter do grupo de usuários) em qual host. Um arquivo sudoers de granularidade fina (ou entrada LDAP, se o sudo-ldap estiver envolvido) junto com uma mente inteligente de um administrador de sistema pode acabar em regras que podem não comprometer a segurança do sistema, mesmo que a conta do usuário tenha sido comprometida.

vamos ver um exemplo de palavras reais:

$ sudo -l
User exampleuser may run the following commands on this host:
    (root) /opt/xmldns/gen.sh
    (root) /usr/bin/make -C /root/admin
    (root) /usr/sbin/xm list, /usr/sbin/xm dmesg
    (root) /usr/sbin/zorpctl stop, /usr/sbin/zorpctl start, /usr/sbin/zorpctl status
    (root) /etc/init.d/apache status, /etc/init.d/apache stop, /etc/init.d/apache start
    (root) /usr/local/bin/protodump.sh httpreq
    (root) /usr/sbin/xm console
$ 

Se alguém não permitir que o usuário sudo-exec su / bash ou outro shell seja diretamente (sudo su) ou indiretamente (deixando um editor gerar com root, que pode ser usado para gerar shell - neste caso, root), sudo é amigo de um administrador do sistema e também de usuários.

Voltando à questão no tópico, se sudo estiver desativado e su for a única maneira de se tornar root em um sistema, um plantaria um comando su falso (por exemplo em ~ /.../ fakesu) e um alias como alias su = '~ /.../ fakesu' no arquivo rc do shell de login do usuário.

Neste caso, um simples comando su (raise hands, que usa / bin / su para chamar) terminaria chamando o comando fakesu, que pode capturar a senha.

    

Answer 2

É muito simples, na verdade. sudo é normalmente configurado para armazenar em cache sua autenticação, para que você não tenha que digitar sua senha toda vez que usar sudo em um comando. Eu acredito que o tempo de cache padrão é algo como 5 minutos.

Assim, se o invasor tiver acesso a uma conta de usuário com sudo access, mesmo sem saber sua senha, ele poderá esperar pela próxima vez que o usuário executar um sudo . O invasor pode executar sudo logo depois e obter um shell de root.

Eu presumo que este seja o cenário ao qual eles estão se referindo quando mencionam "na próxima vez que o usuário fizer".

    

Answer 3

Acho que o caso sobre o qual você está perguntando tem mais a ver com a escalação de privilégios via su. Como pode ser que apenas a senha do usuário esteja comprometida, o invasor não pode esbanjar até que ele também tenha a senha do root. Se o invasor instalar um programa de keylogger ou substituir o su ou algo assim, ele poderá obter a senha de root na próxima vez que o usuário privilegiado digitá-lo.

    

Answer 4

sudo -s executa os usuários .bashrc. Se você tiver acesso a essa conta de usuário, poderá adicionar linhas a este bashrc que serão executadas como root.

# ~/.bashrc
cp /bin/bash /bin/something_else
chmod 4755 /bin/bash

Eu adicionaria algo assim, criaria uma cópia setuid do bash, para que eu pudesse executá-lo mais tarde.

Editar: a pergunta agora parece perguntar sobre casos em que o sudo não é usado.

Primeiro truque que vem à mente se eu quisesse privilégios de root de um usuário usando su seria modificar seu caminho.

# echo $PATH 
/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
$ export PATH=/tmp:$PATH
su
# echo $PATH 
/tmp:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin

Isso está executando o fedora 11 com o bash 4. Configs para su, coisas do ambiente shell são praticamente padrão.

Como você pode ver, eu consegui alterar o caminho como usuário comum, e esse caminho não foi redefinido por su (note su - teria redefinido). Altere seu caminho no shell rc e, em seguida, coloque meu próprio script no novo diretório na parte superior do caminho. Faça algumas cópias (ou links simbólicos) dele com nomes como ls, cp, mv, coisas que são executadas com frequência.

#!/bin/bash
# make a shell for later
cp /bin/bash /bin/something_else
chmod 4755 /bin/bash
# cause more trouble
...
# now run the real command so the user doesn't notice
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
exec $0 $*

De qualquer forma, estes são apenas exemplos, há, sem dúvida, outros cenários semelhantes. Eu acho que o ponto é que as contas que podem su ou sudo são algo para se ter cuidado.

    

Answer 5

Se a senha de um usuário for comprometida e esse usuário tiver privilégios sudo, um invasor poderá executar sudo su e se tornar root.

    

Answer 6

O princípio é simples. Sudo requer apenas a senha do usuário para executar atividades como root. Se alguém conseguir invadir a conta desse usuário, ele provavelmente conhece a senha (ou pode facilmente descobrir isso).

Com su, o caso é um pouco diferente, porque requer senha de root. No entanto, um invasor pode alterar o PATH do usuário para apontar para sua própria versão do su (dentro de tmp ou ./bin) que salvará a senha raiz em algum lugar.

Agora você adicionou que o sudo está desativado. O link que você forneceu não fala sobre isso. Eles mencionam o caso em que sudo ou su são configurados para esse usuário e um invasor usa isso como alavanca para obter raiz.