¿Y si te contara que un usuario normal de una red corporativa puede tomar el control de un servidor de ficheros Windows sólo creando una carpeta con un nombre especial dentro de un recurso compartido?
En Windows el caracter & es interpretado como un separador de comandos, por lo que para ejecutar el segundo comando sólo hace falta mostrar una variable de entorno o asignar el valor de una variable a otra:
En sí mismo esto no se considera un exploit porque está claro que si pueden modificar las variables de entorno de tu servidor ya estás jodido. Pero, ¿y si existe una tarea programada que ejecuta un bat con un ECHO %CD% o algo como SET CurrentPath=%CD%?
Si lo piensas, los administradores suelen programar la ejecución de ficheros .bat en servidores de ficheros para realizar algún tipo de mantenimiento, por ejemplo para comprobar los permisos de todos los sub-directorios o para ver el tamaño de cada uno de ellos. Entonces un usuario con privilegios limitados simplemente puede crear un directorio:
\fileServer1\Share\user1\T&malware
Y crear un fichero “malware.bat” que contiene:
Net localgroup administrators domain\user1 /add
O
Net user administrator newpassword123!!
Después simplemente tiene que esperar a que el fichero batch corra con permisos elevados y haga uso de la variable %CD% sobre el nombre del directorio...
Fuente: Command-injection vulnerability for COMMAND-Shell Scripts
En Windows el caracter & es interpretado como un separador de comandos, por lo que para ejecutar el segundo comando sólo hace falta mostrar una variable de entorno o asignar el valor de una variable a otra:
En sí mismo esto no se considera un exploit porque está claro que si pueden modificar las variables de entorno de tu servidor ya estás jodido. Pero, ¿y si existe una tarea programada que ejecuta un bat con un ECHO %CD% o algo como SET CurrentPath=%CD%?
Si lo piensas, los administradores suelen programar la ejecución de ficheros .bat en servidores de ficheros para realizar algún tipo de mantenimiento, por ejemplo para comprobar los permisos de todos los sub-directorios o para ver el tamaño de cada uno de ellos. Entonces un usuario con privilegios limitados simplemente puede crear un directorio:
\fileServer1\Share\user1\T&malware
Y crear un fichero “malware.bat” que contiene:
Net localgroup administrators domain\user1 /add
O
Net user administrator newpassword123!!
Después simplemente tiene que esperar a que el fichero batch corra con permisos elevados y haga uso de la variable %CD% sobre el nombre del directorio...
Fuente: Command-injection vulnerability for COMMAND-Shell Scripts
Si es un usuario, se ejecuta con permisos de usuario, no podrá llevar a cabo tareas de admin.
ResponderEliminarA parte, es práctica recomendada y habitual por admins un poco serios usar file screening en shares para delimitar qué tipo de ficheros se usan, y complementarlo con auditorías en tiempo real para que si se produce oejecuta el proceso se alerte de ello. Applocker y srp son medidas que ayudan mucho en estos casos.
Quien ejecuta el .bat suele ser un usuario administrador del servidor, de ahí que al usar la variable %CD% ejecute comandos con esos permisos.
EliminarEstamos de acuerdo que el uso de ficheros batch en tareas programadas es obsoleto y una mala práctica pero ¿estamos seguros de que todavía no se utiliza?
Claro que se utilizan, pero para programar una tarea en un servidor, tienes que tener permisos de administrador; un usuario no va a poder crear tareas programas en él, ni conseguir elevar privilegios por ello. Es decir, que si puede hacer eso, como indicas, es que tienes un problema mucho más grave que atender :-).
EliminarNo obstante, recalco, si se usa APPLocker y FileScreening, se suelen mitigar el 95% de las cosas tan simples.
quizás no he explicado correctamente (ahora le doy un par de vueltas al texto):
Eliminarlas tareas programadas son las que ya hay en el servidor y han sido puestas por administradores previamente... es luego el atacante con un usuario normal el que se aprovecha de que corren estos scripts mediante la combinación de nombre de dir+%CD%...
Normalmente, cuando hay una tarea programada, el bat, suele estar en una ubicación que por permisos ya el usuario no podrá acceder; y a parte, como digo, si se usa Applocker o SRP, un usuario no podrá ejecutar aún así el proceso. Es decir, que para explotar esto, tienen que darse unas situaciones que aunque parezca mentira, no son tan habituales
EliminarSerá en el escenario de prácticas del autor, pero en la practica una probabilidad far far away
ResponderEliminarLo mismo que comentaba antes: Estamos de acuerdo que el uso de ficheros batch en tareas programadas es obsoleto y una mala práctica pero ¿estamos seguros de que todavía no se utiliza? ;)
EliminarSe utiliza y mucho ... aunque no se crea.
ResponderEliminar