Bypass FS protections: read-only / no-exec / Distroless
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)
If you are interested in hacking career and hack the unhackable - we are hiring! (wymagana biegła znajomość polskiego w mowie i piśmie).
In the following videos you can find the techniques mentioned in this page explained more in depth:
It's more and more common to find linux machines mounted with read-only (ro) file system protection, specially in containers. This is because to run a container with ro file system is as easy as setting readOnlyRootFilesystem: true in the securitycontext:
However, even if the file system is mounted as ro, /dev/shm will still be writable, so it's fake we cannot write anything in the disk. However, this folder will be mounted with no-exec protection, so if you download a binary here you won't be able to execute it.
From a red team perspective, this makes complicated to download and execute binaries that aren't in the system already (like backdoors o enumerators like kubectl).
Note that I mentioned binaries, you can execute any script as long as the interpreter is inside the machine, like a shell script if sh is present or a python script if python is installed.
However, this isn't just enough to execute your binary backdoor or other binary tools you might need to run.
If you want to execute a binary but the file system isn't allowing that, the best way to do so is by executing it from memory, as the protections doesn't apply in there.
If you have some powerful script engines inside the machine, such as Python, Perl, or Ruby you could download the binary to execute from memory, store it in a memory file descriptor (create_memfd syscall), which isn't going to be protected by those protections and then call a exec syscall indicating the fd as the file to execute.
For this you can easily use the project fileless-elf-exec. You can pass it a binary and it will generate a script in the indicated language with the binary compressed and b64 encoded with the instructions to decode and decompress it in a fd created calling create_memfd syscall and a call to the exec syscall to run it.
This doesn't work in other scripting languages like PHP or Node because they don't have any default way to call raw syscalls from a script, so it's not possible to call create_memfd to create the memory fd to store the binary.
Moreover, creating a regular fd with a file in /dev/shm won't work, as you won't be allowed to run it because the no-exec protection will apply.
DDexec / EverythingExec is a technique that allows you to modify the memory your own process by overwriting its /proc/self/mem.
Therefore, controlling the assembly code that is being executed by the process, you can write a shellcode and "mutate" the process to execute any arbitrary code.
DDexec / EverythingExec will allow you to load and execute your own shellcode or any binary from memory.
For more information about this technique check the Github or:
DDexec / EverythingExecMemexec to naturalny następny krok DDexec. To DDexec shellcode demonizowane, więc za każdym razem, gdy chcesz uruchomić inny plik binarny, nie musisz ponownie uruchamiać DDexec, możesz po prostu uruchomić shellcode memexec za pomocą techniki DDexec, a następnie komunikować się z tym demonem, aby przekazać nowe pliki binarne do załadowania i uruchomienia.
Możesz znaleźć przykład, jak użyć memexec do wykonywania plików binarnych z odwróconego powłoki PHP w https://github.com/arget13/memexec/blob/main/a.php.
Z podobnym celem do DDexec, technika memdlopen umożliwia łatwiejszy sposób ładowania plików binarnych w pamięci, aby później je wykonać. Może nawet pozwolić na ładowanie plików binarnych z zależnościami.
Kontenery distroless zawierają tylko najmniejsze niezbędne komponenty do uruchomienia konkretnej aplikacji lub usługi, takie jak biblioteki i zależności uruchomieniowe, ale wykluczają większe komponenty, takie jak menedżer pakietów, powłoka czy narzędzia systemowe.
Celem kontenerów distroless jest zmniejszenie powierzchni ataku kontenerów poprzez eliminację niepotrzebnych komponentów i minimalizację liczby podatności, które mogą być wykorzystane.
W kontenerze distroless możesz nawet nie znaleźć sh ani bash, aby uzyskać zwykłą powłokę. Nie znajdziesz również plików binarnych takich jak ls, whoami, id... wszystko, co zwykle uruchamiasz w systemie.
Dlatego nie będziesz w stanie uzyskać odwróconej powłoki ani enumerować systemu, jak zwykle to robisz.
Jednak jeśli skompromitowany kontener uruchamia na przykład aplikację flask, to python jest zainstalowany, a zatem możesz uzyskać odwróconą powłokę Pythona. Jeśli uruchamia node, możesz uzyskać odwróconą powłokę Node, i to samo z większością języków skryptowych.
Używając języka skryptowego, możesz enumerować system korzystając z możliwości języka.
Jeśli nie ma ochron read-only/no-exec, możesz wykorzystać swoją odwróconą powłokę do zapisywania w systemie plików swoich plików binarnych i wykonywania ich.
Jednak w tego rodzaju kontenerach te zabezpieczenia zazwyczaj będą istnieć, ale możesz użyć wcześniejszych technik wykonania w pamięci, aby je obejść.
Możesz znaleźć przykłady na to, jak wykorzystać niektóre podatności RCE, aby uzyskać odwrócone powłoki języków skryptowych i wykonywać pliki binarne z pamięci w https://github.com/carlospolop/DistrolessRCE.
If you are interested in hacking career and hack the unhackable - we are hiring! (fluent polish written and spoken required).
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
