Menú principal

miércoles, 8 de septiembre de 2010

Mac OS X: Elevación de privilegios en local a través de permisos inseguros en aplicaciones

Cuando realizas una instalación de una aplicación, normalmente se realiza un gesto tan sencillo como arrastrar el contenedor ‘.app’ a carpeta /Applications/. Generalmente esto no debe suponer ningún problema siempre y cuando confiemos en la aplicación, y … en sus permisos en el sistema de archivos.



Los permisos de los ficheros que instalamos deben ser revisados a menudo, ya que hay determinadas aplicaciones que se instalan con permisos inseguros, como es el caso de ‘Zipeg’ (en su última versión).

En este caso, esta aplicación se copia en /Applications/Zipeg.app/ con permisos de drwxrwxrwx. Esto quiere decir que cualquier ususario puede crear ficheros, moverlos y remplazarlos por otros.

Con un simple comando, find /Applications/ -perm -o=w, podremos listar todos los ficheros/directorios contenidos en /Appplications/ sobre los cuales cualquier usuario tiene permisos de escritura.

Como se ve en la siguiente captura de pantalla, la aplicación Zipeg es totalmente insegura, ya que podría ser remplazada o modificada por cualquier usuario.


Poniendo manos a la obra para demostrar como poder explotar este tipo de fallos, crearemos un pequeño script bash que escuchará mediante netcat por el puerto 9999 y ejecutará el comando ‘/usr/bin/id’ como prueba de concepto.


Ese archivo lo utilizaremos para remplazar el fichero original de ‘Zipeg’ llamado ‘JavaApplicationStub’. De este modo, cuando cualquier usuario del sistema ejecute la aplicación ‘Zipeg’, en realidad estará ejecutando el script.


Esto significa que, si un usuario legitimo ejecuta Zipeg, ya sea directamente o indirectamente, por ejemplo intentando descomprimir un fichero comprimido, se lanzará el proceso de netcat.

En la siguiente captura de pantalla se puede ver como el usuario ‘usuario’ con uid 503 realiza una conexión al puerto a la escucha, obteniendo la salida de la ejecución del comando /usr/bin/id por el usuario ‘i64’ con uid 502.


Si la aplicación vulnerable requiriera permisos de administrador para su ejecución, este fallo podría permitir la elevación de privilegios a superusuario, por lo que aconsejamos vigilar los permisos de las aplicaciones instaladas en directorios como /Applications/, /bin/, etc periódicamente mediante el comando find /directorio/ -perm -o=w.

4 comentarios:

  1. Joder he ejecutado la orden de find, y tengo bastantes aplicaciones .... ¿Supone esto algún riesgo si soy solo yo el único usuario del sistema?

    ResponderEliminar
  2. Hola Ismael,

    Se trata de un fallo local, ya que para explotarlo es necesario tener una cuenta en el sistema, por lo que **en principio estas seguro**.

    Pero mas vale prevenir que curar, en muchas ocasiones se hackean equipos no por una unica vulnerabilidad, sino por un conjunto de ellas.

    Lo mas aconsejable es ajustar adecuadamente los permisos de esas aplicaciones y así no correr riesgos

    ResponderEliminar
  3. Buenas,
    Como es eso de que si la aplicacion vulnerable requiriera permisos de administracion podria permitir la elevacion de privilegios a superusuario?

    El atacante local esta reemplazando el fichero por uno propio, del que es propietario, asi que el usuario legitimo cuando use la aplicacion o la ejecuta como el mismo, o como mucho si esta setuidada la ejecuta como el propietario del fichero, que es el atacante, pero no como superusuario.

    Lo mas que se me ocurre que se puede hacer es aprovecharse de un usuario con privilegios de administracion. Si el usuario victima es el usuario Administrator, pues entonces cualquier cosa que haga el script maligno la hara como tal, y podria añadir usuarios con permisos de admin, por ejemplo. Otro posible vector de ataque seria contra un usuario no administrador pero con privilegios para serlo, de modo que las aplicaciones le piden su password antes de ejecutar alguna accion para la que requieren privilegios. Al estar el usuario esperando que esto ocurra, la aplicacion maligna podria simular el comportamiento y robar los credenciales, ademas en claro. Esto se puede extender para aplicaciones en las que ni siquiera se necesitara originalmente permisos de administracion, ya que muchos usuarios no se preguntan por que cierta aplicacion les esta pidiendo esos permisos, simplemente introducen la contraseña cuando se les pide.

    Si se me esta escapando algo de lo de la escalada de privilegios, please comment, que seria interesante.

    ResponderEliminar
  4. Hola Palako

    En realidad, cuando hemos dicho que se podrían obtener privilegios de administrador, es relativo depende el entorno.

    Pero la idea general es que, si un proceso pide elevación a superusuario (no es habitual, pero en determinado tipo de aplicaciones es necesario), el atacante podría remplazarlo por otro que también pidiera elevación, y una vez ahi ya tiene uid0, e incluso una vez con uid0 podria ejecutar el proceso original para que al usuario le resultara transparente.

    El tema de modificar un programa con setuid creo que no es posible, aunque un usuario tenga permisos de escritura sobre el mismo (ejpl: o+w), no podrá escribir en el si tiene setuid y no es el owner.

    Saludos!

    ResponderEliminar

Entrada destacada

Proteger tu cuenta de Google y de Gmail con Latch Cloud TOTP #Latch #Gmail #Google

La semana pasada se liberó la nueva versión de Latch y nuestro compañero Chema Alonso hizo un repaso de todo ello en su artículo Latch...

Otras historias relacionadas

Entradas populares