“Security is not convenient.” Though blunt, this phrase neatly captures the fundamental conflict between typical users and information security personnel. Typical users want their workstations and networks to be configured for speed, accessibility, and convenience, whereas security professionals prioritize tight access control and monitoring. If you believe that security is not convenient, it follows that convenience may, at times, be insecure.
A prime example of convenience at the expense of security is storing passwords in configuration files. In this post, I’m going to specifically address files associated with VNC and WinSCP. Both VNC and WinSCP are likely candidates for this offense because the cross-platform VNC and SCP protocols often used by Windows users to interact with and administer Unix boxes. VNC is also often used on embedded devices, such as point-of-sale terminals. Since VNC servers only have one or two passwords (if a read-only password is enabled) but possibly more administrators, that increases the chances of a VNC password being shared between multiple users. That, in turn, increases the chances that it’s stored in a configuration file on someone’s machine, if not distributed via GPO outright.
Since extracting the passwords from these sorts of files has come in handy before, I decided to play with a few tools in a controlled environment. Hopefully other security assessors can read about them before needing them on a test. Perhaps more importantly, some additional exposure may help administrators and users realize the dangers of storing or distributing passwords in configuration files. For both VNC and WinSCP, I tested Windows-based tools as well as Metasploit modules.
VNC
I played around with the latest versions of TightVNC, UltraVNC, and VNC Viewer (from Real VNC). Once a connection is established, both TightVNC and VNC Viewer provide the user with the option of saving the password along with the connection settings. However, to their credit, both programs warn the user of the security risks associated with this. Due to the ease with which these programs allow saving passwords, one might guess that in an environment using a recent version of either of those clients, the chances of a saved password are more likely, but that’s far from a certain conclusion.
By default, the different clients save their connection information differently, but since different clients should all be compatible with standard VNC servers, they obviously “encrypt” the password in the same manner:
The first tool I tried, “VNC password decoder 0.2” by Luigi Auriemma, was able to instantly break out the password when provided with the .vnc file (or if supplied directly with the hashed password). The author also claims to be able to identify passwords saved in the registry, though I did not have any connection settings saved in my registry and therefore couldn’t evaluate this feature.
Next, I tried the /post/windows/gather/credentials/vnc metasploit module. Since this module checks default installation locations for the UltraVNC.ini file and registry keys, and since I (intentionally) did not install my clients according to defaults, it was initially unsuccessful:
A quick review of the module’s code shows where it’s looking for the UltraVNC.ini file:
For a quick and dirty hack, I simply renamed my .vnc file into untravnc.ini and placed it in Program Files (x86)\UltraVNC\, and changed the “password” line to read “passwd” so that the module could identify the right variable. I found doing this simpler than messing with the code of the module itself. With the file changed to fit what the module was looking for, it successfully decrypted the stored password.
Despite my natural preference for working within my Linux machine and metasploit, I appreciate the flexibility of the command line tool in this scenario.
WinSCP
Like VNC, WinSCP may save password information either in the registry or in a file. There is a Windows-based tool, winscppwd, which works off of the saved .ini file or the raw password hash. It’s important to note that if you encounter an installation of WinSCP with saved credentials stored in the registry, you can change the options to save the credentials as an .ini without reentering them.
Therefore, if your access or privileges are limited for any reason, you may still be able to get your hands on an .ini file which may prove easier than searching the registry. When pointed at the .ini file, winscppwd extracts the password without issue:
Though the metasploit module missed the .ini file due to it not residing in a default location, it quickly found and cracked the password saved in the registry:
If necessary, one could either change this module or the location of the .ini file on the target machine if the password were not saved in the registry.
Though there’s nothing new in this post, I hope readers find the brief review of different tools useful. Given their ease of use and reliability, I would recommend looking for .ini or .vnc files as a normal part of pillaging, especially given their potential to illuminate devices on the network whose presence may not be otherwise apparent.
References:
https://github.com/trinitronx/vncpasswd.py
http://www.blogsdna.com/19939/retrieve-recover-winscp-stored-passwords.htm
https://bitbucket.org/knarf/winscppwd/downloads/winscppwd.exe
