Cuidado con lo que ejecutas
La primera vez que toqué un Unix fue en la escuela de informática para una asignatura que se llamaba Sistemas Abiertos. Lo primero que descubrimos era que podías hablar con la gente con una cosa que se llama talk. Después nos lo caparon, junto con el write, así que lo que nos quedaba era el famoso cat > /dev/tty para escribir directamente en la pantalla de otro. Era bastante divertido.
Una de las cosas que nos llamaba al principio a todos es que el directorio . no estaba en el path y lo achacábamos a dejadez, así que nada, todos a crearnos nuestro .login con el $PATH=$PATH:. Para que así no tener que poner el ./programa.
Al final tenía su lógica, ya que es la forma que tiene el sistema de proteger los comandos auténticos, es decir, cuando un usuario root utiliza un comando como vi, lo que quiere es que se le ejecute el autentico vi. Si el root se encuentra en una carpeta trabajando donde ha podido escribir otro programa podría crear un programa vi, que lanzara el vi autentico y creara una copia de la sh con el permiso de setuid activo. Cuando el root llamara a vi desde esa carpeta entregaría sus permisos a una shell que permitiría a cualquier usuario que la utilizase ser root.
Una idea similar ha publicado Roberto Paveza para engañar a los usuarios y “saltarse” el UAC en Vista.
El objetivo de UAC es prevenir y alertar de cualquier ejecución que requiera privilegios. Para el sistema se basa en aprovecharse de programas no firmados que haya instalados en el sistema y que estén configurados en el entorno de usuario. A la hora de crearse la barra de programas del menú de inicio se mezclan los programas de entorno de usuario y los del sistema, es decir, los accesos directos que están en All Users: C:\ProgramData\Microsoft\Windows\Start Menu y en los del usuario concreto : C:\Users\User Name\AppData\Roaming\Microsoft\Windows\Start Menu
El proceso es el que tienes en el gráfico.
1.- Te bajas un programa y lo ejecutas sin privilegios.
2.- Como el programita corre sin privilegios solo puede escribir en la carpeta de datos de usuario.
3.- El programa busca todos los accesos directos en el entorno de usuario. Si apunta a un programa firmado o a un programa de Windows no hace nada debido a que esto generaría una nueva alarma que avisaría al usuario, así que busca programas que no estén firmados o que no sean de Windows.
4.- Genera un programita que lanzará el programa original y el malware.
5.- Sustituye el acceso directo en el entorno de usuario por un nuevo acceso directo que llama al nuevo programa lanzadera.
6.- Cuando el usuario ejecuta el programa a través del acceso directo se comprueba si el usuario está corriendo como administrador para lanzar el malware. Si no lo está no hace nada y ejecuta el programa normalmente.
Este engaño está pensado para atacar entornos principalmente domesticos, donde el número de programas que se ejecutan es grande y sin un control especial. Encontrar aplicaciones que corran en entornos de usuario de estas características no es lo normal en el entorno profesional, pero el autor apunta a una muy famosa en las casas, el cliente del World of Warcraft.
Tienes el Whitepaper completo en este link, junto con una prueba de concepto.
En este caso se busca no alertar al usuario con mensajes "extraños" pero el verdadero problema sigue siendo aquellos que desactivan el UAC o que directamente hacen click a cualquier cuadro de dialogo que va a permitir que el malware siga campando a sus anchas. ¿Por qué montar todo esta arquitectura esperando encontrar programas en entorno de usuario no firmados que se ejecuten con privilegios de administrador si puedo pedirle los permisos de administrador al usario para jugar este juego tan chulo que soy yo?
3 comentarios:
Pues imaginate si se infectan de esta manera todos los usuarios de WoW que usan Vista que si tienen 8 millones de usuarios los de Blizzard seguro que al menos medio millón usa Vista en modo administrador.
Claro...ahora que lo pienso eso les pasa por jugar al WoW...8 millones de personas engañadas en el mundo por Blizzard...ains.
De hecho, en cmd.exe "." sí está en el PATH, pero en Monad/Powershell ya tienes que poner .\programa, no?
Curioso... sobretodo porque utilizan .NET para fabricar el troyano.
Aunque ahora ando "en frio" es posible que modificando las políticas del .NET Framework... tendría que mirarlo, pero por ejemplo se puede limitar la visibilidad de la reflexión de .NET, y habilitarla solo para las aplicaciones confiables.
Aun asi, cada dia parece más importante el firmar las aplicaciones, y yo soy el primero que muchas veces no lo hace :$
Muy interesante el whitepaper :)
Publicar un comentario