Supongamos 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 al que se le ocurrió esta idea no tenía imaginación y le asignó un uid y un 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 en un programa que siempre salía con fallas. Además, la configuración predeterminada para cualquier acceso por red (telnet, rlogin, rcp, ftp) se estableció para evitar el acceso de cualquier uid de cero. Había una entrada passwd separada para root, con una contraseña, un directorio de inicio y un shell configurados correctamente.
Esto significaba que si intentaba iniciar sesión como juegos, ocurriría lo siguiente:
- Iniciar sesión como juegos en la consola tendría éxito al principio, pero luego generaría el
/bin/false
shell, que saldría inmediatamente. - Usar telnet o rlogin denegaría por completo el inicio de sesión. Incluso si hubiera tenido éxito, el
/bin/false
shell se cerraba inmediatamente. - FTP y scp no usan shells, pero se configuraron para denegar el acceso a uid cero, por lo que no podía iniciar sesión de esta manera.
- Un inicio de sesión de GUI iniciaría los servicios de GUI predeterminados, incluido un administrador de ventanas, un cliente de reloj y una terminal. Este último saldría inmediatamente porque su shell secundario saldría inmediatamente. Entonces obtendría una pantalla vacía excepto por un reloj. (Más sobre esto a continuación...)
- Si realmente tuviste para iniciar sesión como root, tendría que hacerlo desde la consola, o primero iniciar sesión/telnet como otro usuario en esa máquina y luego
su root
. De cualquier manera usa la raízpasswd
entrada en lugar de los juegospasswd
y, por lo tanto, funciona de la forma en que debería funcionar la raíz.
Entonces, la cuenta de juegos parecía fallar siempre, a menos que hiciera un inicio de sesión de 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 proporcionada de fábrica que los usuarios normalmente personalizarían por sí mismos. (La personalización del menú no funcionó para la cuenta de juegos; no recuerdo exactamente por qué). Podría intentar abrir más ventanas de terminal, lo que fallaría. Hubo un juego de rompecabezas (que puede haber sido el impulso de la cuenta en primer lugar). Otra opción era cerrar la sesión. Y luego estaba la herramienta de depuración gráfica, dbxtool
.
dbxtool
era una interfaz gráfica para el dbx
depurador simbólico, similar al actual gdb
. Al ser uid cero, podía conectarse y controlar cualquier proceso del sistema, aunque esto no era útil porque los programas proporcionados por Sun se compilaban sin símbolos. Podría iniciar un shell, pero esto usaría su SHELL
variable de entorno, que era /bin/false
. Sin embargo, ¡también podría cambiar las variables ambientales! Esto significaba que podía obtener un intérprete de comandos raíz de la siguiente manera:
- Inicie sesión a través de la GUI como juegos, sin contraseña.
- Haga clic derecho para que aparezca el menú raíz.
- Inicie un
dbxtool
. setenv SHELL /bin/sh
- (Opcional)
setenv HOME /
- Inicie un shell con
!
- Debido a que el terminal no está configurado, haga
stty sane
¡Voilá, root shell sin contraseña!
Por lo tanto, no asuma que un usuario no puede escapar de un shell no válido.
No 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 , cerrará su sesión cada vez que finalice. Pero puede usar peculiaridades, errores e inconsistencias en el shell de inicio de sesión para escapar.
Una cosa que podría hacer es escapar a un caparazón usando cualquier opción del menú. Si el menú te permite iniciar vim
, less
, more
o algunos otros comandos, teóricamente puedes liberarte. Si el administrador del sistema tiene experiencia, 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 caparazón apuntaba a algo que simplemente imprimía algún resultado usando más comando, luego finalizó la sesión. Sin embargo, dado que más cuenta con un editor de texto incorporado (en este caso particular fue vi), fue suficiente para cambiar el tamaño de la ventana de la terminal desde la que se estaba conectando para que se active más, luego utilícelo para escapar del shell.
Entonces, la respuesta depende de lo que haga su script. Revisa al hombre páginas para cada uno de los comandos que está ejecutando para evitar una vulnerabilidad.