RE: Oracle OS level security

NRC audits, boy those sure are fun to be on the receiving end of. Nothing like getting comfy on the couch and reading 10CFR for pleasure.

-----Original Message-----
Sent: Wednesday, November 27, 2002 10:56 AM To: Multiple recipients of list ORACLE-L

Jared - I would be very careful about naming specific tools. Having been an NRC auditor and been audited a lot of times, there is sometimes too much specific information, which will leave the auditor with the impression there is no security at all. They will then feel obligated to "flunk" your system/process/site, or at least give you a ton or corrective action items. If you feel heavily obligated, you might allude to the fact that an expert could access the Oracle data at the O.S. level if they were very determined and leave it at that. I'm sure there are some O.S. tools that can accomplish what BBED can, if not as conveniently.

Dennis Williams
DBA
Lifetouch, Inc.
dwilliams_at_lifetouch.com

-----Original Message-----
Sent: Wednesday, November 27, 2002 8:09 AM To: Multiple recipients of list ORACLE-L

Hadn't even considered BBED, and I have no idea what their take is on it.

Guess I'll have to ask.

Jared

On Tuesday 26 November 2002 16:09, K Gopalakrishnan wrote:
> Jared:
>
> Any one with a reasonable knowledge of Oracle Data Storage
> Internals can use the Data block Editor (BBED) to update
> anything in your database without the knowledge of the
> RDBMS kernel auditing mechanisms.
>
> Agreed,BBED is protected by a password in Windoze ports
> and one need to explicitly make the executable in Unix
> ports. But the point here is the hacker can do anything
> using the BBEd and this can be done even while your
> database is up and running !!
>
> What is their take on this kind of attack(!)s?>
>
>
> Best Regards,
> K Gopalakrishnan
>
>
>
>
> -----Original Message-----
> Jared.Still_at_radisys.com
> Sent: Tuesday, November 26, 2002 3:05 PM
> To: Multiple recipients of list ORACLE-L
>
>
> Dear list,
>
> Let me toss a hypothetical situation at you.
>
> Say some auditors looked at some of your primary systems,
> and concluded that they had no assurance that someone with
> admin access to the server had not changed financial information
> to benefit themselves, or to falsify financial records for the
> gain of the company.
>
> Not that they might have any proof that something like that
> had been done, but rather, just not proof that it had *not*
> been done.
>
> I've been pondering this for a bit, and it seems to me that if
> someone had good knowledge of both the OS and the
> database (Oracle), as well as having admin rights on the
> server, there are few things you can do to prevent such a person
> from changing data in the database, and completely
> covering his or her tracks.
>
> The platforms in question are Unix, Windows NT and
> Windows 2000. I've limited it to those as most database
> systems use one of those, and besides, that's all I know. :)
>
> Consider what steps you might take to audit unauthorized
> transactions performed by an admin.
>
> Oracle Auditing could be used, but someone with admin
> access to the server and database could easily alter the
> records created by system auditing.
>
> You could create an audit table, using a trigger to audit
> sensitive tables. A materialized view on a remote database
> could be created on sensitive tables to remotely log all
> actions.
>
> In the case of the audit table, that could easily be disabled,
> and then re-enabled after the nefarious DML had completed.
>
> The materialized views might be more difficult to circumvent.
>
> If the remote end is using a dblink to the server employing a
> password that is *different* than that of it's own account at the
> remote server, it should be impossible for someone to completely
> cover the traces of transactions created to falsify data.
>
> The MV Logs could be dropped, but without access to the MV's
> at the remote server, the MV's would have to be left in place.
>
> These could be used as a reference to look for unauthorized transactions
> in the primary server. If this same admin has access to the remote
> server where the MV's are, then this can also be circumvented.
>
> There is also the logs created as when logging in as internal
> or sysdba. ( $ORACLE_HOME/rdms/audit/*.aud )
>
> These can simply be deleted. Some system could be used to save
> these to a remote server, but it would have to run *very* frequently to
> be effective.
>
> Oracle password files could also be used. While this can prevent
> someone from logging in as SYS or SYSTEM while in place, all it
> takes is a change to init.ora, and a database bounce to fix that.
>
> Make your bogus data changes, change the init.ora back and
> bounce the database again.
>
> A somewhat clever person could set this up to automatically
> take place the next time the DB is bounced.
>
> The conclusion I have come to is that the only effective method
> that could be used to create an audit trail for such a scenario is
> to create Materialized Views on sensitive tables, and create them
> on a server that admins are guaranteed to not have access to.
>
> Of course, I may be missing something. I'm not always one to
> catch all the details right off. Input, comments, suggestions, far
> out ideas are all welcome.
>
> If you've read this far, thanks!
>
> Jared

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Jared Still
  INET: jkstill_at_cybcon.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: DENNIS WILLIAMS
  INET: DWILLIAMS_at_LIFETOUCH.COM

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Farnsworth, Dave
  INET: DFarnsworth_at_Ashleyfurniture.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).