Hacking Oracle From Web Apps – Sumit Siddharth
Exploitation techniques for exploit SQL Injection attacks on Web Applications with Oracle databases
Because it’s Defcon… and we love SQL Injection!
No free tools for hacking Oracle Databases from the web
- Even commercial tools like Pangolin have outdated techniques
Oracle comes with a number of default packages. This has reduced a lot with the latest 11g release
By default these packages run with the privileges of the definer
This can be changed to the caller of the function, but must be set in the function/procedure (AUTHID CURRENT_USER)
Owning from the network is easy
- Enumerate SID
- Enumerate common users
- Connect to the Oracle DB
- Exploit SQL Injection in a procedure owned by SYS
- Become DBS
- Execute OS Code
Demonstrated by Chris Gates last year using a number of Metasploit plugins
In Oracle there are 2 classes of Injection
- Doesn’t allow chained statements
OS Code execution is also not as simple as it is in Microsoft SQL Server
- Injection in Anonymous PL/SQL Block
- No Restriction
- Execute DDL/DML
- Common SQL Injection
- Limited capabilities
- No chained statements
eExploitating PL/SQL Injection
Using David Litchfield’s exploit from Blackhat DC 2010 –> Enable JAVA IO Permissions
OS Command Injection can then be obtained by calling a JAVA function (DBMS_JAVA_TEST) and calling a command on the local system
Exploiting SQL Injection
This could mean many thing… do you want data from the DB or a shell –> depends on the goals of a test/attacker
Extraction of Data
- Error Messages Enabled
- Error Messages Disabled
- Union Query
- Blind injection
- Time delay / Heavy queries
- Out-of-band channels
- Privilege escalation
- OS Command Execution
Is your SQL Injection Privileged or unprivileged?
Are you executing with DBA privileges or something else
- Privileged SQL Injection
- Happens more often when the application connects to a database with DBA privs
- SQL Injection is in a procedure owned by the DBA (regardless of the connection string)
- Unprivileged SQL Injection
To exploit the Os we need Functions executable by public and vulnerable to :
- PL/SQL Injection
- Allows PL/SQL execution as a feature
- Buffer overflow
There are a few functions known but the exploit is not publicly available
e.g. DBMS_JAVA_TEST (10g) buffer overflow
Of those known the following are popular:
- Function vulnerable to PL/SQL Injection
- Runs with definer (SYS) privileges
- Allows privilege escalation
- OS Command Execution
Privileges needed to execute code on the OS
- DBA Privileges
- JAVA IO Privileges
Versions prior to CPU April 2006 there are a number of exploits in Pangolin and CoreImpact
Functions to execute code on the OS
These take an Oracle class as input and cannot be executed without JAVA IO Privileges.
DBA can grant himself the required privileges, however even without he can use the SYS.KUPP$PROC.CREATE.MASTER_PROCESS() function on 10g/11g to execute code on the remote OS.
Supports these new attack types and can be downloaded from Google Code.
Includes the ability to upload and execute a Metasploit payload through these vulnerabilities
Supports JAVA IO and DBA execution as required
Has a cleanup mode for nice penetration testers 😉
Non-interactive second order injections
Even if a field is not injectable it could be that the code is executed if for example, an administrator views the injected code through a second vulnerable application (for example a logging tool, or administration screen).
The malicious user will never see the response however, as the secondary user is running the injection. This means any output will be returned to the secondary user and not the malicious user.
Another possible scenario is a trigger or automated nightly process that acts on the injected code when run.
So how can we make these non-interactive attack vectors interactive ?
Encode and upload a binary (Metasploit payload) to the remote server and wait for the secondary user/process to trigger the exploit –> Shell –> WIN
webraider tool implements this style of attack to upload a Metasploit module
You’ve been hacked… so what?
PCI compliance mandates the card data must be stored encrypted –> So the output is encrypted
PCI doesn’t specific if the encryption happens at the DB or App level
If it’s at the DB level, then the App decrypts the data when requesting –> Passing the encryption key means an attacker could extract them
- v$sql table logs statistics on shared SQL area
- Typically stores last 500 queries –> including the encryption details