ddexec.md (5315B)
1 --- 2 title: "DDexec / EverythingExec" 3 section: "Linux" 4 sectionSlug: "linux-hardening" 5 sourcePath: "src/linux-hardening/linux-basics/bypass-linux-restrictions/bypass-fs-protections-read-only-no-exec-distroless/ddexec.md" 6 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/linux-hardening/linux-basics/bypass-linux-restrictions/bypass-fs-protections-read-only-no-exec-distroless/ddexec.md" 7 sha: "188de82beb54e70956b2952367a0af91d26758b8" 8 isIndex: false 9 modified: true 10 license: "CC-BY-NC-4.0" 11 --- 12 13 # DDexec / EverythingExec 14 15 ## Context 16 17 In Linux in order to run a program it must exist as a file, it must be accessible in some way through the file system hierarchy (this is just how `execve()` works). This file may reside on disk or in ram (tmpfs, memfd) but you need a filepath. This has made very easy to control what is run on a Linux system, it makes easy to detect threats and attacker's tools or to prevent them from trying to execute anything of theirs at all (_e. g._ not allowing unprivileged users to place executable files anywhere). 18 19 But this technique is here to change all of this. If you can not start the process you want... **then you hijack one already existing**. 20 21 This technique allows you to **bypass common protection techniques such as read-only, noexec, file-name whitelisting, hash whitelisting**.<sup>[[1]](#references)</sup> 22 23 ## Dependencies 24 25 The final script depends on the following tools to work, they need to be accessible in the system you are attacking (by default you will find all of them everywhere): 26 27 ```text 28 dd 29 bash | zsh | ash (busybox) 30 head 31 tail 32 cut 33 grep 34 od 35 readlink 36 wc 37 tr 38 base64 39 ``` 40 41 ## The technique 42 43 If you are able to modify arbitrarily the memory of a process then you can take over it. This can be used to hijack an already existing process and replace it with another program. We can achieve this either by using the `ptrace()` syscall (which requires you to have the ability to execute syscalls or to have gdb available on the system) or, more interestingly, writing to `/proc/$pid/mem`.<sup>[[1]](#references)</sup> 44 45 The file `/proc/$pid/mem` is a one-to-one mapping of the entire address space of a process (_e. g._ from `0x0000000000000000` to `0x7ffffffffffff000` in x86-64). This means that reading from or writing to this file at an offset `x` is the same as reading from or modifying the contents at the virtual address `x`. 46 47 Now, we have four basic problems to face: 48 49 - In general, only root and the program owner of the file may modify it. 50 - ASLR. 51 - If we try to read or write to an address not mapped in the address space of the program we will get an I/O error. 52 53 This problems have solutions that, although they are not perfect, are good: 54 55 - Most shell interpreters allow the creation of file descriptors that will then be inherited by child processes. We can create a fd pointing to the `mem` file of the sell with write permissions... so child processes that use that fd will be able to modify the shell's memory. 56 - ASLR isn't even a problem, we can check the shell's `maps` file or any other from the procfs in order to gain information about the address space of the process. 57 - So we need to `lseek()` over the file. From the shell this cannot be done unless using the infamous `dd`. 58 59 ### In more detail 60 61 The steps are relatively easy and do not require any kind of expertise to understand them:<sup>[[1]](#references)</sup> 62 63 - Parse the binary we want to run and the loader to find out what mappings they need. Then craft a "shell"code that will perform, broadly speaking, the same steps that the kernel does upon each call to `execve()`: 64 - Create said mappings. 65 - Read the binaries into them. 66 - Set up permissions. 67 - Finally initialize the stack with the arguments for the program and place the auxiliary vector (needed by the loader). 68 - Jump into the loader and let it do the rest (load libraries needed by the program). 69 - Obtain from the `syscall` file the address to which the process will return after the syscall it is executing. 70 - Overwrite that place, which will be executable, with our shellcode (through `mem` we can modify unwritable pages). 71 - Pass the program we want to run to the stdin of the process (will be `read()` by said "shell"code). 72 - At this point it is up to the loader to load the necessary libraries for our program and jump into it. 73 74 **Check out the tool in** [**https://github.com/arget13/DDexec**](https://github.com/arget13/DDexec).<sup>[[1]](#references)</sup> 75 76 ## EverythingExec 77 78 There are several alternatives to `dd`, one of which, `tail`, is currently the default program used to `lseek()` through the `mem` file (which was the sole purpose for using `dd`). Said alternatives are:<sup>[[1]](#references)</sup> 79 80 ```bash 81 tail 82 hexdump 83 cmp 84 xxd 85 ``` 86 87 Setting the variable `SEEKER` you may change the seeker used, _e. g._: 88 89 ```bash 90 SEEKER=cmp bash ddexec.sh ls -l <<< $(base64 -w0 /bin/ls) 91 ``` 92 93 If you find another valid seeker not implemented in the script you may still use it setting the `SEEKER_ARGS` variable: 94 95 ```bash 96 SEEKER=xxd SEEKER_ARGS='-s $offset' zsh ddexec.sh ls -l <<< $(base64 -w0 /bin/ls) 97 ``` 98 99 Block this, EDRs. 100 101 ## References 102 103 - [1] [DDexec: A technique to run binaries filelessly and stealthily on Linux](https://github.com/arget13/DDexec)