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: