Giving Up on Oracle, Researcher Discloses Critical Vulnerabilities in Oracle Forms and Reports

Vulnerability disclosure can be a thorny issue in the world of security – something recently demonstrated in a dispute about security bugs hiding in Oracle software.
In a blog post, security researcher Dana Taylor recounted what became a two-year odyssey between her and the company to fix software vulnerabilities in Oracle Forms and Reports. Oracle did not respond to multiple requests over the past few weeks from SecurityWeek to comment, but Taylor said in an email interview that she went "above and beyond" what is normally considered responsible disclosure.
"I will continue to follow responsible measures when it comes to reporting and disclosing vulnerabilities," Taylor said Saturday. "I went so far above and beyond responsible it is almost comical. After what happened with Oracle I will likely change my full disclosure policy a bit. I may use Rapid7/Metasploit guidelines or another. Not sure yet."
The situation began in 2011. In April of that year, Taylor uncovered a vulnerability that enables an attacker to steal a list of database passwords without authentication. According to Taylor, she reported the bug to Oracle in April of 2011, but was told by the company that it did not consider the issue to be an actual vulnerability. Instead, the company referred to it as a "configuration error."
Seven months later she found another vulnerability that is significantly more serious. According to Taylor, this bug offers an attacker using an unauthenticated browser to take a number of actions, including viewing the file system, downloading any file the Oracle account has access to and loading external pages inside the browser with the Oracle server grabbing the external page for the attacker.
After discovering this second vulnerability, she contacted Oracle and said she planned to release details of the bug. According to Taylor, she received a reply that same day, with the company stating it had re-classified her first bug report as a vulnerability. Later, she was notified that the second bug was being investigated as well, and she continued to receive monthly updates until a patch was released for 11g versions of the software. However, older iterations were not patched; instead the company advised customers to apply workarounds.
"They rated the vulnerabilities as less critical than they are so it is more likely that people wouldn't install them than if it had a high-criticality rating," Taylor told SecurityWeek. "Also, it is worth mentioning that it appears they didn't even fix the parsequery vulnerability but hid it by disabling diagnostic output (at least the 11g patch/workaround). Parsequery can still be exploited at least based on their latest 11g development release if you enable diagnostic output. If Oracle didn't actually fix a vulnerability that allows dumping passwords and executing remote code, it needs to be verified. This would be about as irresponsible as a vendor could get."
The vulnerabilities are critical, she said, because they allow remote code execution on the target system.
"There is one exploit in the wild now that exploits both vulnerabilities, and a Metasploit module is in the works," she explained. "There is talk of creating other Metasploit modules as well due to the horrific things you can do with these vulnerabilities."
Though many Oracle servers are behind firewalls, it is not uncommon for there to be one or two in an enterprise that are public facing, she added.
"It is very hard to block access to ports on Oracle Reports because it would render the server unable to let people use the server," she said. "Break into that server and then you will likely be able to break into the other Oracle servers behind the firewall. If these servers use non-password ssh keys then any server they can access, you can access without needing a password. Once you are in, you own the data with sqlplus /nolog that allows you to gain sysdba with no password."
"Just thinking about [releasing the exploits] had my stomach in knots," Taylor wrote on her blog. "But this had to be done to get a vendor to take serious vulnerabilities seriously which in turn will help protect it’s customers in the future."
There is no way to fully escape vulnerabilities in software, said Barry Shteiman, director of security strategy at Imperva.
"In the Oracle reporting server’s case it is unfortunately fairly easy to show the magnitude of the problem," he said. "A simple Google dork search on "inurl:rwservlet" which is the fingerprint of a reporting server that may be vulnerable, returns [roughly] one million results. That means that when a zero-day like this comes to play, hackers have a starting point of [approximately] one million potential targets."
While some companies are good at patching servers in time, it is never immediate due to the service disruption that ensues as well as the process of applying every update as soon as it comes out, he added.
"This is why when zero-day vulnerabilities appear, patching will always come late," he said. "A vulnerability might be out in the open for ages before the vendor gets notified and patches it, and then it takes another period of time before companies are informed and then patch themselves."