phpCAS is a widely used authentication library that enables PHP applications to authenticate users via a Central Authentication Service (CAS) server. Recently, a security vulnerability (CVE-2022-39369) has been discovered that affects phpCAS versions below 1.6.. This vulnerability allows an attacker to gain unauthorized access to a victim's account on a susceptible CASified service when specific conditions are met. This blog post will discuss the vulnerability, exploit details, and mitigation steps, as well as provide code snippets and links to original references.
Vulnerability - Authentication Bypass in phpCAS
The vulnerability CVE-2022-39369 exists due to phpCAS relying on HTTP headers to determine the service URL used for ticket validation. As a result, an adversary can manipulate the host header and use a valid ticket issued for any authorized service in the same Single Sign-On (SSO) realm to authenticate to the service protected by phpCAS.
The impact of this vulnerability depends on the CAS server service registry's settings. In the worst-case scenario, an attacker can abuse this vulnerability if the allowed URLs are configured to "^(https)://.*". Alternatively, the severity is substantially reduced if the CAS server service registry is set to allow only known and trusted service URLs.
Exploit Details
To successfully exploit this vulnerability, an attacker must be in control of another authorized service in the same SSO federation when proper URL service validation is applied. Additionally, the victim must visit the attacker's website while logged in to the same CAS server.
By exploiting the vulnerability, an attacker can gain unauthorized access to the victim's account on a vulnerable CASified service without their knowledge.
Mitigation
A major version upgrade to phpCAS 1.6. resolves this issue by enforcing service URL discovery validation. To ensure protection against this vulnerability, you are required to pass an additional service base URL argument when constructing the client class.
Refer to the upgrading documentation for more information: [link to upgrading doc]
The vulnerability only impacts phpCAS clients, and you may not be affected if the following criteria are met:
1. If phpCAS::setUrl() is called to pass in the fully qualified URL of the current page rather than the service base URL.
If phpCAS::setCallbackURL() is called only when the proxy mode is enabled.
3. If HTTP header inputs such as X-Forwarded-Host, X-Forwarded-Server, Host, X-Forwarded-Proto, and X-Forwarded-Protocol are sanitized before reaching PHP (for example, by a reverse proxy), in which case you are not impacted by the vulnerability.
To safeguard your application from this vulnerability, we recommend upgrading to phpCAS 1.6. or later and following the proper configuration settings mentioned above.
Make sure to set up phpCAS correctly to avoid the vulnerability
require_once 'path/to/CAS-1.x.x/CAS.php';
// Initialize phpCAS
phpCAS::client(CAS_VERSION_2_, 'cas.example.com', 443, '/cas', true); // Change the parameters according to your CAS server settings
// Set up the recommended configuration settings
phpCAS::setUrl('https://my-service-url.example.com/my-script.php';); // Replace with the full URL of the current page
phpCAS::setCallbackURL('https://my-service-url.example.com/cas-proxy-callback';); // Only required when proxy mode is enabled
// Authenticate user
phpCAS::forceAuthentication();
Original References
1. phpCAS GitHub Repository: https://github.com/apereo/phpCAS
phpCAS Upgrading Documentation: [link to upgrading doc]
3. CVE-2022-39369 Vulnerability Details: https://nvd.nist.gov/vuln/detail/CVE-2022-39369
Conclusion
The CVE-2022-39369 vulnerability in phpCAS poses a significant security risk, especially when CAS server service registry settings allow potentially malicious service URLs. By upgrading to phpCAS 1.6. and following the recommended configuration settings, you can protect your application and users from unauthorized access. Stay diligent with your application's security and keep abreast of the latest updates and best practices.
Timeline
Published on: 11/01/2022 17:15:00 UTC
Last modified on: 01/11/2023 17:23:00 UTC