macOS Electron Applications Injection
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Se non sai cos'è Electron, puoi trovare molte informazioni qui. Ma per ora sappi solo che Electron esegue node. E node ha alcuni parametri e variabili d'ambiente che possono essere utilizzati per eseguire altro codice oltre al file indicato.
Queste tecniche saranno discusse in seguito, ma recentemente Electron ha aggiunto diversi flag di sicurezza per prevenirle. Questi sono i Fuses di Electron e questi sono quelli usati per prevenire che le app Electron su macOS carichino codice arbitrario:
RunAsNode: Se disabilitato, impedisce l'uso della variabile d'ambiente ELECTRON_RUN_AS_NODE per iniettare codice.
EnableNodeCliInspectArguments: Se disabilitato, parametri come --inspect, --inspect-brk non saranno rispettati. Evitando in questo modo l'iniezione di codice.
EnableEmbeddedAsarIntegrityValidation: Se abilitato, il file asar caricato sarà validato da macOS. Prevenendo in questo modo l'iniezione di codice modificando i contenuti di questo file.
OnlyLoadAppFromAsar: Se questo è abilitato, invece di cercare di caricare nell'ordine seguente: app.asar, app e infine default_app.asar. Controllerà e utilizzerà solo app.asar, garantendo così che quando è combinato con il fuse embeddedAsarIntegrityValidation sia impossibile caricare codice non validato.
LoadBrowserProcessSpecificV8Snapshot: Se abilitato, il processo del browser utilizza il file chiamato browser_v8_context_snapshot.bin per il suo snapshot V8.
Un altro fuse interessante che non impedirà l'iniezione di codice è:
EnableCookieEncryption: Se abilitato, il cookie store su disco è crittografato utilizzando chiavi crittografiche a livello di OS.
Puoi controllare questi flag da un'applicazione con:
Come menzionato nella documentazione, la configurazione delle Fuses di Electron è configurata all'interno del binario di Electron che contiene da qualche parte la stringa dL7pKGdnNz796PbbjQWNKmHXBZaB9tsX.
Nelle applicazioni macOS, questo si trova tipicamente in application.app/Contents/Frameworks/Electron Framework.framework/Electron Framework
Puoi caricare questo file in https://hexed.it/ e cercare la stringa precedente. Dopo questa stringa puoi vedere in ASCII un numero "0" o "1" che indica se ogni fusibile è disabilitato o abilitato. Modifica semplicemente il codice esadecimale (0x30 è 0 e 0x31 è 1) per modificare i valori dei fusibili.
Nota che se provi a sovrascrivere il binario del Framework Electron all'interno di un'applicazione con questi byte modificati, l'app non verrà eseguita.
Potrebbero esserci file JS/HTML esterni che un'app Electron sta utilizzando, quindi un attaccante potrebbe iniettare codice in questi file la cui firma non verrà controllata ed eseguire codice arbitrario nel contesto dell'app.
Tuttavia, al momento ci sono 2 limitazioni:
Il permesso kTCCServiceSystemPolicyAppBundles è necessario per modificare un'app, quindi per impostazione predefinita questo non è più possibile.
Il file compilato asap di solito ha i fusibili embeddedAsarIntegrityValidation e onlyLoadAppFromAsar abilitati
Rendendo questo percorso di attacco più complicato (o impossibile).
Nota che è possibile eludere il requisito di kTCCServiceSystemPolicyAppBundles copiando l'applicazione in un'altra directory (come /tmp), rinominando la cartella app.app/Contents in app.app/NotCon, modificando il file asar con il tuo codice maligno, rinominandolo di nuovo in app.app/Contents ed eseguendolo.
Puoi estrarre il codice dal file asar con:
E imballalo di nuovo dopo averlo modificato con:
ELECTRON_RUN_AS_NODESecondo la documentazione, se questa variabile di ambiente è impostata, avvierà il processo come un normale processo Node.js.
Se il fuse RunAsNode è disabilitato, la variabile d'ambiente ELECTRON_RUN_AS_NODE verrà ignorata e questo non funzionerà.
Come proposto qui, potresti abusare di questa variabile d'ambiente in un plist per mantenere la persistenza:
NODE_OPTIONSPuoi memorizzare il payload in un file diverso ed eseguirlo:
Se il fuse EnableNodeOptionsEnvironmentVariable è disabilitato, l'app ignorerà la variabile d'ambiente NODE_OPTIONS quando viene avviata, a meno che la variabile d'ambiente ELECTRON_RUN_AS_NODE non sia impostata, che sarà anch'essa ignorata se il fuse RunAsNode è disabilitato.
Se non imposti ELECTRON_RUN_AS_NODE, troverai l'errore: Most NODE_OPTIONs are not supported in packaged apps. See documentation for more details.
Potresti abusare di questa variabile d'ambiente in un plist per mantenere la persistenza aggiungendo queste chiavi:
Secondo questo, se esegui un'applicazione Electron con flag come --inspect, --inspect-brk e --remote-debugging-port, una porta di debug sarà aperta così potrai connetterti ad essa (ad esempio da Chrome in chrome://inspect) e sarai in grado di iniettare codice su di essa o persino avviare nuovi processi.
Per esempio:
Se il fuse EnableNodeCliInspectArguments è disabilitato, l'app ignorerà i parametri node (come --inspect) quando viene avviata, a meno che la variabile di ambiente ELECTRON_RUN_AS_NODE non sia impostata, che sarà anch'essa ignorata se il fuse RunAsNode è disabilitato.
Tuttavia, puoi comunque utilizzare il parametro electron --remote-debugging-port=9229 ma il payload precedente non funzionerà per eseguire altri processi.
Utilizzando il parametro --remote-debugging-port=9222 è possibile rubare alcune informazioni dall'App Electron come la cronologia (con comandi GET) o i cookie del browser (poiché sono decrittografati all'interno del browser e c'è un endpoint json che li fornirà).
Puoi imparare come farlo qui e qui e utilizzare lo strumento automatico WhiteChocolateMacademiaNut o uno script semplice come:
In questo post del blog, questo debug viene abusato per far sì che un chrome headless scarichi file arbitrari in posizioni arbitrarie.
Potresti abusare di questa variabile d'ambiente in un plist per mantenere la persistenza aggiungendo queste chiavi:
Il demone TCC di macOS non controlla la versione eseguita dell'applicazione. Quindi, se non puoi iniettare codice in un'applicazione Electron con nessuna delle tecniche precedenti, puoi scaricare una versione precedente dell'APP e iniettare codice su di essa poiché otterrà comunque i privilegi TCC (a meno che il Trust Cache non lo impedisca).
Le tecniche precedenti ti permetteranno di eseguire codice JS all'interno del processo dell'applicazione electron. Tuttavia, ricorda che i processi figli vengono eseguiti sotto lo stesso profilo sandbox dell'applicazione padre e erediteranno i loro permessi TCC. Pertanto, se desideri abusare dei diritti per accedere alla fotocamera o al microfono, ad esempio, puoi semplicemente eseguire un altro binario dal processo.
Lo strumento electroniz3r può essere facilmente utilizzato per trovare applicazioni electron vulnerabili installate e iniettare codice su di esse. Questo strumento cercherà di utilizzare la tecnica --inspect:
Devi compilarlo tu stesso e puoi usarlo in questo modo:
Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
