Bugtraq mailing list archives
CuteFTP saved password 'encryption' weakness
From: nick () VIRUS-L DEMON CO UK (Nick FitzGerald)
Date: Wed, 5 Jan 2000 21:39:02 +1200
Another case of very weak 'protection' of secrets in Win32 network client software... I came across the following while investigating why the Melissa macro virus variant W97M/Melissa.M was interested in stealing a file called 'tree.dat' from victim machines. That file is the CuteFTP v1.x and v2.x 'Site Manager' data file, recording site names, addresses, site preferences, firewall information and (optionally) username and password data. A quick look at a sample tree.dat after installing CuteFTP suggested the passwords were 'encrypted' in a very weak manner. A few moments digging revealed that 'encrypted' is too strong a term -- the stored value was the original permuted by the simple expedient of adding 48h to the ASCII value of each character. The file has a fairly simple binary structure, which a few more minutes work would easily reverse but the usernames and 'encrypted' passwords are easily obtained with a hex file editor. This means that stealing of tree.dat not only allows the thief access via CuteFTP to any 'secrets' that may be recorded in that file, but they can also be easily decoded for other uses. The v3.x releases of CuteFTP store this data in smdata.dat (the virus does not look for that file) but it has a very similar appearing structure to tree.dat and uses the same 'encryption' of stored passwords. Briefly looking further, I note the pre-v3.0 release of CuteFTP's INI file includes the plaintext username and password for the default firewall configuration (if one is set). This same data is stored in HKCU\Software\GlobalSCAPE\CuteFTP 3.0\CuteFTP (also in plain text) in version 3.56 (tested), and from the key name presumably all other v3.x releases. NT users of CuteFTP would be advised to update to a v3.x release and apply adequate security to the DAT file and the registry key mentioned (and maybe its siblings -- check for yourself as I only found this because I was testing something unrelated to my normal concerns), particularly in multiple-user workstation situations. Presumably users of other OSes supported by CuteFTP don't care too much about security anyway so this is not an issue for them... A quick check of the CuteFTP Help files failed to find any mantion of the inherent insecurity in the chosen mechanisms for storing these user details. Regards, Nick FitzGerald
Current thread:
- PHP3 safe_mode and popen() Kristian Koehntopp (Jan 03)
- FWD: Redhat advisory Alfred Huger (Jan 04)
- Re: FWD: Redhat advisory (RPM --upgrade/-U vs. --freshen/-F) Peter W (Jan 04)
- Re: PHP3 safe_mode and popen() David TILLOY (Jan 04)
- Re: PHP3 safe_mode and popen() Thomas Köhler (Jan 05)
- CuteFTP saved password 'encryption' weakness Nick FitzGerald (Jan 05)
- Re: CuteFTP saved password 'encryption' weakness Brian Kifiak (Jan 05)
- Handspring Visor Network HotSync Security Hole Jay C Austad (Jan 05)
- Re: Handspring Visor Network HotSync Security Hole Jim Frost (Jan 06)
- Re: Handspring Visor Network HotSync Security Hole Chris Adams (Jan 07)
- Re: Handspring Visor Network HotSync Security Hole Jason Spence (Jan 06)
- Re: PHP3 safe_mode and popen() Kristian Koehntopp (Jan 06)
- FWD: Redhat advisory Alfred Huger (Jan 04)
- [rootshell] Security Bulletin #27 Kit Knox (Jan 04)