Thank You So much.
As I understand , till the time it's(i.e. the password) in the database and
somebody got access to LINK$ or as you mentioned, even the export dumps are
easily hackable to get the password exposed. So we can at least ensure
restricted access to these views or functions. Or some wallet like
implementation stuff which ensures the password wont reside in the database
itself. (Yet to research this direction.)
And yes, my concern was if the DB link gets created from the export dump in
a third database that can be used to access objects/data from the remote
database easily. But again as you said , if somebody has capability to do
the export/import that itself is enough to hack through the password , so
we should block that first step itself.
Thanks & Regards
Lok
On Sat, Dec 19, 2020 at 7:49 PM Andy Sayer <andysayer@xxxxxxxxx> wrote:
Access to dbms_crypto isn’t itself going to be a problem, it doesn’t give
you anything you wouldn’t already be able to do (you can just use external
cryptographic tools, although it does add effort to the attack).
Yes, there’s no requirement for the connection string in a database link
to work for it to be created. The string will only get used when a query
that uses the link is called. I also wouldn’t be surprised if there were
tools that could just read and decrypt it straight from the export file
without needing a surrogate database.
It’s definitely worth sitting down with your security people, discussing
the problem and seeing what would be an acceptable mitigation of the risk.
Thanks,
Andy
On Sat, 19 Dec 2020 at 13:31, Lok P <loknath.73@xxxxxxxxx> wrote:
Thank you Andy.
I hope you mean that the technique mentioned in the blog below , i.e the
password for the DB link as it's stored in sys.link$ table can be decrypted
using dbms_crypto.decrypt?
https://community.oracle.com/tech/developers/discussion/4157188/how-to-retrieve-the-database-link-password
Also if I understand you correctly, as the password is
readable/decryptable in this version 11.2.0.4, So if somebody gets access
to sys.Link$ OR dbms_decrypt OR having export/import privilege OR SYSDBA
privilege can see it and play with it. So it is advisable to control
access/privileges on these entities rather than worrying about the exposure
of DBlink password through export/import file/utility.
And by the way, from your description it looks like a simple export of a
db link and importing it on any other database can quietly create it with
the same password/credentials without fail. Correct me if wrong.
And yes, we are planning to move to 19C asap, but some third party tool
dependency are currently restricting us for that, but it's in plan.
On Sat, Dec 19, 2020 at 5:54 PM Andy Sayer <andysayer@xxxxxxxxx> wrote:
For 100% clarity, DB link passwords can be read without much issue in an
11g database if you have the right privileges (default sysdba).
If you have privileges to export the DB link then you can import it
wherever you want and grab the password from the database it was imported
into. You want to treat your DB exports as secure as possible (you would be
doing this anyway because data leaks are a serious problem).
As long as sysdba is only given to authorised people and as long as
you’re not putting exports in insecure places then you should be okay. That
said, there may well be privilege escalation vulnerabilities in your
version of Oracle, there might even be in some of the code that you’ve
manually deployed on top.
There’s not really a more secure replacement for DB links, if you need
to use them then you’re going to have a hard time moving away.
Thanks,
Andy
On Sat, 19 Dec 2020 at 11:58, Lok P <loknath.73@xxxxxxxxx> wrote:
Thank You.
Actually even these are two different databases and both are prod say
DB1 and DB2 and are in the same network. The DB links of DB1 should not get
simply imported to DB2 silently(with same credentials under the hood even
if it's not exposed in EXPORT/IMPORT files) thus opening a window to access
the REMOTE PRODDB (say DB3) which was initially meant for DB1
users/applications only. Won't this be considered as a threat? Correct me
if my understanding is wrong here.
On Sat, Dec 19, 2020 at 11:56 AM Stefan Knecht <knecht.stefan@xxxxxxxxx>
wrote:
Well, there's two sides to this.
In any proper secured network, a DEV machine should not be able to
connect to a PROD machine. Be it via DB link or any other means. That's
not
a database problem, that's a network zoning problem.
But also, most places use post-import or post-restore steps which are
automatically or manually performed, to deal with anything left over that
shouldn't be the way the import creates them (e.g. you'd replace real
world
user's emails with dummy emails when refreshing dev or qa with prod, and
you'd likely also want to change any passwords or database links
accordingly).
On Sat, Dec 19, 2020 at 1:34 AM Lok P <loknath.73@xxxxxxxxx> wrote:
I checked two ways i.e first by taking the export dump and doing
impdp with parameter SQLFILE and as I see in version 11.2.0.4 the dblink
DDL is having a bind variable in place of password.
Then I did try to see the .DMP file content and it's all junk. I
didn't see any hashed value or bind value. So that looks perfect with
respect to security stand point.
Now one thing wanted to see, if somebody takes the export dump of
dblink from PRODDB and import it in some Dev database say DEVDB , will
that
dblink will be created without any error? And in that case will the user
silently able to connect to the REMOTEPROD using that dblink without
anyone's notice? If it's true then even the password is not exposed to
outside but still it's a security risk. Correct me if wrong?
On Thu, 17 Dec 2020, 9:59 am Lok P, <loknath.73@xxxxxxxxx> wrote:
I am not very sure how to create DB links using TCPs and if it's the
safest with no security loophole. Can you explain a bit and we are on
11.2.0.4 so if there is any version dependency?
But the below doc does state that the password was stored as
cleartxt in sys.link$ in prior 10GR2. But nothing mentioned if
export/import password is exposing that in clear text in current
versions
or not?
MOS Doc ID 202987.1
On Thu, Dec 17, 2020 at 8:14 AM Mladen Gogala <
gogala.mladen@xxxxxxxxx> wrote:
Or create link using TCPS.
On 12/16/20 2:03 PM, Powell, Mark wrote:
Ask the security team to present you proof the password can beexposed
when some exports/imports the link
--
Mladen Gogala
Database Consultant
http://mgogala.byethost5.com
--
//www.freelists.org/webpage/oracle-l
--
//
zztat - The Next-Gen Oracle Performance Monitoring and Reaction
Framework!
Visit us at zztat.net | @zztat_oracle | fb.me/zztat | zztat.net/blog/
