Cryptographie faible

Le VNC standard ne chiffre pas la session, de sorte que le contenu de l'écran, les frappes clavier et le challenge-réponse d'authentification traversent le réseau en clair. La négociation du type de sécurité RFB peut aussi être dégradée vers un type plus faible ou sans authentification, et le chiffrement que certaines implémentations ajoutent est souvent faible ou optionnel, laissant le trafic VNC capturé et les informations d'identification récupérables.

1 min de lecturemis à jour le 13 oct. 2026florianamette1 contributeur
Demander à votre assistant (MCP)Modifier sur GitHub

Le VNC de base n'a pas de chiffrement de transport : la session RFB, les mises à jour du framebuffer (l'écran), la saisie du client (frappes clavier et souris), et même le challenge-réponse d'authentification circulent en clair. Un attaquant bien positionné lit donc le bureau et capture le matériel d'authentification. En plus de cela, le type de sécurité est négocié et peut être dégradé vers une option plus faible ou sans authentification, et le chiffrement que certaines implémentations greffent (schémas propriétaires, VeNCrypt/TLS) est souvent faible, optionnel ou non vérifié, de sorte qu'il échoue fréquemment à protéger la session en pratique.

bash
# confirm the session is cleartext (no VeNCrypt/TLS security type)
nmap -p5900 --script vnc-info <target>         # security types; absence of VeNCrypt(19) => cleartext
tcpdump -i eth0 -w vnc.pcap port 5900          # capture for analysis

Sous-thèmes#

Références#