来源

关联漏洞

介绍

## Proof of Concept CTF challenge
### By Silas Springer
Based on `CVE-2018-10933`

## Background
`CVE-2018-10933` is a vulnerability discovered in select versions of `libSSH`, which can allow potentially unrestricted machine access. The vulnerability arises from improper handling of packet headers during the authentication process, where sending a crafted packet with the `MSG_USERAUTH_SUCCESS` byte can allow anyone to bypass authentication. They then have full access to the machine.

The basis of this challenge, then, is to require competitors to poke around at the docker image provided, discover this vulnerability, exploit it to gain access, then find the key hidden in a symlink on the machine.

## Example CTF Challenge Description
```
Someone got into my machine via port 22...
It looks like they didnt even know my credentials.

Anyways, they made a file with an odd name, but it's gone now, 
I wonder if there's still some trace of the filename - 
it might be something symbolic of the attacker...

Can you figure out how they got in and help me find the filename?
```

## Solution
The following is a detailed walkthrough of the intended solution:

Notice, from the Challenge Description, that the attacker gained access through port 22, a port typically reserved for SSH. 
Also notice that the attacker didnt use credentials to gain access. 

From this, if you look around for past bugs with gaining access to a machine via SSH without credentials, the issue with the `MSG_USERAUTH_SUCCESS` byte is quite likely. Alternatively, by initiating a connection to port 22, one can determine the version of `libSSH` that is being run, and then look for common exploits for that version.

One may also see from the Description that the filename they seek to find (the flag) only exists as the target of a _symbolic_ link.

Knowing now, that access can be gained by exploiting this vulnerability, one may write their own, or copy an example script which can run this exploit, and run a command on the target machine. I have adapted an exploitation script for this solution, and called it `libsshauthbypass.py`. 

To run this script and get the flag from the machine, in the case of the demo image, one might run a command similar to the following:

```
./libsshauthbypass.py --host localhost -p 1337 -c 'find / -type l -exec stat {} + | grep "File:" | sed -E "s/.*\-> (.*)$/\1/g" | grep "definitelyarealCTF"'
```
#####  -- Note that this assumes the image is being run locally, or a tunnel to the running container has been established via localhost:1337

which then yields an output similar to 
```
sspringer-fedora-CVE: ./libsshauthbypass.py --host localhost -p 1337 -c 'find / -type l -exec stat {} + | grep "File:" | sed -E "s/.*\-> (.*)$/\1/g" | grep "definitelyarealCTF"'
INFO:paramiko.transport:Connected (version 2.0, client libssh_0.8.1)
definitelyarealCTF{totally_a_REAL_flag}
``` 

## Reusing
To use a version of this challenge for your own CTF, it is highly recommended to change the `Dockerfile` to utilize a different path than the default provided, change the flag in `flag.txt` (though it must still be one line), then rebuild the image. Note that it may be necessary to host a new container for each connection attempt to prevent someone running a destructive command and affecting all contestants.

To rebuild the docker image with a new flag (and test it)
- Update `flag.txt` with the new flag
- Run ` ./build_run <image name>[:<version number] <port number> `
- Utilize `./libsshauthbypass.py` or your own script to contact the container with the correct payload and a command you wish to run
- Upon `exit`ing the shell provided by the `build_run` script, the container will be shut down and deleted, but the image will remain and will be tagged as `<image name>`


## Videos
Proof of Concept:
https://youtu.be/ELrOBm02ANg

Walkthrough of challenge
https://youtu.be/Ii121piSZR0

文件快照

 [4.0K]  /data/pocs/c6a536c6fce519de35e066e9bd76a64bfdcf0fcd
├── [ 147]  build_run.sh
├── [ 123]  Dockerfile
├── [  39]  flag.txt
├── [2.6K]  libsshauthbypass.py
├── [3.8K]  README.md
└── [ 264]  run.sh

0 directories, 6 files

备注