Alright, so when we need to recreate a database link for some reason and we do not happen to have the password handy, we’re usually stuck. However, sometimes there is a way to recover passwords for database links.

The method described below only works for the “old” password versions (<= 11.2.0.2)!

Starting with Oracle 11.2.0.2, Oracle salts the password hashes, therefore you will need to crack the password and cannot just query it. However, if the database link was created pre-11.2.0.2, the password is saved in an “old” format without the salt. To check if there are any database links with this old format, query SYS.LINK$ like so:

SQL> select name, userid from sys.link$ where length(passwordx)=50;

NAME                                USERID
----------------------------------- ------------------------------
MYDBLINKNAME                        SIMON
So now we’ve found a database link with a password in the old format, get the encrypted password from the same table:

SQL> select passwordx from sys.link$ where name='MYDBLINKNAME';

PASSWORDX
--------------------------------------------------
0560A31A6EFEC902B9286FFC981F4C9A92F8470D406ADEA670
With this information, we can use the following PL/SQL block (found in the blog of Satyanarayana Murty Munukutla) to calculate the plain password:

set serveroutput on
declare
 db_link_password varchar2(100);
begin
 db_link_password := '0560A31A6EFEC902B9286FFC981F4C9A92F8470D406ADEA670';
 
 dbms_output.put_line ('Plain password: ' || utl_raw.cast_to_varchar2 ( dbms_crypto.decrypt ( substr (db_link_password, 19) , dbms_crypto.DES_CBC_PKCS5 , substr (db_link_password, 3, 16) ) ) );
end;
/
Running this block will give you the password:

Plain password: Forget12

This is my third blog post about DB Link encryption/decryption.In the first one i demonstrated how we can find the database link password in clear text using GDB and Intel pin tools.In the second one i have given more information about how it was encrypted/decrypted (AES in CBC encryption mode).It’s now time to reverse engineer it !


NOTE : All the test are done in oracle 12.1.0.2.6/OEL6/UEK4

Update 08/03/2017 : The script also work in oracle 12.2.0.1

As explained in my previous post to decrypt the password we need three things.

Initialization vector
Ciphertext
Encryption Key
After some investigation it appeared that this parameters are not depending only on “PASSWORDX” of “sys.link$” but also in two other parameters :

NO_USERID_VERIFIER_SALT in table sys.props$ (Database dependent).
1
2
3
SELECT VALUE$
FROM SYS.PROPS$
WHERE name = 'NO_USERID_VERIFIER_SALT';
Variable “ztcshpl_v6” fixed across different databases(note:same value in 11.2.0.4 was named ztcshpl_v6.0)
readelf -s oracle |  grep ztcshpl_v6
112105: 0000000010b9ee40 16384 OBJECT  LOCAL  DEFAULT   29 ztcshpl_v6

Here is some info about how this different parameters combine :

Initialization vector : Using the second byte of passwordx to lookup in ztcshpl_v6
Ciphertext : Using ztcshpl_v6 and passwordx
Encryption Key : Calculated as a XOR between two keys :
Key 1 : Using ztcshpl_v6 and passwordx
Key 2 : Hash sha256 of NO_USERID_VERIFIER_SALT
Installation : (This script use Connor McDonald Package “bitops2” for bit operation like “XOR” bitops2.bitxor )

Download and install : bitops2.sql
Download and install : db_link_password_decrypt.sql
Update 08/03/2017 : the script bitops2.sql is not needed any more just install db_link_password_decrypt.sql

APPLIES TO:
Oracle Database - Enterprise Edition - Version 8.1.7.4 to 11.2.0.1 [Release 8.1.7 to 11.2]
Oracle Database Cloud Schema Service - Version N/A and later
Oracle Database Exadata Cloud Machine - Version N/A and later
Oracle Cloud Infrastructure - Database Service - Version N/A and later
Oracle Database Backup Service - Version N/A and later
Information in this document applies to any platform.
 


PURPOSE
A database link is a mechanism used to provide a method of transparently accessing one server from another.

When creating a database link, a user name and password of the account on the remote server can be specified. Creating the database link without credentials works only if the user exists on both databases and has the same password.

Once this is done, all queries using the link have the privilege of the indicated account on the remote server. By omitting an account and password when creating a database link, the account and password of the user connecting through the link is used. Indicating the username and password of an account to use for all connections through a link can lead to passwords being exposed.

Prior to version 10gR2 database link passwords are stored as plain text. Users with SELECT privilege on the SYS.LINK$ table could view the passwords in plain text. Setting up links to authenticate as the current user prevents unencrypted passwords from being exposed and provides increased accountability.

Oracle accounts were found with permission to view the table SYS.LINK$. Access to view the table SYS.LINK$ should be restricted because database link passwords are stored unencrypted (prior to 10gR2) in this table.


SCOPE
For all DBAs who are defining or maintaining database links.

DETAILS

On any Oracle version prior to 10gR1, if you have been granted the SELECT ANY TABLE privilege you can see the password of any user that is used in a database link (by querying the SYS.LINK$ table). As such you can connect to these remote or local databases at will. We rely on sys to protect link$.



Important change in the SELECT ANY DICTIONARY system privilege
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1) In Oracle release 10gR1, the access to SYS.LINK$ was removed from the  SELECT ANY DICTIONARY system privilege. While this still doesn't solve the general problem, it will  allow the proper functioning of tools that depend on SELECT ANY DICTIONARY(e.g. Oracle Enterprise Manager) without exposing the credentials stored in SYS.LINK$.


2) Starting with Oracle 10gR2 the passwords for the database links are not stored in clear text anymore.





Workarounds:
~~~~~~~~~~~~

-> Drop the database link and create a link without specifying an account and passwords.

To drop a database link, execute the command:


SQL> drop database link mydblink;


To re-create a link without hard coding the password, execute the command:


SQL> create database link mydblink using 'alias';


-> To revoke permissions from the account or role, execute the following command:



SQL> revoke select on SYS.LINK$ from ;



Patches:
~~~~~~~~
Currently there is no patch available to deal with this problem. One of the workarounds listed above must be used.

As of version 10g Release 2 (10.2.0.x), the LINK$ table includes a new column PASSWORDX which is used to store the encrypted database link password. Details of the encryption scheme will not be disclosed for obvious reasons.




REFERENCES