Message-Id: <1158841282.24233.17.camel@localhost>
Date: Thu, 21 Sep 2006 13:21:21 +0100
From: Andrei Mikhailovsky <mlists@...ont.com>
To: bugtraq@...urityfocus.com
Subject: RSA Keyon Log verification bypass vulnerability

Arhont Ltd.- Information Security

Arhont Advisory by:     Andrei Mikhailovsky
Advisory:               RSA Keon Manager log verification bypass
Product release:        Versions 6.6 and 6.5.1
Arhont ref:             arh200605-1
Class:                  Design flaw
Model Specific:         Other versions of RSA Keon are likely to be
vulnerable


DETAILS:
During the analysis of RSA Keon Certificate Authority Manager, Arhont
Ltd consultants have discovered several vulnerabilities in the Log
Verification function. A rogue CA (Certificate Authority) administrator
or any local administrative user with the access to the CA server could
manipulate the secure logging process to disguise his/her activities.

The RSA Keon product has a designed role separation capability to enable
the specific role of the CA Auditor, separate from the role of the CA
Administrator. The CA Auditor is responsible for looking over the
activity of the CA, including CA reconfiguration, certificate vetting,
signing, revocation, suspension, etc. The Auditor relies on the logging
facility of the Keon software, which has a Log verification function.
This option checks the cryptographic hash signatures embedded in the log
file against the contents of the log file to prevent log modification.
The log files generated by the Keon software are signed and stored for
the purpose of verification and are designed to be temper proof.
However, Arhont consultants have found at least two ways to bypass the
Log verification functionality of the RSA Keon software.


Vulnerability 1

The default installation of the Keon stores xml logs in a «C:\Program
Files\ RSA Security\ RSA_KeonCA\LogServer\logs\<filename>.xml» file.
The logs are stored in the following format:

<LOG BLOCK 1>
        <SIG BLOCK>
                <LOG ENTRY 1>
                        ......
                </LOG ENTRY 1>
                <LOG ENTRY 2>
                        ......
                </LOG ENTRY 2>
                        ..
                        ..
                        ..
                        ..
        </SIG BLOCK>
<SIGNATURE><HASH>
</LOG BLOCK 1>
<LOG BLOCK 2>
        <SIG BLOCK>
                <LOG ENTRY 1>
                        ......
                </LOG ENTRY 1>
                <LOG ENTRY 2>
                        ......
                </LOG ENTRY 2>
                        ..
                        ..
                        ..
                        ..
        </SIG BLOCK>
<SIGNATURE><HASH>
</LOG BLOCK 2>
        ..
        ..
        ..

Depending on the activity cycle of the Keon CA, each log file usually
contains a number of blocks as shown above. It is possible to delete the
entire <LOG BLOCK> with its signature from the log file without failing
the verification process of the Log verification functionality of the
Keon Software. Therefore, it would be possible to hide a malicious
activity from the CA Auditor.

The log verification function seems to lack the capability to store a
cryptographic checksum of the entire <LOG BLOCK> pool in each of the log
files. Instead, it only stores the cryptographic checksum for each of
the <LOG BLOCK>.

During the RSA Keon analysis Arhont consultants have found the following
methods of deleting logs to be effective against the Log Verification
function:

1.It is possible to swap, duplicate, or add the first and the last <LOG
BLOCK> from each of the files in the log directory.
2.It is possible to swap, duplicate, add or delete the <LOG BLOCK>
located anywhere in the file. However, deleting the first and the last
<LOG BLOCK> from the log file gives an integrity failure message in the
verification function.



Vulnerability 2

The local system administrator of the CA server or any user having a
read/write access to the RSA Keon LogServer directory can delete, add
and modify any entries in the live log file. Once the file has been
tempered, it will remain on the server until the next log rotation
schedule. Once the log file is rotated, the cryptographic hashing and
signing is performed and the log entries are grouped and signed. The log
files are then available for the CA Auditor to monitor and verify.

As you can see, there is an opportunity for a rogue or disgruntled CA
administrator to perform malicious activities and remove the
corresponding logs before they are cryptographically signed by the
LogServer. Once the signing is made, the Auditor can successfully verify
the log files that has been tempered.


RISK FACTOR:
The risk factor of Vulnerability 1 and 2 highly depends on the
organisation and the use of the RSA Keon CA. In organisations where the
CA functionality is not highly critical to the business activities and
continuity, the Risk factor is moderate. However, in the organisations
where the Certificate Authority use is paramount to the security and
business continuity and where the Logging activities should be closely
monitored and audited, vulnerabilities present a high risk factor.
Therefore, this could present a threat to the organisational compliance
with standards such as Sarbanes-Oxley, HIPAA and Basel II, where the
great emphasis on the audits and controls is highlighted. In addition,
the Common Criteria certification demands a complete and secure
separation of the CA Administrator and CA Auditor roles and thus can be
seriously affected by this vulnerability.


WORKAROUNDS:
Vulnerability 1: 
This is likely to be a functionality design flaw. To fix this
vulnerability, the Log signing functionality should include an
additional feature of creating and storing the signature for all of the
<LOG BLOCK> sections in the log file. Any modifications made to the
critical sections of the log file will be flagged out by the incorrect
signature.


Vulnerability 2:
This vulnerability seems to be related to the design fault similar to
Vulnerability 1. In order to prevent the log modification, the live log
file should be locked by the operating system or the Keon software.
Alternatively, it should be possible to implement an incremental log
signing process to store a cryptographic hash signatures of the file
content before each log file is signed and written. The second solution
might not be optimal due to the high resource consumption on the busy
Keon servers.




COMMUNICATION HISTORY:
RSA Security notified on 17/06/2006     	- No Response
RSA Security notified again on 01/09/2006       - No Response
Release of advisory to public domain on 21/09/2006

ADDITIONAL INFORMATION:
*According to the Arhont Ltd. policy, all of the found vulnerabilities
and security issues will be reported to the manufacturer at least 7 days
before releasing them to the public domains (such as CERT and BUGTRAQ).

If you would like to get more information about this issue, please do
not hesitate to contact Arhont team at info_ [at] _arhont_ [dot] _com

Powered by blists - more mailing lists