App Tiers Affected:
What attackers spend their time and energy on attacking, and how they attack it, is the best indication of what works for them. Outside of targeted attacks for specific espionage, hacktivism, or warfare purposes, cybercrime is a volume game. Like most apex predators, cyber-attackers optimize their work to maximize their gains with the least amount of effort. That is something we should pay attention to in our cyber security practices, just like we do in the physical world. We protect ourselves from the common motives and methods of crime by paying attention to people around us, locking our doors, and putting up security cameras. Cybercrime is just another industry where the sales people (in this case, attackers) focus on the quickest path to success, which is always the path of least resistance.
Attackers are looking to compromise the most number of systems possible and, as such, are going to spend their time and energy on attacks they know will work. They can choose to spend their Tuesday night scanning for web applications vulnerable to a newly published CVE, their Thursday night launching a phishing campaign, and their Friday night taking the easy route by scanning for SSH and brute-forcing logins. If you measure success by the volume of attacks they launch, the SSH service is the biggest loser.
By attack volume, attackers focus more time and effort attacking SSH than any other online service. Brute forcing access to administrative logins of production applications over SSH occurs 2.7 times more than attacks against the application itself over HTTP (attackers trying to exploit web application vulnerabilities).
Why SSH? Because that is the service applications use for secure remote access (where the attacker is most likely coming from), and commonly associated with sysadmin access – full administration access, as opposed to generic user access. Telnet used to be the remote access service of choice, but due to the lack of protocol security, applications worth securing have migrated to SSH. Note the IoT world is still struggling to keep up with this evolution.
Vendor default credentials are commonly left active because it’s easier for the organizations who deployed the systems to access them. It’s also easy for attackers to exploit them. Attackers know vendor default credentials (outside of the list we are disclosing, a simple Google search of “default credentials” will do the trick) and will use SSH brute force attacks to breach applications with known credentials more readily than they will find and exploit a web vulnerability. Furthermore, attacks against Telnet (the insecure version of SSH, which is also commonly used by IoT devices), were outpaced by SSH brute force attacks at a rate of 3x.
Based on attack volume, if there is one big bang-for-the-buck win you are looking to achieve, it’s addressing SSH access to applications that might have vendor default credentials. This should be addressed not just on your perimeter, but also on your LAN and WiFi accessible devices. To help you prioritize, below is the list of the top 20 attacked username and passwords, as well as how they are used in combination.
Top 20 Attacked SSH Usernames
The most attacked SSH username is “root” - the most common vendor default credential created for administrative access to Unix-based systems (commonly network devices, applications and IoT devices). It is so common for this default user to not be disabled (or password changed), that it is attacked 3 times more than the username “admin,” in the second most attacked position.
Organizations using Ubuntu, Oracle, Postgres, FTP sites, Nagios, Git and Hadoop should prioritize ensuring default credentials are not active in production, as they are all on the top 20 attacked credentials list. Pi, the default user name for a raspberry pi, is also on the top 20 list. Security teams should conduct wireless access point inspections inside their offices to ensure employees haven’t connected one of these devices to the wireless network that could be acting as a network backdoor.
Top 20 Attacked SSH Passwords
The top 20 attacked SSH admin passwords are a literal embarrassment to the security industry. Not only are vendors creating weak default credentials for consumers to forget to change, but consumers haven’t gotten better at changing them since the dawn of computing! Comparing the top attacked usernames to the top attacked passwords, you see a lot more consistency in passwords. In other words, vendors are using the same weak passwords for default credentials over long periods of time. The best example for this is the #20 most attacked password: 7ujMko0admin. That is a root password for Unix systems first disclosed in 19991, almost 20 years ago! This problem actually goes back 3 decades to the Morris worm2 of 1988 that used weak credentials to exploit systems.
(The fifth entry on the list, “12345,” inevitably brings to mind the excellent Spaceballs: “1-2-3-4-5? That's the stupidest combination I've ever heard of in my life! That's the kinda thing an idiot would have on his luggage!)”1
Top Attacked Username and Password Pairs: Credentials
Every security team should make it a priority to ensure that the top attacked usernames and passwords, especially in combination, do not exist on any application. Proper access control is not a one-time effort. Access continually changes as new systems are deployed, new services are enabled, new employees are onboarded, or job roles change. Many enterprise environments have services that customers access and those rights change over time as well. Keeping up with appropriate access rights is an operationally intensive task so to help with prioritization, start with ensuring none of the following most attacked username and password pairs exist anywhere:
For the top 100 list of attacked user names and passwords, see the Hunt for IoT v5 Report on F5Labs.
It is worth noting that the most commonly attacked credentials are the vendor defaults for some of the most commonly used applications in enterprise environments today. Simply having a basic system hardening policy that ensures vendor default credentials are disabled or changed before the system goes live will prevent this common issue from becoming a painful breach. This is the reason system hardening is a requirement in every best practice security framework or compliance requirement.
Someone with compliance, audit, or security in their job title should be continually reviewing access to all systems. Commonly, security teams focus only on systems within the scope of some compliance or regulatory obligation, but fail to review the seemingly innocuous systems that could result in a major breach. Two casinos, one in the US2 and one in Europe3, have been breached through thermometers in their lobby fish tanks. Target was breached through their HVAC system. These cases reinforce the importance of access control, no matter the nominal criticality of the system. Targeting SSH can provide attackers with access to commonly deployed enterprise applications, but also to seemingly innocuous IoT devices like a fish tank thermometer and HVAC system. As a result, every business connected to the internet needs to prioritize access control review.
Outside of continual access reviews, monitoring should be in place to detect access attacks. The F5 Security Incident Response Team (SIRT) commonly helps customers recover from brute force attacks they were not aware of because they didn’t have monitoring in place. Brute force attacks can not only lead to a breach, but they often cause performance impact on the targeted system or lock customers out of their accounts from the failed login attempts. Because of this, there is a significant financial incentive for any organization to get proper monitoring in place.