Bypass FS protections: read-only / no-exec / Distroless
Se sei interessato alla carriera dell'hacking e vuoi hackerare l'inviolabile - stiamo assumendo! (richiesta competenza polacca scritta e parlata).
Video
Nei seguenti video puoi trovare le tecniche menzionate in questa pagina spiegate più approfonditamente:
Scenario di sola lettura / no-exec
È sempre più comune trovare macchine Linux montate con protezione del file system in sola lettura (ro), specialmente nei container. Questo perché eseguire un container con file system in sola lettura è semplice come impostare readOnlyRootFilesystem: true nel securitycontext:
Tuttavia, anche se il file system è montato come ro, /dev/shm sarà comunque scrivibile, quindi è falso che non possiamo scrivere nulla sul disco. Tuttavia, questa cartella sarà montata con protezione no-exec, quindi se scarichi un binario qui non sarai in grado di eseguirlo.
Dal punto di vista di un red team, questo rende complicato scaricare ed eseguire binari che non sono già nel sistema (come backdoor o enumerator come kubectl).
Bypass più semplice: Script
Nota che ho menzionato binari, puoi eseguire qualsiasi script purché l'interprete sia all'interno della macchina, come uno script shell se è presente sh o uno script python se è installato python.
Tuttavia, questo non è sufficiente per eseguire la tua backdoor binaria o altri strumenti binari che potresti aver bisogno di eseguire.
Bypass di memoria
Se vuoi eseguire un binario ma il file system non lo consente, il modo migliore per farlo è eseguirlo dalla memoria, poiché le protezioni non si applicano lì.
Bypass syscall FD + exec
Se hai alcuni potenti motori di script all'interno della macchina, come Python, Perl o Ruby, potresti scaricare il binario da eseguire dalla memoria, memorizzarlo in un descrittore di file di memoria (create_memfd syscall), che non sarà protetto da tali protezioni e quindi chiamare una syscall exec indicando il fd come file da eseguire.
Per fare ciò puoi facilmente utilizzare il progetto fileless-elf-exec. Puoi passargli un binario e genererà uno script nella lingua indicata con il binario compresso e codificato in b64 con le istruzioni per decodificarlo e decomprimerlo in un fd creato chiamando la syscall create_memfd e una chiamata alla syscall exec per eseguirlo.
Questo non funziona in altri linguaggi di scripting come PHP o Node perché non hanno un modo predefinito per chiamare le syscall grezze da uno script, quindi non è possibile chiamare create_memfd per creare il fd di memoria per memorizzare il binario.
Inoltre, creare un fd regolare con un file in /dev/shm non funzionerà, poiché non ti sarà consentito eseguirlo perché si applicherà la protezione no-exec.
DDexec / EverythingExec
DDexec / EverythingExec è una tecnica che ti consente di modificare la memoria del tuo stesso processo sovrascrivendo il suo /proc/self/mem.
Pertanto, controllando il codice assembly che viene eseguito dal processo, puoi scrivere uno shellcode e "mutare" il processo per eseguire qualsiasi codice arbitrario.
DDexec / EverythingExec ti permetterà di caricare ed eseguire il tuo shellcode o qualsiasi binario dalla memoria.
Per ulteriori informazioni su questa tecnica controlla il Github o:
pageDDexec / EverythingExecMemExec
Memexec è il passo successivo naturale di DDexec. È un shellcode demonizzato di DDexec, quindi ogni volta che vuoi eseguire un binario diverso non è necessario riavviare DDexec, puoi semplicemente eseguire il shellcode memexec tramite la tecnica DDexec e poi comunicare con questo demone per passare nuovi binari da caricare ed eseguire.
Puoi trovare un esempio su come utilizzare memexec per eseguire binari da una shell inversa PHP in https://github.com/arget13/memexec/blob/main/a.php.
Memdlopen
Con uno scopo simile a DDexec, la tecnica memdlopen consente un modo più semplice di caricare binari in memoria per eseguirli successivamente. Potrebbe persino consentire di caricare binari con dipendenze.
Bypass Distroless
Cos'è Distroless
I container Distroless contengono solo i componenti minimi necessari per eseguire un'applicazione o un servizio specifico, come librerie e dipendenze di runtime, ma escludono componenti più grandi come un gestore di pacchetti, shell o utility di sistema.
L'obiettivo dei container Distroless è ridurre la superficie di attacco dei container eliminando componenti non necessari e riducendo al minimo il numero di vulnerabilità che possono essere sfruttate.
Shell Inversa
In un container Distroless potresti non trovare nemmeno sh o bash per ottenere una shell regolare. Non troverai nemmeno binari come ls, whoami, id... tutto ciò che di solito esegui in un sistema.
Pertanto, non sarai in grado di ottenere una shell inversa o enumerare il sistema come fai di solito.
Tuttavia, se il container compromesso sta eseguendo ad esempio un'applicazione web Flask, allora Python è installato e quindi puoi ottenere una shell inversa Python. Se sta eseguendo node, puoi ottenere una shell inversa di Node, e lo stesso con la maggior parte dei linguaggi di scripting.
Utilizzando il linguaggio di scripting potresti enumerare il sistema sfruttando le capacità del linguaggio.
Se non ci sono protezioni read-only/no-exec potresti abusare della tua shell inversa per scrivere nel file system i tuoi binari ed eseguirli.
Tuttavia, in questo tipo di container queste protezioni di solito esistono, ma potresti utilizzare le tecniche di esecuzione in memoria precedenti per aggirarle.
Puoi trovare esempi su come sfruttare alcune vulnerabilità RCE per ottenere shell inverse di linguaggi di scripting ed eseguire binari dalla memoria in https://github.com/carlospolop/DistrolessRCE.
Se sei interessato a una carriera nell'hacking e ad hackerare l'impossibile - stiamo assumendo! (richiesta competenza polacca scritta e parlata).
Last updated
