¿Hay alguna forma en que el atacante pueda usar mkdir para comprometer un sistema?

22

Estoy configurando una cuenta de usuario restringida para el usuario ricardo, un usuario problemático en mi sistema. Quiero otorgarle el derecho de crear directorios utilizando sudo, lo que a veces necesita hacer. Estoy considerando esta regla en mi /etc/sudoersarchivo:

ricardo   ALL=(root) NOPASSWD: /bin/mkdir

Usando solo esta regla, ¿hay alguna forma en que Ricardo pueda comprometer intencional o accidentalmente el sistema?

security directory

— Ricardo Altamirano
fuente

2

Si tiene un sistema de archivos con un recuento de inodos estático, podría usar todos sus inodos.

— jordanm

2

@schaiba Le gusta jugar y ver si puede explotar el sistema y no siempre lee las páginas del manual tanto como debería.

— Ricardo Altamirano

8

Una educación adecuada para el usuario, combinada sin sudo en este momento, sería lo más recomendable para mí.

— schaiba

2

Como dice @schaiba, puede utilizar dichos usuarios enseñándoles y otorgándoles responsabilidades (bajo estrecha supervisión). He visto guerras entre sysdamins y usuarios, ya que los primeros trataron de bloquear demasiado el sistema. Los usuarios superaron en número a los administradores de sistemas 10 a 1, e incluso entonces (¡ sin el acceso a Internet de hoy!) La derrota de los administradores de sistemas fue humillante. ¡Nunca te pongas en esa posición!

— vonbrand

2

Ese es el caso de un Ricardo demasiado. O al menos, así habló BOFH ...

— Deer Hunter

21

Sospecho que un ataque como este funcionaría, donde «algo» es un módulo del núcleo que intentará cargar después de que se monte rootfs:

$ sudo mkdir -m 777 /lib/modules/`uname -r`/a
$ cp evil.ko /lib/modules/`uname -r`/a/«something».ko

Tenga en cuenta también que podría usar otros nombres, dependiendo de los alias declarados en el módulo. Supongo que no se cargará hasta que se ejecute depmod, lo que sucederá la próxima vez que haya una actualización del kernel, por lo que elmkdir que ni siquiera se mostrará recientemente en el registro de sudo.

Hay muchas cosas en / etc que leen todos los archivos en un directorio, a veces de forma recursiva. Peor aún, algunos de esos directorios no existen por defecto, y la única forma de conocerlos es leer la página de manual, los scripts de inicio, etc. para el programa que los usa. Algunas, peor aún, son cosas obsoletas de compatibilidad con versiones anteriores, y es posible que ya ni siquiera estén documentadas.

editar: Pensé en algunos directorios más, estos en /usr/local:

/usr/local/lib/perl/5.14.2(difiere según la versión de Perl, intente perl -Vaveriguarlo). Cree un Filesubdirectorio allí y póngalo Find.pm. Ahora, cuando alguien use File::Find, usará la versión del atacante. Del mismo modo, haz lo mismo con Getopt::Long. Las utilidades del sistema a menudo se escriben en Perl, por lo que esto probablemente da origen. (Prueba ack-grep --color -a 'use.+::' /usr/sbin | less -R)
Creo que Python, Ruby, etc. tienen directorios similares. Las utilidades del sistema también están escritas en Python.
Subvierte muchas cosas que alguien compila con subdirectorios /usr/local/include.

— derobert
fuente

Ah, pero si <usuario malvado> puede copiar módulos donde el núcleo los cargará, el juego termina antes del inicio.

— vonbrand

1

@vonbrand <usuario malvado> normalmente no puede, pero usó el suyo sudo mkdirpara crear un nuevo directorio donde pueda.

— derobert

20

Al ejecutarse mkdircomo root, el usuario puede impedir que otros procesos / usuarios creen nuevos archivos y directorios creando directorios con nombres idénticos (y / o derechos incorrectos) anteriormente.

Esto podría ser relevante para la seguridad, especialmente con archivos de registro y bloqueo .

Como señaló Jordan , el número máximo de inodos también se puede utilizar, lo que puede bloquear todo el sistema.

Al agregar al usuario a grupos específicos (o usar ACL ), debería poder resolver los problemas sin otorgar ningún derecho a través de sudo.

— jofel
fuente

Grandes puntos Probablemente dejaré de mkdirlado la lista de comandos que Ricardo puede usar.

— Ricardo Altamirano

Si es para agotar los inodes, un simple funcionará for((i = 0;; i++)); do touch $i; donebien (bashism, lo siento; pero ya entiendes la idea).

— vonbrand

@vonbrand Excepto que no es tan raíz, por lo que se detendrá mediante una cuota. Por supuesto, otros sudocomandos que OP está considerando pueden permitir también inodos agotadores; OP necesita ser consciente de ese vector DoS.

— derobert

11

Deberías redirigirlo a una cárcel chroot. O incluso mejor, para un pequeño VM, que puede bloquearse una vez por hora. Todo lo que necesita hacer es proporcionar una nueva copia.

— ott--
fuente

Lo recomiendo mucho Dale acceso de root en su propia VM.

— emory

a un chroot ^ H ^ H ^ H ^ H ^ Cárcel de Hounty ...

— Deer Hunter

6

Hay posibilidades debido a la posibilidad de crear directorios con acceso de escritura. Con mkdir -m 777 blahel ricardousuario puede escribir lo que quiera en el nuevo directorio. Necesitaría un proceso en el sistema que ya se ejecuta como un usuario diferente que recurrirá a un árbol de directorios para cargar configuraciones, scripts o módulos. Entonces, el usuario podría agregar sus propias cosas para cargar o ejecutar. Lo primero que puedo pensar es si ejecuta un servidor web que puede ejecutar php o cgi. Luego podría ejecutar scripts como ese usuario. Estoy luchando por encontrar más ejemplos del mundo real, especialmente rootalgunos, pero estoy seguro de que se trata.

ssh es un ejemplo de un demonio que atrapa este tipo de escenario. Si creó un .sshdirectorio para un usuario que no tenía uno y puso su propio authorized_hostsarchivo en su lugar. sshdadvierte que los permisos de los directorios son demasiado abiertos e ignora la clave pública.

Definitivamente, podría ser una molestia crear directorios donde se espera que aparezcan archivos (como archivos transitorios tmp o swap) que muchos programas no manejarían bien.

Podrías crear muchos cgroups pero no parece que hagas nada con ellos. Es posible que pueda poner un sistema de rodillas al menos. Se necesitaron alrededor de 10000 cgroups en una caja con 256M para que el asesino OOM elimine sshd.

Si controlas la -mopción mkdiry el UMASK del sudoentorno, creo que es solo una molestia.

— Mate
fuente