EDICIóN GENERAL
124 meneos
2634 clics
Técnicas para escapar de shells restringidas (restricted shells bypassing)

Técnicas para escapar de shells restringidas (restricted shells bypassing)

Recientemente, @n4ckhcker y @h4d3sw0rmen publicaron en exploit-db un breve pero útil paper para escapar de shells restringidas como rbash, rksh y rsh, ya sabéis, aquellas que bloquean algunos de comandos como cd, ls, echo, etc., restringen variables de entorno como SHELL, PATH, USER y a veces incluso comandos con / o las salidas de redireccionamiento como >, >>; todo ello para añadir una capa extra de seguridad para protegerse contra posibles atacantes, comandos peligrosos o simplemente como una prueba en un CTF. A continuación se listan la mayoría de las técnicas para bypassear estas shells restringidas.

| etiquetas: técnicas , escapar , shell restringida , restricted shell bypassing
pues menudo coladero las shells restringidas
#1 Es la técnica del la puerta blindada en la casa de papel mientras nadie se de cuenta que la casa es puta mierda todos intentaran entrar por la puerta principal.
anv #8 anv *
#5 Lo hace. Pero en los ejemplos verás que por ejemplo se puede ejecutar un tar y pedirle que pare y ejecute un comando (bash en este caso). O ejecutar python y desde ahí ejecutar un bash.

#1 En definitiva, que el shell restingido no es nada seguro. Es sólo un obstáculo menor. Incluso sin salir del shell restringido, éste sólo te restringe los cambios de directorio que puedes hacer. Pero se puede hacer de todo sin moverte de tu home simplemente especificando los caminos completos.
#8 en mi mentalidad que por otro lado es bastante lógica algo está "restringido" cuando me impide hacer algo aunque lo programe en C o lenguaje ensamblador. Está restringido y punto.

Si no es así como concepto de seguridad es irrelevante.
#9 Recuerda que es un shell restringido. Sólo restringe las cosas que hace el shell (y sus shell scripts). Para completar la seguridad tendrías a demás que impedir el acceso de esos usuarios a distintos programas que puedan permitirle ejecutar otros a voluntad (se puede pero es engorroso).

Sólo el kernel puede poner restricciones a lo que hacen los demás programas. Si quieres eso en linux tienes selinux y apparmor.

Por eso el shell restringido no se suele usar mucho. Yo sólo lo vi una vez en la universidad cuando el administrador quiso intentar que siguiéramos haciendo trastadas varias (iluso de él).
yo por eso uso mac que no restringe las conchas.
Me parece pobre el artículo, no explica en qué casitas de la ciudad 3D hay que pinchar en el sistema unix para conseguir el acceso a las puertas de seguridad del recinto.
#4 Que recuerdos me has traido. Ví Parque Jurásico en vídeo el día antes de mi examen de SS.OO. II con Unix. Me eché a temblar pensado que no tenía ni puta idea para el examen :wall:
Y por qué no hacen una shell restringida que ignore el uso de la cadena /bin/bash, /bin/sh y por el estilo y asunto resuelto ;)
#5 Porque hay cientos de shells. Ksh intrrpretewnde Python, de Ruby, de Perl y comandos que te pueden permitir of Oscar cadenas, como por ejemplo sed.
Jeje... me acuerdo que hace muuuchos años en un equipo NCR me escapaba entrando al vi y de ahí ejecutando un sh normal.
¿Una shell restringida que para escapar lo que hay que hacer es lanzar una shell no restringida? De verdad que no sé de qué me están hablando.

Para mi una shell restringida es un chroot de toda la vida y de ahí no sales así, algo me he perdido.
#7 Cuidao que un chroot mal configurado es una caja de bombas.
#11 Como todo en la vida.
#14 Gracias por esta gran aportación.
#16 ¡De nada! ¡A mandar!
#14: Pues imagínate lo fácil que es de entender esta noticia para los que como mucho conocemos las palabras "pwned" y "pwn3d" y aún así no conocemos en profundidad todos sus matices. xD
#7 chroot no es un mecanismo de seguridad, es un mecanismo diseñado para evitar problemas de compatibilidad de versiones. Se diseño con ese fin y no con la seguridad en mente. Para aplicar bien un chroot como mecanismo de seguridad tienes que saber muy muy bien lo que haces, sino puedes salirte de mil formas (mknod, la propia syscall de chroot, que no el binario, a través de un enlace simbólico, etc.)

Lo suyo es usar un mount namespace y SELinux o AppArmor y quitar todas las capabilities que sobren, o si no sabes lo que estás haciendo docker run --cap-drop=all (docker siempre con SELinux o AppArmor, sino, a nada que salgan del namespace tienen acceso a todo)
Gracias, si algún día tengo que hacer un shell restringido seguiré los consejos al revés. :-D

menéame