Re: VNC authentication weakness

[Andreas Beck <becka () uni-duesseldorf de>]

> 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> =