API obsoleta de Apple puede usarse para ejecutar códigos en root

24/08/2017

Una API obsoleta de autorización de Apple, usada por instaladores de terceros, sigue siendo la opción preferida por los desarrolladores para actualizar aplicaciones y servicios en macOS. Y eso es un problema debido a una carencia de seguridad masiva que podría ser abusada por un ciberatacante local para elevar los privilegios de root con un poco de ayuda involuntaria del usuario.

La situación es conocida y se planteó de nuevo el mes pasado durante DEF CON por el destacado investigador de seguridad de Mac, Patrick Wardle, investigador jefe de seguridad de Synack. Lo que agrava la gravedad potencial asociada con el uso continuado de la API AuthorizationExecuteWithPrivileges es que los instaladores de aplicaciones populares como Slack, Google Chrome, Dropcam de Google, VMware Fusion, numerosos actualizadores de software de seguridad y la librería de actualización de código abierto Sparkle todas llaman al API obsoleto durante las actualizaciones.

La API, explicada por Wardle, hace que el sistema muestre el cuadro de diálogo de autenticación familiar, que es manejado por un daemon separado, lo que significa que el usuario no tiene que confiar la contraseña al instalador de la aplicación. En su lugar, el sistema operativo confía y cualquier funcionalidad que necesite privilegios de administrador o de root durante la instalación puede proceder como tal.

AuthorizationExecuteWithPrivileges, sin embargo, no valida que lo que está a punto de ejecutarse en la máquina no haya sido maliciosamente modificado, dijo Wardle. Por lo tanto, un ciberatacante ya presente en el equipo y que esté ejecutando su código puede esperar a que el instalador de terceros llame a la API de autorización insegura y colgar las credenciales del usuario a medida que se introducen en el cuadro de diálogo.

"Normalmente lo que ocurre es que estas aplicaciones piden al sistema operativo que ejecute algo como root, y lo que piden ejecutar es grabable por todos, algo que está en un Temp o en el paquete de aplicaciones descargado", dijo Wardle. "Código local, malware o un ciberatacante local que ya tiene acceso básicamente puede modificar lo que está a punto de ser ejecutado como root. Dado que el sistema no verifica lo que la aplicación solicita para ser ejecutada no se haya modificado, cuando el usuario introduce sus credenciales y hace clic en instalar, el sistema ejecutará lo que se solicitó, incluso si se ha modificado de forma maliciosa”.

Wardle dijo que la situación también se extiende al instalador de Apple, que sufre de un problema separado, pero relacionado. Explicó que cuando un usuario hace doble clic en un archivo .pkg, el instalador de Apple ejecuta y busca complementos en el archivo y los copia a un Temp, cargando esas bibliotecas en el contexto de proceso de la aplicación de instalación, firmada por Apple y de confianza por el sistema operativo. Wardle dijo que un ciberatacante local puede ganar una condición de ejecutador y modificar esos paquetes antes de que estén instalados en el sistema local. Los dylibs maliciosos y sin firma, que no son verificados por la aplicación del instalador, serán cargados ciegamente, dijo Wardle. Esos dylibs maliciosos pueden crear su propia ventana de autenticación fácilmente forjada que será confiada por el sistema operativo. El usuario a continuación, introduce sus credenciales, sin darse cuenta que está dando al código malicioso permiso para ejecutar como root en la máquina.

Apple desaprobó la API AuthorizationExecuteWithPrivileges en 2013 y ahora recomienda que los desarrolladores usen otro llamado SMJobBless.

SMJobBless trabaja copiando cualquier cosa que se le pida que instale en un directorio privilegiado más alto, y una vez que está en ese directorio seguro, SMJobBless valida cifradamente que no haya sido alterado y luego le pide al usuario que se autentique.

Los desarrolladores, sin embargo, están dirigiéndose a un escenario mucho más complicado cuando optan por confiar en SMJobBless en su lugar, empezando con el hecho de que requiere a los desarrolladores de un certificado de desarrollador de Apple para realizar la firma cifrada necesaria.

"El problema es que hay una solución segura, pero cuesta dinero y es increíblemente complicado. Me tomó varias horas para que funcionara ", dijo Wardle. “Ya que la API obsoleta es literalmente como tres líneas de código. Es muy fácil y es por eso que todo el mundo lo usa. "

Wardle dijo que reveló en privado a Apple que su instalador estaba cargando bibliotecas sin firmar; Apple aún no ha respondido, dijo Wardle. También dijo que reportó el problema de la API a Google con respecto a Chrome y respondió que era consciente, y que no existe "un buen reemplazo" -incluyendo SMJobBless.

"Mirando el reemplazo seguro, es un dolor de trabajo", dijo Wardle. "Hay una compensación masiva. En un mundo ideal, todo el mundo usaría el reemplazo seguro o Apple proporcionaría un reemplazo seguro que sería más fácil de usar. Cuando los chicos de Chromium dicen que esto no es un reemplazo válido, generalmente saben de lo que están hablando ".

Artículos relacionados: