Win32 API 'shatter' vulnerability found in VNC-based products CONFIRMED PROGRAMS: VNC v3.3.3R9 TightVNC v1.2.5 TridiaVNC 1.5.4 SUSPECTED PROGRAMS: TridiaVNC Pro All other VNC-based remote console products EXPLOIT TYPE: 'Shatter'-type win32-based local privilege escalation (See: http://security.tombom.co.uk/shatter.html for details) SCOPE: Any Win32 system with VNC-based software installed, and interactive logon access. While this is technically a local exploit, it can be done through a VNC session (In my tests the VNC process died after spawning the shellcode, which would certainly end the VNC session (But not the shellcode, which stayed functional)). SUMMARY DESCRIPTION: After reading up on the 'shatter' class of Win32 API exploits discovered by Chris Paget (aka Foon), I decided to see what other programs immediately leapt out at me as being potentially vulnerable. Staring out of my system tray was my beloved VNC logo. Applying Mr. Paget's exploit as described in the white paper resulted in a LocalSystem command shell on both NT 4 and Win2K systems (with current Service Packs). I lacked an XP box for the purposes of this demonstration, but I see no reason that XP would be immune. Further testing revealed that the VNC-derivative products TightVNC and TridiaVNC are also vulnerable via the same process. I suspect that all currently available VNC-derived code is vulnerable. EXPLOIT REQUIREMENTS:: 1. Windows machine A has VNC service installed (for remote access, remote helpdesk, etc etc) 2. Hostile user has some sort of account allowing local access, such as Guest or normal user account. In my demonstration, I used both unprivileged local and Active Directory accounts. TECHNICAL DETAILS: Please consult Chris Paget's white paper concerning the Shatter class of Win32 API vulnerabilities at http://security.tombom.co.uk/shatter.html for a much more thorough treatise on the perils of interactive services being owned by LocalSystem than I could ever hope to write. The only pertinent info to be added is that the "Add new clients" dialogue box was used to send the shellcode. To demonstrate this oneself, simply s/NAV/VNC in the Paget document. VENDOR STATUS: Multiple VNC developer lists were consulted recently. Every response received to date has been "VNC is not a good tool to use when local access is granted to users". This seems a fine reply for servers, where only trusted users are given physical access or interactive logons, but VNC is used in many workstation environments for remote helpdesk applications. Tridia repeatedly told me to buy TridiaVNC Pro which, while admirably supporting SSL/TLS, does little to address this problem. If the user can log on interactively, the game is over. As of the time of this alert, I had not been told any efforts were being made to separate privileged service code from user-accessible system tray code by any developers. EXPLOIT STATUS: Unpatched, unresolved, and most likely in the wild as soon as the kids finish reading. CREDIT: Chris Paget, for giving win32 developers their very own sprintf() to worry about. Keith Morgan from Terradon Communications, for keeping me from writing a bad vulnerability report. Chris Bellers 314.233.7181 OSA System Administrator Boeing, Phantom Works
