macOS Electron Applications Injection
Last updated
Last updated
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
Si no sabes qué es Electron, puedes encontrar mucha información aquí. Pero por ahora solo debes saber que Electron ejecuta node. Y node tiene algunos parámetros y variables de entorno que se pueden usar para hacer que ejecute otro código además del archivo indicado.
Estas técnicas se discutirán a continuación, pero en tiempos recientes Electron ha añadido varios flags de seguridad para prevenirlos. Estos son los Fusibles de Electron y estos son los que se utilizan para prevenir que las aplicaciones Electron en macOS carguen código arbitrario:
RunAsNode: Si está deshabilitado, impide el uso de la variable de entorno ELECTRON_RUN_AS_NODE para inyectar código.
EnableNodeCliInspectArguments: Si está deshabilitado, parámetros como --inspect, --inspect-brk no serán respetados. Evitando así la forma de inyectar código.
EnableEmbeddedAsarIntegrityValidation: Si está habilitado, el archivo asar cargado será validado por macOS. Previniendo de esta manera la inyección de código al modificar el contenido de este archivo.
OnlyLoadAppFromAsar: Si esto está habilitado, en lugar de buscar cargar en el siguiente orden: app.asar, app y finalmente default_app.asar. Solo verificará y usará app.asar, asegurando así que cuando se combine con el fusible embeddedAsarIntegrityValidation sea imposible cargar código no validado.
LoadBrowserProcessSpecificV8Snapshot: Si está habilitado, el proceso del navegador utiliza el archivo llamado browser_v8_context_snapshot.bin para su instantánea V8.
Otro fusible interesante que no impedirá la inyección de código es:
EnableCookieEncryption: Si está habilitado, el almacenamiento de cookies en disco está cifrado utilizando claves criptográficas a nivel de OS.
Puedes comprobar estos flags desde una aplicación con:
Como mencionan los docs, la configuración de los Fuses de Electron se encuentra dentro del binario de Electron que contiene en algún lugar la cadena dL7pKGdnNz796PbbjQWNKmHXBZaB9tsX.
En las aplicaciones de macOS, esto se encuentra típicamente en application.app/Contents/Frameworks/Electron Framework.framework/Electron Framework
Podrías cargar este archivo en https://hexed.it/ y buscar la cadena anterior. Después de esta cadena, puedes ver en ASCII un número "0" o "1" que indica si cada fusible está deshabilitado o habilitado. Simplemente modifica el código hex (0x30 es 0 y 0x31 es 1) para modificar los valores de los fusibles.
Ten en cuenta que si intentas sobrescribir el binario de Electron Framework dentro de una aplicación con estos bytes modificados, la aplicación no se ejecutará.
Podría haber archivos JS/HTML externos que una aplicación Electron esté utilizando, por lo que un atacante podría inyectar código en estos archivos cuya firma no será verificada y ejecutar código arbitrario en el contexto de la aplicación.
Sin embargo, en este momento hay 2 limitaciones:
Se necesita el permiso kTCCServiceSystemPolicyAppBundles para modificar una aplicación, por lo que por defecto esto ya no es posible.
El archivo compilado asap generalmente tiene los fusibles embeddedAsarIntegrityValidation y onlyLoadAppFromAsar habilitados
Haciendo que esta ruta de ataque sea más complicada (o imposible).
Ten en cuenta que es posible eludir el requisito de kTCCServiceSystemPolicyAppBundles copiando la aplicación a otro directorio (como /tmp), renombrando la carpeta app.app/Contents a app.app/NotCon, modificando el archivo asar con tu código malicioso, renombrándolo de nuevo a app.app/Contents y ejecutándolo.
Puedes descomprimir el código del archivo asar con:
Y empaquétalo de nuevo después de haberlo modificado con:
ELECTRON_RUN_AS_NODESegún la documentación, si esta variable de entorno está configurada, iniciará el proceso como un proceso normal de Node.js.
Si el fuse RunAsNode está deshabilitado, la variable de entorno ELECTRON_RUN_AS_NODE será ignorada, y esto no funcionará.
Como se propone aquí, podrías abusar de esta variable de entorno en un plist para mantener la persistencia:
NODE_OPTIONSPuedes almacenar la carga útil en un archivo diferente y ejecutarla:
Si el fuse EnableNodeOptionsEnvironmentVariable está deshabilitado, la aplicación ignora la variable de entorno NODE_OPTIONS al iniciarse, a menos que la variable de entorno ELECTRON_RUN_AS_NODE esté configurada, la cual también será ignorada si el fuse RunAsNode está deshabilitado.
Si no configuras ELECTRON_RUN_AS_NODE, encontrarás el error: Most NODE_OPTIONs are not supported in packaged apps. See documentation for more details.
Podrías abusar de esta variable de entorno en un plist para mantener la persistencia añadiendo estas claves:
Según esto, si ejecutas una aplicación Electron con banderas como --inspect, --inspect-brk y --remote-debugging-port, se abrirá un puerto de depuración para que puedas conectarte a él (por ejemplo, desde Chrome en chrome://inspect) y podrás inyectar código en él o incluso lanzar nuevos procesos.
Por ejemplo:
Si el fuse EnableNodeCliInspectArguments está deshabilitado, la aplicación ignorará los parámetros de node (como --inspect) al iniciarse, a menos que la variable de entorno ELECTRON_RUN_AS_NODE esté configurada, la cual también será ignorada si el fuse RunAsNode está deshabilitado.
Sin embargo, aún podrías usar el parámetro de electron --remote-debugging-port=9229 pero la carga útil anterior no funcionará para ejecutar otros procesos.
Usando el parámetro --remote-debugging-port=9222 es posible robar información de la aplicación Electron como el historial (con comandos GET) o las cookies del navegador (ya que están desencriptadas dentro del navegador y hay un endpoint json que las proporcionará).
Puedes aprender a hacer eso aquí y aquí y usar la herramienta automática WhiteChocolateMacademiaNut o un script simple como:
En esta publicación de blog, este depurador se abusa para hacer que un chrome sin cabeza descargue archivos arbitrarios en ubicaciones arbitrarias.
Podrías abusar de esta variable de entorno en un plist para mantener la persistencia añadiendo estas claves:
El daemon TCC de macOS no verifica la versión ejecutada de la aplicación. Así que si no puedes inyectar código en una aplicación Electron con ninguna de las técnicas anteriores, podrías descargar una versión anterior de la APP e inyectar código en ella, ya que aún obtendrá los privilegios de TCC (a menos que Trust Cache lo impida).
Las técnicas anteriores te permitirán ejecutar código JS dentro del proceso de la aplicación electron. Sin embargo, recuerda que los procesos secundarios se ejecutan bajo el mismo perfil de sandbox que la aplicación principal y heredan sus permisos de TCC. Por lo tanto, si deseas abusar de los derechos para acceder a la cámara o al micrófono, por ejemplo, podrías simplemente ejecutar otro binario desde el proceso.
La herramienta electroniz3r se puede usar fácilmente para encontrar aplicaciones electron vulnerables instaladas e inyectar código en ellas. Esta herramienta intentará usar la técnica --inspect:
Necesitas compilarla tú mismo y puedes usarla así:
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
