For the EXTREMELY adventurous

scovel · Post by **scovel** » 2005-04-16 00:49

I have added a BETA section to my plugin website.

http://home.comcast.net/~msrc4plugin/beta.html

I've added an AES based plugin. Its BETA quality. Future versions may not be 100% compatible. Its a BETA after all...

Its based on some code I found at www.workspot.org/vnc/. At the very least I'll need to update the AES version in the near future. It is based on an OLD version of OpenSSL's AES codebase. So old the function names and parameters don't match up... The code and the concept are solid though.

Kinda cool though. Might be possible to update the Linux patches too so that they are compatible with the plugin when I'm done....

Sean

Post by **UltraSam** » 2005-04-16 08:08

Kinda cool ??

No, it's just great

Thanks Sean for this promising stuff.

Sergio · Post by **Sergio** » 2005-04-16 17:02

Scovel:

First feedback on AESPlugin ... if the password setted on the server side have more than 8 chars, the authentication fails.
On the viewer side, I have to type ONLY the first 8 characters of the password to make it work.

BTW ... is awesome the work you've done !!!

cobratbq · Post by **cobratbq** » 2005-04-16 21:56

Whoah... this looks very interesting.

Can't test it yet, but I'll certainly follow this thread for the experiences of others

scovel · Post by **scovel** » 2005-04-17 01:51

Well,

I managed to get the crypto stuff updated to OpenSSL 0.9.7f. The way I've gone about it so far I'm using libeay32.dll. Don't know if its a good or bad thing. I'll probably build the code into the DSM directly again later. Good to see that it can be done.

I'll release a new version in a few days.

Sean

scovel · Post by **scovel** » 2005-04-17 02:10

Hey Sam,

Does this mean the plugin is only getting passed 8 characters of the password? Can that be fixed?

Sean

Post by **UltraSam** » 2005-04-17 07:45

Yep. Presumably...
(Going to check this part of the code just in case...)

UltraVNC or VNC only manage 8 chars passwords.

I remember that I had added a n chars password support back in 2002 for eSVNC (for my first encryption plugin attempt), without breaking the VNC password compatibility.

The deal was: when encryption/plugin is used -> get/manage more than 8 chars for th VNC password.

Because 8 chars is considered weak...
I can try to retreive my code that was doing this and put it in Ultra. Should'nt be difficult.

We could also force users to enter a 8 chars password in ultraVNC server and viewer when AESplugin is used... it takes some time to break a 8 chars password by brute force anyway... and you seem to make a MD5 (or SHA ?) digest from it to use as the primary encryption key (am I right ?).

Just tell me what you need

scovel · Post by **scovel** » 2005-04-17 20:08

Sam,

More is ALWAYS better. Its also less confusing if the plugin gets the whole password, so the user can enter the whole password they setup...

Funny you mention MD5 or SHA hashes... The Workspot code does something really odd to the password. The original code 3DES encrypted the password (a couple times) and then AES encrypted it (a couple times) and then used that as the key. Strange.

It SHOULD use an MD5 hash, and I'll probably change the code to an MD5 hash at some point.

You shouldn't add code that would only be used with the AESPlugin, but adding code so DSM plugins can get more than 8 characters of the password would be good.

Sean

scovel · Post by **scovel** » 2005-04-18 01:34

Beta 002 is out.

AES is updated to OpenSSL 0.9.7f
Password is now MD5 Hashed (OpenSSL 0.9.7f)

No libeay32.dll needed.

I haven't tested it much. I have a crypto.exe (like msrc4plugin has a crypto.exe) that I've tested it out with. Working fine. Let me know.

Yes, I will post the code GPL'd someday.

Sean

DodgeV83 · Post by **DodgeV83** » 2005-04-18 03:44

I have one main question about this plugin. Since it is dependent on looking at the password that the user puts in, does this mean that the password is not 128-bit encrypted? How can it be 128-bit encrypted if the viewer isn't using a key yet?

What makes this only for the "EXTREMELY adventurous"? Does it crash more or something?

I'm going to test this with UltraVNC SC. Hope it works!

Post by **UltraSam** » 2005-04-18 08:06

Sean,

If I was alone to decide, I would presumably do the following (that's actually what I had done in eSVNC):

- If the UltraVNC password is <= 8 chars and no plugin is used -> full VNC compatibility.

- If the UltraVNC password is > 8 chars AND a plugin is used, handle the "big" password and pass it to the plugin if this plugin requires the password.

- If the UltraVNC password is > 8 chars AND NO plugin is used just get the first 8 chars of the password to ensure the full VNC compatibility

This way: no big modification is needed and we don't need to store a second "special plugin big password".

Any suggestion, objection, idea is welcome...

scovel · Post by **scovel** » 2005-04-18 12:36

Sam,

Sounds reasonable to me!

Sean

scovel · Post by **scovel** » 2005-04-18 12:41

DodgeV83 wrote:I have one main question about this plugin. Since it is dependent on looking at the password that the user puts in, does this mean that the password is not 128-bit encrypted? How can it be 128-bit encrypted if the viewer isn't using a key yet?

What makes this only for the "EXTREMELY adventurous"? Does it crash more or something?

I'm going to test this with UltraVNC SC. Hope it works!

2 things make this for the EXTREMELY adventurous:

1. Its BETA and subject to MUCH change.
2. Its exercising some new areas of the DSM architecture.

Example of #1. 001 is not compatible with 002
Example of #2. Longer than 8 char password support is spotty.

I would NOT recommend deploying this in a production system any time soon. Future versions may not be 100% compatible with older versions.

BUT, it does work, and there are no major crashes that I'm aware of.

Sean

Sergio · Post by **Sergio** » 2005-04-18 22:09

Sean:

Some feedback ... If you connect using the AESPlugin, open the Admin Properties and uncheck the Use DSM Plugin box, and apply ... bump ... the winvnc server crush.

Server: RC205 - installed as service - MS Logon II
Viewer: RC206

HTH

scovel · Post by **scovel** » 2005-04-19 02:01

Confirmed. Odd. I'll have to look into that at some point.

Put it on my ToDo list.

Sean

scovel · Post by **scovel** » 2005-04-19 02:18

Beta 003 is out.

Restored an encoded message length to the MAC header. The original code was encoding the value in 2 bytes. The actual message size can be larger than 2 bytes can hold. Ugly bug. I now encode it in 3 bytes (Ugly too!).

003 is not compatible with 001 or 002.

The encoded message length is important to the non-UltraVnc versions.

Sean

For those crypto buffs, the Workspot code implemented AES encryption in CCM mode. Google it for details. Its a little slower than some AES modes, but has additional security against certain types of attacks.

Guest · Post by **Guest** » 2005-04-19 05:07

DodgeV83 wrote:I have one main question about this plugin. Since it is dependent on looking at the password that the user puts in, does this mean that the password is not 128-bit encrypted? How can it be 128-bit encrypted if the viewer isn't using a key yet?

Still no answer. This is important to me because when using the MSRC4 plugin there is 128-bit encryption from the beginning, including password input. I would like to know if AES is the same. Thanx!

scovel · Post by **scovel** » 2005-04-19 12:53

Sorry, guess I skipped this one.

Here's the answer:

The first step in the whole process is to MD5 hash the password into a key. MD5 generates a 128bit key from any size password. Obviously the more characters the password contains the "better" the 128bit hash is. Look up MD5 on the net for more details.

FYI, 128Bits = 16 Characters. A "random" 16 character password would be the "best" possible password to hash.

Hope this helps!

Sean

P.S. It is my personal opinion that the RC4 plugin is still far more secure. It requires a randomly generated 128 bit key to be broken before they can even begin their dictionary attack on your password. Technically, with the AES plugin, they can begin the dictionary attack right away. With a pathetic 8 character password, it wouldn't take too long to break into your server.

If Sam gets UltraVNC to give us up to 16 characters (and you use them all...), it will be virtually impossible to dictionary attack the AES plugin.

scovel · Post by **scovel** » 2005-04-19 13:11

BTW,

The password is never sent over the wire.

To clear things up a little more: The MD5 hashed password is then used to encrypt all communication that goes over the wire. The MD5 hash is for ENCRYPTION.

The actual VNC password exchange, which is for AUTHENTICATION, is still done using 3DES encrypted passwords, using the VNC standard key exchange.

With MSRC4, the 128bit pre-shared key is used for ENCRYPTION, and the VNC standard password exchange (3DES) is still used for AUTHENTICATION.

Any more questions, ask away!

Sean

P.S. AES CCM (the mode I'm using) has some additional security methods to guard against injection, man-in-the-middle, and replay attacks. It was one of the standards chosen for 802.11 and 802.16 (wireless).

scovel · Post by **scovel** » 2005-04-19 18:46

Sam,

It appears that this problem:

Sergio wrote:Sean:

Some feedback ... If you connect using the AESPlugin, open the Admin Properties and uncheck the Use DSM Plugin box, and apply ... bump ... the winvnc server crush.

Server: RC205 - installed as service - MS Logon II
Viewer: RC206

HTH

might be a bug in DSM. Its crashing on a NULL pointer in the server. It looks to me like the plugin is unloaded (during an active connection) but the server is still trying to communicate over the encrypted connection.

Here's where it bombs:

100010c3()
CDSMPlugin::RestoreBufferStep2(unsigned char * 0x0105fcfc, int 11, int * 0x0105ebfc) line 394 + 21 bytes
VSocket::ReadExact(char * 0x0105fcfc, const unsigned int 1) line 654 + 23 bytes
vncClientThread::run(void * 0x00000000) line 1142 + 20 bytes
omni_thread_wrapper(void * 0x00a9e0e0) line 502
_threadstartex(void * 0x00a9e198) line 212 + 13 bytes
KERNEL32! 77e4a990()

Sean

P.S. Sergio, I did find and fix a memory leak in the plugin, but that didn't fix this problem. Thanks for the feed-back.

For the EXTREMELY adventurous

For the EXTREMELY adventurous

First feedback ...

Beta 003