<<< Date Index >>>     <<< Thread Index >>>

Insecure Use of RC4 in LSrunasE and Supercrypt (CVE-2007-6340)



#############################################################
#
# COMPASS SECURITY ADVISORY               http://www.csnc.ch/
#
#############################################################
#
# Product:      LSrunasE, Supercrypt
# Vendor:       Geert Moernaut
# Type:         Flawed Encryption
# Risk:         Medium
# Author:       Daniel Roethlisberger
# Date:         2008-01-29
# CVE Name:     CVE-2007-6340
#
#############################################################



Introduction
------------
LSrunasE [1] and Supercrypt [2] are utilities used to run
commands under a different user account within Windows batch
scripts.  Passwords are encrypted using strong cryptography.
Due to insecure use of the RC4 algorithm, the encryption can
be trivially broken.



Affected Product
----------------
Vulnerable:
 * LSrunasE 1.0
 * Supercrypt 1.0

Not vulnerable according to vendor:
 * LSrunasE 2.0
 * Supercrypt 2.0

Since versions 2.0 of the utilities are no longer free,
Compass Security has not been able to verify the implemented
fix.



Technical Description
---------------------
The following description of the vulnerability in LSrunasE is
also applicable to Supercrypt.

LSrunasE has two components, lsrunas.exe and lsencrypt.exe.
One would encrypt the password to the user account using
lsencrypt.exe, yielding an encrypted password.  This
encrypted password is then used as parameter to
lsrunase.exe, for example in a batch script:

   lsrunase.exe /user:Administrator \
                /password:/kpyg/8D96HYhJ61SsJagmPw \
                /domain:somecorp \
                /command:"example.exe /dosomething"

LSrunasE supposedly uses AES-256 to protect the passwords,
so an attacker would have to reverse engineer the key out
of the binary, right?

However, the properties of the encrypted passwords turn out
to be very weak, leading to an easy break very quickly.
The password encryption is equivalent to a simple XOR with
a constant key, leading to the following simple break:

1) Find the XOR keystream by XORing an arbitrary string s
   with its encrypted form:

   keystream = unbase64(lsencrypt(s)) XOR s

2) Now you can decrypt any encrypted password:

   password = unbase64(encrypted_password) XOR keystream

This result strongly suggested that AES-256 has no role in
the encryption scheme.  Digging a little deeper, Compass
Security was able to unpack the PECompact packed binary and
reverse engineer the cryptographical algorithm used by
LSrunasE.  The result is interesting, since it turned out
that LSrunasE is using strong cryptography, albeit in an
insecure way.

LSrunasE uses SHA1 and RC4 to encrypt the passwords.  The
SHA1 hash of a constant string is directly used as 160 bit
RC4 key.  There is no random IV construction.

   secret = "(constant string embedded in the binary)"
   key = sha1(secret)
   encrypted_password = base64(rc4(key, password))

As a stream cipher, RC4 is only secure as long as you make
sure that no two plaintexts are encrypted using the same
keystream.  When using raw RC4 without some form of unique
IV construction, the keystream will be the same for every
key.  In the case of LSrunasE and Supercrypt, the very same
RC4 keystream is being generated for all encrypted passwords,
completely compromising the security of RC4.



Other Attacks
-------------
Note that this advisory is only about the insecure use of
the RC4 stream cipher, not about the fact that reverse
engineering is possible.  Of course, utilities like LSrunasE
and Supercrypt cannot be secure against reverse engineering;
it will always be possible to reverse engineer the algorithm
and find the key within the binary.

However, encrypted passwords should not be very easily
broken without resorting to more time consuming binary
reverse engineering.  And there is the obvious attack in
LSrunasE of copying the encrypted password and using it to
run arbitrary commands, which Supercrypt addresses.



Recommendation
--------------
Compass Security recommends not to use any utilities
which store credentials, especially not with privileged
accounts on untrusted systems.  When used in logon
scripts or within automated staging scripts, privileged
accounts used with LSrunasE or similar tools can be
compromised, leading to privilege escalation.



PoC Code
--------
Available on request.



Disclosure Timeline
-------------------
2008-01-29:  Coordinated public disclosure
2007-12-17:  Initial vendor response
2007-12-17:  Initial vendor notification
2007-12-14:  Assigned CVE-2007-6340
2007-12-05:  Discovery by Walter Sprenger, Ivan Buetler, Martin Sueess
             and Daniel Roethlisberger of Compass Security AG



References
----------
[1] http://www.moernaut.com/default.aspx?item=lsrunase
[2] http://www.moernaut.com/default.aspx?item=supercrypt
[3] http://www.csnc.ch/en/downloads/advisories.html



-- 
Daniel Roethlisberger <daniel.roethlisberger@xxxxxxx>
Compass Security Network Computing AG, Rapperswil, Switzerland
http://www.csnc.ch/ - Tel: +41 55 214 41 77 - PGP: 0x69292CBA
Security Review - Penetration Testing - Computer Forensics