Oracle’s next quarterly Critical Patch Update is slated for July 18, but two vulnerabilities in an older version of the company’s Oracle Access Manager (OAM) solution won’t be among the bugs patched.
Version 10g of the software, Oracle’s solution for web access management and user administration, suffers from two issues: an open redirect vulnerability, and the fact that it sends cookie values in GET requests.
The software features a proprietary multiple network domain SSO capability. Critical to that is ObSSOCookie, a super cookie of sorts. If a user was tricked into clicking through a link via phishing email, for example, and logging into the OAM portal, a remote attacker could read that cookie value and hijack that session, Nabeel Ahmed and Tom Gilis, security researchers based in Belgium warned on Monday.
Ahmed, a senior security assessment consultant at the security firm Dimension Data Belgium, said he and Gilis combed through 100 “high profile domains” running OAM 10g. Only one of the sites was adequately protected against the attack. Ahmed and Gilis discovered the vulnerability while performing a penetration testing assessment for a client earlier this spring.
The researchers realized the service was poorly configured after reviewing a series of raw HTTP requests and responses between the OAM server and the user.
After the two determined the server was sending the ObSSOCookie cookie via a GET request, Ahmed and Gilis set out to steal that cookie. After sending a request to the server for access to a non-existent server, the researchers got redirected to a login screen and in turn, were able to secure a OAMREQ cookie from the server. From there they got a redirect – a cookie – from the OAM server, http://localhost/obrar.cgi?, with a lengthy cookie value appended to the end.
From there all they had to do was swap a valid domain name in for localhost and they were in.
“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 wrote in a disclosure Monday.
The researchers reported the issue to Oracle on March 30, but didn’t hear back from the company until May 4.
Oracle dismissed the researchers’ findings, calling the attack vector more of a configuration issue than a vulnerability. The company did not immediately return Threatpost’s request for comment on Tuesday but told the researchers that companies should use SSODomains, a feature that specifies legitimate web servers within the Oracle Access Manager installation to control where the obrar.cgi redirect is sent, to mitigate attacks.
The company has technically fixed one of the issues in a newer version of the software. Oracle made it so that cookies are encrypted in the GET parameter when it released OAM 11g but the company is unwilling to backport a fix to 10g, according to Ahmed. This could be particularly troublesome for a slew of high profile companies still running 10g, the researcher says.
Large, multinational corporations–car manufacturers, airlines, a pharmaceutical corporation, banks, payment processors, a U.S. government agency, and one of the larger defense contractors in the world–are vulnerable to the attack, Ahmed told Threatpost.
“To be completely honest you can find them via Shodan… or a simple Google search,” Ahmed said, adding that in his opinion, it’s clear the majority of corporations affected aren’t aware this is even an issue.
“Regarding these high profile domains, I assume [these companies] don’t know about this configuration,” Ahmed told Threatpost Tuesday, “Oracle documented it very badly, and talking with Oracle experts from other organizations (those we work very closely with) were unaware of this configuration.”
The researchers informed Deutsche Telekom, one of the affected companies that happened to have a bug bounty program running, and had them fix how SSODomains was configured. According to Ahmed, the two earned “a nice bounty” from the company for reporting the issue.
A video demonstrating the attack against the company’s Romanian site, telekom.ro, was posted on Monday:
As shown in the video, even after the victim logs out the attacker still has an active session and can perform actions as the victim.
It wouldn’t be difficult for an attacker to take advantage of the vulnerabilities, Ahmed claims. A victim would only have to be tricked into entering their credentials on a benign looking login site. After they’ve submitted their credentials, the victim would be redirected to a HTTP 302, which in turn would steal the users cookie. From there the cookie would be used by the attacker’s webserver, listening on port 80, to sign into the user’s account, while the victim would be redirected to his or her own domain, none the wiser.
“The result is that both the attacker and the victim are logged in, both sessions are independent from each other and most importantly the victim will never notice that something is wrong,” Ahmed wrote.
