Re: CVE-2012-1675 (Oracle 11gR2 RAC) - Actual Risk?
Date: Tue, 26 Jun 2012 19:28:39 +0100
Message-ID: <4FE9FF57.9030209_at_petefinnigan.com>
I would add to David's comments; also stop people you employ connecting to the database or from having direct access to try and connect to the database; the bigger threat is internal for a number of reasons. You give lots of employees access to your systems including for some to databases; In lots of companies i work in there is "open routing" available to the databases therefore even without a username/password remote non authenticated exploits doesnt mean remote as in a kid in his bedroom but simply connecting to the database which could be inside your org. The other problem with insiders is that often they also have more knowledge than outsiders because you pay them to know your systems and data and they know where to steal it.
removal of accounts, hardening of passwords, reduction of privilege and above all preventing actual direct connections to the database and potential connections will go a long way to make it harder to exploit your databases. A skilled attacker will never be thwarted by all the layers given enough time but patching/hardening and securing data access . Of course as David says all comments are general as I have not seen the environment and dont know what you have done already.
Risk reduction is about money; when there are lots of databases that could be lots of money so its best to target your money wisely to reduce the risk as much as possible for whats spent. Strategic solutions (maybe a firewall in front of the DB not in front of the company) often can be cheaper than technical targetted solutions on hundreds or thousands of databases.
cheers
Pete
david_at_databasesecurity.com wrote:
> Hey all,
>
>> The risk for an external threat is pretty much minimized through a set of >> security layers such as the Firewall, anti-virus, etc.
>
> Without seeing a specific environment I'd tend to disagree; better to be
> more cautious than not. If the database in question is connected to a web or
> application server then there's the potential for SQL injection; there's
> potential for exploitation of flaws in the app environment itself (struts,
> anyone? OAS?); and host of other issues that can relegate the firewall to an
> expensive box with pretty flashing lights. In this day and age, anyone that
> thinks a firewall offers sufficient protection should open a newspaper and
> read about all the database security breaches taking place. Do you really
> think those orgs weren't using firewalls? As far as WAFs are concerned -
> they can be bypassed by a moderate to skilled attacker. I know it's a pain
> but the best strategy really is keeping your patches up to date and reducing
> your attack surface.
> Cheers,
> David
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
-- Pete Finnigan CEO and Founder PeteFinnigan.com Limited Specialists in database security. Makers of PFCLScan the database security auditing tool. Makers of PFCLObfuscate the tool to protect IPR in your PL/SQL If you need help to audit or secure an Oracle database, please ask for details of our training courses and consulting services Phone: +44 (0)1904 791188 Fax : +44 (0)1904 791188 Mob : +44 (0)7759 277220 email: pete_at_petefinnigan.com site : http://www.petefinnigan.com Registered Office: 9 Beech Grove, Acomb, York, YO26 5LD, United Kingdom Company No : 4664901 VAT No. : 940668114 Please note that this email communication is intended only for the addressee and may contain confidential or privileged information. The contents of this email may be circulated internally within your organisation only and may not be communicated to third parties without the prior written permission of PeteFinnigan.com Limited. This email is not intended nor should it be taken to create any legal relations, contractual or otherwise. -- http://www.freelists.org/webpage/oracle-lReceived on Tue Jun 26 2012 - 13:28:39 CDT