Demostración de vulnerabilidad en Ubuntu 9.04

Para una clase sobre seguridad de TI, quiero demostrar la escalada de privilegios a los estudiantes. Para hacerlo, busqué en la exploit/linux/locallista del Metasploit Framework, encontrando (entre otros) exploit/linux/local/sock_sendpagedesde agosto de 2009.

Configuré una VM con Ubuntu Server 9.04 de 32 bits ( http://old-releases.ubuntu.com/releases/9.04/ubuntu-9.04-server-amd64.iso ) desde abril de 2009. uname -rme da 2.6.28-11-generic. Según la descripción del exploit

Se cree que todas las versiones de Linux 2.4 / 2.6 desde mayo de 2001 se ven afectadas: 2.4.4 hasta 2.4.37.4 inclusive; 2.6.0 hasta 2.6.30.4 inclusive

Entonces parece que el servidor Ubuntu que configuré debería ser adecuado para la demostración. Sin embargo, no pude hacerlo funcionar.

Agregué un usuario (regular) en el servidor y el acceso SSH funciona. Desde dentro de Metasploit Framework, puedo crear una sesión SSH usando auxiliary/scanner/ssh/ssh_login. Sin embargo, cuando ejecuto el exploit, obtengo

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

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

No obtengo más información, ni siquiera cuando se establece DEBUG_EXPLOITen verdadero. /tmpes writabe, también desde dentro de la sesión 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

También intenté configurar WriteableDirel directorio de inicio del usuario en el servidor, pero sin ningún cambio. ¿Que me estoy perdiendo aqui? ¿Esta versión del servidor de Ubuntu (que deliberadamente no he actualizado) no es vulnerable?

La versión 9.04 se admitió hasta el 23 de octubre de 2010. La vulnerabilidad que encontró se informó en agosto de 2009. Parece razonable que, dado que la versión aún era actual y compatible en ese momento, el ISO se parchó y lo que descargó fue una versión que está Ya no es vulnerable.

Además, parece haber demostrado bastante bien que no es vulnerable. Después de todo, probaste el exploit y parece que falló.

¿Por qué no pruebas un exploit más nuevo? Algo como CVE-2013-2094 que también debería afectar a Ubuntu , por ejemplo.

Esto no responde a su consulta específica, sino que le brinda más opciones privadas para mostrar a sus estudiantes ...

Es posible que también desee considerar las siguientes dos configuraciones incorrectas de administrador que podrían conducir a priv esc en 'nix (hay muchas otras formas de configurar erróneamente una' caja nix que podría permitir priv esc, así que considere esto como un apetito abierto) ....

1. binarios suid y guid propiedad de root / root group ( find / -uid 0 -perm -4000 -type f 2>/dev/nully find / -uid 0 -perm -2000 -type f 2>/dev/null) y vea si son de escritura mundial para permitir que el usuario con privilegios bajos los cambie; la carpeta en la que existen es editable por su usuario low priv, para una posible inyección de ruta de biblioteca. ¿Qué pasa con las bibliotecas que usan? ¿Son aquellas que se pueden cambiar? Verifique los valores de cualquiera DT_RPATHy los DT_RUNPATHencabezados ELF dentro de los binarios usando uno de los siguientes comandos:

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

2. sudoers fallas

   • NOPASSWD - Un atacante local podría usar este acceso para escalar sus privilegios dentro del sistema operativo cuando el usuario olvida bloquear su pantalla

   • Ejecutables perdidos en Sudoers: algunos ejecutables en el /etc/sudoersarchivo no existen. Si se crean los ejecutables, se pueden ejecutar a través de sudo como root, lo que permitiría la escalada de privilegios.

   • Entradas huérfanas de Sudoers: el /etc/sudoersarchivo puede contener varias entradas huérfanas para las que no hay una cuenta correspondiente configurada en el /etc/passwdarchivo. Si se creara un usuario con uno de los nombres huérfanos, le proporcionaría al usuario un medio para escalar privilegios al acceso raíz completo.

   • Algunos programas no deben estar en sudo - like vi, use :eo Ctrl o and use :wpara acceder /etc/shadow.

   • Comando incorrectamente pensado / incorrecto utilizado en el archivo sudoers, a menudo veo httpden sudoers, así que intente como un usuario de bajo privilegio con acceso a sudo para ejecutar solo ese comando ( sudo -lo sudo -llmostrará lo que un usuario puede hacer): sudo /usr/bin/httpd -t /etc/shadowy mire el error.

   • las permanentes de los comandos y los archivos mencionados en sudoers son débiles; consulte mi párrafo anterior sobre los binarios de bits suid y guid propiedad de root