macOS Electron Applications Injection
Informazioni di Base
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.
Fusibili di Electron
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'ambienteELECTRON_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 fileasar
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 infinedefault_app.asar
. Controlla e utilizza solo app.asar, garantendo così che quando combinato con il fusibileembeddedAsarIntegrityValidation
sia impossibile caricare codice non convalidato.LoadBrowserProcessSpecificV8Snapshot
: Se abilitato, il processo del browser utilizza il file chiamatobrowser_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.
Verifica dei Fusibili di Electron
Puoi verificare questi flag da un'applicazione con:
Modificare i Fusibili di Electron
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à.
RCE aggiungendo codice alle Applicazioni Electron
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 fusibiliembeddedAsarIntegrityValidation
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:
RCE con ELECTRON_RUN_AS_NODE
ELECTRON_RUN_AS_NODE
Secondo 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à.
Iniezione dal Plist dell'App
Come proposto qui, potresti abusare di questa variabile di ambiente in un plist per mantenere la persistenza:
RCE con NODE_OPTIONS
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.
Iniezione dall'App Plist
Potresti abusare di questa variabile di ambiente in un plist per mantenere la persistenza aggiungendo queste chiavi:
RCE con ispezione
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.
Iniezione dal Plist dell'App
Potresti abusare questa variabile di ambiente in un plist per mantenere la persistenza aggiungendo queste chiavi:
Bypass TCC sfruttando le versioni precedenti
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).
Esegui codice non JS
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.
Iniezione automatica
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:
Riferimenti
Last updated