Subject: Re: Kerberos: telnet to Solaris -> Bad encryption type
To: None <firstname.lastname@example.org>
From: Steven M. Bellovin <email@example.com>
Date: 10/02/2005 11:57:15
In message <firstname.lastname@example.org>, Pavel Cahyna writ
>On Tue, 27 Sep 2005 09:14:31 -0400, Steven M. Bellovin wrote:
>> Lack of integrity-checking in a crypto protocol is indeed serious. For
>> telnet, it's' slightly worse for CFB than for CBC, but both are
>> seriously flawed against replay attacks.
>Is this flaw a problem in practice? If the connection data are encrypted
>with a secret key, how can an attacker replace them with different data
>without producing just uncontrollable garbage? If he can replay
>previously transmitted data, what can he achieve, since he don't know what
>actually he's replaying?
We've seen little of in practice, since buggy software is a much easier
way in to most systems.
For discussion of how some ciphers fail badly with lack of integrity
checking, see http://www.cs.columbia.edu/~smb/papers/badesp.pdf (or
.ps), a paper of mine from 1996. That focuses on CBC and stream
ciphers such as RC4, since those were the ones of interest for IPsec.
As for knowing what you're replaying -- traffic analysis can yield an
amazing amount of information about what's going on. Or consider this
attack. Record the ciphertext traffic during a session. Wait for a
pause, then send the target some email that will merit a resopnse.
When the typing starts, and you think your target is working on the
reply -- typed text sticks out like a sore thumb, because of very
characteristic inter-character delays -- replay the ciphertext of
interest. If the replayed text includes the reply to another email,
there's probably a ^D in there, ending this one, too.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb