Attacks Against SSH 1 And SSL

AndyR writes: "SecurityPortal has a very interesting article by Kurt Seifried in which he writes "dsniff 2.3 allows you to exploit several fundamental flaws in two extremely popular encryption protocols, SSL and SSH." He makes many very strong arguments about key validity and the problem with not having a trusted third party signing keys." Don't throw away SSH just yet, it's still a lot better than nothing.

Comments

Kurt's SSL article is wrong!

[chicago greg]

I consider myself somewhat knowledgable about cryptography in general and SSL in particular. I read the articles by Kurt Seifried, especially the "foundation" articles dates Sep 30, 1999 and Oct 7, 1999. He is very cagey about actually demonstrating an attack, but I think his points are either technically wrong or technically useless.
First, the technically useless. Every security product/protocol I am aware of is vulnerable to so-called social engineering attacks. That's their whole point! They go around the security perimeter and get "behind" the protection to get humans to give away information. It is certianly fair to analyze the ease to which some products/protocols facilitate this, but I didn't see much of that. Instead, the articles discuss a company called DigitalBond with a solution that perhaps is also vulnerable to social engineering attacks.
Now lets look at the technical attacks and claims, which are contained in the Sep 30th article. I'll only comment on the weaknesses he alleges are in SSL. His first claim is that you should not order from a store that uses the http GET method. He doesn't say why, and I cannot think of any reason. If the form is submitted with an SSL-secured action (action="https:...") then both are equally secure.
His next claim is that the user must inspect the certificate of the server every for every SSL connection. He does not say what attack he can mount if the user doesn't do this. I am guessing that he believes the man-in-the-middle can substitute his own certificates and appear to be legitimate. This is firstly not an attack on the SSL protocol, only perhaps on implementations, and secondly it does not work with the implentations I have tested, IE 5+ and Netscape 4.7+. These implementations verify that the hostname you asked the browser to connect to matches the hostname specified in the CN field of the certificate. Of course, you must trust that the CA will do some checking to make sure hostnames actualy belong to the entity getting the certificate, but that is way outside the scope of the SSL protocol. These "flaws" cannot be the basis for later claims of insecurities. These implementations do not rely entirely on having savvy users carefully inspect every certificate.
I'd like to check up on earlier broswer versions to see if they also behave similarly. I'd be particularly interested in browsers that were in play at the time the article was written, say fall of 1999.
--greg

SFS - DNS the way you want it

[Frac]

some guys at MIT developed a file system called SFS - Secure File System. Knowing how untrustworthy DNS really is, they used a novel authentication scheme by embedding the public key and hostname into a string called the HOSTID that's required to connect. Their implementation is based on NFS3, but the key-certifying scheme is applicable to everything.

http://www.fs.net

Re:Locks are to keep honest people honest

[Dr. Evil]

Locks are to keep honest people honest

I disagree, the strength of your locks reflect your assessment of risk. If sufficiently valuable in the real world, locks are replaced with security guards and automatic rifles. Most people don't have anything that valuable, and find it more cost effective to place limits on their credit cards, check up on protection from their credit card companies and take up insurance policies.

If there were no banks and no insurance policies, would you, with your life savings under your mattress, still say that your locks are to keep honest people honest?

Besides, this SSH and SSL attack is very well documented, known and understood for a long time to be a limitation of the system. If your life savings are on the line, use callback, challenge response, or don't use remote logins at all.

This isn't as bad as it looks

[enterfornone]

These vunrubilities have always existed. It comes from the fact that SSH is not signed by a certificate authority, and as such you cannot trust the server on the other end. If someone cracks DNS etc to direct you to another server, you won't know about it, except for a warning that the key is different from last time.

SSL is similar, but it is signed on the server side, usually not on the client.

This isn't anything new, it's just not there are publically available tools to exploit this.

Re:This isn't as bad as it looks

[bellings]

It comes from the fact that SSH is not signed by a certificate authority, and as such you cannot trust the server on the other end.

You most certainly do not need a certificate authority to trust the server on the other end. And for this article to imply that somehow SSH v2 is a solution is downright wrong.

If you're using SSH (either v1 or v2) to communicate with a server, and you want to avoid the man-in-the-middle attact described by the article, then you must be certain you're talking to to the server, and not to the man in the middle. The only way to do this is to be certain that the public key that you have for the server you want to talk to really is the public key for the server you want to talk to.

There are several ways to do this:

• You can copy the public key from the server using some secure method, such as copying it onto a floppy and transfering it to your machine using sneaker net, or transfering it through encrypted email
• You can copy the public key across the (possibly insecure) network, and verify that the key was not replaced in transit by verifying the key signature by some secure means (perhaps by getting on the telephone with an administrator of the other machine)
• Although I don't believe SSH directly supports it (someone will hopefully correct me if I'm wrong), the public key can be signed by some trusted third party. If you trust the thrid party, you can trust the key.
• or, you can simply allow SSH to transfer the public key across the insecure network, and when it asks "should I trust this key", you can simply answer "yes".

This last method, of course, is the only method that is vulnerable to the man in the middle attack described in the article. Unfortunatly, its also the default method used by most SSH users. Obviously, there are several ways to reliably transfer the public keys without using a signature by a certificate authority.

It also can not be emphasised enough that a generic "certificate authority" by itself should not be considered a guarantee that you're talking to who you think you're talking to. Getting a signed certificate from a company like Verisign is not an insurmountable problem. Verisign is certainly reliable enough to trust with something like your credit card numbers -- credit card numbers are relatively inexpensive to replace if they're stolen, and stealing credit card numbers is painfully simple through many means much simpler than attacking Verisign. But I certainly wouldn't trust it for anything really important, unless I had absolutely no choice.

If you're using SSH (v1 or v2), or setting up a vpn, and you want to be reasonably certain you're not talking to a man in the middle, then nothing can replace coping the public key from machine in a known secure and reliable method. And if your client ever says "the signature of the server has changed. connect anyway (y/n)?" be very, very, very certain you know exactly what you're doing before you hit "y".

Re:This isn't as bad as it looks

[Idaho]

Well, it may be a little more serious than it looks.

Okay, these vulnerabilities have always existed and you could live with them because it was quite hard to exploit them.

However, as the author of the article points out, there is now a very convenient, easy to compile/install, almost 'off-the-shelf shrinkwrapped' set of applications that can do these kinds of things, which means the l33t 5(r1pt k1dd135 are probably going to find it a lot easier to use then before.

So that's why he writes the article, and I think he certainly has a point here.

Re:This isn't as bad as it looks

[linuxelf]

Well, this isn't actuall as bad as you might think. The attacker has to be in a pretty specific point, somewhere between you and your target. Some script kiddie sitting at home with his road runner account will still need to hack into an ISP that's routing your packets in order to intercept. And, that warning that SSH gives saying that they key changed should never be ignored. If you get that, drop the connection.

OpenSSH helps here

[dmiller]

With OpenSSH you have a chance to thwart these attacks - not only does it support SSH protocol 2, it also displays "fingerprints" for each unknown key it receives from over the network. You can use this fingerprint to do out-of-band checking of key authenticity (eg. by phone, in person, PGP signatures on a web page, etc).

There is also a project underway to allow OpenSSH to use keys distributed by DNSSEC.

This attack then comes back to user apathy (i.e not bothering to verify key fingerprints). An alternative (not yet implemented) is some form of PKI, which has its own problems (complexity, centralised trust, revocation issues).

Not a probelm for local nets

[veg]

For administering a private network, SSH and SSL
are perfectly secure. You can surely trust keys certificates that you generate yourself. As most of the dsniff tools rely on being on the same segment of ethernet, with careful key management they're not really a threat. Ever tried changing a ssh host key and then sshing into it ? You get the largest, scariest warning that makes you feel totally paranoid.

Also, if you are connecting to a server for the first time - fingerprints allow you to check the validity of the keys.

The problem is with connections to machines you can't personally validate, where DNS spoofing could be used, for example with e-commerce sites. But this is what CAs are for. So where's the problem (until a CA gets cracked that is :-).

...wanna tell us something we DON'T know, Kurt?

[mugwumpjism]

This is definitely FUD. The SSH documentation deals specifically with this issue. This is a good thing and SSH's handling of the situation is more secure than a central signing authority.

What he's basically advocating is removing the need for people to have secure methods for exchanging keys. Instead of having the chance of a "man-in-the-middle" attack during the first connection (which, if you've exchanged the fingerprint of the server with the admin of the server involved, is eliminated), he'd rather that we trust some other person with our security.

What if:

1. Someone actually manages to break the key authority's signing key
2. Someone replaces the key authority's signing key in your browser/software
3. Somebody working for the key authority secretly leaks the key (a "purchase-key" attack)

If any of these happen then your security is FUBAR. Bear in mind that the key could potentially be used to attack e-commerce sites, and is therefore pretty valuable. If the secret of the key being leaked is kept well enough, it is quite possible that no-one will ever find out - except for the odd sum of money missing from random credit cards worldwide.

Compare that to SSH, where upon connecting to the server, you are notified that you are connecting to an unknown host key, and it gives you its fingerprint to check against what you have recorded it should be. If the key ever changes, you are presented with a huge warning message saying that the host key has changed, and that a man in the middle attack may be in progress.

If you were using this commercially, you generally would be using SSH between two machines that you admin yourself, or between one that you admin and one that your peer's company admins, and you can verify the keys, set them up in each systems ssh_known_hosts file, and rest secure that you are not vulnerable to man-in-the-middle attacks.

Personally, I think he's trying to promote the idea that "security needs trusted arbitraries" to the corporate IT world - I wonder if Kurt Seifried has received any "donations" from any large key authorities recently?

Let's face it - if people use security that doesn't need key authorities, then they'll go away.

Every security system that uses a trusted authority is vulnerable to a purchase-key attack, and don't let anyone convince you otherwise!

Re:...wanna tell us something we DON'T know, Kurt?

[bellings]

This is a good thing and SSH's handling of the situation is more secure than a central signing authority.

black is white. stop is go. SSH's handling of the situation is most certainly not more secure than a central signing authority.

he'd rather that we trust some other person with our security.

Look, the article was a tripey piece of crap, but it certainly never said that. The simple, basic fact that the article gave was this -- if you don't verify who you're talking to, then you haven't verified who you're talking to. Somehow, this dumbass managed to make an entire article out of that. And I read it, and got the ad impressions, and everything. I feel dirty.

For anyone who hasn't taken the time to read the article yet, or ever learn basic security stuff, let me boil it down: In every single system known to man or mathematics, to identify an entity X, you must trust something to say "method Y is an accurate method to identify X". Unfortunately, the default way to get get that identification method in SSH and SSL is fundementally flawed. If entity W has no way to identify X, but wants to talk to X for the very first time, W simply asks X "what is a question that only you can answer correctly, and by answering proves that you are X?" That leads to a false sense of security at best, because entity Z can step in front of X, and provide a false answer to the "how can I identify you?" question. Voila! Now, W is talking to Z, and since Z was presumably smart enough to supply a question it can answer, W will never know that its speaking to Z instead of X.

Most two year olds could come up with a half dozen solutions for this problem. Certificate Authorities (where, essentially, someone pays a third party to certify that the identification question is a valid one) are certainly one partial solution. Manually transmitting the identification question (usually in the form of public keys) on secure medium is another. Ignoring the problem, because its inconvenient to deal with, is another solution.

As many people have pointed out already, ignoring the problem is often the "good enough" thing to do anyhow, since intercepting SSH or SSL communications is still several orders of magnitude more difficult than other attack vectors. But saying a Certificate Authority is bad because you can be lulled into a false sense of security is kind of like saying "you should only do electrical work on your house with the power switched on, since switching the power off lulls you into a false sense of security." You're certainly still vulnerable to attacks to the Certificate Authority, in exactly the same way you can still be electrocuted even if you think the fuse box is off. But there are certainly many situations where the CA's are the least inexpensive and effective method to mitigate the most risk.

Ehmz, no.

[Lion-O]

Thus Alice thinks she is talking directly to Bob in a secure manner, when in fact Charlie is in the middle intercepting the communications, able to monitor them and also to modify the content.

Bob : 245.345.0.20
Alice : 245.345.0.40
Charlie: 245.345.0.50

Now Alice wants on Bob's machine so he (Bob) opens up the firewall to allow Alice to access his server (don't forget; SSH isn't about encrypting and decrypting email, its a real time connection. And hey; if you need security and therefor use SSH but no firewall I think you're missing the point). Their keys get intercepted by Charlie. Charlie tries to access Bobs machine but is rejected by his firewall. Now what?

Insurance

[oolon]

I find the quest for the holy grail of perfect encryption/perfect protocol rather odd.

Why do we put locks on doors? To stop people walking in an stealing our stuff, So lets lock the windows, fair enough better security, people are less likely to break in that good. Fit an alarm?

So why not fit better locks? etc etc every upgrade costs money, and as it gets more expensive I get less return on my money. However this is completely ignoring one factor, insurance!

My SSL connection to buy a porn flick via my credit card... Hmm, how much do I care about it being broken.. well a thief just wants my number, my gf might be interested in my buying porn.

My GF does not have the skills to break the encryption, so SSL is secure. A thief, well so long as the Credit Card company pays up if someone else uses it I really don't care.

A tool should be fit for the job, SSL with real world insurance is seccure for credit cards, the day they don;t pay out, SSL falls!

James

Locks are to keep honest people honest

[dasunt]

I don't think twice about giving my credit card to a waiter at a restraunt, although its rather easy for the waiter to use the information to charge false expenses to my account (and it has happened to other people before). Its nice to have security holes pointed out, but really, locks are to keep honest people honest, any transaction is potentially insecure, and it pays to double check any financial records you receive to find any false charges or transactions. I don't fear this hole, statistically speaking, I suspect real life is a lot riskier.

Re:Pity... But:

[PigleT]

"In the end nothing is 100% secure... "

Of course. I knew that.

But the article doesn't say anything new at all. I've long-since known about the possibility of interception, and when it comes to signed documents, the presence of a digital signature on a document, even one that matches someone else's signature, does not mean that that person wrote that document. (It means there exists at least one person out there who knows the private key password for that identity and/or chose to apply it to the document; if you go around signing things you didn't even write yourself willy-nilly, the whole concept loses any strength it had.)

Again, this is a luser-space problem. There is no security vulnerability in ssh that's been discovered, this is an "if you abuse it you'll lose it" article. Well woopie-doo.
~Tim
--
.|` Clouds cross the black moonlight,

A Hybrid approach

[FreeUser]

If each administrative domain could maintain its own key-signing/authentication service, then at least enterprises, ISPs, and the like could provide solid security between their own systems. Contact between such entities could be preceeded by "out-of-band" authentication or exchange of keys (e.g. something like a PGP key signing party, a phone call, or an exchange of keys signed by a trusted third party).

The flexibility of the current approach could be maintained, with added levels of trust ranging from completely secure to completely open to "man-in-the-middle" attack.

There is still the possibility of abuse, however, as the "trusted third party" (particularly in the case of ISPs) could easilly be subverted by a law enforcement or spook agency into signing counterfeit keys. Indeed, they could legally be required to do so with legislation akin to the wiretapping laws requiring phone companies to provide technical facilities that facilitate evesdropping by law enforcement on demand.

just mitm

[QuMa]

It's just a man in the middle attack, hardly worth the electrons it's published with. Anyways, it claims man in the middle is fundamentel to public key is not true. The interlock protocol by rivest and shamir is quite effective against this sort of thing... The following description is quoted from Applied Cryptography by Bruce Schneier, second edition (page 49):

The interlock protocol, invented by ron rivest and adi shamir, has a good chance of foiling the man-in-the-middle attack. Here's how it works:

1. Alice sends bob her public key.
2. Bob sends alice his public key.
3. Alice encryptions her message using bob's public key. She sends half of the encrypted message to bob.
4. Bob encrypts his message using alice's public key. He sends half of the encrypted message to alice.
5. Alice sends the other half of her encrypted message to bob.
6. Bob puts the two halves of alice's message together and decrypts it with his private key. Bob sends the other half of his encrypted message to alice.
7. Alice puts the two halves of bob's message together and decrypts it with her private key.

The improtant point is that half of the message is useless without the other half; it can't be decrypted. Bob cannot read any part of alice's message until step 6; Alice cannot read any part of bob's message until step 7. There are a number of ways to do this:

• If the encryption algorithm is a block algorithm, half of each block (e.g., every other bit) could be sent in each half message.
• Decryption of the message could be dependent on an initialisation vector, which could be sent with the second half of the message.
• The first half of the message could be a one-way hash function of the encrypted message and the encrypted message itself could be the second half.

To see how this causes a problem for Mallory, let's review his attempt to subvert the protocol. He can still substitute his own public keys for alice's and bob's in steps 1 and 2. But now, when he intercepts half of alice's message in step 3, he cannot decrypt it with his private key and re-encrypt it with bob's public key. he must invent a totally new message and send half of it to bob. When he intercepts half of bob's message to alice in step 4, he has the same problem.

dsniff URL

[phaze3000]

For those that want to check out dsniff itself, the URL is:

http://www.monkey.org/~dugsong/dsniff/

Clever stuff...


--

So when *should* it change?

[Alik]

As pointed out in the article, you can't really defeat stuff like this through user education, because Users Are Dumb. Seems to me that you *can* do the sort of risk-reduction that Schneier's always talking about. Therefore, o wise Slashdot users (I'm pretty sure there's one of you somewhere...), when is it reasonable to see a host key change? I can think of:

1. Installation of new sshd
   
2. Upgrade of OS (new software installed)
   
3. Serious mucking with hardware configuration (not sure why --- I guess the keygen code uses some parameters as a seed)
   

I'm also pretty sure that rebooting the system isn't supposed to change the key. So what else is there that can legitimately change a key?

(And yes, I *did* try to RTFM. Checked the SSH specification, but that just says that hosts MUST have keys and MAY have multiple keys. STFW didn't help either; bunch of tech support announcements that some host somewhere was changing its key.)

Interlock protocol is not applicable.

[Paul Crowley]

I don't think you can plausibly apply the interlock protocol to SSH. When I log into a server, I expect a conversation in which each side reads the message from the other before generating their own messages. If that's the fundamental top-level conversation, any attempt to impose an interlock underneath that, unbeknownst to the communicating parties, can be spoofed.

Interlock only works if the actual communicating parties know they're interlocking. No attempt at automated interlock is going to work, because the MITM can separately spoof two separate interlocked conversations.

No, the correct answer is strong password protocols like SRP and B-SPEKE, as another poster has already observed ("Encrypted Key Exchange").
--

Encrypted key exchange

[XNormal]

Encrypted key exchange algorithms such as SRP and SPEKE provide strong password authentication which is resistant to all known passive and man-in-the-middle attacks. An added benefit is that they authenticate the server to the client as well as the other way around. And all this is done without PKI and without even requiring particularly strong passwords.

Why are they not in widespread use? It might have something to do with the fact that (AFAIK) all these algorithms are patented. SRP is patented by Stanford but apparently they allow it to be used without licensing fees in free software.

Another problem is that these algorithms cannot be used with the existing password databases. Replacing critical components such as /etc/shadow, passwd and requiring all users to change their password to move to the new system is never going to be very popular with system administrators.

----

Man-in-the-middle is not completely unavoidable

[ddstreet]

Now, W is talking to Z, and since Z was presumably smart enough to supply a question it can answer, W will never know that its speaking to Z instead of X.

Not entirely true.

If you are using SSH to connect to a machine, the automated key exchange and authentication may be 'impossible' to do without being vulnerable to man-in-the-middle attacks. However, once you've logged in, compare the /etc/ssh_host_key.pub to the ~/.ssh/known_hosts key you just got; if they're different, watch out! It would have to be a very smart sniffer program to realize 'cat /etc/ssh_host_key.pub' and all other variations should get the 'fake' key substituted in.

man in the middle is hard

[QuantumG]

bah. I have seen a few people intercept SSH before but only at demonstrations. I knew all of these guys and they said they have never wanted for accounts - there's enough unencrypted traffic to not bother going after the encrypted traffic. If there is one box that no-one connects to without using ssh, it is almost always connected to from an insecure box and, at present, there is nothing to stop tty sniffing. I wont even bother mentioning people who use windoze ssh clients. On most "secure" networks, ssh is the strong link in the weak chain. As for SSL, I have never seen an intercept of SSL by anyone who didn't have the SSL certificate.