macOS Electron Applications Injection
Last updated
Last updated
Impara e pratica l'Hacking su AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica l'Hacking su GCP: HackTricks Training GCP Red Team Expert (GRTE)
Se non sai cos'è Electron, puoi trovare molte informazioni qui. Ma per ora sappi che Electron esegue node. E node ha alcuni parametri e variabili d'ambiente che possono essere usati per farlo eseguire altro codice oltre al file indicato.
Queste tecniche saranno discusse in seguito, ma di recente Electron ha aggiunto diversi flag di sicurezza per prevenirle. Questi sono i Fusibili di Electron e questi sono quelli utilizzati per prevenire alle app Electron su macOS di caricare 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 verrà validato da macOS. Prevenendo in questo modo l'iniezione di codice modificando i contenuti di questo file.
OnlyLoadAppFromAsar: Se abilitato, anziché cercare di caricare nell'ordine seguente: app.asar, app e infine default_app.asar. Controlla e utilizza solo app.asar, garantendo così che quando combinato con il fusibile embeddedAsarIntegrityValidation sia impossibile caricare codice non convalidato.
LoadBrowserProcessSpecificV8Snapshot: Se abilitato, il processo del browser utilizza il file chiamato browser_v8_context_snapshot.bin per il suo snapshot V8.
Un altro fusibile interessante che non impedirà l'iniezione di codice è:
EnableCookieEncryption: Se abilitato, il cookie store su disco è crittografato utilizzando chiavi di crittografia a livello di sistema operativo.
Puoi verificare questi flag da un'applicazione con:
Come menzionato nella documentazione, la configurazione dei Fusibili di Electron è impostata all'interno del binario di Electron che contiene da qualche parte la stringa dL7pKGdnNz796PbbjQWNKmHXBZaB9tsX.
Nelle applicazioni macOS questo si trova tipicamente in applicazione.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 il codice esadecimale (0x30 è 0 e 0x31 è 1) per modificare i valori del fusibile.
Nota che se provi a sovrascrivere il binario di Electron Framework all'interno di un'applicazione con questi byte modificati, l'applicazione non si avvierà.
Potrebbero esserci file JS/HTML esterni che un'applicazione Electron sta utilizzando, quindi un attaccante potrebbe iniettare codice in questi file la cui firma non verrà verificata ed eseguire codice arbitrario nel contesto dell'applicazione.
Tuttavia, al momento ci sono 2 limitazioni:
È necessaria l'autorizzazione kTCCServiceSystemPolicyAppBundles per modificare un'applicazione, quindi per impostazione predefinita ciò 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 aggirare 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 malizioso, rinominandolo nuovamente in app.app/Contents ed eseguendolo.
Puoi estrarre il codice dal file asar con:
E ricompilalo 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 fusibile RunAsNode è disabilitato, la variabile di ambiente ELECTRON_RUN_AS_NODE verrà ignorata e ciò non funzionerà.
Come proposto qui, potresti abusare di questa variabile di ambiente in un plist per mantenere la persistenza:
NODE_OPTIONSÈ possibile memorizzare il payload in un file diverso ed eseguirlo:
Se il fusibile EnableNodeOptionsEnvironmentVariable è disabilitato, l'app ignorerà la variabile di ambiente NODE_OPTIONS all'avvio a meno che la variabile di ambiente ELECTRON_RUN_AS_NODE sia impostata, la quale verrà ignorata se il fusibile RunAsNode è disabilitato.
Se non si imposta ELECTRON_RUN_AS_NODE, verrà visualizzato l'errore: La maggior parte delle NODE_OPTION non è supportata nelle app confezionate. Consultare la documentazione per ulteriori dettagli.
Potresti abusare di questa variabile di 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, verrà aperta una porta di debug a cui potrai connetterti (ad esempio da Chrome in chrome://inspect) e sarai in grado di iniettare codice al suo interno o addirittura avviare nuovi processi.
Per esempio:
Se il fusibile EnableNodeCliInspectArguments è disabilitato, l'app ignorerà i parametri node (come --inspect) al momento del lancio a meno che la variabile d'ambiente ELECTRON_RUN_AS_NODE sia impostata, la quale verrà ignorata se il fusibile RunAsNode è disabilitato.
Tuttavia, è comunque possibile 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 decriptati all'interno del browser e c'è un endpoint json che li restituirà).
Puoi apprendere come farlo qui e qui e utilizzare lo strumento automatico WhiteChocolateMacademiaNut o uno script semplice come:
Nel questo post sul blog, questo debug viene abusato per fare in modo che un chrome headless scarichi file arbitrari in posizioni arbitrarie.
Potresti abusare questa variabile di 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, potresti scaricare una versione precedente dell'APP e iniettare del codice al suo interno poiché otterrà comunque i privilegi TCC (a meno che la Trust Cache lo impedisca).
Le tecniche precedenti ti permetteranno di eseguire codice JS all'interno del processo dell'applicazione Electron. Tuttavia, ricorda che i processi figlio vengono eseguiti sotto lo stesso profilo sandbox dell'applicazione genitore e ereditano i loro permessi TCC. Pertanto, se desideri abusare dei diritti per accedere alla fotocamera o al microfono ad esempio, potresti semplicemente eseguire un altro binario dal processo.
Lo strumento electroniz3r può essere facilmente utilizzato per trovare applicazioni Electron vulnerabili installate e iniettare del codice al loro interno. Questo strumento cercherà di utilizzare la tecnica --inspect:
Devi compilarlo da solo e puoi usarlo in questo modo:
Impara e pratica l'Hacking su AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica l'Hacking su GCP: HackTricks Training GCP Red Team Expert (GRTE)
