Security in a multi-user system relies on individuality of account access and Identity Integrity.
The ability to assume the identity of another user is one of the most powerful privileges that exists and should be monitored and logged using a Database Activity Monitoring System both for compliance, assurance and good practice.
Client supplied identity information passed to the DB can be selected using this script ~ Press the plain text button above the code to copy and paste clean code into SQL*PLUS.
set heading off
select SYS_CONTEXT('USERENV','TERMINAL')
,SYS_CONTEXT('USERENV','LANGUAGE')
,SYS_CONTEXT('USERENV','SESSIONID')
,SYS_CONTEXT('USERENV','INSTANCE')
,SYS_CONTEXT('USERENV','ENTRYID')
,SYS_CONTEXT('USERENV','ISDBA')
,SYS_CONTEXT('USERENV','NLS_TERRITORY')
,SYS_CONTEXT('USERENV','NLS_CURRENCY')
,SYS_CONTEXT('USERENV','NLS_CALENDAR')
,SYS_CONTEXT('USERENV','NLS_DATE_FORMAT')
,SYS_CONTEXT('USERENV','NLS_DATE_LANGUAGE')
,SYS_CONTEXT('USERENV','NLS_SORT')
,SYS_CONTEXT('USERENV','CURRENT_USER')
,SYS_CONTEXT('USERENV','CURRENT_USERID')
,SYS_CONTEXT('USERENV','SESSION_USER')
,SYS_CONTEXT('USERENV','SESSION_USERID')
,SYS_CONTEXT('USERENV','PROXY_USER')
,SYS_CONTEXT('USERENV','PROXY_USERID')
,SYS_CONTEXT('USERENV','DB_DOMAIN')
,SYS_CONTEXT('USERENV','DB_NAME')
,SYS_CONTEXT('USERENV','HOST')
,SYS_CONTEXT('USERENV','OS_USER')
,SYS_CONTEXT('USERENV','EXTERNAL_NAME')
,SYS_CONTEXT('USERENV','IP_ADDRESS')
,SYS_CONTEXT('USERENV','NETWORK_PROTOCOL')
,SYS_CONTEXT('USERENV','BG_JOB_ID')
,SYS_CONTEXT('USERENV','FG_JOB_ID')
,SYS_CONTEXT('USERENV','AUTHENTICATION_TYPE')
,SYS_CONTEXT('USERENV','AUTHENTICATION_DATA')
,SYS_CONTEXT('USERENV','CURRENT_SQL')
,SYS_CONTEXT('USERENV','CLIENT_IDENTIFIER')
,SYS_CONTEXT('USERENV','GLOBAL_CONTEXT_MEMORY') from dual;
But the above information is known to be easily falsified which has also been demonstrated . Only the IP address has reasonable integrity, post TCP hand shake that is.
Therefore the Identity Integrity of DB users usually relies on username/password confidentiality but there are a number of ways to bypass this control which need to be recorded in a Database Activity Monitoring System or DAMS.
1. The BECOME USER system privilege allows an OCI call to be made thus changing the effective identity of a logged on user.
2. BECOME USER is built into sys.kupp$proc.change_user(’ASSUMED_USERNAME’);
This is a handy command to use in release scripts that require a change of user from the higher DBA downwards and has also been used to go up in privileges such as in Tanel’s now removed post http://blog.tanelpoder.com/2007/11/10/oracle-security-all-your-dbas-are-sysdbas-and-can-have-full-os-access/ which has been duplicated at this URL http://www.articles.freemegazone.com/oracle-security-all-dba-os-access.php. This is how the identity change looks.
SQL> conn dbauser@(description=(address=(protocol=tcp)(host=myhost)(port=1521))(connect_data=(service_name=orcl)))
password
Connected.
SQL> SELECT USER FROM DUAL;
USER
------------------------------
DBAUSER
SQL> exec sys.kupp$proc.change_user('PAULMWRIGHT');
PL/SQL procedure successfully completed.
SQL> SELECT USER FROM DUAL;
USER
------------------------------
PAULMWRIGHT
The good news is that Sentrigo HH will still record the original DBAUSER in its alerts and logs even after kupp$proc.change_user(). Additionally a rule can be set up to record all calls to the sys.kupp$proc package.
object='SYS.KUPP$PROC' and statement contains 'change_user'
But there are more straightforward ways of assuming another user’s identity in Oracle such as simply changing the password of a user to a known value and logging on as them. These techniques are invaluable when troubleshooting a user’s privilege errors. But they need to be monitored and logged so how many ways of doing that?
ALTER USER ASSUMED_USER IDENTIFIED BY NEWPASSWORD;
--But if wish to put back the old password after the identity has been used can use this well known method
SELECT PASSWORD FROM SYS.USER$ WHERE NAME='ASSUMED_USER';
ALTER USER ASSUMED_USER IDENTIFIED BY NEWPASSWORD;
ALTER USER ASSUMED_USER IDENTIFIED BY VALUES 'ORIGINALPASSWORDHASH';
Therefore good idea to alert to ALTER USER commands in Sentrigo HH with this rule:
statement contains 'ALTER USER'
--or even better using RegEx to allow for variable white space:
statement matches 'ALTER\s*USER'
--but also need to consider the GRANT syntax:
grant role to paulwright identified by password;
--additionally the direct update:
update sys.user$ set password = '737B466C2DF536B9' where name=’PAULMWRIGHT’;
--both of which are going to require a more sophisticated rule writing strategy to catch all possible permutations
--more on this later...
A perhaps less obvious method of temporarily assuming another’s identity is by backing up the password file and then overwriting a new one and then copying back the original by combining the techniques in these two papers.
http://www.dcs.co.jp/security/NGS_freedownloads/OracleSysDBA_Backdoor.pdf
http://www.oracleforensics.com/wordpress/index.php/2008/10/10/create-any-directory-to-sysdba/
This method will allow a user to assume the identity and privileges of the SYS user as long as they have CREATE ANY DIRECTORY to start with. Therefore a DAMS should alert to UTL_FILE and references to the location of the password file as well. BUT what if the password file has been overwritten by using an OS based script which has been written via UTL_FILE and executed by CREATE TABLE without needing a directory pointing to the password file location itself, as per CREATE TABLE to OSDBA? Again the DAMS rules have to be more sophisticated.
Also need to think about a DB user with Java privileges running orapwd from the OS. This will allow the user to change the SYS password by recreating the password file, thus enabling the SYS identity and privileges.
See JAVA_ADMIN to OSDBA paper http://www.oracleforensics.com/wordpress/index.php/2009/08/31/java_admin-to-osdba/. Commands such as the following do allow a DB user to change the SYS password and thus assume the SYS identity.
SQL> call javaos('C:\app\PaulWright\product\11.1.0\db_1\bin\orapwd.exe file=PWDorcl2.ora password=pass entries=5 FORCE=Y');
Call completed.
If you check the password file you will see the password changed. This will then need a reboot to be effective but once OS access is gained via Java the whole DB is open for reboot and deletion of audit trail. DB is meant to be a firewall to the OS not a gateway.
But the required Java privileges are not set by default, so they need to be granted.. On this note I recommend reading an interesting Metalink article Doc ID:787878.1 entitled “Data Pump Errors With ORA-39083 And ORA-29532 During Full Import When Creating Object Type PROC_SYSTEM_GRANT”. Can you see what this article from March 2009 is actually showing? ….. more to come on this at the SANS conference.
Lastly I have a “CREATE PROCEDURE to OSDBA” escalation that affects 10g and 11g which I will also be discussing at the SANS DAMS course on Saturday 5th December where I will show you how to solve all the above vulnerability issues as well as provide effective profiling of user activity to give assurance that your organisation’s security measures are being enforced. It is important for those responsible for defending internal assets to keep ahead of the cutting edge, so see you there.
Best regards,
Paul
November 1st, 2009 | Category: Uncategorized | Comments Off
