Summary
Introduction
During the latest GreHack CTF (2017) there was a simple 150 points network challenge (easier than the 50 points exploit challenge ;-) ).
The text of the challenge invited us to listen to the port 4242.
Solution
Thanks to the netcat command we detected a SSH connection attempt. We had to wait a while (as we understood, all IP addresses of each VLAN have been scanned in loop).
In order to catch the traffic we decided to use sshesame, a fake SSH server.
For that you just need to install the golang package on your favorite Linux OS (Kali Linux for instance) and run go get -u github.com/jaksi/sshesame to download the sources and compile the program.
At this time we were ready to catch the SSH traffic and check if there was some insteresting stuff like a password or a username.
./sshesame -port 4242 -listen_address 192.168.142.201
But at the first connection we got an error message because we run sshesame with the default cryptographic configuration: ED25519. The bot tried to use RSA or DSA.
The simplest way for sshesame is to create the private/public keys (the RSA ones in our case).
ssh-keygen -t rsa
And re-run the command with the good option.
./sshesame -port 4242 -listen_address 192.168.142.201 -host_key id_rsa
After a while, we received these information:
WARN[3888] Failed to establish SSH connection:[]
WARN[3888] Failed to establish SSH connection:[]
WARN[3888] Failed to establish SSH connection:[]
WARN[3888] Failed to establish SSH connection:[]
WARN[3888] Failed to establish SSH connection:[]
INFO[3898] Client connected client="192.168.4.30:54620"
INFO[3899] Client connected client="192.168.4.30:54630"
INFO[3899] Client connected client="192.168.4.30:54636"
INFO[3899] Client connected client="192.168.4.30:54646"
INFO[3899] Client connected client="192.168.4.30:54650"
INFO[3899] Client connected client="192.168.4.30:54662"
INFO[3899] Password authentication accepted client="192.168.4.30:54646" password=admin user=root version=SSH-2.0-libssh2_1.8.0
INFO[3899] SSH connection established client="192.168.4.30:54646"
INFO[3899] Password authentication accepted client="192.168.4.30:54636" password=root user=root version=SSH-2.0-libssh2_1.8.0
INFO[3899] SSH connection established client="192.168.4.30:54636"
INFO[3899] Password authentication accepted client="192.168.4.30:54662" password="GH17{bruteforce_is_not_hacking}" user=root version=SSH-2.0-libssh2_1.8.0
INFO[3899] SSH connection established client="192.168.4.30:54662"
INFO[3899] Password authentication accepted client="192.168.4.30:54650" password=123456 user=root version=SSH-2.0-libssh2_1.8.0
INFO[3899] SSH connection established client="192.168.4.30:54650"
INFO[3899] Password authentication accepted client="192.168.4.30:54630" password=toor user=root version=SSH-2.0-libssh2_1.8.0
INFO[3899] SSH connection established client="192.168.4.30:54630"
INFO[3899] Client connected client="192.168.4.30:54664"
INFO[3899] Client connected client="192.168.4.30:54666"
INFO[3899] Client connected client="192.168.4.30:54668"
INFO[3899] Client connected client="192.168.4.30:54670"
INFO[3899] Client disconnected client="192.168.4.30:54662"
INFO[3899] Client disconnected client="192.168.4.30:54646"
INFO[3899] Client connected client="192.168.4.30:54672"
INFO[3899] Client disconnected client="192.168.4.30:54630"
WARN[3899] Failed to establish SSH connection:[no auth passed yet]
It was a SSH - bruteforce.
And if you check each login/password you find this entry:
INFO[3899] Password authentication accepted client="192.168.4.30:54662" password="GH17{bruteforce_is_not_hacking}" user=root version=SSH-2.0-libssh2_1.8.0
And the password was corresponding to the flag format: “GH17{bruteforce_is_not_hacking}”
Conclusion
This (easy) challenge was related to this interesting talk Down The Rabbit Hole: How Hackers Exploit Weak [SSH] Credentials To Build DDoS Botnets we saw before the CTF.
Thanks for the challenge.