Re: Oracle OS level security

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).