Banner grabbing

A VNC server opens the RFB handshake by sending its protocol version as a fixed 12-byte string, for example RFB 003.008, before any authentication. That version, and the security types the server then offers, identify the protocol generation and the authentication the server will accept, directing the choice of attack.

1 ನಿಮಿಷದ ಓದುಅಕ್ಟೋ 5,2026 ರಂದು ನವೀಕರಿಸಲಾಗಿದೆflorianamette1 ಕೊಡುಗೆದಾರ
ನಿಮ್ಮ ಸಹಾಯಕವನ್ನು ಕೇಳಿ (MCP)GitHub ನಲ್ಲಿ ಸಂಪಾದಿಸಿ

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.

bash
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.003 versus 003.007/003.008 determines 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.

References#

ಹಿಂದಿನದುEnumerationಮುಂದಿನದು Implementation detection