The word "automation" is on everyone's lips for a while. We need to perform tasks as fast as possible and we develop or use tools to automate as much as possible. Also because we are lazzy people (well, honestly, I am ;-), if you can solve annoying tasks with a few lines of Python, go ahead! But results must be controlled and validated. Expecially when you perform scans or vulnerability assessments. It's so easy to drop a device on a network with a bunch of tools and start to scan everything. 

Here is a practical example:

An unknown device has been found vulnerable via SSH on a network but it was discovered and flagged via a very old Metasploit module called "exagrid_known_privkey"[1]:

msf6 > use exploit/linux/ssh/exagrid_known_privkey
[*] Using configured payload cmd/unix/interact
msf6 exploit(linux/ssh/exagrid_known_privkey) > set RHOST 192.168.x.x
RHOST => 192.168.x.x
msf6 exploit(linux/ssh/exagrid_known_privkey) > set TARGET 0
TARGET => 0
msf6 exploit(linux/ssh/exagrid_known_privkey) > exploit
[+] Successful login
[*] Exploit completed, but no session was created.
msf6 exploit(linux/ssh/exagrid_known_privkey) >

Great, you found credentials but no session was created!? The module tried to authenticated through a private key or an hardcoded password and it worked! So it was reported as successful in Metasploit and you could think "Yes, pwned!" and grab a beer!

But the discovered SSH daemon was a very old SSH-2.0-dropbear_2018.76 daemon. At a first look, it seems to not accept usernames passed through the command line:

root@kali:~/.ssh# ssh -i test.key admin@192.168.x.x

Please login:

Let's have a look in verbose mode, we can see this:

...
debug1: Authenticating to 192.168.x.x:22 as 'admin'
...
debug1: Will attempt key: test.key  explicit
debug1: SSH2_MSG_SERVICE_ACCEPT received
Authenticated to 192.168.x.x ([192.168.x.x]:22) using "none".
debug1: channel 0: new [client-session]
debug1: Entering interactive session.

What happened? The SSH server accepts connection with the "admin" login (using the "none" authentication) and the spawned shell starts the real authentication process by asking the login. This "none" method is used for access to password-less accounts when "PermitEmptyPasswords" is enabled).

This is a perfect example why more manual tests are sometimes required to validate some findings. Note that maybe the shell or program spawned by the SSH daemon is vulnerable and could be exploited but it's another story! Keep in mind, automation is nice but use your knowledge to validate results!

[1] https://www.rapid7.com/db/modules/exploit/linux/ssh/exagrid_known_privkey/

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key