Fran's site and blog

       Puertas traseras en Linux:

¿Qué tal de nuevo?
 
Tenía cosas que preguntarte y consultarte:

  1. Intenté instalar tu distro en una máquina virtual, tanto en virtualbox, como en VMWare, pero me daba error en los dos. El mismo error. Un error de grub que no recuerdo ahora. Como si la imagen no se hubiera copiado en el disco duro.

 Re:     Si te cuento con virtualbox tienes que decirle cuando crees la imagen del disco duro, le dices que no sea dinamica o sea que el tamaño sea fijo y le das 13 Gigas, por lo que sea el partimage (el que realiza la clonación) no funciona bien con unidades de disco duro dinámicas, yo lo he instalado ya en  mi trabajo.



  1. Puertas traseras en Linux:
Cuando estuve en L### me gustaba, en los ordenadores que tenían Lin*, que estaban para uso público, buscarme maneras de tener privilegios de administrador. Para tonterías como averiguar la dirección ip de su configuración y poco más; o tener la opción de poder instalar algún programilla que a mí se me antojara. Así que estuve aprendiendo maneras mediante las que, sin llegar a conocer la contraseña de root, poder ejecutar tareas como tal.

Escenario:
Ordenador de uso público con Lin* instalado, que en la mayoría de los casos tiene gdm configurado para entrada automática de un usuario no administrador; o sea, de los normalitos, vamos. No tienes privilegios de administrador y no sabes ni la contraseña de ese usuario porque el ordenador, al encenderse, entra automáticamente en esa cuenta.

Método:

Todo empezaba editando grub cuando aparecía su menú, y añadir, en la segunda línea, al final, init=/bin/bash

Pulsar Enter, y la tecla b para que arrancara. Aparecías en una consola de bash, sin entorno gráfico ni nada. Y remontabas la partición a rw.

Y luego venía la puerta trasera en cuestión:

1.- La más usada por mí, pero quizás más cantosa, estando en esa consola root todavía, era editar (o instalar primero si no lo estaba), el programa sudo  y editar sudoers como en ubuntu con la expepción de que no me pidiera contraseña nunca al hacer sudo. Previamente creaba un usuario del que sí sabía la contraseña (porque lo estaba creando yo) y definía como su directorio $HOME uno existente, para que no fuera muy cantoso la existencia de un nuevo usuario. A ese nuevo usuario le daba los permisos en SUDOERS.

Así, como usuario normal, una vez reiniciado, y en lo sucesivo, cambiaba a mi usuario en la consola, escribía sudo -i, y tenía una consola root para hacer lo que quisiera.


1.- La segunda manera de tener una "puerta trasera" en lo sucesivo era, también desde esa consola de arranque bash en la que se entra con el truco de editar el menú de grub, era seguir las instrucciones que hay por ahí para cómo conectarse por ssh a un ordenador sin tener que introducir la clave (en este caso de root), cada vez. Se crea una clave pública y otra privada, y la pública se introduce en cierto directorio dentro del $HOME del usuario en el que pretendes logearte en el futuro por ssh sin petición de contraseña. Así que hacía eso para el propio usuarior normal para que este a través de un ssh root@localhost iniciara una consola root al igual que en el caso anterior.


3.- El tercer método es el objeto de mi pregunta: el uso del "sticky bit", o sea, ese bit que, en los permisos de un archivo, si está activo hace que, quien ejecute un programa con el bit s activo (chmod +s /usr/bin/apt-get), por ejemplo, adquiera los permisos del dueño de ese programa durante la ejecución del mismo. Y que así es como passwd puede ser usado por cualquier persona para cambiar entradas de los archivos /etc/passwd, etc, cuando cambia su propia contraseña.
Mis pruebas me han llevado a pensar que, una vez editado grub para entrar como admin a través de la consola bash que he comentado antes, sería muy útil cambiar el bit "s" a los programas chmod y chown, para así poder cambiar permisos luego a cualquier otro que yo quiera usar con derechos de root.
Estoy pensando en éste método, porque me parece el menos cantoso de los tres expuestos. El administrador sólo vería algo raro si, al hacer un ls -l en ciertos directorios, se encontrara con más programas con el "s" activo de la cuenta.


Porque:
el método 1) implica la existencia de un nuevo usuario, la presencia del programa sudo si antes no estaba instado, y, por supuesto, una configuración muy cantosa que ahora no recuerdo su sintaxis exacta pero que incluía un NOPASSWD en la línea sensible de configuración.


El método 2) implica un logging en /var/log de muchas conexiones ssh al localhost (y aunque se tratara de otro sitio), muchas conexiones ssh (y además a root), es cantoso y descubre al administrador el origen del truco.


Pero el método 3) me plantea la duda de cómo usar la propiedad del bit "s" de la manera más eficaz posible, para que no tenga que hacer tantos cambios de permisos a ejecutables, que también sería cantoso.
La prueba que realizado es la de copiar a mi directorio de trabajo los programas que quería usar como root, (teniendo previamente chmod y chown con el bit "s" activo), y a través de ellos, cambiar sus dueños a root otra vez, y asignarles bit "s". Así funcionaron bien ifconfig y apt-get update (las copias traidas a mi directorio de trabajo), a partir de una cuenta de usuario normal.


¿Tú cómo lo ves?
Sé que existen rootkits que hacen todo este tipo de trabajo mucho más fácil, pero esto es un método de andar por casa bastante eficaz. De hecho, pones a prueba la configuración deficiente de muchos ordenadores que hay en los V####, bibliotecas públicas etc, etc. Y sin intención de hacer daño, por supuesto.





Saludos.


 Re:  QUe  como lo veo?, que eres un autentico friqui y controlas un huevo y parte del otro, yo sabia lo del grub y parte del bit setuid, pero esperaba que fuera tan fácil, si supongo que lo mejor es lo que comentas entrar editando el grub y poner setuid -s a los programas que quieres que tengan privilegios para que tú como usuario los puedas utilizar.


   Es muy buena idea.


    Bueno viendo el nivel que tienes, cuando tenga dudas de seguridad ya se a quien preguntar.


    Un saludo.