STS: Blowfish - Level 3

This was an interesting stage which took a little google research. When we connect, we're dropped into an rbash shell. This is a restricted shell which we have limited power. What I mean by this is that we have limited access to commands like "ls" or anything really in /bin. Trying to run a command with a full path yields:


level3@blowfish:~$ /bin/ls
-rbash: /bin/ls: restricted: cannot specify `/' in command names

This stinks! So after doing some research on bypassing rbash, it appears if we can invoke a different shell, bash/sh, we are free to go. The only problem is that we cannot give it a full path to the binary and issuing the "sh" command doesn't seem to work. So let's check our PATH envar and see if we can edit it.


level3@blowfish:~$ echo $PATH
/home/rbash
level3@blowfish:~$ export PATH=/bin
-rbash: PATH: readonly variable

Doh! It doesn't seem like we can edit it. After some thinking, I wondered if I can invoke the perl command and launch the "sh" command via the system() function.

Getting shell

Perfect! Now that we've gained shell, we still need to find a backdoor onto the next level. Like the previous challenge, I'll just use find to see any suid binaries owned by level4 and complete the challenge.

SPOILER! Highlight below to view the password:

n3xt_l3v3l!

STS: Blowfish - Level 2

This stage we needed to find a backdoor. This to me meant finding another suid file owned by the level3 user so that we can read the password. To do this I just did some bash magic using find:

find / -type f -perm +4000 -user level3 2>/dev/null

This searched the drive for a file with suid permissions owned by level3. There will be a bunch of error messages, such as permission denied, which I send off into the land of /dev/null. Let's see what I found.

Backdoor

We can see in the green that we've found the backdoor. The suid bit is set for user, level3. Now I just run it and it appears I'm dropped into a shell. Running, id, I can see that I have the effective ID of level3. Now all I need to do is read the password!

SPOILER! Highlight below to view the password:

l3thal_Rul3Z!

STS: Blowfish - Level 1

This stage was particularly easy. All that was required was to connect to blowfish.smashthestack.org:6666 and crack the md5 hashed password returned.

Cracked password

SPOILER! Highlight below to view the password:

welcome

STS: Blackbox - Level 5

This stage was easy in retrospect, but it took some research for my to accomplish it. We have a binary list and the corresponding source code, list.c. Running list seems to do nothing so I open up the source:


#include <stdio.h>


int main(int argc, char **argv)
{
char buf[100];
size_t len;
char fixedbuf[10240];
FILE *fh;
char *ptr = fixedbuf;
int i;

fh = fopen("somefile", "r");
if(!fh)
return 0;

while((len = fread(buf, 1, 100, fh)) > 0) {
for(i = 0; i < len; i++) {
// Disable output modifiers
switch(buf[i]) {
case 0xFF:
case 0x00:
case 0x01:
break;
default:
*ptr = buf[i];
ptr++;
}
}
}
printf("%s", fixedbuf);

fclose(fh);
}
It looks like it's opening "somefile" and copying the contents into fixedbuf. So it seems like a typical buffer overflow vuln. However, I did notice that we can do something else here. Since the binary has suid of the level6 user, why not just have it open up the password file? We can easily do this by making a symbolic link to /home/level6/password and name it somefile. The only problem is, how do we write to our home directory if we aren't allowed to. This was the problem I was facing. Copying the binary to our tmp directory strips ownership. After some time researching, it turns out that the binary will read "somefile" from where I called it. That means I can be in in my tmp directory and invoke the binary ~/list and it will read the local somefile in my current directory. Let's see it in action.

Reading the password file

Looks like it worked!

Alternate Solution: I'd like to redo this challenge by actually exploiting the buffer. It would be good practice and hands on experience with exploitation.


SPOILER! Highlight below to view the password:
OverWritten!

STS: Blackbox - Level 4

This was an interesting stage. It took me a while to figure out, but after some time - I saw the light. Again, we have a binary and some source code: shared, and shared.cc. Running shared yields this message:


This program allows you to read files from my shared files. See /usr/share/level5 for my shared files. Simply use the path relative to my shared files to read a file!
Example: ./shared lyrics/foreverautumn

Doing an ls of /usr/share/level5 displays:


drwxr-xr-x 2 root root 4096 2008-04-21 18:17 lyrics
-rw-r--r-- 1 root root    5 2008-01-12 21:10 shit1
-rw-r--r-- 1 root root    5 2008-01-12 21:10 shit2
-rw-r--r-- 1 root root    5 2008-01-12 21:10 shit3
-rw-r--r-- 1 root root    5 2008-01-12 21:10 shit4
-rw-r--r-- 1 root root    5 2008-01-12 21:10 shit5

And an ls -l of lyrics displays:

-rw-r--r-- 1 root root 45 2008-04-21 18:17 foreverautumn


Running the example given: ./shared lyrics/foreverautumn prints out the contents of the file. This is interesting. The results of this makes me feel like there's a directory traversal bug here, so I quickly try to move up directories



level4@blackbox:~$ ./shared /usr/share/level5/lyrics/../shit1
Contents of /usr/share/level5/usr/share/level5/lyricsshit1:
Unable to open file


This is interesting. It says it's unable to open the file, and it completely removed the "/../" from my string. Time to crack open the source.

Filter in code

Here is the root of that. It seems that it replaces the patterns: /../ and /./ The strings also cannot start with a "/" or "." Now, for this challenge, I spent a lot of my time looking at the function strreplace (a custom function) for bugs, however, this was not the case. It turns out the vulnerability here is the logic in which it filters the strings. It first filters /../ first recursively throughout the string. Then it filters out /./ recursively. Knowing this, we can perform directory traversal using this pattern to move up a directory: /./.././ This will remove the inner /../ and concatinate the 2 /./ forming /../ Confusing? Let's take a look.



level4@blackbox:~$ ./shared lyrics/./.././shit1
Contents of /usr/share/level5/lyrics/../shit1:
shit

Perfect! Now all we need to do is traverse to level5's home directory and read the password!

Directory Traversal

SPOILER! Highlight below to view the password:
Traveller

STS: Blackbox - Level 3

This challenge was a lot easier than the last, but I certainly caught a few snags. Landing in the level3 home directory, I see a few files: PID, proclist, proclist.cc and the obvious password file.

PID is a bash script with the following contents:

#!/bin/bash
/bin/touch /tmp/bash
/bin/chmod +sx /tmp/bash

proclist is an ELF 32-bit binary. And proclist.cc turns out being the source for proclist. Taking an initial look at the challenge, I decide to run the binary. It seems to prompt me to enter the name of the program. This is kind of ambiguous to me, so I enter the name of the binary, proclist.

proclist in action

Interesting... it returned the process info. I know... I'm slow. Putting two and two together, I figure the name, proclist, lists processes! Intrigued by this, I decided to try some command injection.

Command injection attempt

This didn't seem to work and greeted me with a heart "Fatal error". Enough is enough and I crack open the source code they humbly provided.

Source code display filter

Aha! We can see that they are filtering for common concatenating and piping chars: ;^&|><. Reading the code more leads me to my next hint, it makes a system() call with premade commands: /bin/ps and grep. So this is how it works, it lists the processes with ps and then greps for whatever program we enter. The vulnerability here happens to be in how it's calling grep.

Vulnerable code

Here, it's calling grep without an absolute path. What this means is that it will search our PATH environment variable for a binary named "grep". We can abuse this by prepending our controlled dir to the PATH variable. And in our dir, we can have our own binary/script named "grep" which will be executed. This works because programs are searched in the order they are placed in PATH. Now that we know how to go about this challenge, let's go ahead and complete the exploit to get the password for the next stage.

I first made a shell script named grep in my tmp directory with the contents:

#!/bin/sh

cat /home/level4/password

I made sure to chmod it so that it's executable by anyone. Then I went ahead and modified my PATH:

export PATH=/tmp/history3:$PATH

This prepends the directory /tmp/history3 before the rest of the PATH directories. Now all that is left is to run it and see what happens!

Exploited

It seems like it worked! I've held back the password from the screenshot. On to the next!

Blooper: When I was completing this challenge, for some reason in my shell script, using #!/bin/bash resulted in an access error. I'm not entirely sure why this happened as /bin/sh is a symlink to /bin/bash. Also, running sh --version and bash --version produce the same output. What's weird though is if you type sh, it drops you into a sh terminal. Maybe for backwards compatibility? I'm not entirely sure, but I'd love to know the answer!


SPOILER! Highlight below to view the password:
BashingSh

STS: Blackbox - Level 2

This challenge welcomes us with the files: getowner and getowner.c in our level2 home directory. This is great, as it's always nice when challenges come with some source code. Running the application displays the error, "No filename configured!" Providing some arguments also doesn't seem to change anything.

Running getowner and some arguments

Since this doesn't seem to be very helpful, I decide to take a quick look at the source. Taking a cursory look at the code, it's easily identifiable that there is a buffer overflow by using strcpy().

Vulnerable code

Reading more of the code helps me understand how to go about this challenge. It appears it's looking for an environment variable named filename. Setting this and re-running the binary quickly shows that this is the intended use of the program.

Getowner running with filename envar set

The code shows the name the value of filename being put into an unbounded buffer. Armed with this information, it's apparent how to go about this: we must perform a buffer over flow by having a really long value in the envar filename.

Triggering the buffer overflow

It appears we are correct! Now that we know how to successfully trigger the vulnerability, it's time to get down and dirty with gdb and get our exploit ready.

EIP is overwritten

We can see here that eip has been overwritten with the A's we set in our filename envar. Things are looking good for us right now. The next thing I wanted to do was calculate the distance to the return address. To do this I used Metasploit's pattern_create.rb and pattern_offset.rb tools. This returned a buffer space of 151. 

Now all we need to do is craft up our special filename envar with [nops][shellcode][ret] and we should be good to go!

Elevated shell

STS: Blackbox - Level 1

This challenge, like every beginning of a game, was the easiest. All that was needed was to run /usr/bin/strings on the binary supplied, login2. Going through the output displayed the discernable password.

SPOILER! Highlight below to view the password:

The password for level 2 is: PassFor2

Alternative solution: I'd like to revisit this challenge and try reversing the binary.