Before naming your vulnerabilities became cool (Heartbleed anyone?) I discovered an issue on the EMC Documentum software and internally called it “injeception”. Now that naming your vulnerability is so mainstream I will just call it ESA-2014-046 (that, surprisingly, matches with the name used by the vendor!)
But why that name? Well, it’s 2014 and they have released other 45 vulner…. Oh, you mean the injeception? Well, because if you do an injection inside an injection; let me explain to you how it works:
- The EMC Documentum software uses an abstraction layer to allow the software to use any backend database server, such as Oracle or MSSQL. This layer uses their own query language (DQL, from Documentum Query Language) and this the first part for the injeception to work.
- I found an issue (CVE-2014-2508) that allows me to inject DQL at the end of a query. Descriptive error messages also helped to understand what was happening on the backend.
- We are now at the DQL level (moving from the app level that we were before) and we are still confined to the ORM system that EMC has in place to prevent users from one unit/department accessing files from other departments.
- Reviewing the DQL Reference Manual I found references to two interesting keywords: ENABLE and ORACLE. The use of both can be seen in the page 323 (Passthrough hits) of the manual. It essentially allows insertion of custom Oracle (and presumably MSSQL, but didn’t have the chance to try that) SQL into the final query that is generated by the Documentum software. We have our third jump! (And I think this one is CVE-2014-2507 but I haven’t been credited for this one, so I am not sure if I am right assuming this…)
- Now we find ourselves in an interesting position. We are inside an Oracle hint. For those who don’t know (I didn’t at the time) hints are a special set of keywords that you can write between the SELECT and the first parameter of the query to improve the performance. Like this:
SELECT /* HINT */ 1 from dual;
- So… can we escape from the hint syntax and execute code? Sure thing! If we write ‘*/’ Documentum passed it unescaped to the SQL query and we are able to inject any SQL query from our original DQL injection. Let’s go up a level again on this injection to construct the final valid query.
- First we need to make our Oracle query:
*/ user FROM dual--
- Now we need to add it into a valid DQL query:
ENABLE(ORACLE('*/user FROM DUAL--'))
- Finally, we have to add that string at the end of our DQL Injection:
table_field from valid_table ENABLE(ORACLE('*/user FROM DUAL--'));--
- As you can see we need a valid table and a valid field but I got those from the debug messages, documentation might also help.
This way we have moved from a DQL Injection (CVE-2014-2508) to a shell injection (CVE-2014-2507?) and execute Oracle queries. But what about CVE-2014-2506? Well, the user running those Oracle queries does not have any privilege limitations so it can access any information, no matter what department or OU the user executing the DQL is member of, they will access even configuration details from the server.