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\.xml» file. The logs are stored in the following format: ...... ...... .. .. .. .. ...... ...... .. .. .. .. .. .. .. 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 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 pool in each of the log files. Instead, it only stores the cryptographic checksum for each of the . 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 from each of the files in the log directory. 2.It is possible to swap, duplicate, add or delete the located anywhere in the file. However, deleting the first and the last 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 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 _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/