Several years ago, using software engineering methods, University of California San Diego researchers demonstrated SSH is provably secure.  And SSH has shown itself to be nearly as good as claimed, posting only 31 bugs since 1998, most of which were minor.  Until now…  Three researchers from the Royal Holloway Information Security Group (ISG) at the University of London, Martin Albrecht, Kenny Paterson and Gaven Watson, found flaws in the proof.  They’ve shown that SSH is vulnerable to a “Man-in-the-middle” attack, where someone inserts themselves between a sender and receiver, grabs information, changes it and sends it along.

The Problem

There are actually three problems that account for the ISG discovered flaw:

1. The first lies in the manner the original security models used for the proof were constructed. The original proof pre-supposes garbled information may simply be reset as a failure and will not impact the security of the encryption used to protect the data.  The model never distinguished between the various kinds of failure, but the failure information turns out to be accessible to an adversary.  
2. The second is an implementation decision made by the original software developers for SSH.  The developers had two choices: send how big the transmitted information is (packet length field) unencrypted, which gives a small amount of information that tells an attacker how much data they had to crack, or encrypt hacker detectable information in the packet length field, possibly creating a “known plaintext” attack and thereby decreasing the keyspace.  SSH’s developers chose the unknown.  
3. The last problem has to deal with encryption modes and feedback loops.  In order to efficiently create and keep an encrypted tunnel between two computers hard to break, information from the current set of mathematical operations is used to incrementally change the next set, preventing various encryption attacks.  What data are taken from the current packet and fed into the next depend on the “cryptographic mode” chosen.  By default, SSH uses cipher-block chaining (CBC) mode instead of counter (CTR) mode.

Exploiting the ssh flaws

The ISG researchers took the error information reported that the proof never accounted for, and the design decision made by SSH developers, and began tinkering.  They eventually found a method of reducing the security in the default settings of SSH.  They reduced the overall security by creating a guessing game where an attacker has a one in 262,144 chance of success versus a brute force attempt at 1 in 4.2 billion  (2^18 vs 2^32).  You’ll only recover a very small amount of information using this method (14 or 32 bits), but it is enough to be useful.  The researchers’ vulnerability was first announced in November 2008, when the UK Centre for the Protection of National Infrastructure (CNPI) simply could not ignore the problem and, working with the ISG, issued a CPNI advisory.  Full details of the flaw were not announced until this month, when the researchers presented at an IEEE Symposium in California.

Vulnerability mitigation strategies

Even though the attack will work “with probability 1″ in some circumstances, it’s somewhat difficult to pull-off in general, and is about as stealthy as a freight train.  OpenSSH v 5.2 and above should not be susceptible to this particular exploit.  According to the CPNI advisory, the SSH flaw may be mitigated in current SSH versions by using CTR mode instead of the default CBC mode.  

Takeaway

This same technology reliance problem shows up repeatedly.  Use new equipment and products to increase efficiency, but do not over-rely on automation and technology.  Someone somewhere will notice of something unexpected, even with proven secure products.  Audit system results and write policies to take into account that the technology eventually will fail, not just from hackers or even questionable coding decisions – hurricanes, fires and employee clumsiness can all accomplish the same thing.  If your systems fail, any private information exposed will cost money – in breach notifications, time resetting the systems and general reputation.   The ISG researchers summed up the situation succintly in their paper: 

Unfortunately, it seems that real world cryptographic implementations are more complex than the current security models for SSH handle.

CIPP Candidate Preparation

In preparation for the Certified Information Privacy Professional exam, a privacy professional should be comfortable with topics related to this post including:

• Managing Risk and compliance (Foundations:I.G.b) including: Privacy Policy Development, Risk Management, Compliance
• Information Security (Foundations: II.C) including: Encryption (data-in-motion) and Threats & Vulnerabilities