Escalando privilegios en Windows 10

El pasado 27 de agosto, la experta en ciberseguridad "SandboxEscaper" liberó en Github un exploit de escalada de privilegios local en Windows 10. El exploit, el cual enlazó desde un tweet publicado en la red social Twitter, se hizo viral rápidamente, saltando la noticia hasta varios medios generalistas:



El exploit aún se encuentra accesible, y puede ser descargado desde el siguiente enlace:
https://github.com/SandboxEscaper/randomrepo/blob/master/PoC-LPE.rar

Dentro del mismo se encuentra un completo Write-up explicando la vulnerabilidad. En concreto, el programador de tareas de Windows tiene una vulnerabilidad en la interfaz de la Llamada a Procedimiento Local Avanzada, o Advanced Local Procedure Call (ALPC), que permite a cualquier usuario elevar privilegios hasta SYSTEM.

En esta interfaz hay una llamada a la API (SchRpcSetSecurity) que no verifica correctamente los permisos. De este modo, es posible asignar permisos de forma arbitraria a través de un hard link a cualquier objeto del sistema de forma local.


El funcionamiento de la PoC es muy sencillo. En primer lugar decidiremos que proceso deseamos escalar y seleccionaremos su PID. Para ello nosotros utilizaremos el software Process Explorer:


A continuación, lanzaremos el exploit usando por ejemplo el proceso del bloc de notas (PID 4324)


Si volvemos a Process Explorer veremos como el bloc de notas es ejecutado a través del servicio de cola de impresión, esta vez, con privilegios de SYSTEM:


Ahora si intentamos realizar alguna acción que requiera privilegios, como por ejemplo abrir el archivo "hosts" situado en la ruta "C:\Windows\System32\drivers\etc", no tendremos ningún problema:


Obviamente, modificando un poco el exploit podemos olvidarnos del notepad, y ejecutar algo mucho más interesante como podría ser un Meterpreter. Después de generar nuestra propia DLL maliciosa con msfvenom, adaptamos el proyecto de Visual Studio, lo compilamos y volvemos a ejecutar...


Sin embargo, esta vez tenemos nuestro listener preparado y podemos observar como inmediatamente nos llega la sesión de Meterpreter sin problemas, y por supuesto corriendo como SYSTEM.




Os confirmamos que esta PoC ha sido realizada en un sistema Windows 10 Pro x64, actualizado con los últimos parches de seguridad, y se sabe que también afecta a Windows Server 2016. Sin embargo, con modificaciones menores es posible ejecutarlo en la versión 32 bits de Windows 10, y probablemente sea posible hacerlo funcionar en otros sistemas de Microsoft que dispongan de esta funcionalidad.

Microsoft ha reconocido la vulnerabilidad y ha anunciado que se encuentran trabajando para resolver el problema lo antes posible. Hasta entonces, cuidado con lo que ejecutáis... :)

Podéis consultar más información sobre esta vulnerabilidad en la segunda entrada que hemos realizado en nuestro blog.

¡Saludos!


Doble factor de autenticación

Aparte del uso de contraseñas seguras, una de las recomendaciones básicas a la hora de proteger nuestras cuentas online es el uso de múltiples factores de autenticación.

Esta forma de autenticación nos permite proteger una cuenta solicitando varias pruebas diferentes al usuario con el objetivo de verificar si se trata de un usuario autorizado en un sistema.

Los métodos de autenticación más comunes se dividen en:

  • Algo que sé: el método más utilizado, y es dar al sistema un secreto que sólo el usuario debería conocer. Es el caso, por ejemplo, de los pin, patrones, las contraseñas y las frases de paso.
  • Algo que soy: en los que se utilizan características propias del sujeto para poder identificarlos en un sistema. Dentro de esta categoría caerían las huellas dactilares y otras propiedades biométricas.
  • Algo que tengo: en este caso, se hace uso de un elemento que sólo el usuario debería tener, como son los token de seguridad, un teléfono móvil, etc.

Hoy en día la mayoría de servicios permiten habilitar mecanismos de doble factor de autenticación, generalmente combinando el uso de contraseñas con el envío de códigos de seguridad mediante SMS a teléfonos móviles. También existen aplicaciones móviles que permiten generar códigos de doble factor, como son Google Authenticator o Authy.

Por otro lado, podemos fijarnos en que cada cierto tiempo un servicio con miles de usuarios es hackeado, y en numerosas ocasiones este servicio no había protegido debidamente las contraseñas almacenadas en la base de datos. El resultado es que en apenas unas horas miles de usuarios y contraseñas quedan expuestas en Internet. Por si esto no fuese suficiente, acto seguido se comienzan a detectar intrusiones en numerosos servicios ajenos al hackeo, siempre a consecuencia de la gran cantidad de usuarios que reutilizan el mismo correo y contraseña para toda su vida online. En cuanto unas credenciales son descubiertas, se verifican inmediatamente esos datos en los mayores servicios de Internet para continuar comprometiendo cuentas y acceder a más información, robar datos o extorsionar a la posible víctima.

Dejando de lado que nunca deberíamos reutilizar contraseñas, y que todo el mundo debería utilizar programas como Keepass para generar contraseñas únicas para cada servicio utilizado, ¿qué sucedería en el caso anterior si un usuario que ha reutilizado contraseñas tiene el doble factor de autenticación habilitado? Pues que los criminales intentarían iniciar sesión, el sistema mandaría un código de seguridad al teléfono del usuario, y como los criminales no tienen forma de acceder a esta información ahí se acabaría el problema. Fin de la intrusión.

¿Pero qué sucede si el ataque es dirigido? Pues generalmente tres cuartos de lo mismo. El atacante casi siempre busca el vector más débil de entrada. Es por ello que en muchísimos ataques no hay necesidad de encontrar un 0-day en el firewall de la organización, ni adivinar complejas contraseñas mediante fuerza bruta... es tan sencillo como mandar una campaña dirigida de phishing (spear-phishing) a determinados empleados para que ellos mismos nos den las llaves del castillo tras ser engañados. Sin embargo, si estos mismos empleados están protegidos por un doble factor de autenticación, el potencial atacante que está intentando conectar con la contraseña recién robada se va a topar con un problema difícilmente franqueable, como es tener acceso al teléfono móvil del empleado.

Por ejemplo, reciéntemente se ha sabido que si bien durante la campaña de Obama se hizo uso de doble factor de autenticación a través de tokens de la empresa Yubico, durante los ataques mediante spear-phishing contra la campaña de Clinton o al DNC no se estaba protegiendo las cuentas con 2FA. ¿Habría evitado esto lo sucedido? Muy probablemente el resultado de los ataques habría sido distinto.

Google mismo ha reconocido que, desde que habilitó 2FA con tokens físicos a principios de 2017 para todos sus empleados, no se ha producido ni un sólo robo de cuentas

Por tanto, os recomendamos encarecidamente que habilitéis el doble factor de autenticación en todas vuestras cuentas online. 

Por cierto, ¿sabíais que podéis proteger vuestra base de datos Keepass con una Yubikey configurada en modo Challenge-Response? Para ello, sólo tenéis que descargar el plugin KeeChallenge y seguir las instrucciones de configuración paso a paso. Es muy sencillo, y una vez configurada, vuestra base de datos quedará protegida por la combinación de vuestra frase de paso y un token físico.




Enviando instrucciones ocultas a través de Gmail


Una de las características menos conocidas de Gmail hace referencia a la interpretación del carácter "." (punto) en los nombres de las cuentas de los usuarios de Gmail. Gmail no interpreta este caracter, por lo que enviar un correo electrónico a [email protected] y a [email protected] produce el mismo resultado; el usuario recibirá el correo electrónico correctamente, pero mostrará en el encabezado que el referer tiene el punto ubicado en un lugar diferente. Esta característica permite que la posición del punto se use para enviar mensajes secretos usando técnicas esteganográficas.

La técnica presentada puede tener muchos usos, y entre ellos, algunos maliciosos. En el caso de la creación de malware, la posición del punto se puede utilizar por ejemplo para camuflar los comandos enviados por correo electrónico desde un panel de control a los bots de una botnet, determinando la instrucción que deben realizar.

Para ampliar el número de instrucciones que podrían ocultarse sin la necesidad de crear cuentas de Gmail con nombres largos, una posibilidad que se nos ocurrió en el año 2015, y que presentamos como paper al congreso RootedCON 2016 mis compañeros Jesús Alcalde, Gonzalo Junquera y yo (aunque no fue seleccionada para conferencia), fue el uso de codificación binaria, tomando la existencia de un punto como un 1 lógico y la inexistencia del punto como un 0. Por ejemplo, una instrucción enviada al bot podría ser "[email protected]", y el código binario traducido sería el número 000101, que podría corresponder internamente con una instrucción del malware para capturar la cámara web del dispositivo troyanizado.

La siguiente figura presenta una tabla con el número de instrucciones que se pueden codificar utilizando esta técnica, dependiendo del tamaño de la cuenta de correo electrónico registrada en Gmail. Estas cuentas, según la política de Google, deben tener un tamaño de entre 6 y 30 caracteres, lo que determina un valor máximo de 2^(n-1), donde n es el valor máximo del carácter de una cuenta de Gmail, es decir, 536,870,912 comandos posibles; un valor suficiente para codificar todas las instrucciones de un malware u ocultar mensajes más complejos.


Recientemente, James Fisher publicó una interesante aproximación de esta técnica, que podría ser utilizada para Scam. Podéis leer el artículo completo aquí.

Esta técnica es habitualmente utilizada para crear múltiples cuentas en servicios de Internet, utilizando una única dirección de correo de Gmail, y aprovechando que en el registro en todos estos servicios no se comprueba si el email es "parecido" a uno ya registrado, simplemente suelen verificar si existe uno idéntico. De esta manera, pueden registrarse múltiples usuarios y todos los emails enviados por los proveedores de los servicios llegarán sin problemas a la cuenta de correo registrada de Gmail.

¡Saludos!

Fuente imagen: google.com