Two security researchers recently discovered an issue with improperly configured Oracle Access Manager (OAM) 10g that can be exploited by remote attackers to hijack sessions from unsuspecting users.
The issue, security researchers Nabeel Ahmed and Tom Gilis discovered, is related to the OAM authentication flow. In this Oracle Single Sign-On (SSO) implementation, the OAM server only validates whether the requested resource is indeed protected or not, and then redirects the user to a login page.
The OAM Server, the researchers note, sets the OAMREQ cookie (which contains information regarding the location of the requested resource) in the user’s browser, so it would know on the next request for which resource the user is authenticating.
Next, the user submits credentials on the provided login screen, and the OAM server verifies them and, if the logon is successful, serves a cookie and a valid session, while also redirecting the user to the protected resource.
While analyzing the cookies the server delivers to the user, the security researchers noticed that the request/response flow contains some red flags. One of them is a parameter called rh=, which is the domain of the protected resource, while the other is the fact that the cookie is sent via a GET request.
The security researchers also noticed that, while the OAM server validates whether the resource is protected or not, it doesn’t serve an error if the resource doesn’t exist. Even in such cases, the OAM server redirects the user to the login page and serves an OAMREQ cookie.
After receiving a cookie for a non-existing resource, the researchers tested their findings against real resources and discovered two issues: the user is redirected after submitting credentials (Open Redirect), and the cookie value is transmitted in the GET request
“Since we can control where the user has to go and since we also can read the cookie value that is coming from the user we can hijack his session,” Ahmed notes.
For that, the user would need to be tricked into clicking a link and logging in. However, since the user is required to log in on the real portal, that shouldn’t raise suspicion. If the user is logged in, the cookie would be retrieved without issues and without the victim noticing it.
“We found hundreds of hundreds of high profile organization with the same misconfiguration, all of them exposed against session hijacking. We analyzed 100 high profile domains and only 1 was properly secured against this attack,” Ahmed said.
An attacker knowing such domains could send phishing emails and lure victims into clicking the link. The attacker doesn’t have to set up another website to capture credentials, but the victim is redirected to the login page, where they are asked to submit their credentials.
The server responds with a HTTP 302 redirect pointing to a malicious domain that steals users’ cookie and uses it to log in to their account. The webserver sends a redirect to the victim with the same cookie information to the appropriate domain, meaning that both the victim and the attacker are logged in, each on their independent session.
According to the researcher, when they contacted Oracle to point out the configuration issue, the company informed them that the problem had been already addressed through a feature called SSODomains. However, if SSODomains isn’t defined, it “effectively means you’ll be able to get valid session for any domain,” the security researcher said.
According to Ahmed, the NIST CVSSv3 calculator would give the vulnerability an overall score of 9.3, meaning that it is a Critical issue.