Looking back at old vulnerabilities can be both fun and useful. Part history, part nostalgia, and still a healthy dose of understanding the technical innerworkings of some software or system. I'm sure that George Santayana would agree. I had planned to go into detail about a bygone vulnerability I found a long time ago in Oracle Reports, but for now this is just a teaser.
Several years ago, I performed an assessment that included an Oracle Reports server. At the time, Oracle Reports had a number of known, high-impact security vulnerabilities. Examples include a file overwrite vulnerability reported by Alexander Kornbrust in 2005 and other vulnerabilities (such as CVE-2012-1734, CVE-2012-3152, and CVE-2012-3153) that can lead to arbitrary file reads and remote code execution, via the rwurl job type.
I wound up digging into Oracle Reports, and found a couple of new / non-public vulnerabilities. These vulnerabilities led to arbitrary file reads and command execution, but did not use the rwurl job type, as that vulnerability had been fixed in my target environment. I finished that assessment, did a little more product testing, and confirmed that my vulnerabilities could be exploited in Oracle 10gR2 and Oracle 11gR2 (other versions untested). I also reported my findings to Oracle Product Security, and their response was (to paraphrase, if memory serves), that these vulnerabilities would not be exploitable in a properly-configured system set up in accordance with a customers-only configuration document. Not being an Oracle expert or even ever having been even an Oracle administrator, my depth of what was common, typical, or recommended in Oracle environments was limited. And so I didn't really pursue the issue further (nor did I come across other Oracle Reports servers in subsequent assessment target environments).
Extended Support for Oracle 11gR2 ended on December 31, 2020. I had planned to blog in more detail about the vulnerabilities I found (many years after the fact), since the techniques to find and exploit older vulnerabilities can still be relevant and rewarding today. However, since there are still systems online as of May 2021 that could be vulnerable, I'm going to wait for the time being.
With that said, if you are still running Oracle 10/11 Reports Server in 2021 or later, I'd recommend you take the following actions immediately:
- Ensure that you are running a fully-supported Oracle Product, with the latest relevant security patches. Like not Oracle 10g/11g. Really.
- Enforce authentication to the Oracle Reports Servlet by default
- Validate and/or whitelist the expected values for report inputs and outputs
- Limit the file creation/modification rights of the Report Servlet output
- Review and enforce other relevant authentication, authorization, and file access control controls on the local system.
No comments:
Post a Comment