RealVNC Remote Auth Bypass?

Published: 2009-09-03. Last Updated: 2009-09-03 18:29:43 UTC
by Marcus Sachs (Version: 1)
8 comment(s)

We had an interesting submission from one of our readers today.  He thinks there might be a problem with RealVNC.  Here are the comments he sent us:

I'm a professional computer tech for a living, although I don't specialize in security.  A few minutes ago I was shutting my PC down to go to a job when I noticed the VNC icon in my system tray was black, indicating a connection.  I was immediately suspicious and powered the machine back on but unplugged the network cable until I could firewall the VNC service.  I have a home broadband connection and the router is opened up to allow incoming remote access on port 5900.  I have often noted the many failed attempts to connect to my VNC service in the windows logs; however, this was different.  According to my event log, the service had been connected about for 15 minutes before I noticed it.  Here are the technical details:

RealVNC version: 4.1.3
IP address: 121.32.14.72 (somewhere in China, apparently)
password: 12 characters, alphanumeric

In the logs there were no prior or repeated connection attempts from this or similar IP addresses, as if a brute force attack was happening.  Even at that a 12-character password should be relatively strong.  To me this looks like an authentication bypass vulnerability reminiscent of the 2006 vulnerability; I hope I'm wrong.  You may want to encourage everyone to be on the lookout for suspicious VNC connections.  For now my VNC is remaining firewalled.

For those who use RealVNC would you check your event logs to see if there is anything similar that you did not authorize?  Use the "comment" section below to post your brief thoughts or if you have a lot of information to submit use our contact form.

Marcus H. Sachs
Director, SANS Internet Storm Center

 

Keywords:
8 comment(s)

Comments

I recommend not opening your VNC up to the world in general. Configure it to allow connections only from localhost, and use an SSH tunnel. Then you only have to worry about the security of SSH. Although SSH has also had its share of vulnerabilities in the past, its emphasis is still on security.
My suspicion would be that the correct login credentials were captured in a previous/separate incident. A quick list of possible ways to obtain the login include a keylogger on the vnc server system, keylogger on a client, or by sniffing traffic if a client used an insecure network while connecting (i.e., an open wifi connection).

Remember, the attack you see today may entirely unrelated to the system(s) or method(s) involved with the initial compromise.
We don't have VNC running here at all and a couple days ago I noticed a peak in scans for port 5900 on my Dshield report. It's dropped off to normal levels the last couple of days though. Not sure if it's related, just seemed unlikely to be coincidental.
Even though you have 12 character password, some versions of VNC don't check anything over 8. I noticed that if I typed 8 characters of our 10 character password, that I'd still be allowed in.

Also, check to see if the version of VNC you're using supports encryption. If it doesn't, do what the other person here suggested, and always encrypt the tunnel you're using for VNC.

I have few servers here, and nothing is suspicous in our logs. We're running UltraVNC authenticating to our domain though.
"Even though you have 12 character password, some versions of VNC don't check anything over 8. I noticed that if I typed 8 characters of our 10 character password, that I'd still be allowed in."

they must take after unix...
"Even though you have 12 character password, some versions of VNC don't check anything over 8"

verified with our systems...

time to look for a new VNC server...
ISS seems to think that your version of RealVNC (4.0 - 4.2.2) is vulnerable to the 2006 exploit:
http://xforce.iss.net/xforce/xfdb/26445

There may have been an additional patch or workaround that you applied?
1) RealVNC 4.1.x is vulnerable to the exploit.

2) Consider putting the VNC listener on a different port. 5900 is the default - everyone is scanning for VNC there.

Diary Archives