Pete Finnigan's Oracle Security Weblog

Andrea Purificato (Bunker) emailed me yesterday to let me know that he has posted two exploit scripts for the CTXSYS.DRVTABC.CREATE_TABLES bug for 9i and 10g. He has posted two versions of the exploit. The first is the traditional one and the second uses cursor injection. Andreas main page also includes links to his usual perl versions of exploits as well.

I saw a post yesterday on my Oracle security forum by DSU titled "Oracle Security Tools (GUI)" that talks about a new Russian Oracle security tool written to test Oracle vulnerabilities. The tool is limited at the moment. The site that hosts the code is http://securetools.ru/en/index.php and the code can be downloaded from http://securetools.ru/tools/OraSecureTools.7z; beware that my virus scanner says the site could be malicious although I am unsure that this is actually true.

[update: cyber$snake has posted a comment below confirming that his download not malicious and there is a virus check link posted as well - the issue of genuine security tools being picked up by commercial virus scanners can be a problem that i have seen before; this is often because genuine tools get listed on sites that are the source for virus definitions]

DSU has written a quick summary of the new tool on his blog and also the site hosting it contains a lot of screen dumps of the tool in action. As DSU says its limited at the moment but development is in hand.

DSU has also got a nice blog about Oracle security written in Russian. Translating is easy with google to English although as always code and pictures are readable anyway in English. I have added DSU's blog to my oracle blogs aggregator so you can always get a link to new posts. For inastance today he has just posted an exploit for DBMS_SQLHASH.GETHASH written in Perl for instance.

I have not posted for a few days as I have been in Helsinki, Finland teaching my class "How to perform a security audit of an Oracle database" and I had not carried my email client and web access in general was not good from either the hotel or the training site. This was a pity as I have a growing list of things to blog about and I could have spent some evening time writing about them.

Finland was great (as usual!), this was my third commercial trip to Finland this year so its been a successful country for me. Next week is the UKOUG conference in Birmingham, UK. I always enjoy the UKOUG yearly conference as its always very well run, lots of great speakers and I always meet a lot of old friends, new people and have some really good chats. I am speaking on Monday 30th at this years UKOUG conference and I am also hosting an Oracle security round table session on December 1st. There are links to both my sessions on my main Oracle Security sites main page.

I received my copy of David Knox's (plus co-authors) new book "Applied Oracle Security" last Saturday, the day before I set off for Finland so i didnt get time to blog about it before I went or time to read it of course. I have had time to flick through it and it looks like an excellent book. Davids earlier 2004 book "Effective Oracle database 10g security by design" was already an excellent book. This new book has been created as a follow on to the first one. Whilst the book has a slightly different focus to what i would write it (the focus is on using product features well) it is well structured and has excellent content. The book is product focused which is fine but my only critisism (some of this is againt the 2004 book and is not against the writing quality in either book) is that not everyone runs EE so not everyone gets features like VPD, not everyone can afford Advanced Security,m Database Vault, Audit Vault or the identity products; for instance.

I have had the discussion about Oracle security features and products a number of times. I often talk to clients and others at conferences for instance and i find that a very small percentage of users of Oracle database software actually use or implement the extra features such as VPD, OLS, TDE, AS, ID, DV or AV to name a few. This is a great shame and the reason is always the same; money and time. Davids books give an excellent overview of how to secure data in the Oracle database using features available from Oracle; this is the way to secure data in an Oracle database; to use the tools available from Oracle. I just wish the tools were part of all versions of the database; well not just "i wish", lots of others say the same to me. Maybe one day some of the cool security features will be part of standard edition as well?

Gary pointed us to an article written on database journal by james in a forum post titled "OS Authentication". The article is titled "Securing Client Connections: OS Authentication" and it discusses the virtues of externally (OS) authenticated accounts.

There are some issues with this article and Gary has picked up on some already with his comment there at the end of the article but i wanted to mention something else.

The article checks the parameter OS_AUTHENT_PREFIX which in the example is set to a NULL string - not the default value. The article then suggests setting back to a value of OPS$, its default. Oracle recommends in its hardening guide (and indeed there are many other sources saying the same) that setting it to the NULL string is best. This is to prevent dual authentication of externally authenticated accounts.

James does make a good point though; check that no externally authenticated accounts exist before you change this value as it would stop them logging in.

The other point in the article about root access is that the acticle suggests that if you have root access you could randomly guess OS account names and create them in the hope of connecting as an externally authenticated account; why? just su to the software oracle owner and connect "as sysdba" and then do what you want.

I do agree with James that when done correctly externally authenticated accounts (local only not remote) are a good way to manage external jobs that must remain outside the database. This is OK, if OS access is limited, the OS and DB accounts have the least privileges necessary, the account is designed and used for one purpose only and its ever move is audited. Security in layers is good.

I saw today Pauls recent post to his blog "DAMS for Post and PRE-CPU Change Management" and when I read:

A quicker and simpler way to remove the threat of a vulnerable package is to simply REVOKE the PUBLIC EXECUTE on that package

I was concerned as simply revoking a PUBLIC execute privilege is not enough but luckily Paul went on to correct this by talking about applications breaking and dependencies; Paul rightly points out that SYS does not use PUBLIC EXECUTE itself when calling its own packages.

Revoking PUBLIC EXECUTE is difficult and will rarely close out an issue usually for two reasons; 1) revoking the PUBLIC EXECUTE will not stop someone executing the said vulnerable package IF it is used through another package and the issue is worse if the dependant package is executable by PUBLIC. 2) It also may be used without PUBLIC EXECUTE, i.e. another schema may use the feature/package via its own privileges (perhaps also via other packages).

Imagine if PACKAGE B and PACKAGE C use PACKAGE A (perhaps the vulnerable one) the simply revoking PUBLIC EXECUTE from PACKAGE A will not fix the issue unless you also revoke PUBLIC EXECUTE from PACKAGE B and C as well. What if PACKAGE A has EXECUTE granted to SCOTT, then SCOTT is also a target to exploit the vulnerability in PACKAGE A, less of a target than PUBLIC BUT still a target. If SCOTT didnt have privileges on PACKAGE A but has them instead on PACKAGE B or C then because all three packages in this simple example are all owned by one user then PACKAGE A is still accessible - there is a serious proviso that we must know to what extent PACKAGE B and C use PACKAGE A and if the vulnerable code is still exploitable.

The whole area of revoking PUBLIC privileges is fraught with problems; perhaps this is why Oracle dont simply revoke all of them!, static analysis of code is possible but only useful if all the code is static; if internal code in the database is dynamic and uses the vulnerable code then revoking privileges may cause unstable functionallity in the future.

Paul's suggestion to use Sentrigo Hedgehog to monitor the package SYS.DMP_SYS in his example is a good idea but monitoring needs to be ongoing and perhaps the a better solution than revocation is ongoing IDS/IPS techniques; of course a better solution is to apply the CPU.

If we take Paul's example of SYS.DMP_SYS we can investigate the relationships and privileges at a high level. Start with privileges assigned to SYS.DMP_SYS on 11.1.0.7 as an example:

SQL> @who_can_access who_can_access: Release 1.0.3.0.0 - Production on Tue Nov 17 18:06:56 2009 Copyright (c) 2004 PeteFinnigan.com Limited. All rights reserved. NAME OF OBJECT TO CHECK [USER_OBJECTS]: DMP_SYS OWNER OF THE OBJECT TO CHECK [USER]: SYS OUTPUT METHOD Screen/File [S]: S FILE NAME FOR OUTPUT [priv.lst]: OUTPUT DIRECTORY [DIRECTORY or file (/tmp)]: EXCLUDE CERTAIN USERS [N]: USER TO SKIP [TEST%]: Checking object => SYS.DMP_SYS ==================================================================== PL/SQL procedure successfully completed. For updates please visit /tools.htm SQL>

Rather interestingly there is no default PUBLIC EXECUTE privilege on this package on 11.1.0.7:

SQL> select * from v$version; BANNER ------------------------------------------------------------------- Personal Oracle Database 11g Release 11.1.0.7.0 - Production PL/SQL Release 11.1.0.7.0 - Production CORE 11.1.0.7.0 Production TNS for 32-bit Windows: Version 11.1.0.7.0 - Production NLSRTL Version 11.1.0.7.0 - Production 5 rows selected. SQL>

Lets check for dependencies anyway on SYS.DMP_SYS to see if its functionallity has been exposed through any other packages:

SQL> @dep Enter value for object_to_test: DMP_SYS Enter value for owner_to_test: SYS NAME OWNER TYPE ------------------------------ ------------------------------ -------------- DMP_SEC SYS PACKAGE BODY DMP_SYS PUBLIC SYNONYM DMP_SYS SYS PACKAGE BODY DBMS_DM_MODEL_IMP SYS PACKAGE BODY DBMS_DATA_MINING SYS PACKAGE BODY DBMS_DATA_MINING_INTERNAL SYS PACKAGE BODY DBMS_PREDICTIVE_ANALYTICS SYS PACKAGE BODY DBMS_JDM_INTERNAL SYS PACKAGE BODY 8 rows selected. SQL>

There are some packages that use (that is depend on) SYS.DMP_SYS that are granted to PUBLIC (in a real investigaation you would check all grants though not just PUBLIC). We can run a different script to isolate the PUBLIC grants on dependant packages of SYS.DMP_SYS. Remember that we ought to actually look at what is vulnerable in SYS.DMP_SYS and then check if that functionallity is exposed in the dependant packages although one approach may be to assume that any dependancy is dangerous independantly of the actual exposure. Lets look at the PUBLIC dependencies (in this case only on EXECUTE):

SQL> @dep_priv Enter value for object_to_test: DMP_SYS Enter value for owner_to_test: SYS NAME OWNER TYPE ------------------------------ ------------------------------ ---------------- DBMS_DM_MODEL_IMP SYS PACKAGE BODY DBMS_DATA_MINING SYS PACKAGE BODY DBMS_PREDICTIVE_ANALYTICS SYS PACKAGE BODY DBMS_JDM_INTERNAL SYS PACKAGE BODY 4 rows selected. SQL>

OK, four packages. Lets check the exposure on one sample:

SQL> @get_tab2 get_tab2: Release 1.0.0.0.0 - Production on Tue Nov 17 19:09:02 2009 Copyright (c) 2004,2009, PeteFinnigan.com Limited. All rights reserved. OBJECT TO CHECK [XXX_XXXX]: DBMS_DATA_MINING SCHEMA/OWNER OF THE OBJECT TO CHECK [USER]: SYS OUTPUT METHOD Screen/File [S]: S FILE NAME FOR OUTPUT [priv.lst]: OUTPUT DIRECTORY [DIRECTORY or file (/tmp)]: Testing root object => [SYS.DBMS_DATA_MINING] GRANTOR GRANTEE S I U D A F D I R Q C E ------------- -------------- - - - - - - - - - - - - SYS PUBLIC X PL/SQL procedure successfully completed. For updates please visit /tools.htm SQL>

As predicted its just EXECUTE privilege to PUBLIC but it could have been granted to other schemas. As i said you would need to check out all dependencies, check code (unwrapper needed) and all direct grants to schemas if they exist.

Nice post though Paul, good food for thought!

We often get enquiries for our Oracle security training classes and security consulting including Oracle database security audits from clients in the USA. We have come to the point in time where we need to have full time representation on the ground in the United States.

Therefore we are happy to announce that PeteFinnigan.com Limited has, after careful selection, agreed partnerships with two security consulting companies in the United States who will offer PeteFinnigan.com Limited training classes, security audits and consulting services in the United States.

To enable this PeteFinnigan.com Limited has now agreed a partnership with One Security Solutions Applied, LLC who are based in Washington DC and PeteFinnigan.com Limited has also agreed a partnership with Reidy Database Consulting LLC based in Denver.

PeteFinnigan.com Limited training and consulting services are only offered in the USA through our approved partners and will only delivered by approved and authorised trainers and consultants.

If you are interested to book an Oracle security training class in the USA then please either contact PeteFinnigan.com Limited on info@petefinnigan.com or http://www.1ssa.net/contact_us.html - (broken link) 1SSA LLC via their contact page or Reidy Database Consulting LLC also via their contact page.

PeteFinnigan.com Limited will also offer 1SSA web application security and security strategy programs in the UK and European market.

We will be adding details of partners, contact details, service offerings and more over the coming days to our websites.

We at PeteFinnigan.com Limited are very excited to be fully entering the US market with excellent partners.

After the very successful Oracle security training event we held in York in July we are now going to run a new event, again in York on February 9th and 10th 2010. The two day training will be held at a hotel in York, England. The two day seminar includes the actual instruction and each student will get a delegate pack of a CD of scripts and tools, a signed certificate and also two professionally printed manuals to accompany the course. The course also includes coffee breaks and hot 3 course lunch.

The details of the course structure are show on the "How to perform a security audit of an Oracle database" page and the detailed course agenda is here.

The course will be £895 + VAT per student and to help delegates secure their own accomodation we have arranged with the venue a special delegate rate of £70 per person/per night for bed and breakfast.

A detailed page including directions, venue and the agenda will go live early next week. If you would like to register your place in the meantime then please do so by emailing info@petefinnigan.com.

I saw a nice post on Alex Nuijten's blog yesterday titled "Create Users with DBMS_METADATA" via my Oracle blogs aggregator that talks about Alex's use of DBMS_METADATA to copy database users from one database to another by generating the DDL for user creations including all of the granted roles, system privileges and object privileges. This is an easy way to copy users and obviously beats the old ways of trying to derive this knowledge from the data dictionary yourself.

The reason I want to highlight this is really to emphasise the fact that there is more than one way to achive something in Oracle; This is important; its not just about creating users but about deducing the privileges and status of users in this case without directly selecting that detail from the dictionary. The simplistic view of security is to protect data (in this case meta-data) at source, a simplistic view would be to review the direct select privileges on SYS.USER$ or DBA_USERS and all the associated views and base tables such as DBA_SYS_PRIVS or DBA_ROLE_PRIVS or DBA_TAB_PRIVS but there are other ways to read data in this case by using DBMS_METADATA to get the same information. This post by Alex is useful is showing that there is more than one route to user details.

I posted in a post titled "A new Oracle Security book.... or three!" a couple of weeks ago (or so) that Alexandr Polyakov had written and published a book on Oracle security in Russian. The book is only available in Russian and in Russia!. So i went ahead and ordered it; I received an email about a week ago (in Russian) that my wife translated for me; it said the book had been despatched and it would take between 1 and 5 weeks to arrive. Well it arrived in a neat cardboard wrapping in good shape yesterday. I cannot read it of course as its in Russian; that said there is still quite a lot that can be understood, all of the commands, SQL, PL/SQL, tools output is almost all in English so I can still understand that. I am going to get my wife to read out some of it to me but that will take some time.

Anyway, I wanted to let everyone know its arrived, its the first book on Oracle security written in Russian and published in Russia. It looks good; my wife said it looks good!. Its good that a book is available in Russian because a lot of work on Oracle security has come out of Russia and Russian speaking people; well done!

One of the interesting discussions with the delegates that took place in my Oracle security class in Prague last week was a discussion around the difference between privileges granted via roles and those granted directly and the effects of privileges in PL/SQL code that is written as definer rights or written as invoker rights.

In the class I made an example where I was specifically comparing the difference between the statement GRANT ALL PRIVILEGES and also GRANT DBA for a specific user; i.e. whats the difference (only in terms of system privileges) if a single user is granted the DBA role and then if he instead had ALL PRIVILEGES granted. The DBA role amongst other things has almost all of the system privileges granted to it so a good comparision can be made between GRANT ALL PRIVILEGES to a single user and GRANT DBA to another. In essense they are similar in terms of power BUT not exactly the same. I wrote an article about the differences in the privileges for the new Oracle scene magazine for the UKOUG which has just been published as the first in my new regular Oracle security column for the http://www.ukoug.org/publications/index.jsp?parent=0&id=1 - (broken link) Oracle Scene magazine - you need to be a membeer to read it or attend a conference to receive a paper printed version.

The issue of power is not simple. The main difference is what happens when the user runs definer rights code or invoker rights code. In definer rights PL/SQL code roles; and therefore the privileges assigned to them are not recognised - of course the code is also run as the owner not the invoker. In invoker rights code the owner of the codes privileges are ignored completely and the code runs with the rights of the invoker and roles are not ignored. Rather than set up some examples of this I am going to defer to a nice article written recently by Martin Widlake on his blog titled "Accessing Roles in stored PL/SQL".

So my comment was that the grant of direct privileges (via GRANT ALL PRIVILEGES - in this example) is more dangerous than the GRANT DBA - again in this example but this needed to be qualified at the time. A direct privilege; in this case all of them; well almost all of them; see the Oracle scene article for why is always "ON" whilst system privileges granted via the role can sometimes be off. Well the qualification is that this of course applies if the user is primarily accessing functionallity via PL/SQL and this depends on whether its definer rights or invoker rights - if a user is designed as an admin type user and is not primarily accessing code then its a different issue. Thats one issue, the second is that if the code is definer rights then its safer if the owner has been granted a role because its "OFF" during the definer rights code and definer rights code has the problem that if its exploited then the exploiter gets access to the owners privileges if the exploit allows this but not the owners privileges via his roles.

So there are lots of factors involved. The discussion was comparing ALL PRIVILEGES with DBA and importantly for a schema account - now the downside is that simply saying use a ROLE because its turned OFF during definer rights code is irrelevant if the code was invoker rights (in a good way as the privileges of the invoker count not the owner) - in other words the type of code matters. roles for schema owners are going to be safer BUT the issue is really about least privileges. Whether its definer rights code or invoker rights code, reduce the privileges of the owner (definer) or user (invoker) to the bare minimum necessary to do the business function exposed by the code.

Good privilege design and code design are very closely linked - unfortunately in real life we don't see too many good designs! but beware of how privileges are exposed.

I have not been able to blog for the last couple of days as I have been in Prague teaching my companies two day class "How to perform a security audit of an Oracle database" which went really well; there was some great people at the class and also some great discussions during the training and also spilling into the lunches and coffee breaks. I noted down two specific things that were really interesting discussions and will talk about them here in the next couple of days. One is around permissions and the other around the state of Oracle security across the industry.

I have also been writing a paper on the plane out and back to Prague about external access but instead of putting it out as a paper I may make it a multi-part blog instead next week.

Finally I saw today that james Koopmann has put out a new Oracle security related article titled "Explicit GRANTs and ROLES in Oracle Database 11g" which is nice as it highlights some basic issues that should be recognised.

I blogged last week about Dennis Yurichev's FPGA password cracker here in a blog titled "Update to Dennis Yurichevs FPGA cracker plus exploit code for the CPU CVSS 10.0 bug" and i set off two example cracker sessions for users with passwords; one starting with AA and the other starting with ZZ:

AA 3FC24C0BFAED94B1 test 1 -  SOLVED ZZHG76J time spent: 21m31s; average speed: 69M 
AB 111E83722DB9BF88 test 2 -  SOLVED AAGHB6G time spent: 40s; average speed: 81M 

The results above are from Dennis's site. This proves my theory that if you choose a password starting with AA its cracked much faster with Dennis's cracker than one starting with ZZ. This is replicated with software based crackers cycle through possible passwords by walking the character set in the same order as the alphabet.

This is really important to remember when you create password verification and password management rules. One thing you should be doing is designing password complexity and length and also calculating password lifetimes so that if a prolonged attack is made against your passwords with a password cracker they will survive their own lifetime. This means you must consider the "flaws" (perhaps the wrong word but it will suffice for this discussion) in the passwords crackers out there. If you design a password length assuming that a password would fall in perhaps 50% of the time necessary to try all possible passwords with decent average hardware and a software based cracker then you must ensure that passwords cannot start with easier (quicker) to cracker letters or you must increase the length of the passwords. There is a downside to forcing a reduced character set for a password to counteract a password attack with password crackers - it in itself makes the password weaker and someone could modify an existing cracker source code to exploit this against your passwords - so be careful and ensure your rules are not leaked and ensure that you cover all bases.