IMPORTANT INFORMATION: Distributed SSH Brute Force Attacks

Published: 2010-06-18. Last Updated: 2010-06-18 17:05:49 UTC
by Tom Liston (Version: 1)
9 comment(s)

Based on an analysis of the logs for my SSH honeypot, it appears that this latest spate of SSH brute force attacks are using keyboard-interactive authentication, rather than the standard password authentication.

2010-05-21 19:29:11+0000 203.185.xxx.xxx trying auth password
2010-05-23 19:31:57+0000 200.175.xxx.xxx trying auth password
2010-05-25 01:02:57+0000 122.155.xxx.xxx trying auth password
2010-05-25 01:09:06+0000 75.156.xxx.xxx trying auth none
2010-05-25 01:09:07+0000 75.156.xxx.xxx trying auth password
2010-05-25 05:08:07+0000 68.40.xxx.xxx trying auth password
2010-05-29 14:39:51+0000 122.226.xxx.xxx trying auth password
2010-06-02 06:27:31+0000 217.25.xxx.xxx trying auth password
2010-06-03 11:32:22+0000 62.83.xxx.xxx trying auth none
2010-06-03 11:32:24+0000 62.83.xxx.xxx trying auth password
2010-06-11 08:44:52+0000 222.173.xxx.xxx trying auth password
2010-06-11 15:42:46+0000 220.163.xxx.xxx trying auth password
2010-06-13 22:14:15+0000 67.228.xxx.xxx trying auth password
2010-06-15 01:21:39+0000 211.254.xxx.xxx trying auth password
2010-06-15 02:09:01+0000 202.98.xxx.xxx trying auth password
2010-06-15 19:53:49+0000 89.128.xxx.xxx trying auth none
2010-06-15 19:53:51+0000 89.128.xxx.xxx trying auth password
2010-06-15 20:10:45+0000 89.133.xxx.xxx trying auth password
2010-06-16 18:20:54+0000 165.98.xxx.xxx trying auth keyboard-interactive
2010-06-16 18:33:35+0000 64.122.xxx.xxx trying auth keyboard-interactive
2010-06-16 19:05:53+0000 59.124.xxx.xxx trying auth password
2010-06-16 19:06:47+0000 220.73.xxx.xxx trying auth keyboard-interactive
2010-06-16 19:28:54+0000 219.159.xxx.xxx trying auth keyboard-interactive
2010-06-16 19:47:52+0000 80.94.xxx.xxx trying auth keyboard-interactive
2010-06-16 19:57:57+0000 203.15.xxx.xxx trying auth keyboard-interactive
2010-06-16 20:18:00+0000 119.161.xxx.xxx trying auth keyboard-interactive
2010-06-16 20:27:40+0000 82.91.xxx.xxx trying auth keyboard-interactive
2010-06-16 20:47:02+0000 190.12.xxx.xxx trying auth keyboard-interactive
2010-06-16 21:27:00+0000 200.40.xxx.xxx trying auth keyboard-interactive
2010-06-17 16:59:36+0000 210.82.xxx.xxx trying auth password

Understand: If you have disabled password authentication in your ssh_config by uncommenting the line:

PasswordAuthentication no

that *WILL NOT* protect you against this latest round of attacks.

In order to disable keyboard-interactive logins, you must also uncomment the line:

ChallengeResponseAuthentication no

NOTE: DO NOT DO THIS unless you understand what you're doing and know that it will not break anything (I don't want a bunch of emails saying "I got in trouble because I did what Liston said...")

To test if your server is configured correctly, log in using the command line version of ssh with the "-v" option.  That will spit out a whole bunch of debugging information.  The important line is this:

debug1: Authentications that can continue: publickey,password,keyboard-interactive

If you see something like that, then you're not only vulnerable to standard password brute force attacks, but this newer keyboard-interactive attack as well.

Tom Liston
Handler - SANS Internet Storm Center
Senior Security Analyst - InGuardians, Inc.

Keywords: ssh brute force keyboardinteractive
9 comment(s)

Comments

Fortunately, it looks like a lot of Linux distros have ChallengeResponseAuthentication disabled by default, but you should double check anyway.

jtanium

Jun 18th 2010
1 decade ago

Thanks for the high-quality analysis! I am actually using S/Key (OPIE) on one of my servers, so I have ChallengeResponseAuthentication. I have other layers of protection that should keep them at bay.

But my question is: Do you know any more about the vulnerability? Are the attackers just trying to identify systems with S/Key enabled, and brute-force the S/Key response? Or are they exploiting an actual bug in OpenSSH or OPIE, which will get them in on the first try without having to do a dictionary attack?

bjnord

Jun 18th 2010
1 decade ago

@bjnord: I don't think they are exploiting any OPIE authentication. We too have noticed a change in scanning/BF'ing behavior the last couple days (with a massive new rash of attacks that started Wednesday). It appears that the SSH BF'ing engine in the bots has been overhauled. As Tom said, there are hosts that have PasswordAuthentication disabled. It appears the new engine has now taken that into consideration, being rewritten to supply a "keyboard interactive" password instead.

Another indicator of the SSH BF'ing engine rewrite is the ower amount of LibSSH occurrences in the sessions. In addition, the distributed nature scanning has been adjusted to be really stealth, running quite a bit under previous thresholds.

Anyone using Snort signatures with thresholds on SSH attacks is advised to re-evaluate those threshold levels. Having SSH honeypots will certainly assist in spotting the attacks.

Frank

Jun 18th 2010
1 decade ago

We have been using Fail2Ban in place (for SSH, POP3/IMAP4, et al) ... would this attack be impervious to this as well?

CSI

Jun 18th 2010
1 decade ago

@CSI: No. Fail2Ban triggers on host-based logs. As long as the failure message logged is recognized as a failure (which it should), Fail2Ban will still function fine.

Frank

Jun 18th 2010
1 decade ago

If this option is manageable, use TCP Wrappers to limit which IPs should have access to the server. It will also log the authentication failures. I have seen the same activity as well on my gate for a while now.

Jun 16 19:56:51 blocker sshd[2263]: refused connect from 119.147.xxx.xx (119.147.xxx.xx)
Jun 16 20:50:57 blocker sshd[2389]: refused connect from 109.169.xxx.xx (109.169.xxx.xx)
Jun 17 06:29:58 blocker sshd[3828]: refused connect from 220.231.xxx.xx (220.231.xxx.xx)

Guy

Jun 18th 2010
1 decade ago

I'm stunned. Thank you for writing about this setting, as I wasn't aware of it, and I actually had left it accidentally enabled on a machine with weak login passwords. Thankfully I didn't get compromised before reading this and fixing the problem.

Hikaru

Jun 19th 2010
1 decade ago

RTFM.

ChallengeResponseAuthentication
Specifies whether challenge-response authentication is allowed. All authentication styles from login.conf(5) are supported. The
default is “yes”.

-----------
On debian lenny - with PasswordAuthentication no
the output is debug1: Next authentication method: publickey

dave

Jun 19th 2010
1 decade ago

I note that the default in debian lenny is -->
ChallengeResponseAuthentication no

dave

Jun 19th 2010
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives