full-disclosure - RSA Key Manager SQL injection Vulnerability ( CVE-2010-1904 )

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <AANLkTikhM8nHJWg1FUR8y1I5qjq5S_qyq56UyR7JLBnW@mail.gmail.com>
Date: Thu, 3 Jun 2010 13:15:32 -0400
From: Kyle Quest <kcq.lists@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: RSA Key Manager SQL injection Vulnerability (
	CVE-2010-1904 )

CVE: CVE-2010-1904

Product: RSA Key Manager

Vendor: EMC/RSA

Vulnerable Component: Key Manager Client

Vulnerable Component Version: 1.5.x

Vulnerability Type: SQL injection

Vendor Contact Date: 4/20/2010

Status: Vendor does not want to fix the vulnerability.

Vulnerability Details:

RSA Key Manager Client software uses an SQLite database to cache its
encryption keys.
The software fails to properly validate the metadata embedded inside of the
RSA Key Manager
encrypted data when it perform a key lookup when the encrypted data is being
decrypted.
An attacker can inject SQL commands into the metadata section of the RSA Key
Manager
encrypted data, which will be executed by the Key Manager Client software.
For example, an attacker can inject SQL statements to modify existing
encryption keys,
remove existing encryption keys, add new encryption keys, etc.

The Key Manager client uses two types of cache: memory cache and file
cache.
As long as both or either of the caches are enabled the problem can be
triggered easily.

RSA Key Manager Client 1.5.x uses the following format when it encrypts
data:

Field 1 = KeyIdString
Field 2 = NULL Terminator
Field 3 = Encryption IV
Field 4 = Encrypted Data

Encryptionn Key Cache tables:

1. "ClassTable" [contains encryption key classes configured on the server]

classID     VARCHAR(255) PRIMARY KEY
keyID       VARCHAR(255) [current key id for this key class]
refreshTime INT UNSIGNED
updateTime  INT UNSIGNED

2. "ConfigTable" [includes kekhash - KEK, Key Encryption Key, hash]

name VARCHAR(255) PRIMARY KEY
value VARCHAR(255)

3. "KeyTable" [holds the cached encryption keys]

keyID       VARCHAR(255) PRIMARY KEY
classID     VARCHAR(255)
keyData     BLOB
algorithm   VARCHAR(255) [usually "AES/CBC"]
refreshTime INT UNSIGNED
updateTime  INT UNSIGNED

Sample Injections:

Injecting the following sql code results in a new encryption key in the Key
Manager (client).

"; INSERT INTO KeyTable
VALUES('1111','MyClass','MyKeyData','ABC',1000,2000);--

Injecting something like the sql code below can be used to replace
the encryption keys used by Key Manager.

"; UPDATE KeyTable SET keyData ='NewKeyData' WHERE classID='MyClass';--

Content of type "text/html" skipped

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