Anular el comando / script especificado en / etc / passwd

Con el script de muestra que ha publicado, el usuario restringido, por ejemplo, puede aprender mucho sobre el sistema, como los nombres de otros usuarios y los programas instalados. Por ejemplo,

What is your name?
> /home/* 
Hi /home/foo /home/bar /home/sadeq

El script real que tiene puede ser explotable de maneras similares, tal vez hasta el punto en que el usuario pueda obtener un acceso de shell real.

Probablemente podría mejorar la situación iniciando el menú de inicio de sesión en un entorno de espacio aislado: no necesariamente será 100% a prueba de balas, pero al menos el espacio aislado tapará un montón de agujeros de seguridad que el autor del script pudo haber dejado.

Suponga que hay una puerta trasera (probablemente no intencional).

El /etc/passwd predeterminado en las estaciones de trabajo Sun de principios de la década de 1990 incluía una entrada como esta:

games::0:0:games:/nopath:/bin/false

En otras palabras, una cuenta llamada 'juegos' sin contraseña. Aparentemente, el genio que tuvo esta idea no tuvo imaginación y le asignó un uid y gid de cero (es decir, raíz y rueda). En general, eso estaba bien, ya que el directorio de inicio no tenía sentido y el shell estaba configurado para un programa que siempre salía con un error. Además, la configuración predeterminada para cualquier acceso por red (telnet, rlogin, rcp, ftp) se configuró para evitar el acceso mediante cualquier uid de cero. Había una entrada de contraseña separada para la raíz, con una contraseña, un directorio de inicio y un shell configurados correctamente configurados.

Esto significaba que si intentabas iniciar sesión como juegos, sucedería lo siguiente:

• El inicio de sesión como juegos en la consola tendría éxito al principio, pero luego generaría el shell /bin/false , que se cerraría inmediatamente.
• El uso de telnet o rlogin denegaría directamente el inicio de sesión. Incluso si hubiera tenido éxito, el /bin/false shell se cerraría inmediatamente.
• FTP y scp no usan shells, pero se configuraron para denegar el acceso a uid zero, por lo que no se pudo iniciar sesión de esta manera.
• Un inicio de sesión de GUI iniciaría los servicios de GUI predeterminados, que incluyen un administrador de ventanas, un cliente de reloj y un terminal. Este último saldría inmediatamente porque su caparazón hijo saldría inmediatamente. Así que obtendrías una pantalla vacía a excepción de un reloj. (Más sobre esto a continuación ...)
• Si realmente tenía para iniciar sesión como root, tendría que hacerlo desde la consola o primero rlogin / telnet como otro usuario en esa máquina y luego su root . De cualquier manera, se usa la entrada root passwd en lugar de la entrada games passwd , y por lo tanto funciona de la manera en que debería funcionar la root.

La cuenta de los juegos parecía fallar siempre, a menos que hicieras un inicio de sesión GUI. En ese caso, lo único que apareció fue el reloj. Sin embargo, puede hacer clic con el botón derecho en el fondo para obtener un menú raíz, con una lista de programas provista de fábrica que los usuarios normalmente personalizarían para ellos mismos. (La personalización del menú no funcionó para la cuenta de juegos; no recuerdo exactamente por qué). Se podría intentar abrir más ventanas de terminal, lo que fallaría. Hubo un juego de rompecabezas (que pudo haber sido el ímpetu de la cuenta en primer lugar). Otra opción fue cerrar la sesión. Y luego estaba la herramienta de depuración gráfica, dbxtool .

dbxtool era una interfaz gráfica para el depurador simbólico dbx , similar al gdb de hoy. Siendo uid cero, podría adjuntar y controlar cualquier proceso en el sistema, aunque esto no fue útil porque los programas proporcionados por Sun se compilaron sin símbolos. Podría iniciar un shell, pero esto usaría su variable de entorno SHELL , que era /bin/false . Sin embargo, también puedes cambiar las variables ambientales! Esto significaba que podría obtener un shell raíz de la siguiente manera:

1. Inicie sesión a través de la GUI como juegos, sin contraseña.
2. Haga clic con el botón derecho para abrir el menú raíz.
3. Inicia un dbxtool .
4. setenv SHELL /bin/sh
5. (Opcional) setenv HOME /
6. Inicia una shell con !
7. Debido a que el terminal no está configurado, haga stty sane

Voila, root shell sin contraseña!

Por lo tanto, no asuma que un usuario no puede escapar de un shell no válido.

No se puede omitir la ejecución del script. Este es su shell de inicio de sesión y se iniciará cada vez que inicie sesión. Y como un shell de inicio de sesión , lo desconectará cada vez que finalice. Pero puedes usar peculiaridades, errores e inconsistencias en el shell de inicio de sesión para escapar.

Una cosa que podrías hacer es escapar a un shell usando cualquier opción en el menú. Si el menú le permite iniciar vim , less , more o algunos otros comandos, teóricamente puede liberarse. Si se experimenta el administrador del sistema, esos comandos usarán sus versiones restringidas y no funcionarán.

Recuerdo un desafío de juego de guerra en el que había un caso similar: el shell apuntaba a algo que simplemente imprimía algo con el comando más , y terminaba la sesión. Sin embargo, dado que más cuenta con un editor de texto incorporado (en este caso particular, era vi), fue suficiente para cambiar el tamaño de la ventana de terminal desde la cual se conectó, de modo que se active más, luego úselo para escapar de la cáscara.

Entonces, la respuesta depende de lo que haga su script. Compruebe las páginas man para cada uno de los comandos que está ejecutando para evitar una vulnerabilidad.

TLDR: ¡El script que mencionas es seguro!

Pero entendiendo que en producción puede usar una versión diferente, debe tener en cuenta los siguientes conceptos:

1. Si la 'lectura' es vulnerable a la inyección de comandos. Si es vulnerable, entonces el valor 'nombre' como 'Bob; cat / etc / passwd ' podría devolver el contenido del archivo passwd y ' Bob & & / bin / bash -i ' podría dar una sesión de bash interactiva.

Estas preguntas ya se hicieron, por ejemplo. aquí:

enlace

La respuesta dice "No, no es vulnerable", debido a:

  

"(..) las conchas modernas analizan la instrucción antes de cualquier variable   sustitución, y por lo tanto no se ven afectados por este ataque ".

Por lo tanto, en su ejemplo, la entrada del usuario por 'lectura' no se puede omitir desde el shell estándar.

2. ¿Dónde se analiza la entrada?

Su script es seguro, porque 'echo' no proporciona ninguna técnica de escape (al menos no se conoce). Pero tenga en cuenta el uso de binarios "peligrosos" como se menciona en f.e. aquí:

enlace

Si la entrada del usuario es analizada por: man | less | more, awk, find, nmap, python | php | perl, bash | sh , entonces es posible escapar, otorgando un shell completamente interactivo ( Acabo de probar con menos, python y find).

Si solo ingresas el eco, como en tu ejemplo, entonces estás bien.

3. Si su entrada se usa dentro del comando de shell con asteriscos (*), como: tar * o ls *

No puedo imaginar cuándo puede ser útil en tu escenario, pero siempre es mejor mencionarlo. Si este es un caso, familiarícese con lo siguiente:

enlace

Este tipo de comportamiento también puede llevar a escapar de su script.