RE: Privileges by session

  • From: "Andre van Winssen" <dreveewee@xxxxxxxxx>
  • To: "'Robert Freeman'" <robertgfreeman@xxxxxxxxx>, <jkstill@xxxxxxxxx>
  • Date: Fri, 8 Jan 2010 20:21:07 +0100

All you need is access to user$ and the algorithm to brute force and compare
calculated hashes with the stored hashes. No need to try to login as the
user and get it locked out ! There are lots of implementations for Oracle
=<10g and 11g password algorithm already out there. Pete Finnigan even wrote
one in plsql. 

Just get a smart list of candidate passwords (start with password=username)
and try them out using the hash and compare method.

 

I would check ALL database accounts. Also the ones with seemingly low
privilege. Because they can be turned into baron-von-Munchausens, elevate
themselves to higher levels due to the many security vulnerabilities that
exist in unpatched oracle databases.

 

Get cooperation from the security / risk / internal auditing departments and
business representatives and then these checks can all be done in a
controlled manner, i.e. without having to disrupt production system
availability. Unfortunately I haven't had the privilege of that cooperation.

 

Andre

 

 

 

Van: Robert Freeman [mailto:robertgfreeman@xxxxxxxxx] 
Verzonden: vrijdag 8 januari 2010 18:52
Aan: jkstill@xxxxxxxxx; Andre van Winssen
CC: wblanchard@xxxxxxxxxxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Onderwerp: Re: Privileges by session

 

>> have you seen auditors actually use tooling to perform password sanity
checks on databases subject to SarbanesOxley, HIPAA, PCI or any >> number of
other legislated security policies ?
One issue you run into is if you have automated account locking... the
sanity checking can cause accounts to get locked out. If you have systems
where account locking is not enabled, then I would have no objection to such
testing. Sanity testing of the SYS account password on various systems makes
perfect sense to me.

 
I have no objections to auditing performing penetration testing as long as
it's coordinated with our group and designed to not impact systems. If
security is really the goal (and so many places it still just gets lip
service it seems like) then I'm of the opinion that all the testing you can
do is worthwhile as long as it's under control and well documented and
compliant with current security policies. 

RF

Robert G. Freeman
Oracle ACE
Ask me about on-site Oracle Training! RMAN, DBA, Tuning, you name it!
Author:
Oracle Database 11g RMAN Backup and Recovery (Oracle Press) - ON ITS WAY
SOON!
OCP: Oracle Database 11g Administrator Certified Professional Study Guide
(Sybex)
Oracle Database 11g New Features (Oracle Press)
Oracle Database 10g New Features (Oracle Press)
Other various titles
Blog:  <http://robertgfreeman.blogspot.com>
http://robertgfreeman.blogspot.com
Check out my new blog series on installing Oracle Database 11gR2 on Windows
using VMWare!

 

 

  _____  

From: Jared Still <jkstill@xxxxxxxxx>
To: Andre van Winssen <dreveewee@xxxxxxxxx>
Cc: wblanchard@xxxxxxxxxxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Sent: Fri, January 8, 2010 9:16:28 AM
Subject: Re: Privileges by session

On Fri, Jan 8, 2010 at 3:23 AM, Andre van Winssen <
<mailto:dreveewee@xxxxxxxxx> dreveewee@xxxxxxxxx> wrote:

 

have you seen auditors actually use tooling to perform password sanity
checks on databases subject to SarbanesOxley, HIPAA, PCI or any number of
other legislated security policies ?

 


No, I haven't.  I have seen penetration tests do that, but never SOX
auditors.

 

I have seen big shops where fancy database compliancy reports, created by
the dbas, were just about enough to let the auditors say "Ok, compliant!"
Motto: business comes first, security second.


Reports here are created by the DBA's.  Same for Sysops, and application
Admins.

Really though, it would be quite difficult for the auditors to accomplish
this.

At least in my limited SOX experience, it isn't quite as simple as "Here's
my 
report, sign it off please".

I generate reports for databases that must comply with Sarbanes Oxley.
These reports are reviewed with the Security admin for the app.
(how timely, did this just yesterday)

In this particular case, the reports are shown to verify SOD (separation of
duties)
so that no one has DBA privileges unless they are warranted.

The auditors must rely on DBA's to provide the information.  There are many
ways
that a user can have DBA privileges - roles, legitimate roles that have been
granted
extra privilges, roles that appear to be system roles but are created to
provide
extraordinary privileges, direct grants, execution on packages, ...

You can't really expect an auditor to be able to do all that.
Sorry, this goes a bit off topic, as it is more than just checking for
password complexity.


Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist
Oracle Blog:  <http://jkstill.blogspot.com> http://jkstill.blogspot.com
Home Page:  <http://jaredstill.com> http://jaredstill.com

Other related posts:

  1. Home
  2. oracle-l
  3. Archive
  4. 01-2010