Saturday | 30 August, 2008
Computerworld
How to avoid the Debian SSH key attacks
It only took two days, but viable, simple attacks against the weak Debian SSH key generation flaw have surfaced
Carl Jongsma 16/05/2008 08:35:57

Computerworld Buyer's Guide - Vendors Matched to this Article
Additional Resources
Executive Guides
Whitepapers
Zones
Zone logoZones provide focussed content from Computerworld and leading technology partners.

Newsletter Subscription

Sign up for our Computerworld newsletters!
Computerworld's twice-daily news service keeps you in touch with the latest, most important headlines from Australia and around the world.
Keep up with the latest virtualisation technologies, products, news and features.
RSS Feeds

If you are running a Debian-based Linux system and haven't already caught up with the announcement that there was a major flaw with the generation of SSH, OpenVPN, DNSSEC, SSL/TLS session keys and X.509 certificate key material, you might want to update your system to address the problem.

This doesn't just affect Debian, but Debian derivatives as well, such as Ubuntu.

The flaw was the removal of most of the entropy (randomness) from the key generation process in OpenSSL in September 2006, and wasn't picked up on until just last week.

This means that any keys you have generated since that time should be regenerated as the only entropy present was the pid (Process ID) of the currently running process that generated the key.

This means that there are only 32,767 possible keys for each key length and there are a number of resources starting to appear that are targeting the weak key issue. One of the tools, developed by Markus Mueller, claims to defeat a 2048 bit RSA SSH key in less than 20 minutes.

H D Moore, the founder of Metasploit, points out that there are several features of Debian that make the process of brute forcing a key even simpler, given that a lot of Debian systems use sequential pid allocation and most keys are likely to have been user generated with a pid between 500 and 10,000 (which effectively reduces the keyspace to 9,500 keys).

Systems being developed at the moment are focussing on brute forcing the weakened keys and are being released as people finish creating the complete set of each key length.

If you thought you were safe by using a key length of more than 2048 bits, that isn't the case, as tables of 8192 bit RSA SSH keys have begun to appear (as well as lengths below that).

Keys created with GnuPG or GNUTLS are reported as not being affected by this issue. If you are not in the position to update your system (which you should really be doing), you should look at limiting the number of SSH login attempts to less than one per minute.

SSH brute forcing login attempts (using a set of assumed weak keys) have been a problem plaguing most systems with an exposed SSH port for a long time. Now that attackers have ready access to the complete keyspace for affected Debian systems it is guaranteed that they will gain SSH access if there is nothing set up to limit login attempts.

Some of the best means to limit login attempts include limiting the number of attempts per minute from all sources, blacklisting IPs that fail 2 or more login attempts, or only permitting whitelisted IPs to attempt SSH login (and trusting that those IPs are not compromised themselves).

While these measures will not prevent a successful brute force attack from working, it will mean that a successful attack won't take 20 minutes, it may take many hours or days to succeed.

Computerworld Buyer's Guide - Vendors Matched to this Article
More about RSA, IPS, SuSE, Ubuntu, Debian, Linux, SSH

Comments

weak security

Every system running an sshd should employ fail2ban, denyhosts, or something similar. Even if it's weakly configured to allow 20 failures or more, there's no reason any ssh server should tolerate a brute force attack of any sort -- ppk, keyboard-interactive, or otherwise.

There are services, such as the DroneBL dnsbl service, that employ honeypot servers to lure attackers onto their blacklist. Adding a line to hosts.deny using aclexec to query such services can improve security. If a host is known to be a source of brute force attacks, it will simply be denied connectivity before any authentication is attempted.

Market Place

Computerworld Member Login


 

Prioritizing Services with IT Service Management (ITSM)

Computerworld Live Webinar
Wednesday 20th, August 2008
11:00am EST (Sydney, Australia)

To be repeated on:

Thursday 4th, September 2008
11:00am EST (Sydney Australia)

Sign up and receive a free copy of The Forrester WaveTM Service Desk Management Tools, Q2 2008 at the conclusion of the Webinar.

Attend and discover:

  • How to deliver value to your business through ITSM
  • Best practice ITSM implementation
  • Why emphasis is changing from optimizing IT management processes to better servicing customers and demonstrating real dollar value
  • If service-oriented ITSM is best for your business
Whitepaper

Best Practice IP Storage: Discover the Cost Savings

Storage over IP, or the replication of block-level data over leased virtual private networks, allows users to select the type of wide-area service that best meets their budget and application requirements. Discover the best questions to ask IP SAN vendors, the cost savings that can be created by using IP storage methods and the future of iSCSI.

Enterprise IT Buyer's Guide
Find Technology Vendors Fast
 
Find vendors by name | Find by category
Sponsored Links