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" <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> >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@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: <[EMAIL PROTECTED]> >X-Comment: Oracle RDBMS Community Forum >X-Sender: "K Gopalakrishnan" <[EMAIL PROTECTED]> >Sender: [EMAIL PROTECTED] >Errors-To: [EMAIL PROTECTED] >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: [EMAIL PROTECTED] >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----- >[EMAIL PROTECTED] >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: [EMAIL PROTECTED] > >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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] > >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: [EMAIL PROTECTED] (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). _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Arup Nanda INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
