The RFB protocol begins with the server sending a 12-byte version string such as RFB 003.008\n, before authentication. The client must reply with the compatible protocol version it intends to use. Under RFB 3.3 the server then selects a single security type; under 3.7 and later the server sends a list and the client selects a supported type. The list identifies available authentication and transport mechanisms. A downgrade opportunity exists only when an on-path attacker can alter negotiation and both endpoints support a weaker type that the server genuinely offered.
nc <target> 5900 | head -c 12 # "RFB 003.008"
nmap -p5900 --script vnc-info <target> # version + security type list
# selected registered values: 1=None, 2=VNC Authentication, 16=Tight,
# 18=TLS, 19=VeNCrypt, 20=SASL
Exploitation notes#
- The version string is pre-auth;
003.003versus003.007/003.008determines whether the server dictates one type or the client chooses from the server's list. - The security types offered right after are the decisive fact: security type 1 is "None" (no authentication), type 2 is the weak VNC DES password, and vendor types (Tight, VeNCrypt) point at implementation-specific handling.
- Combine protocol evidence with implementation detection, then match only named advisories to confirmed products and versions.
- Displays beyond the first sit on 5901, 5902, etc.; scan the range, as multiple VNC servers on one host are common.