Demonstração de vulnerabilidade no Ubuntu 9.04

Para uma aula sobre segurança de TI, quero demonstrar a escalação de privilégios para os alunos. Para fazer isso, examinei a exploit/linux/locallista no Metasploit Framework, encontrando (entre outros) a exploit/linux/local/sock_sendpagepartir de agosto de 2009.

Eu configurei uma VM com o Ubuntu Server 9.04 de 32 bits ( http://old-releases.ubuntu.com/releases/9.04/ubuntu-9.04-server-amd64.iso ) a partir de abril de 2009. uname -rme fornece 2.6.28-11-generic. De acordo com a descrição da exploração

Acredita-se que todas as versões do Linux 2.4 / 2.6 desde maio de 2001 sejam afetadas: 2.4.4 até 2.4.37.4 inclusive; 2.6.0 até 2.6.30.4 inclusive

Portanto, parece que o servidor Ubuntu que eu configurei deve ser adequado para demonstração. No entanto, não consegui fazê-lo funcionar.

Adicionei um usuário (regular) no servidor e o acesso SSH funciona. No Metasploit Framework, eu posso criar uma sessão SSH usando auxiliary/scanner/ssh/ssh_login. No entanto, quando executo a exploração, recebo

[*] Writing exploit executable to /tmp/mlcpzP6t (4069 bytes)

[*] Exploit completed, but no session was created.

Não recebo mais informações, nem mesmo quando definido DEBUG_EXPLOITcomo verdadeiro. /tmpé escrito, também de dentro da sessão SSH do Metasploit:

$ sessions -c "touch /tmp/test.txt"
[*] Running 'touch /tmp/test.txt' on shell session 1 ([redacted])

$ sessions -c "ls -l /tmp"
[*] Running 'ls -l /tmp' on shell session 1 ([redacted])

total 0

-rw-r--r-- 1 [redacted] [redacted] 0 2016-03-28 09:44 test.txt

Também tentei definir WriteableDiro diretório inicial do usuário no servidor, mas sem nenhuma alteração. O que estou perdendo aqui? Esta versão do servidor Ubuntu (que eu deliberadamente não atualizei!) Não é vulnerável?

A versão 9.04 foi suportada até 23 de outubro de 2010. A vulnerabilidade encontrada foi relatada em agosto de 2009. Parece razoável que, como a versão ainda era atual e com suporte no momento, a ISO foi corrigida e o que você baixou foi uma versão que é não é mais vulnerável.

Além disso, você parece ter demonstrado muito bem que não é vulnerável. Afinal, você tentou a exploração e parece que falhou.

Por que você não tenta uma nova exploração? Algo como o CVE-2013-2094, que também deve afetar o Ubuntu , por exemplo.

Isso não responde à sua consulta específica, mas oferece mais opções de esc priv para mostrar aos seus alunos ...

Você também pode considerar as duas configurações erradas de administrador a seguir que podem levar à priv esc on 'nix (existem muitas outras maneiras de configurar erroneamente uma caixa' nix que poderia permitir a priv esc; portanto, considere isso um apetite) ....

1. binários suid e guid pertencentes ao grupo raiz / raiz ( find / -uid 0 -perm -4000 -type f 2>/dev/nulle find / -uid 0 -perm -2000 -type f 2>/dev/null) e ver se eles são graváveis ​​no mundo para permitir que usuários com poucos privilégios os alterem; a pasta em que eles existem é gravável pelo usuário com pouca privacidade - para possível injeção no caminho da biblioteca. E as bibliotecas que elas usam - são as que podem ser alteradas: verifique os valores de qualquer cabeçalho DT_RPATHe DT_RUNPATHELF nos binários usando um dos seguintes comandos:

   • objdump -x ...
   • readelf -a ...
   • scanelf (do PaX)
   • elfdump (do sol)
   • readelf -a binary | grep PATH

2. sudoers falhas

   • NOPASSWD - Um invasor local pode usar esse acesso para aumentar seus privilégios no sistema operacional quando o usuário esquecer de bloquear a tela

   • Executáveis ​​ausentes em sudoers - alguns executáveis ​​no /etc/sudoersarquivo não existem. Se os executáveis ​​forem criados, eles poderão ser executados via sudo como root, o que permitiria a escalação de privilégios.

   • Entradas de Sudoadores Órfãos - O /etc/sudoersarquivo pode conter várias entradas órfãs para as quais não há uma conta correspondente configurada no /etc/passwdarquivo. Se um usuário fosse criado com um dos nomes órfãos, ele forneceria ao usuário um meio de escalar privilégios para o acesso root completo.

   • Alguns programas não devem estar no sudo - like vi, use :eou Ctrl o e use :wpara acessar /etc/shadow.

   • Comando incorretamente pensado / incorreto usado no arquivo sudoers - geralmente vejo httpdem sudoers -, então tente como um usuário privado com acesso sudo para executar apenas esse comando ( sudo -lou sudo -llmostrará o que um usuário pode fazer): sudo /usr/bin/httpd -t /etc/shadowe observe o erro.

   • as permissões de arquivo dos comandos e arquivos mencionados nos sudoers são fracas - veja meu parágrafo anterior sobre binários suid e guid de propriedade de root