Servers are under constant siege by hackers and botnets. How are attackers getting into these servers? Servers are typically broken with brute-force password attacks because this is easy when people use passwords like "1234" and "changeMe". The Secure Shell protocol and SSH Keys are ubiquitous in data centers and servers in every corner of the world. What do attackers do when faced with SSH Keys instead of passwords?
High volume SSH Key scanning attacks going undetected
We worked on a honeypot project with Marist college to learn more about how hackers exploit poor SSH Key management. The activity surrounding what passwords were being used by attackers and where the attackers are based is interesting, but we wanted to learn more about what attackers are doing with SSH Keys. Activity reported by web servers has proven attackers are exploiting SSH Keys to gain access to company data. Attackers can breach the perimeter in a number of ways, as they have been doing, but once they get in, they steal SSH Keys to advance the attack. Most businesses know this and have taken steps to address this problem, but some companies are still slow to adopt SSH best practice and compliance.
Ransomware, malware, and phishing scams make the headlines, but these attacks are just the beginning. The bigger problem is uncontrolled SSH access. SSH Keys quietly connect every business environment. This SSH access is considered the plumbing layer and invisible to business decision makers, similar to the water pipes running through your walls, but mounting evidence shows that this plumbing layer is leaking. Recent hacker activity shows attackers are actively scanning web servers for SSH keys to exploit.
Wordfence advisory shines spotlight on mass key scanning
Wordfence, a security company, identified a new attack focused on mass-scanning of websites for private SSH Keys. Wordfence released an advisory to ensure the wider web community is aware of this new activity and the clear threat it represents. Wordfence has logged attacker activity as the attacker tries to scan a variety of file directory paths to find the location of any accessible private SSH Keys that are not protected.
The graph below, demonstrates the sudden spike in SSH scanning traffic captured by Wordfence:
Private SSH keys found in the wild
According to Mark Maunder of Wordfence this spike in activity indicates that attackers are having success scanning the web for exposed private SSH Keys and then using those keys to connect to servers. Attackers have found that there is an operational mistake in how users are handling SSH Keys. Hence, malicious actors have invested more and more effort in exploiting the lack of understanding around SSH Key management.
Attacking and exploiting SSH-related weaknesses is not new to hackers. Last year we worked on a honeypot project with Eric Wedaa of Marist College. Eric collected a lot of wonderful stats on the type of attacks his sacrificial SSH servers (honeypots) sustained from around the world. Attackers use machines and programs called botnets to scan the internet for unprotected machines. Eric told us that it used to take days for one of his honeypots to be attacked, but now it takes minutes for an attacker to find and attack the honeypot. Exploiters are having success and getting more aggressive.
The trap is set
A honeypot is a server that looks legitimate to malicious actors, but in reality the purpose of this server (honeypot) is to collect information on attack patterns by hackers. This information helps us better understand what methods hackers are using to servers. In the case of the Marist honeypot, called LongTail, an OpenSSH server was modified to log information about anyone who targets the server. The honeypot saved information such as the username, password, and the IP address the attacker used to try and get into the server.
The trick with honeypots is to make the server look just like a normal server. If the attackers notice anything unusual about the server, they will suspect it is a trap or honeypot and move to the next target. The Marist LongTail honeypot fools attackers by using the real OpenSSH code with small modifications and running this code as the SSH server on the honeypot server. The honeypot looks just like a real OpenSSH server because it is using the actual OpenSSH code.
Most of the attacks on the Marist honeypot are SSH brute force, meaning that the attacker just guessed common user passwords until they were successful. The vast majority of attacks came from China. One key reason for this is cybercriminal groups similar to the China based SSHPsychos. This group is so active in their brute-force attacks that at times they account for up to 35% of all SSH traffic on the internet.
Passwords are easy to guess
Passwords are susceptible to brute-force attacks for a number of reasons, but one of the main reasons is that people use insecure or easily guessed passwords. The LongTail project proves this by collecting the most common passwords attempted by attackers. The most common passwords attempted on the root (the prizedv privileged admin account) are about as bad as you would expect, but with a few surprises: root, wubao, admin, 123456, password, 1234, and jiamima. Wubao translates from Chinese to ‘without protection’ or ‘no password’ and jiamima translates to ‘encryption key’ or ‘password’. As mentioned before, attackers are attempting these methods because they work!
The most 20 common root passwords discovered:
Constant brute-force password attacks
Eric felt like this was just the tip of the iceberg. He suspected that attackers must be trying to exploit SSH Keys in the same way. These could be SSH private keys that were duplicated and propagated throughout an environment or SSH private keys that were mistakenly exposed to the network as the Wordfence report details. After hearing Eric’s story, we began to help him collect data on SSH Key attacks. We made some updates to the Marist LongTail OpenSSH code to capture SSH Key data when an attacker attempts to breach SSH using a compromised key.
Select your weapon, choose your target
At the time, the one honeypot we deployed with the updated code to capture SSH Keys showed no attacks. This was probably due to the fact that it was only deployed on one honeypot and deemed a low value target by the attackers. In other words, a university virtual machine is not worth targeting with a more advanced SSH Key attack when brute force password attacks are working and the return on investment for the attacker is low.
SSH Keys are credentials, just like passwords, but there are a lot of complicated differences between SSH Keys and other credentials, such as passwords and certificates. Understanding these complex differences is paramount to properly manage and secure SSH Key access.
Millions of unused SSH private keys waiting to be exploited
An SSH Key pair contains both a private and public key. The private key is stored on the machine you are connecting from and the public key is kept on the remote machine you are connecting to. SSH private keys, as the name implies, should never be shared or exposed to the wider network because this key allows anyone to impersonate the owner of the private key and to connect to any machine that private key is authorized to connect to. You should never put them where other people can read them, send them in an email, FTP them, or transmit them insecurely.
To properly control your SSH Key access you first need to discover what SSH Keys you have, what machines they can access, and determine what SSH Keys violate compliance regulations by being too old or too weak. From there it is important to monitor SSH Key activity over time to determine what SSH Keys are unused or obsolete. Unused keys should be removed to reduce your attack surface and to gain quick wins.
What is a proportionate response?
We work with the world's biggest companies to secure and manage their vast SSH Key environments. We run advanced key scanning with our SSH Risk Assessment software and have found that major financial services companies can have more than a million unused SSH Keys waiting to be exploited by attackers.
If you think you might have a challenge with SSH Key management, or an impending audit that will highlight the problem, we are here to support you. We can help you prevent a small breach from turning into a headline grabbing disaster. We always recommend starting by assessing your key inventory. We will uncover your true compliance status, your remediation priorities, and you will learn just how far and how fast an attack could spread across your enterprise. Start by talking to us about SSH Risk Assessment...
