Chris Gates, CISSP, CISA, GCIH, GPEN, C|EH
In the first article, Oracle Web Hacking Part I, I talked about scanning Oracle Application Servers for default content and how to use that content for information gathering. A pentester can utilize that information to run SQL queries and to gain a foothold into the network. I also talked about iSQLPlus and some fun things you can do with that application, if you are able to guess credentials for it. I also showed some Metasploit modules to help you accomplish all of it.
In Part 2 of 3 of this ongoing series of columns, I’ll dive into attacking the Oracle Application Server Portal (OracleAS Portal). I’ll focus on Oracle 9i and 10g up to Release 2. With 11g (10.3.x) Oracle moved to Weblogic, and it’s completely different and therefore out of the scope of this series. But there are plenty of shops out there still using 9i and 10g, which gives us plenty of opportunity for breaking stuff. So, let’s get to it.
What is Oracle Application Server Portal?
To start, here’s a couple quotes directly from the Oracle documentation:
“Oracle Application Server Portal (OracleAS Portal) is a Web-based application for building and deploying portals. It provides a secure, manageable environment for accessing and interacting with enterprise software services and information resources.”
“A portal is a central place for making all types of information accessible to an audience of varying range. Portals can be roughly broken down into two major classifications: the enterprise information portal and the content management portal. In most cases, you’ll find that you need to combine the two implementations in order to meet the full spectrum of your business needs.”
I like to think of portals as Content Management Systems (CMS) before they existed. Joomla, WordPress, and others *essentially* do the same thing now.
Enough Talk… Let’s Break Stuff
1. Locate Portal Servers
2. Determine Portal Database Access Descriptor (DAD)
3. Verify PL/SQL is enabled
4. Locate an injectable function
5. Privilege escalation to DBA
6. Post Exploitation
1. Locate Portal Servers
The scanner module does this for us. Typical results when we find an Portal server look like the screenshot below:
Figure 1: Output from the Metasploit Oracle Application Server scanner module.
2. Determine Portal Database Access Descriptor (DAD)
A Database Access Descriptor (DAD) is “a named set of configuration values that specify the information necessary to create a session for a specific database and a specific database user/password. This includes the database service name and the Globalization Support setting (for example, language) for the session.”1
The DAD points to PL/SQL (mod_plsql) Gateway resources. The job of the PL/SQL Gateway is to act as a proxy server taking the user’s web request and passes it on to the database server, where it is executed.
1. The web server accepts a request from a web client and determines if it should be processed by the PL/SQL Gateway.
2. The PL/SQL Gateway processes the request by extracting the requested package name, procedure, and variables.
3. The requested package and procedure are wrapped in a block of anonymous PL/SQL and sent to the database server.
4. The database server executes the procedure and sends the results back to the Gateway as HTML.
5. The gateway sends the response, via the web server, back to the client.
It typically looks like this:
|DAD location||A virtual path to handle PL/SQL requests that you have configured in the Web server. The DAD location can contain only ASCII characters.|
|The database schema name. If omitted, name resolution for package.proc_name occurs based on the database user that the URL request is processed as.|
|The package that contains the PL/SQL stored procedure. If omitted, the procedure is standalone.|
|proc_name||The PL/SQL stored procedure to run. This must be a procedure and not a function. It can accept only IN arguments.|
|The parameters for the stored procedure. The string follows the format of the GET method. For example:
● Multiple parameters are separated with the & character. Space characters in the values to be passed in are replaced with the + character.
● If you use HTML forms to generate the string (as opposed to generating the string yourself), the formatting is done automatically.
● The HTTP request may also choose the HTTP POST method to post data to mod_plsql.
And some examples2:
Example 1. A procedure that takes no arguments.
The web server running on www.mysite.com and listening at port 9000 handles the request. When the web server receives the request, it passes the request to mod_plsql. This is because the /pls/mydad indicates that the web server is configured to invoke mod_plsql. It then uses the DAD associated with /pls/mydad and runs the myproc procedure stored in mypackage.
Example 2. A procedure that takes arguments.
The web server running on www.mysite.com and listening at port 9000 handles the request. When the web server receives the request, it uses the DAD associated with /pls/mydad/ and runs the myproc stored procedure in mypackage, and passes two arguments, a and b, with the values v, and 1 to the procedure.
The challenge as a pentester is determining/finding the “/pls/mydad/” portion. Sometimes its obvious. Sometimes its a default like “/pls/portal/”, but in reality it can be anything the programmer wants it to be.
Some common DADs are listed below:
Figure 2: Common Oracle DADs.
To help identify some of the more common DADs, I wrote the Oracle DAD scanner (oracle_dad_scanner.rb). Below are some examples of the DAD scanner in action.
Figure 3: Oracle DAD scanner discovering valid DADs.
Figure 4: Oracle DAD scanner discovering valid DADs (also redirecting to an internal resource).
3. Verify PL/SQL is Enabled
Once we think we have a valid DAD, we need to make sure the PL/SQL gateway is up and running. This is pretty simple to do. The function “null” is a valid function for Oracle Portal, so if we browse to:
We should receive a HTTP 200 response back. Something random is not a valid function so if we browse to:
We should receive a HTTP 404 response back. If the server responds with a 200 OK for the first request and a 404 Not Found for the second request then it indicates that the server is running the PL/SQL Gateway.3
The oracle_plsql_enabled.rb module can test to see if the PL/SQL gateway is up and running.
Figure 5: Validating the PL/SQL gateway is running on our target.
4. Locate an Injectable Function
It is possible to exploit vulnerabilities in the PL/SQL packages and stored procedures that are installed by default in the application and database servers. How you do this depends on the version of the PL/SQL Gateway and what version of Oracle Application Server is running. One of the more common vulnerabilities is SQL Injection in the default packages or default stored procedures. XSS is also possible (but not covered here).
Going back to our explanation of the Database Access Descriptor:
We see for our first example:
/pls/dad/ is the DAD
OWA_UTIL.CELLSPRINT? is the vulnerable package
P_THEQUERY is the query string
SELECT+USERNAME+FROM+ALL_USERS is our injected SQL query
Information on the OWA_UTIL.CELLSPRINT vulnerability is available here:
To assist in locating some of these well known vulnerabilities, I wrote oracle_modplsql_pwncheck.rb. This module simply checks for common oracle portal SQL Injection vulnerabilities. It is based on Sid’s oap.pl. The module attempts to do a non-malicious SQL query of “select 1 from dual.” If this is successful, then the application will return an HTTP 200 response and HTML content of “1.”
Figure 6: a “1” returned for our SQL query.
If the 1 is returned, then we know the application is processing SQL queries. We can now beginning enumerating database information.
For example, enumerate database information:
Figure 7: Querying database version information.
Figure 8: Querying database version information.
Enumerate database SID:
Figure 9: Querying database SID.
Enumerate all database users:
Figure 10: Querying database users.
Enumerate privileges of the current user:
Figure 11: Querying privileges of the portal user.
From here you can query all database information the portal user has permissions to see. To see other sensitive tables you may have to conduct privilege escalation attacks to make the current user a DBA. DBA will also be a requirement for most of the common post-exploitation activities that a pentester will attempt as well. In Part III we’ll cover the remaining sections:
5. Privilege Escalation to DBA
The code discussed is available here:
and has also been ported to wXf (web eXploitation framework):