Message-ID: <001701cd0c80$60571780$21054680$@com>
Date: Tue, 27 Mar 2012 21:16:16 -0400
From: "b" <b@...isoryalerts.com>
To: <full-disclosure@...ts.grok.org.uk>
Subject: Re: PcwRunAs Password Obfuscation Design Flaw

So this brings up an interesting problem to tackle: 

How can you encrypt things for use by applications such as service account
credentials for authentication to other systems and database access
credentials on disk in such a way that the application can obtain the
encrypted information without prompting the end user for a decryption
passphrase and an attacker with local filesystem access cannot obtain the
encryption key to the credentials by simple computation (like if you had the
encryption key calculated based on some static/easily guessable
information)?



I have seen some attempts to solve this problem, such as with setting up SSL
certs for apache's use if the certs private key is encrypted, you have to
supply the private key decryption password at application startup and the
key then lives in memory.

This isn't very practical, in my opinion, in most environments I have seen
because an unplanned outage could require system reboots by your monitoring
personnel who might not know the application decryption passphrase and
higher administrators have to be called in to start the services up
properly. 

With web pages written in something like PHP, it would be even less
practical because then you would have to design some sort of daemon that
stays running in memory and the php code would ask the daemon to decrypt the
database credentials for each request. Or another approach would be to thing
like that like using the IPC capabilities of your operating system and using
shared memory. To use this shared memory you would have some program that
runs on system startup and you enter the credentials and they get saved to
this shared memory location and your other apps or php pages can use the IPC
interface to read this memory. 

Even these things have their issues because if the attacker can trigger a
memory dump that gets written to disk (like causing a BSOD and you have full
memory dumps enabled) and the attacker has local filesystem access they
could then read the dump from disk (after the system comes back up) and
obtain the key like that. 




I'd like to hear you all's thoughts on this so I can learn something new.




-B







Message: 7
Date: Mon, 26 Mar 2012 12:17:03 +0200
From: otr@...kcay.de
Subject: [Full-disclosure] PcwRunAs Password Obfuscation Design Flaw
To: Bugtraq <bugtraq@...urityfocus.com>,	Full Disclosure
	<full-disclosure@...ts.grok.org.uk>
Message-ID: <20120326101703.GA23723@X>
Content-Type: text/plain; charset=iso-8859-1

# Vuln Title: PcwRunAs Password Obfuscation Design Flaw
# Date: 26.03.2012
# Author: Christian Landstr?m, otr
# Software Link: http://www.pcwelt.de/downloads/pcwRunAs-1215998.html
# Version: <= 0.4
# Tested on: Windows
# CVE : CVE-2012-1793

# Risk: high
# Type: Privilege Escalation
# Vendor: PC-Welt

Timeline:

2012-03-19 Vendor contacted
2012-03-19 Vendor response
2012-03-19 CVE number requested
2012-03-20 CVE number assigned
2012-03-26 Public disclosure

Summary:

The PcwRunAs software available from the PC-Welt website is prone to a
trivial password recovery attack that allows local users to obtain
passwords encrypted with the pcwRunAsGui.exe.

Context:

PcwRunAs is a substitute for the RunAs tool included in the Windows
operating system. The tool allows to run commands in a different user
context. Usually this is used to execute commands that only higher
privileged users are allowed to run (like administrative or maintenance
tasks). Included in the PcwRunAs package is a tool called pcwRunAsGui
which features the creation of batch scripts that contain an encrypted
version of the command line arguments. This is used to hide the password
information from ordinary users that have access to the batch script but
should not know the administrator password. Currently two versions of
the tool are used in the wild. These are versions 0.3 and 0.4.

Design Flaw:

Both the PcwRunAsGui and the PcwRunAs tool share a common encryption key. By
design it is impossible to have PcwRunAs decrypt the string produced by
PcwRunAsGui and not give an attacker that wants to decrypt the cipher text
access to it. Hence the encryption key is embedded in the binaries of both
tools. This allows an attacker to reverse engineer the static encryption key
from the available binaries. The encryption key is derived from a RIPEDM-160
hash (160bits) that serves as initialization for the blowfish encryption
algorithm. This RIPEDM-160 hash is static for each version of the pcwrunas
tool as it is simply a hash sum of the pcwRunAs.exe executable file. The
plain
text command line arguments get Blowfish-EBC encrypted with the static
RIPEDM-160 hash and the result encoded in base64, e.g. in version 0.3:

/u "admin" /p "test1234" /app "C:\WINNT\NOTEPAD.EXE"

Becomes, encrypted with blowfish and base64 encoded:

pEmoTVE5jk9r8X1An1CeuVU9yTOVN0SNG7XUZkec+/udmzjTvMOUyk2OofUkMNk/2y7KJkY=

As the string is blowfish EBC(!) encrypted it is possible to brute force
a given base64 string by hand, systematically trying different inputs
for the pcwrunasgui tool and trying to reproduce the encrypted string
one once to decipher.

By reverse engineering the binaries it is possible to extract the static
RIPEDM-160 hash that is used for encryption and write a tool that takes the
encrypted base64 string and decrypts it using the static RIPEDM-160 hash
(different in version 0.3 and 0.4). The version 0.4 features a
protection mechanism that salts the encryption key with the hard disk
serial number. However this feature is not widely used by enterprises as
administrative batch scripts are usually rolled out to many
workstations. This would mean that a new script would have to be created
on each workstation. In any case an attacker knowing the serial number
is again able to decrypt the cipher text by RIPEDM-160 hashing the number
and
the key and using it as blowfish initialization.

Fix:

There is no trivial fix for this problem as this is a flaw by
design. As companies and individuals trust the pcwrunas tool for
securing their administrator password, we suggest that an advisory be
made public in order to inform administrators of the problem.

POC:

./decrypt_pcwrunas
Tool to decrypt blowfish-ebc from the PcwRunAs tool
Author: otr
---------------
Usage: decrypt_pcwrunas [version] [base64encryptedblowfish]

Example: decrypt_pcwrunas v0.3
pEmoTVE5jk9r8X1An1CeuVU9yTOVN0SNG7XUZkec+/udmzjTvMOUyk2OofUkMNk/2y7KJkY=
Example: decrypt_pcwrunas v0.4
EaVnXUyaAbve9Ef4K3QCm2dCzyH9znKcrZBwjaTLCgOT2sWBtCy38DEVTr5S

root@bt ~/Desktop/runwasdec # ./decrypt_pcwrunas v0.4
EaVnXUyaAbve9Ef4K3QCm2dCzyH9znKcrZBwjaTLCgOT2sWBtCy38DEVTr5S
[+] Decrypted: /u "aaaaaaa" /p  /app "aaaaa" /arg "aaaaaa"

root@bt ~/Desktop/runwasdec # ./decrypt_pcwrunas v0.3
pEmoTVE5jk9r8X1An1CeuVU9yTOVN0SNG7XUZkec+/udmzjTvMOUyk2OofUkMNk/2y7KJkY=
[+] Decrypted: /u "admin" /p "test1234" /app "C:\WINNT\NOTEPAD.EXE"



------------------------------

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

End of Full-Disclosure Digest, Vol 85, Issue 32
***********************************************

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists