Demonstração de vulnerabilidades no Ubuntu 9.04

Question

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

Eu configurei uma VM com o Ubuntu Server 9.04 de 32 bits ( link ) de abril de 2009. uname -r me dá 2.6.28-11-generic . De acordo com a descrição da exploração

All Linux 2.4/2.6 versions since May 2001 are believed to be affected: 2.4.4 up to and including 2.4.37.4; 2.6.0 up to and including 2.6.30.4

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

Eu adicionei um usuário (regular) no servidor e o acesso SSH funciona. De dentro do Metasploit Framework, posso criar uma sessão SSH usando auxiliary/scanner/ssh/ssh_login . No entanto, quando eu executo o exploit, 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 definimos DEBUG_EXPLOIT como true. /tmp é writabe, também de dentro da sessão Metasploit SSH:

$ 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

Eu também tentei definir WriteableDir para o diretório pessoal do usuário no servidor, mas sem alterações. O que estou perdendo aqui? Esta versão do servidor Ubuntu (que eu deliberadamente não atualizei!) Não está vulnerável?

    

Answer 1

A versão 9.04 foi suportada até 23 de outubro de 2010. A vulnerabilidade encontrada foi reportado em Agosto de 2009. Parece razoável que, desde que a versão ainda era atual e suportada na época, o ISO foi corrigido e o que você baixou foi uma versão que não está 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 CVE-2013-2094 que deve também afetam o Ubuntu , por exemplo.

    

Answer 2

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

Você pode querer considerar também as duas configurações de falta de administrador que podem levar ao priv esc on 'nix (existem muitas outras maneiras de configurar uma caixa' nix que pode permitir privil esc por favor considere isto um whetting de apetite) ....

1. binários suid e guid pertencentes ao grupo raiz / raiz ( find / -uid 0 -perm -4000 -type f 2>/dev/null e find / -uid 0 -perm -2000 -type f 2>/dev/null ) e ver se eles são mundiais para permitir que usuários com poucos privilégios os alterem; a pasta em que existem é gravável pelo seu usuário low priv - para possível injeção do caminho da biblioteca. E as bibliotecas que eles usam - são aquelas que podem ser alteradas: verifique os valores de quaisquer cabeçalhos DT_RPATH e DT_RUNPATH ELF dentro dos binários usando um dos seguintes comandos:

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

2. sudoers falhas

   • NOPASSWD - Um invasor local pode usar esse acesso para escalonar seus privilégios dentro do sistema operacional quando o usuário se esquece de bloquear sua tela

   • Ausência de executáveis em Sudoers - Alguns executáveis no arquivo /etc/sudoers não existem. Se os executáveis forem criados, eles podem ser executados via sudo como root, o que permitiria o escalonamento de privilégios.

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

   • Alguns programas não devem estar em sudo - como vi , use :e ou Ctrl o e use :w para acessar /etc/shadow .

   • Comando incorreto / incorreto usado no arquivo sudoers - geralmente vejo httpd em sudoers - tente como um usuário baixo privado com acesso sudo para executar apenas esse comando ( sudo -l ou sudo -ll mostrará o que um usuário pode fazer): sudo /usr/bin/httpd -t /etc/shadow e analisa o erro.

   • perms de arquivos de comandos e arquivos mencionados em sudoers são fracos - veja meu parágrafo anterior em binários de bit suid e guid de propriedade de root