Esta semana, en la popular lista de correo de BugTraq, se produjo un hilo bastante interesante que capturó nuestra atención par aun artículo en Seguridad Apple. El tema principal del mismo era que el software que Apple está distribuyendo en Windows tiene errores de principiantes y puede ejecutar programas maliciosos en el equipo de las víctimas que consigan una Elevación de Privilegios o generen una Denegación de Servicio en el sistema. Al final, el bug se produce por una forma incorrecta de crear los servicios en un sistema Microsoft Windows, como vamos a ver.
Creación de servicios de forma insegura en Windows
 |
| Figura 1: Servicios de un sistema Microsoft Windows |
Creación de servicios de forma insegura en Windows
El error presentado se produce porque el programador de la aplicación para Windows, en el caso del hilo, Apple Software Update para Windows, ha creado un servicio que corre con permisos de Administración en el sistema y que es invocado a través de una DLL que se encuentra en un fichero, cuya ruta por defecto es C:\Program Files\Apple Software Update\SoftwareUpdateAdmin.dll.
El error se produce porque en vez de seguir las recomendaciones de Microsoft, al pasar a services.exe la ruta del fichero no se ha tenido en cuenta que esta presenta caracteres de espacio en la ruta, por lo que debería ser pasada entre comillas, es decir con "C:\Program Files\Apple Software Update\SoftwareUpdateAdmin.Dll" para que no hubiera ninguna confusión con el archivo que se quiere ejecutar.
Al no hacerlo, Windows busca todas las posibilidades, por lo que probará los siguientes nombres de fichero en el sistema, a ver si es capaz de localizarlos. Si localiza alguno, el primero será ejecutado y el resto no se buscarán:
- C:\Program.exe
- C:\Program Files\Apple.exe
- C:\Program Files (x86)\Apple.exe
- C:\Program Files\Apple Software.exe
- C:\Program Files (x86)\Apple Software.exe
- C:\Program Files\Apple Software Update\SoftwareUpdateAdmin.dll.
- C:\Program Files (x86)\Apple Software Update\SoftwareUpdateAdmin.dll.
Por supuesto, si no existen ningunos de los primeros, como es lo habitual, el programa acabará ejecutando el que debe, y el sistema no debería dar ningún problema. Pero si existe cualquiera de los anteriores, será ejecutado - en este caso - con permisos Administrativos y por supuesto la aplicación de Apple Software Update no funcionará en absoluto.
Es decir, se habría producido una Elevación de Privilegios para los programas maliciosos que utilicen esos nombres y una Denegación de Servicio estúpida y absurda para el sistema de actualizaciones de Apple, dejando a ese usuario sin nunca más poder actualizar su software.
Este problema no es solo de Apple Software Update, y en el hilo se pudo ver que Microsoft Windows Live Mail y el software de iCloud Control Panel de Apple también son vulnerables a este fallo, lo que podría dar mucho juego a usuarios con acceso a servidores que puedan escribir en alguno de los directorios que van a ser invocados.
Buscando más software vulnerable a este bug
Como a mí me había sorprendido lo fácil y absurdo del fallo, ayer en Eleven Paths nos juntamos a jugar un poco con este fallo y ver qué otro software podría ser vulnerable a esta técnica. En lugar de revisarnos todo los archivos, lo que hicimos fue un test bastante sencillo que orquestamos en unos minutos.
Primero hicimos un programa en .NET guardaba en un log los paths de arranque con los que era llamado, lo que nos permitiría saber qué programa había invocado a éste para que se ejecutara. Luego lo llamamos Program.exe y lo pusimos en la raíz del sistema. Después reiniciamos el sistema y vimos qué aplicaciones lo llamaban. Como se puede ver, en un equipo cualquiera fuimos capaces de ver que varios de los programas que corríamos eran vulnerables a este fallo.
 |
| Figura 2: Lista de llamadas a Program.exe |
Entre la lista que salió se encuentran Btwdins.exe que es el Servicio de BlueTooth de BroadCom Corporation. También salió el software de Microsoft Office 2013, el controlador Synaptics del TouchPad de nuestros equipos portátiles y WiseLinkPro de Samsung. Todos ellos arrancaron nuestro Program.exe en lugar del programa que deberían lanzar.
Por supuesto, todos esos programas dejaron de funcionar en el sistema y hubo que parar el experimento y reinicar el equipo para que todo volviera a la normalidad, porque los servicios que ellos querían crear no fueron los que se crearon.
Comprobándolo con Autoruns de SysInternals
Para verificar que estos programas era vulnerables es posible ir a ver con Autoruns de Sysinternals cuáles son las rutas que se lanzan, donde se puede ver que todos ellos llaman a Services.exe o a un programa externo como SynTPEnh.exe con la ruta de un fichero como parámetro sin entrecomillar. Allí encontraremos muchos servicios creados con la ruta del fichero entrecomillados, tal y como se puede ver en la siguiente imagen. Es la forma correcta de hacerlo.
 |
| Figura 3: Un servicio correctamente creado con la ruta del fichero entrecomillada |
En el caso de services.exe, Microsoft deja claro en su documentación que los servicios en Windows se crean a bajo nivel a través de la API CreateService de Advapi32.dll y que ésta recibe un parámetro con la ruta del servicio, que si tiene algún un espacio se debe estar entrecomillada.
 |
| Figura 4: Indicaciones de Microsoft para rutas pasadas por parámetros con espacios |
Así que cualquier aplicación que tire de esta API que cargue un fichero desde una ruta con espacios y no haya tenido en cuenta que debe entrecomillar la ruta, tendrá problemas. Tal y como pudimos ver con la lista de programas que salieron en nuestro experimento.
 |
| Figura 5: Microsoft Office 2013 vulnerable a este bug, que Microsoft advierte |
Eso sí, hasta el equipo de desarrollo del propio Microsoft Office 2013 olvidó seguir esta recomendación y cayó vulnerable en las pruebas.
¿Y la ejecución de programas de Logon con Explorer.exe?
En las pruebas que realizamos, decidimos mirar si pasaba lo mismo con los scripts que tiran de explorer.exe, pero como se puede ver en la siguiente prueba, tanto si se pone entrecomillada la ruta, como si no, se obtiene el mismo resultado. En nuestras pruebas, nunca se ejecutó C:\Program.exe.
 |
| Figura 6: A través de explorer.exe se ejecuta Marmita cuando va entre comillas la ruta |
 |
| Figura 7: Si va sin entrecomillar, con explorer.exe también se ejecuta Marmita y no Program.exe |
A nosotros se nos han ocurrido un buen numero de escenarios en los que podrían ser utilizadas estas técnicas. Evidentemente, escribir en C:\ no está al alcance de todos los usuarios, y menos si han tenido presente la fortificación de un sistema Windows, pero en un sistema en el que haya mucho software vulnerable, el número de carpetas que se pueden utilizar es grande. Por ejemplo, en el caso del software de BlueTooth de Broadcom, la ruta que se invoca es: C:\Program Files\WIDCOMM\Bluetooth Software\Btwdins.exe.
 |
| Figura 8: Ejecución insegura en Btwdins.exe de Broadcom Corporation |
Con esa ruta, se pueden intentar crear los siguientes tres ficheros para conseguir el mismo objetivo.
- C:\Program.exe
- C:\Program Files\WIDCOMM\BlueTooth.exe
- C:\Program Files (x86)\WIDCOMM\BlueTooth.exe
Esto parece que va a dar bastante juego, así que ya os iré contando más adelante qué se puede hacer, que estamos pensando nuevas pruebas para completar estos resultados.
Saludos Malignos!
