46%
21%
41%
It was found in OpenShift, before version 4.8, that the generated certificate for the in-cluster Service CA, incorrectly included additional certificates. The Service CA is automatically mounted into all pods, allowing them to safely connect to trusted in-cluster services that present certificates signed by the trusted Service CA. The incorrect inclusion of additional CAs in this certificate would allow an attacker that compromises any of the additional CAs to masquerade as a trusted in-cluster service.
CVSS 3.1 Base Score 4.6. CVSS Attack Vector: adjacent_network. CVSS Attack Complexity: low. CVSS Vector: (CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N).
CVSS 2.0 Base Score 4.1. CVSS Attack Vector: adjacent_network. CVSS Attack Complexity: low. CVSS Vector: (AV:A/AC:L/Au:S/C:P/I:P/A:N).
The following code intends to ensure that the user is already logged in. If not, the code performs authentication with the user-provided username and password. If successful, it sets the loggedin and user cookies to "remember" that the user has already logged in. Finally, the code performs administrator tasks if the logged-in user has the "Administrator" username, as recorded in the user cookie.
}
}ExitError("Error: you need to log in first");
););DoAdministratorTasks();Unfortunately, this code can be bypassed. The attacker can set the cookies independently so that the code does not check the username and password. The attacker could do this with an HTTP request containing headers such as:
[body of request]By setting the loggedin cookie to "true", the attacker bypasses the entire authentication check. By using the "Administrator" value in the user cookie, the attacker also gains privileges to administer the software.
This code checks the certificate of a connected peer.
foo=SSL_get_verify_result(ssl);
// certificate looks good, host can be trustedIn this case, because the certificate is self-signed, there was no external authority that could prove the identity of the host. The program could be communicating with a different system that is spoofing the host, e.g. by poisoning the DNS cache or using a MITM attack to modify the traffic from server to client.
The following OpenSSL code obtains a certificate and verifies it.
}
// do secret thingsEven though the "verify" step returns X509_V_OK, this step does not include checking the Common Name against the name of the host. That is, there is no guarantee that the certificate is for the desired host. The SSL connection could have been established with a malicious host that provided a valid certificate.
The following OpenSSL code ensures that there is a certificate and allows the use of expired certificates.
//do stuffIf the call to SSL_get_verify_result() returns X509_V_ERR_CERT_HAS_EXPIRED, this means that the certificate has expired. As time goes on, there is an increasing chance for attackers to compromise the certificate.
The following OpenSSL code ensures that there is a certificate before continuing execution.
// got a certificate, do secret thingsBecause this code does not use SSL_get_verify_results() to check the certificate, it could accept certificates that have been revoked (X509_V_ERR_CERT_REVOKED). The software could be communicating with a malicious host.
The following OpenSSL code ensures that the host has a certificate.
}
// got certificate, host can be trusted//foo=SSL_get_verify_result(ssl);//if (X509_V_OK==foo) ...Note that the code does not call SSL_get_verify_result(ssl), which effectively disables the validation step that checks the certificate.
ExploitPedia is constantly evolving. Sign up to receive a notification when we release additional functionality.
If you'd like to report a bug or have any suggestions for improvements then please do get in touch with us using this form. We will get back to you as soon as we can.