Published by CyberCX Intelligence on 23 January
In October, CyberCX discovered three distinct vulnerabilities in Symantec Identity Manager 14.3 during a routine penetration test. This blog outlines how we found them and the complexities of exploiting them in our customer’s environment, which involved a Web Application Firewall (WAF) that it was not possible to disable during the test.
What we found
Symantec Identity Manager is a popular identity management system that can be used to streamline the process of managing user accounts and granting users access to applications. We identified the vulnerabilities during a timeboxed web application penetration test performed by CyberCX on behalf of a customer. Our identification and exploitation of the vulnerabilities was complicated by the presence of a Web Application Firewall (WAF) that could not be disabled during the test for operational reasons. As a result, the payloads in examples shown below are more complex than they need to be, as they also needed to be able to bypass the WAF.
WebApp pentesting with WAFs in the way
In general, penetration testing web applications with a WAF protecting the application is problematic. WAFs can be an effective security control for slowing down attacks and can be useful chokepoints to swiftly block known attacks. However, if a vulnerability exists in the underlying WAF application, they can in most cases be bypassed by attackers using specially crafted payloads.
While WAFs are a helpful control for production systems, when timeboxed penetration testing is being done, you want your testers to be as fast and thorough as possible. WAFs can hinder these objectives. After a penetration tester has finished identifying vulnerabilities without the WAF present, “would the WAF have prevented this vulnerability being exploited?” is a simple question to answer with some quick tests with the WAF in place.
If you’re having web application penetration testing performed against a target protected by a WAF, please allow-list the penetration tester’s source IP for the duration of the test if possible!
CVE-2023-23949: Reflected cross site scripting
Cross-Site Scripting (also known as XSS) occurs when a web application does not properly filter HTML tags, allowing malicious JavaScript to be embedded in websites or in links. The malicious script can perform actions such as exploiting browser vulnerabilities, running commands, or forward a user’s cookie to a malicious site.
We identified reflected (non-persistent) XSS vulnerabilities in the authenticated functionality of the application. A reflected XSS vulnerability occurs when the application displays user supplied data immediately back to the user without performing any encoding routines on the supplied data. Exploiting reflected XSS vulnerabilities often requires a victim to follow a specially crafted HTTP link in a phishing scenario.
The following screenshot shows an HTTP request demonstrating exploitation of this vulnerability. The payload from the request can be seen reflected in the response:
The following screenshot shows the payload executing within the browser:
CVE-2023-23950: Response splitting on binary attribute page
Our testing also identified that Identity Manager was vulnerable to HTTP response splitting.
HTTP splitting is a less common vulnerability that occurs when user supplied input (usually a CRLF sequence) can be used to split a returned response into two responses. CRLF refers to Carriage Return (\r) Line Feed (\n).
To prove an attack against this vulnerability was possible, an additional cookie header was added to the HTTP response from the web application:
HTTP splitting can be leveraged into a variety of attacks on end users such as Cross Site Scripting, Cache Poisoning, Open Redirects and more.
To further demonstrate the impact of the response splitting vulnerability, we leveraged it to perform XSS. The following screenshot shows the HTTP request and the payload within the response:
This screenshot shows the payload executing within the browser:
CVE-2023-23951: Oracle LDAP attribute information disclosure
Unrelated to the XSS and response splitting vulnerabilities, we identified a third vulnerability in Identity Manager relating to the disclosure of LDAP information.
An LDAP directory is a data store that provides a simple way for applications to query data such as usernames, passwords, email addresses and other directory information. LDAP is intended to be exposed to applications but not users, as directories may contain sensitive information.
File upload functionalities are a common source of vulnerabilities for web applications, so one of the first functions we tested was how the profile image was loaded by the application. Reviewing the request, the parameter directoryAttribute=jpegPhoto was noted which raised suspicions. Further testing confirmed that the directoryAttribute parameter was querying LDAP, and could be modified to return other LDAP attributes. We were able to enumerate other valid attributes using Burp intruder and a combination of wordlists. One of the attributes identified as being particularly sensitive was the userPassword attribute, which would return the SHA256 hash of the user’s password.
The following screenshot is an example request used to reveal the userPassword attribute of the user:
In addition to the password hash, a number of other attributes useful to an attacker were able to be retrieved, including security group membership. Attributes returned were limited to those of the current user, limiting the impact of this vulnerability.
Chaining the attacks
Using either the XSS present in the application, or the induced XSS possible from the response splitting vulnerability, an XSS payload could be crafted that exploited the LDAP information disclosure. This provides attackers with a ‘one-click’ avenue to gain access to the hash of a victim’s password. An attacker would still need to crack this hash for it to be useful, but if the victim had a weak password that could be cracked by the attacker, this would provide an avenue for the attacker to gain persistent access to the victim’s account.
Conclusion
Mature products such as Symantec Identity Manager are often regarded as ‘known-good’ by organisations that use them, and as such are not often subject to penetration testing. The identification of three separate high-impact web vulnerabilities during the course of a single penetration test suggests that even mature platforms can have vulnerabilities lurking. As the proverb says, “trust, but verify”.
Affected Products and Software Versions
Hot fixes are available for 14.3 CP3, 14.4.1 and 14.4.2.
Disclosure Timeline
- 18 October 2022: Vulnerabilities sent to Symantec by CyberCX
- 15 December 2022: Vulnerabilities confirmed by Symantec.
- 20 January 2023: Public disclosure of vulnerabilities.
CyberCX would like to thank the Broadcom/Symantec PSIRT for their cooperation in having these vulnerabilities remediated.
All vulnerabilities were identified by Christopher Vella of CyberCX.
