On port 8065, the connection seems to close pretty quick.
On port, 8085 we are in vim and on port 8095 we are in nano. So it's looks like we have to escape to the shell (shell escape, see this challenge on ROOT-ME).
If you don't know the tricks by heart, you can refresh your memories with gtfoblookup:
With :!/bin/bash, we have this error: Cannot execute shell /tmp/sh. But in fact, whatever is the command we want to execute we have the same error.
:echo $FLAG2 displays the 2nd flag.
Let's see if we have more chance with nano:
Seems that the classic technic doesn't work here.
Let's get back to vim, :py doesn't work but :py3 does!
A simple os.system isn't very useful as the output is not returned as a string. The two following commands either as they try to open a shell with /bin/sh. The same apply for all reverse shell techniques as we can't use a shell.
So rather than trying harder, we can trying smarter. os.system doesn't use a shell so let's redirect the output to a file then read that file…
But for some reason whatever is use (pipe, redirection, or script) os.system seems to not be able to write to a file (only on this machine). So then open returns an error.
With :Ex we have a file explorer we can use to browse and read files.
We notice /bin points to /usr/bin that is empty so we don't have shell. At some point we may be forced to upload one (I can write text files with nano or vim, binary files with ftp or python, and we can vim functions like :call setfperm("/tmp/noraj.sh","rwxrwx---") to make binaries executable).
FTP files are in /tmp/ftp.
Uploading a static shell alone won't be very useful as no coreutils or mostly any useful binaries outside those in /usr/sbin are available.
Wait! So my :py3 experimentations were not working because /bin and /usr/bin are empty. But it seems tehre is a busybox as there are files: /etc/busybox and /etc/file/busybox. We can also see this via environment variables.
Note: 💡 :echo $ let you list all existing environment variables.
I also saw the current "shell" is /tmp/sh and there is one in /usr/forsty/sh as well but both seems "empty".
In /etc/shell we can see /usr/busybox/sh. Also /.docerenv indicates we are in a docker container.
In /proc/etc/environ we can read the following (some ideas on about how the busybox was setup).
Note :version in Vim show the compilation options and all, so it can speedup the recon rather than trying to exectue any command to see if it's available or not.
At this point I know I could upload a reverse shell binary or a busybox or something but I'm excited about rooting the box without uploading anything, I think it should be possible.
Just to verify that theory (and to prove I'm smart), let's try to do this:
Escape busybox
which bash -> /usr/bin/bash on a normal machine
We can read /proc and /proc/<id>/root is a symbolic link to the root of process
Let's create a loop over positive interger and trying to access /proc/<id>/root/usr/bin/bash
Once we found the true bash outside teh busybox we define it as shell in vim with :set shell=path/to/bash
Escape by executing :!/proc/<id>/root/usr/bin/whatever
Mess with the f**king system!
Note: in our case os.path.exists('file') is better than pathlib.Path('file').exists() because the later triggers a PermissionError while the first just return False in that case.
Now let's inline that.
Vim it!
It returns lots of IDs but teh first one is 1018.
Shell it!
:!id will return /proc/1018/root/usr/bin/bash: id: command not found because of course we still have no coreutil binaries in our PATH.
But remember? Our mission is to be smart. So what about: