Pete Finnigan's Oracle Security Weblog
This is the weblog for Pete Finnigan. Pete works in the area of Oracle security and he specialises in auditing Oracle databases for security issues. This weblog is aimed squarely at those interested in the security of their Oracle databases.
[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.
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?
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.
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 126.96.36.199 as an example:
Rather interestingly there is no default PUBLIC EXECUTE privilege on this package on 188.8.131.52:
Lets check for dependencies anyway on SYS.DMP_SYS to see if its functionallity has been exposed through any other packages:
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):
OK, four packages. Lets check the exposure on one sample:
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!
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 firstname.lastname@example.org or 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.
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 email@example.com.
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.
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!
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 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 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.
AA 3FC24C0BFAED94B1 test 1 - http://www.petefinnigan.com SOLVED ZZHG76J time spent: 21m31s; average speed: 69M
AB 111E83722DB9BF88 test 2 - http://www.petefinnigan.com 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.