Vulnerabilities

The vulnerability exists in the EJBCA service, version 8.0 Enterprise. Not tested in higher versions. By modifying the ‘Host’ header in an HTTP request, it is possible to manipulate the generated links and thus redirect the client to a different base URL. In this way, an attacker could insert his own server for the client to send HTTP requests, provided he succeeds in exploiting it.

PrimeKey EJBCA 7.9.0.2 Community allows stored XSS in the End Entity section. A user with the RA Administrator role can inject an XSS payload to target higher-privilege users.

An issue was discovered in Keyfactor PrimeKey EJBCA before 7.9.0, related to possible inconsistencies in DNS identifiers submitted in an ACME order and the corresponding CSR submitted during finalization. During the ACME enrollment process, an order is submitted containing an identifier for one or multiple dnsNames. These are validated properly in the ACME challenge. However, if the validation passes, a non-compliant client can include additional dnsNames the CSR sent to the finalize endpoint, resulting in EJBCA issuing a certificate including the identifiers that were not validated. This occurs even if the certificate profile is configured to not allow a DN override by the CSR.

An XSS was identified in the Admin Web interface of PrimeKey SignServer before 5.8.1. JavaScript code must be used in a worker name before a Generate CSR request. Only an administrator can update a worker name.

An issue was discovered in PrimeKey EJBCA before 7.6.0. CMP RA Mode can be configured to use a known client certificate to authenticate enrolling clients. The same RA client certificate is used for revocation requests as well. While enrollment enforces multi tenancy constraints (by verifying that the client certificate has access to the CA and Profiles being enrolled against), this check was not performed when authenticating revocation operations, allowing a known tenant to revoke a certificate belonging to another tenant.

An issue exists in PrimeKey EJBCA before 7.4.3 when enrolling with EST while proxied through an RA over the Peers protocol. As a part of EJBCA's domain security model, the peer connector allows the restriction of client certificates (for the RA, not the end user) to a limited set of allowed CAs, thus restricting the accessibility of that RA to the rights it has within a specific role. While this works for other protocols such as CMP, it was found that the EJBCA enrollment over an EST implementation bypasses this check, allowing enrollment with a valid client certificate through any functioning and authenticated RA connected to the CA. NOTE: an attacker must already have a trusted client certificate and authorization to enroll against the targeted CA.

An issue was discovered in PrimeKey EJBCA 6.x and 7.x before 7.4.1. When using a client certificate to enroll over the EST protocol, no revocation check is performed on that certificate. This vulnerability can only affect a system that has EST configured, uses client certificates to authenticate enrollment, and has had such a certificate revoked. This certificate needs to belong to a role that is authorized to enroll new end entities. (To completely mitigate this problem prior to upgrade, remove any revoked client certificates from their respective roles.)

An issue was discovered in EJBCA before 6.15.2.6 and 7.x before 7.3.1.2. In several sections of code, the verification of serialized objects sent between nodes (connected via the Peers protocol) allows insecure objects to be deserialized.