Hoy hablaremos de la configuración por defecto de
AppLocker y los riesgos que esto proporcionan para la defensa del sistema. Las reglas por defecto de AppLocker
permiten a todos los ficheros que se encuentran dentro de la ruta Windows y Program Files ser ejecutados, ya que, si no fuera así, el sistema
no funcionaría de forma normal. Si no se establecen los permisos de forma
adecuada en estas carpetas, un atacante podría explotar esto para conseguir
bypassear AppLocker.
En Windows 2008 R2, se permite por defecto a los usuarios estándar del
sistema tener acceso de lectura y escritura sobre estas carpetas: \Windows\Temp y \Windows\Tracing. La herramienta accesschk se puede utilizar para identificar si el grupo de
usuarios o “Users” tiene permisos de
lectura y escritura dentro de la carpeta Windows.
En la imagen se puede visualizar este hecho en Windows 10.
Aunque en la imagen no se visualiza, la ruta \Windows\Tasks también está disponible y podemos almacenar binarios
en dicha ruta. Ahora vamos a ver cómo funciona todo esto para hacer un bypass
de AppLocker.
PoC: Jugando con las rutas y
AppLocker
En primer lugar, vamos a ver las reglas que se crean por defecto en AppLocker al activarlo. Hay que recordar
que tenemos que, en caso de no estarlo, tenemos que reiniciar el servicio de
identidad llamado Application Identity.
En la imagen se puede visualizar las reglas que Windows crea por defecto,
cuando todo está activo.
Si analizamos vemos que nos dan acceso, a cualquier usuario del sistema, a
ejecutar binarios que se encuentren en Program
Files y Windows, pero en ninguna
ruta más. Es decir, si tuviéramos un binario en el escritorio no podríamos
ejecutarlo.
Para comprobar este hecho, utilizamos el propio binario del accesschk.exe
que hemos bajado con anterioridad. Si ejecutamos el fichero accesschk.exe en la
ruta del escritorio, por ejemplo, obtendremos una denegación en la ejecución
del fichero, tal y como se puede ver en la imagen.
Pero bien, si utilizamos una ruta que se encuentre en \Windows, dónde el usuario puede copiar archivos y utilizar dicha
ruta como válida, ante la configuración por defecto de AppLocker, tendremos la posibilidad de hacer el bypass.
Como se puede ver en la anterior imagen, cuando lanzamos el fichero
accesschk.exe en una ruta como \Windows\tasks,
la cual está permitida por defecto por AppLocker,
podemos lograr la ejecución. Esto es un riesgo grande de las rutas por defecto.
Además, en sistemas como Windows 2008 R2 se probó que usuarios sin privilegios
pueden lograr la ejecución en dicha ubicación.
PoC 2: Meterpreteando el
AppLocker por defecto
En esta segunda prueba de concepto, la idea es utilizar esta característica
de Windows y su configuración por defecto, para lograr ejecutar un Meterpreter
a través de un binario utilizando la técnica denominada Weak Path Rules.
Lo primero es generarse un binario con Metasploit, por ejemplo. Utilizamos
el módulo payload/windows/meterpreter/reverse_tcp
y configuramos LHOST para que apunte a la dirección IP de la máquina del
atacante/auditor. Después, utilizamos el comando generate para generar el
binario en el formato que queramos.
En la siguiente imagen, se puede ver el fichero app.exe, ya creado. Este fichero contiene un Meterpreter apuntando
a la dirección IP del atacante/auditor. Si probamos a lanzarlo desde el
escritorio no podremos hacerlo, pero si utilizamos la ruta de \Windows\tasks lograremos su ejecución.
En la siguiente imagen, se puede ver como se genera el binario y como se
configura el módulo handler en
Metasploit para recibir la conexión inversa. Además, cuando se consigue el bypass de AppLocker vemos como logramos la sesión inversa en nuestra máquina
proveniente del equipo Windows.
Sin lugar a la duda, una interesante técnica a tener
en cuenta y utilizable en un pentest. Desde el punto de vista de la
fortificación, puede ser interesante utilizar reglas más concretas para evitar
este tipo de técnicas, que muestran lo sencillo, que, en algunas ocasiones,
puede ser esto.
No hay comentarios:
Publicar un comentario