# OpenSSH Exploit

The following instructions set up a second OpenSSH server on your system. The server is reachable on port 31337.
**WARNING:** As the server's key files are publicably available as part of this repository, and thus should considered be unsafe, the server should not be run in a production setup!

### Setup
**WARNING:** We recommend doing this on a lab machine only!
First, we're putting config files for the ssh server on the machine.
- `sudo mkdir /var/empty`
- `sudo cp openssh-config/* /opt/etc/*`
- `sudo cp openssh-config/sshd_config /usr/local/etc`

As the exploit's offsets are depending on the OpenSSH server binary (`sshd`), we provide your with precompiled binaries that allow you to run our exploits without adapting offsets.

#### Test the OpenSSH Setup
- Either use your current user or create a new test user on your machine and set it up with a password
- Execute `./run.sh` in a terminal
- This should start the OpenSSH server and bind it to port 31337
- Connect from another machine and test that a password login works (use the credentials of your test user)
- Verify that you're logged in, e.g., by executing `id`
- Note that `.run.sh` stops the server after a single login attempt, so you need to restart the script if you want to rerun this test

### Test the Memory Corruption with GDB
The following simulates the impact of the exploit using `gdb`. This is useful for debugging, exploit prototyping, and to demonstrate the impact on unaffected systems.

- Execute `./run_with_gdb.sh`
- Connect from another machine and enter `pwd` as the password (the length of the input string matters for the stack offsets)
- If successful, the connection should go through (despite `pwd` being an incorrect password)
- Verify that you're logged in, e.g., by executing `id`

### Simulation
The following simulates the impact of the exploit using our exploit injector. This is useful for debugging, exploit prototyping, and to demonstrate the impact on unaffected systems.
Compared to `gdb`, it is much closer to the actual exploit injection, done in the next step.

- Enable `#define SIMULATION` in `./exploit-injector/main.c`
- Execute `./run_injector.sh`
- Connect from another machine and enter `pwd` as the password (the length of the input string matters for the stack offsets)
- If successful, the connection should go through (despite `pwd` being an incorrect password)
- Note that it may take a couple seconds for the SSH connection to open.
- Verify that you're logged in, e.g., by executing `id`
- If this does *not* work, the required offsets have changed (maybe due to recompilation of OpenSSH) and require manual patching

### Mounting the StackWarp Exploit
To mount the exploit using the StackWarp primitive, proceed as follows:
- Ensure that `#define SIMULATION` is commented out in `./exploit-injector/main.c`
- Execute `./run_injector.sh`
- Connect from another machine and enter `pwd` as the password (the length of the input string matters for the stack offsets)
- If successful, the connection should go through (despite `pwd` being an incorrect password)
- Note that it may take a couple seconds for the SSH connection to open.
- Verify that you're logged in, e.g., by executing `id`

### Recompiling OpenSSH
- `openssh-portable` contains `V_8_9_P1`, i.e., OpenSSH 8.9p1

If you want to recompile it yourself:
- `autoreconf`
- `./configure`
- `make`

Keep in mind that offsets are likely to change and you need to adapt them to run the exploits against the self-compiled server binary.