| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Oracle OS level security
Arup:
BBED is
B lock
B rowser &
ED itor.
Best Regards,
K Gopalakrishnan
-----Original Message-----
Sent: Tuesday, November 26, 2002 6:24 PM
To: Multiple recipients of list ORACLE-L
What is BBED? I never heard of it.
>From: "K Gopalakrishnan" <kaygopal_at_yahoo.com>
>Reply-To: ORACLE-L_at_fatcity.com
>To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
>Subject: RE: Oracle OS level security
>Date: Tue, 26 Nov 2002 16:09:27 -0800
>MIME-Version: 1.0
>Received: from newsfeed.cts.com ([209.68.248.164]) by
>mc8-f17.law1.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 26 Nov
>2002 17:06:39 -0800
>Received: from fatcity.UUCP (uucp_at_localhost)by newsfeed.cts.com
>(8.9.3/8.9.3) with UUCP id RAA43612;Tue, 26 Nov 2002 17:01:24 -0800 (PST)
>Received: by fatcity.com (26-Feb-2001/v1.0g-b72/bab) via UUCP id 0050CFBE;
>Tue, 26 Nov 2002 16:09:27 -0800
>Message-ID: <F001.0050CFBE.20021126160927_at_fatcity.com>
>X-Comment: Oracle RDBMS Community Forum
>X-Sender: "K Gopalakrishnan" <kaygopal_at_yahoo.com>
>Sender: root_at_fatcity.com
>Errors-To: ML-ERRORS_at_fatcity.com
>Organization: Fat City Network Services, San Diego, California
>X-ListServer: v1.0g, build 72; ListGuru (c) 1996-2001 Bruce A. Bergman
>Precedence: bulk
>Return-Path: root_at_fatcity.cts.com
>X-OriginalArrivalTime: 27 Nov 2002 01:06:39.0079 (UTC)
>FILETIME=[3D590770:01C295B1]
>
>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:
> INET: Jared.Still_at_radisys.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: K Gopalakrishnan
> INET: kaygopal_at_yahoo.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: Arup Nanda INET: arupnanda_at_hotmail.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: K Gopalakrishnan INET: kaygopal_at_yahoo.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).Received on Tue Nov 26 2002 - 21:28:42 CST
 |
 |