> VNC uses a DES-encrypted challenge-response system to avoid passing > passwords over the wire in plaintext. > However, it seems that a weakness in the way the challenge is generated by > some servers would make this useless. This is a generic problem common to all challenge response systems. If the challenge can be issued multiple times with a reasonable probability or even timing based like described below, you can just forget about the "security" it adds. O.K. - you don't learn the plaintext passwords, but you can still login by sniffing. > Against tightvnc-1.2.1_unixsrc, you'll see output like > $ python pvc.py somehost:1 > 4b24fbab355452b55729d630fcf73d43 > b3acdf3fab422b7aa49b8d786f93def3 > b3acdf3fab422b7aa49b8d786f93def3 > b3acdf3fab422b7aa49b8d786f93def3 > b3acdf3fab422b7aa49b8d786f93def3 *sigh*. This looks like the challenge is timing based. Dependent on how the server works, it should implement either an extra counter or something like the PID. As long as you cannot go through the PID-space within a second, this should be fair enough. Another possibility would be to iterate a hash function and use a hashed version of its output as challenge. However care should be taken when initializing that one to avoid having the same sequence at every server restart. > WinVNC version 3.3.3R9 will display output more like > 91ff701f7dce8c6eebbc6062ffebcc6a > Server declined connection > Server declined connection *sigh* being too stupid to do it right ... but at least they have done _something_ about it. Eventually they might be ratelimiting only the IP you were trying from, which might be a good idea. > On systems with /dev/urandom, the following function will give challenge > strings which should be immune to the problems discussed: DONT do this. This will deplete the random pool for no good reason. A challenge does not need to be truely random, unless there exist vulnerabilities in the used hash function that will allow better analysis, if the challenge has a specific structure. A challenge only needs to be _different_ each time. Using truely random data of sufficient length will of course yield different data with a very high probability, but is IMHO overkill. Note that at least some implementations of /dev/urandom will start out giving away _all_ the entropy pool and then continue on a cryptographically strong pseudo-random-generator when the pool is empty. If you drain the random pool for simple stuff like that, it will not be filled enough for the really important matters like key generation. CU, Andy -- = Andreas Beck | Email : <becka@uni-duesseldorf.de> =
