3 ms·
It still requires a process to run. AFAICT the probe only puts an entry in a map, which a userspace process reads from and launches a shell. So, while the trigg
by bboozzoo 5y ago
It still requires a process to run. AFAICT the probe only puts an entry in a map, which a userspace process reads from and launches a shell. So, while the triggering mechanism remains hidden, the process that launches the shell needs to take more steps to hide itself. Once it starts pinning the map (which is only possible to do within the bpf fs), it probably has to employ various tricks like unshare to a new mount ns to mount a new instance of bpffs. At the same time, the shell-spawning-process need to have enough privileges to load a BPF program in the first place.
- kris-nova 5y agoThis is a great comment! Next steps are BPF pinning and probably a few userspace hiding tactics. Constraints for the project is that I will not use a kernel module or LD Preload. Additionally I’m going to have sets of triggers in addition to a bad IPv4 checksum. Most modern network equipment will drop the malformed packet long before it reaches a target with a bad checksum. Other ideas are encapsulating RCE over IPv6 (there are 24 bytes available) and using SYNACK retries and TCP RST to also trigger the reverse protocol. We can also probably slim compile time and runtime dependencies down if we lose the hacky double ncat protocol thing I have going on and just open up a reverse socket directly. Which means we should also have the remote not run as root for obvious reasons. I have a lot of ideas, as our friends in Ukraine tell me their needs I’ll be posting more research to the repository to aid them as much as possible.
- deleted 5y ago[deleted]