Probar un entorno chroot para detectar vulnerabilidades de escalamiento de privilegios

6

Estoy buscando agujeros en mi implementación actual de una jaula chroot que he implementado para un grupo de usuarios. ¿Hay algo que pueda hacer mejor aquí?

Utilicé los siguientes paquetes: RHEL6 OpenSSH jailkit

El usuario ejecuta un shell estándar, no el shell específico del jailkit, pero configuré openSSH para iniciar el chroot de los usuarios a través de la directiva MatchGroup.

Solo el acceso ssh a este servidor está habilitado.

Utilicé el jailkit para construir la propia cárcel y resolver las dependencias de biblioteca necesarias.

Construyo la cárcel usando copias de todos los archivos requeridos en lugar de enlaces duros.

Cada usuario tiene su propia cárcel y el punto de montaje para las cárceles se monta en nosuid.

Los usuarios no requieren nada que requiera SUID, por lo que me cuido de quitar todos esos bits de SUID dentro de la cárcel del usuario, no importa mucho con la bandera nosuid en el soporte.

Todos los archivos que se encuentran fuera del directorio principal del usuario son propiedad de root.

La siguiente es la lista completa de comandos, rutas y dispositivos que he puesto a disposición de los usuarios en la cárcel. Cosas bastante estándar:

/ dev / random / dev / urandom / dev / null / bin / vi / bin / env / usr / bin / which / bin / nombre de host / usr / bin / id / usr / bin / archivo / usr / share / misc / magic /lib/libnsl.so.1 /lib64/libnsl.so.1 /lib/libnss*.so.2 /lib64/libnss*.so.2 /etc/nsswitch.conf /etc/ld.so. conf / bin / sh / bin / bash / bin / ksh / bin / ls / bin / cat / bin / chmod / bin / mkdir / bin / cp / bin / cpio / bin / fecha / bin / dd / bin / echo / bin / egrep / bin / false / bin / fgrep / bin / grep / bin / gunzip / bin / gzip / bin / ln / bin / ls / bin / mkdir / bin / mktemp / bin / más / bin / mv / bin / pwd / bin / rm / bin / rmdir / bin / sed / bin / sh / bin / sleep / bin / sync / bin / tar / bin / touch / bin / true / bin / descomprimir / bin / zcat / etc / motd / etc / issue /etc/bash.bashrc / etc / bashrc / etc / profile /usr/lib/locale/en_US.utf8 / usr / bin / awr / bin / bzip2 / usr / bin / bunzip2 / usr / bin / ldd / usr / bin / less / usr / bin / clear / usr / bin / cut / usr / bin / du / usr / bin / find / usr / bin / head / usr / bin / less / usr / bin / md5sum / usr / bin / nice / usr / bin / sort / usr / bin / tac / usr / bin / tail / usr / bin / tr / usr / bin / sort / usr / bin / wc / usr / bin / watch / usr / bin / whoami / usr / bin / m c / usr / bin / mcedit / usr / bin / mcview / usr / share / mc / etc / terminfo / usr / share / terminfo / usr / bin / joe / usr / bin / nano / usr / bin / vi / usr / bin / vim / etc / vimrc / etc / joe / usr / share / vim

Para complicar las cosas, tengo un montaje automático expuesto en el directorio de inicio del usuario encarcelado que monta un sistema de archivos FUSE / sshfs remoto como root con las siguientes opciones: ro, noexec, nodev, nosuid, nonempty, noatime, follow_symlinks, allow_other , auto_cache, max_read = 65536
Cada usuario obtiene su propia entrada de montaje automático codificada en el hogar del usuario encarcelado.

He recopilado todos los ataques que podría encontrar para salir del chroot y ponerlos intencionalmente en la cárcel. Sin haber eliminado la directiva 'nosuid' del montaje de la cárcel, poseer el archivo como root y configurar el bit SUID en uno de ellos, no he podido salir.

¿Me falta algo?

    
pregunta Daren Schwenke 16.05.2012 - 21:44
fuente

1 respuesta

4

bash puede establecer conexiones tcp, no olvides revisar tu firewall. Tal vez le gustaría eliminar todo el tráfico de los usuarios con iptables -A OUTPUT -m owner --uid-owner youruser -j DROP pero esto no debería reemplazar su firewall.

Si el usuario puede abrir una conexión, puede escanear la red y explotar servicios vulnerables para romper la cárcel o comprometerse con los servidores.

    
respondido por el sfx 16.05.2012 - 23:03
fuente

Lea otras preguntas en las etiquetas