|
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: 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: file passwords.in: Both Hydra and Medusa are installed on Kali, I'll try Hydra against an example service here:
Hydra (http://www.thc.org/thc-hydra) starting at 2017-10-31 23:19:54
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 469 Posts ISC Handler |
| Reply Subscribe |
Nov 2nd 2017 8 months ago |
Sign Up for Free or Log In to start participating in the conversation!
