"This is NOT an exploit! This requires prior priviliged access on a server in order to work!"
So what is the point? If you have priviliged access you can do anything.
> I assume this goes without saying but obviously this isn't going to go root any old TCP server folks. You need to have root on a box first, install the rootkit, and then its effectively a backdoor. This isn't going to go pop TCP servers in the wild. Also important to call out that any networking equipment worth its weight is going to block these malicious packets long before they reach the host.
This is not an exploit. This is not a vulnerability.
This is a research project that demonstrates how to access a system in unconventional ways. This allows a user with previously privileged access to install boopkit so they can access with the same privileges again in the future without SSH or other conventional methods.
This is so funny. I watched your stream yesterday for the first time randomly.
Never heard about eBPF before. Since then I've read up on eBPF and its use in low-latency engineering, which I found fascinating. And now I see your post here.
Backdoors are typically installed by privileged users and allow for an arbitrary person to do something to get to that privilege level. The point of installing a backdoor is to maintain your privilege level even if you get found out / or you only were at that privilege level for a period of time.
You may be thinking of privilege escalation vulnerabilities which allow you to run things at a higher privilege level than you are supposed to have. i.e. Running something as root if you are only supposed to be able to run things as a normal user. In a way a backdoor is a privilege escalation vulnerability that you deliberately put into a system.
In addition to the sibling comment, this is particularly backdoorish as it can remain largely hidden until used as it doesn't need a new permanently listening local process, or modification of an existing process, to start the shell (BPF takes care of that) and it can run over existing ports on a system that would already be open on a firewall.
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.
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.
- Bad-bpf: https://github.com/pathtofile/bad-bpf
- Offensive BPF: https://embracethered.com/blog/posts/2021/offensive-bpf/
- Ebpf, I thought we were friends: https://m.youtube.com/watch?v=5zixNDolLrg