Pete Finnigan's Oracle Security Weblog

It's been a while since my last post!, too much work, travel and not enough time for catching up I guess.

I subscribe to the pentest list over at Security Focus and saw a post on their over the weekend when clearing my email boxes about SQL Injection tools. The question was posed in a post titled "SQL Injection Tools". This promoted a number of responses offering views and some links to tools but the original post was very useful as it linked to a list of http://www.security-hacks.com/2007/05/18/top-15-free-sql-injection-scanners - (broken link) The top 15 free SQL Injection Scanners. This is a good list and very useful for anyone interested in protecting applications and database and particularly in our cases applications that are coded against Oracle databases.

I would not suggest running these tools as DBA's against production databases but they offer great value in terms of learning about the issues and how to detect them. Certainly run them against test or development systems that you own ideally isolated from the rest of your organisations data and business, in other words tools like these can in some cases cause issues for working, Dos, changes to data and so on. So be careful with them, run them only on a database/application you fully own and control but learn from them and apply the knowledge learned to help secure databases.

Nice list!

I have been asked to promote the survey on the IOUG site by the IOUG and Oracle to ask customers for feedback on the security and vulnerability remediation procedures implemented by Oracle customers.

I would ask as many people as possible to spend some time to fill this survey in as it will help define feedback to the next Oracle Security Customer Advisory Council (SCAC). This survey should allow everyone to have their say to Oracle on subjects such as the CPU process, advisories and deployments. I have been made aware that quite a lot of people who care about patching and CPU's have taken part all ready. To be able to get a balanced view its important that as many other people as possible also take part and pass their views to Oracle / IOUG.

Let me simply quote from the survey site:

"This survey is conducted by IOUG and Oracle for the purpose of understanding security and vulnerability remediation procedures implemented by Oracle customers. The results of this survey will help identify relevant topics for joint security training activities, and also help IOUG¿s Security Special Interest Group formulate its feedback during Oracle¿s next Security Customer Advisory Council (SCAC). Customer feedback is extremely important and has previously resulted in Oracle¿s adoption of the Common Vulnerability Scoring System (CVSS) and other enhancements in the Critical Patch Update (CPU) documentation and release process."

To take the survey go to http://survey.ioug.org/ and register. This is simply deciding on a username and a password, no more. Then choose to take the "OSSA Security Survey II" survey. There is also a second one that has 20 pages and is much longer. The one I have been told to take is the 12 page one.

The survey is quite simple and includes 12 steps to complete, gathering details on all stages of CPU analysis, test, deployment, decisions, why you might apply a CPU (this is a good one), opinion on the CVSS, the CPU process and much much more.

It is everyones duty to feedback to Oracle on this as (OK, thats strong, but I listen to a lot of people on this one subject). Have your say, Oracle are not going to bite, they want this process to be one that helps and encourages customers to apply patches just as much as we do.

I feel strongly about this survey, if you can pass it on to others to complete, colleagues, forums, blogs etc, please do. Let's get an opinion of what needs to be better and lets get more people to apply CPU's.

I was down in London yesterday in some meetings and also speaking at the http://www.ukoug.com/calendar/show_event.jsp?id=3385 - (broken link) UKOUG Management And Infrastructure SIG on the subject of Oracle Security tools. I will post up the slides later.

The discussion got around to the issue i call "the access issue" - this is basically that any direct connection to the database requires the IP address, port number, service name or SID and a valid username and password. Often the IP address could be found easily using scanning tools such as nmap. My experience of most sites is that a username / password can be guessed easily. That leaves the SID/Service name. If a database has used a default such as ORCL - yes I do see that used in production databases - really - or simple things like PROD10g or DEV10g then they are guessable and tools exist to find these. This discussion has relevance because at most sites there is no internal protection of the database. That is you can connect a laptop/PDA or whatever or use an existing desktop (most sites ship standard builds often including an Oracle client to most desktops) and attempt to connect to the database. This for me is the biggest issue I see. Think for a minute...

If you can stop people attempting a connection to the database, i.e. only the appserver and a small number of staff can connect (DBA) and there is firewalling, packet filtering etc then this makes the database much better in terms of security. All the normal config issues do not go away it just means that its become harder for anyone to attempt to take advantage of a bad configuration or weak password or similar.

This is all about recognising that the threat is likely to be internal and not external and that traditional perimmeter security doesn't work for protecting access to the data held in corporate or government databases. The security for the data must be with the data. Layered security simply must prevent direct access to the data. This doesn't mean that the configuration issues have gone away it just makes them harder to exploit. This is a good plan in securing data.

Anyway during this discussion I was making the point about most desktops having standard builds that may include an Oracle client and also most sites simply potentially allowing access directly to the database if someone were to plug in a laptop or use the desktop. I suggested (tongue in cheek) that a clever hacker may for instance work for the drinks vending company and he may have an Oracle client in the vending machine which happens to be connected to the corporate network. I have looked at these machines in the past whilst idley waiting for a vend and noticed CAT-V cables eminating from the back of them , anyway it was said in fun yesterday but this morning I saw a post on BugTraq titled "Hacking Coffee Makers" - what a coincidence!

I promised to create a short write up on Sentrigo's Hedgehog product some time ago when Tim Hall posted an entry on his blog titled Sentrigo Hedgehog… where he discussed meeting Slavik Markovich who is the CTO of Sentrigo who make the Hedgehog products.

The upshot of Tim's post was that he suggested that someone like me ought to test and comment on the product as its an Oracle Security product and I am working in this area. As I pointed out on Tim's blog post I have a bias in relation to this product as I am on the technical advisory board of Sentrigo and my company PeteFinnigan.com Limited is also a partner of Sentrigo in terms of offering the product to customers here in the UK and some other areas.

It is important for me to state my relationships and position with Sentrigo first, OK disclaimer over.

So that said I want to now discuss the focus of this article. As I said in a comment Tim's blog post the focus for me is "why", i.e. why did I want to work closely with Sentrigo on the Hedgehog product in terms of being on the advisory board and also in terms of offering the product to my companies customers here in the UK and elsewhere.

The answer to this point is actually very simple, at least for me. I first heard about and subsequently saw the product around one and a half years ago when Slavik contacted me and asked if I would like to see it. I was immediatly very interested and was excited by the ideas behind the product. Most of the players in the IDS/IPS (Intrusion Detection System/Intrusion Prevention System - sometimes also refered to as virtual patching) use network sniffer based technologies and this product, HedgeHog, was new and used a completely different approach being host based and not network sniffer based.

For me there has always been an issue with network based solutions that is not easy to get around and solve. Hedgehog solves this issue in one fell swoop. Let me give an example; imagine that you are deploying a network based IDS/IPS and as part of the setup of custom rules/ policies you are required to satisfy and internal/regulatory policy that requires all access to the credit card PAN stored in the database to be audited and recorded but more importantly you must ensure that only those users authorised to read credit card details can do so; or also that no one should be able to alter the credit card table structure. Lot's of things involving credit card tables that appear to be needed more regularly in my experience of working with various customers. OK, so you install a network sniffer based solution and go to the config for policies/rules or whatever its called and you highlight the name of the credit card table and generate the rules to trap access to it, data changes or structural changes. All fine and dandy or so it seems. Now you realise that the tool is sniffing SQL or PL/SQL statements out of network packets. OK, fine you think all access to the table CREDIT_CARD will be seen. Nope, fraid not.... you realise that the application is written partly in PL/SQL and that some of the PL/SQL actually makes the access or changes to the CREDIT_CARD table on the user behalf. This is where network sniffer based solutions fail as they will only see the PL/SQL procedurte or package call.

Sentrigo Hedgehog doesn't have this issue and its one the the reasons I really like it. Hedgehog is "attached" to the data or rather the commands that alter the data or the database. This is like the Oracle technology Virtual Private Database (VPD) is one sense. VPD was one of the technologies introduced by Oracle that I really liked. I really like the idea that the security rules in the case of VPD, policies, are attached to the data they are protecting. This means nothing gets past it, unless you let it of course. Hedgehog works in a similar way. In the example above as Hedgehog is reading the access, SQL, PL/SQL and everything else from the shared memory it's extremely fast (no SQL, no overheads, no effect on the database... and more) this means that it misses nothing. In the example above the PL/SQL call in question is seen by Hedgehog but so is any SQL or further PL/SQL that the original call uses.

I like Hedgehog because of the fact that its fast, slick, exciting and also because mostly for me the security is actually "with the data". This product has great promise.

Let's not be too unfair to the network based boys. They have of course in some cases come up with solutions to this issue. I have heard some examples as follows:

"We make a privileged connection to the database and we check the dependancies on each PL/SQL procedure call and from then on we know that the credit_card table is accessed"

This is not ideal, they promote network based solutions as being non-intrusive, as being network based...... you do the math.

Also i have heard that agents are deployed, this means in those cases that Hedgehog now has a massive advantage. Hedgehog is designed from the ground up to access the data not through the database and is host based and is fast. Any network based solution that requires and agent, SQL based? is slower and also removes their argument that there are no host based requirements.

One other good example I would like to give before we move on and look at the Hedgehog install is that you could take a different approach (the cheaper approach in some senses) and use Oracle's built in solutions such as core database audit or Fine Grained Audit (FGA). What happens when you want to audit actions against a core table such as USER$ that holds password hashes? - you cannot!, Oracle says, "cannot audit a warm start table".. also its not an IDS/IPS solution unless you build the rest of the infrastructure yourself.

I would also say that if we involve products such as Oracle's own Database vault, often championed by people as the ultimate Oracle security product we have to consider its true use which for me is to protect against conflicts of interest, often referred to as CoI and to provide Segregation of duties, again refered to as SoD. These are good uses for Database Vault but as Database Vault uses VPD at its core and as we know I like products where the security is attached to the data its protecting then conceveably we could also use Hedgehog to provide similar SoD and CoI functions without the complex license and product stack. Certainly its not as clean to terminate sessions from Hedgehog instead of VPD's neat way of altering SQL but we can think of ways of doing SoD and CoI using the rules of Hedgehog. It would be an interesting use for HedgeHog.

Hedgehog also has another great use/feature. This is its virtual patching technology. This comes into play when its not possible for a customer to apply a CPU quickly after its release. Hedgehog allows a technology called "virtual patching" to be used instead. Whilst I would never recommend replacing security patches with software such as Hedgehog completely its obvious to see the immense value of virtual patching where you cannot patch straight away or maybe cannot patch because you are stuck on an old version. The same issues apply as before with the networked solutions but for virtual patching. Other "players" use network based technolgies and the same strengths that Hedgehog brings with its insistance to be connected right to the data is obvious for the same reasons as discussed above.

OK, let's have a look at the product. There is an excellent 30 page pdf installation guide that should be read before installation but if you are like me, you will try and install first and resort to the guide to fix any issues that could have been avoided if you did read it..:-)

Sentrigo have cleverly thought of these lazy people like me and have provided two nice short but comprehensive video walk throughs of the install and also for creating customised rules. Here is a look at the installation tutorial:







And the custom rules tutorial is here (BTW: click on the images to get a bigger image):






I just wanted to include a quote here from the install guide as it will serve us well in assessing whether Sentrigo Hedgehog does what it says. The 30 page installation guide first content section reads:

"Hedgehog is an easy-to-deploy software solution that monitors the database and protects it from both internal and external threats.

Hedgehog provides full visibility into database user activity and can issue alerts or terminate suspicious activities based on pre-defined rules and custom rules."

Hedgehog is supported on a number of platforms and also supports SQL Server databases and Oracle databases from 8.1.7 and above. The product has two components, well three really. The server which can be installed on Windows or Linux/Unix and the sensors that attach to the database to actually provide the real time monitoring and functionallity. The third component is that you talk to the server via a browser.

The installation process starts with registering and downloading the software from the Sentrigo website, I have to say the registration is not onerous and is much simpler than some other products I have downloaded. One of the key advantages that I have not mentioned yet about Hedgehog is that if you downloaded the full enterprise solution the 14 day trial period once up doesnt freeze or lock out the software, it reverts to the free version. Yes, Sentrigo are the only company offering a free version of a database IDS/IPS solution, this is great news in its own right.

Download the software and then run the installer. On Windows this is a simple double click and then accept the security message from the OS:





. Then you can run the wizard:





Next choose a username for the server and choose a strong password:





The next step is to choose the ports to communicate with the server and also for the sensors to communicate to and from the server. The server provides httsp and http connections to access the console:





OK, now its installing:





Once complete you should choose to run the server as the server guides you through installing the sensors:





. One slight issue I had was that the server was not accessible by default:





This was easily fixed as i remembered the tutorials suggestion to use 127.0.0.1 for a local console on the server.





The next step in the process to get Hedgehog up and running is to install the license:

















. So now we have a running licensed server, the next step is to install one o more sensors. As I am using an Oracle database and Linux i chose that sensor. I could obviously install multiple sensors on multiple databases/servers (not Sentrigo servers). I particularly liked the install of the whole product as the sensor, install is easy, ftp the file, chmod it and then install / run it. The server then finds the sensor automatically and you need to accept it. The first step is to go to the install sensor page:





Next copy the sensor install file to the server. This is easy and i used WinSCP which is an excellent free product.





Follow all the instructions on the page and you should end up like this:





The next steps are to edit the cobnfig file on the server and change the IP address of the Sentrigo sensor and then finally start the sensor.



/images/edit_configpng - (broken link)








If you now go back to the console the sensor is automatically found but you need to approve it:





OK, its now installed. I have to say that the quote above was right, the install was very easy and it was particularly easy even if you don't read the installation guide as i intentionally didn't do. I like to find out how easy it is, it would also have been a valid test to follow the instructions I guess but it installed easily without needing them, this is a good sign for a peice of software. I also am reasonably sure i could have installed it without seeing the tutorials as well. Maybe someone else can let me know how easy it is without reading anything first.

The software on installation is slick and very easy to find your way around. There is a top menu bar for all the things you need, Alerts to see and deal with, databases and sensors, rules to change, include, set, create and of course normal security of the server and console and finally an array of reports that can be generated. Quite usefully and usually something missing from other products is the ability to report on the configuration/policies themselves. This is really useful as often you want to know what is set up and take it away in a document form.

There are two major groups of rules, these are the builtin or predefined rules and the second set are the custom rules that you can generate yourself. The pre-defined rules cover a lot of issues such as use of default users, evidence of assessment tools, a whole array of exploits both specific and generic. There are around 140 rules predefined and you can subscribe to get more in real time.

An interesting section of the software is the compliance page that provides wizards to allow hedgehog to be configured for PCI, SoX and SAS-70. This is really slick and easy to use.

Here is a look at the dashboard:







One of the most important aspects is the ability to create policy rules to your own internal needs. That is you can take your own policies/regulatory requirements and easily map them to Sentrigo policies and rules. The custom rules are created via a wizard and can be easily editied afterwards. There is a good tutoral as I mentioned at the beginning, comprehensive help and user manuals and also a customer portal including a nice array of downloadable documents and forums.

There is a large array of choices that can be used in the rules, such as time, ip address, host, object, basically you name it its probably there. You can also apply boolean logic to rules to combine them and also use regular expressions. The outcome of the rules is also controlled in that you can specify how its alerted (many types), the severity and also whether the session is terminated or also whether any other subsequent rules are checked. You can also use the advanced section to even run a SQL, PL/SQL script if necessary. I wanted to test the custom rules so i created a very simple one to test access to SCOTT.EMP just for illustration:











Finally select some data from SCOTT.EMP to test it!







OK, this worked easily. Of course I could have created a much more complex rule and even rules dependant on multiple circumstances but I wanted to create something simple to show that once enabled it checks in real time and creates alerts:







So there it is, I am excited by this product which is why I agreed to be closer related to it in terms of selling it through my own company and also in terms of the advisory board position. The product is fast, slick, easy to use and can monitor activity in real time and if necessary act as an IPS and block access/activity. If anyone has any questions then please let me know, also please feel free to download a free 14 day trail copy of the enterprise edition and see how easy it would be configure and use in your own organisations.

I came across a site yesterday called http://www.authoritybase.com/ - (broken link) Authority Base because it threw up an Oracle security presentation. I am always on the look out for any information related to Oracle Security of course. I was actually looking for something related to OCI programming as I am doing some at the moment as a side project; more on that in the near future

The Authority Base site is an database blogging site run by David Yahalom and as he seems to be blogging about Oracle as well as SQL Server, MySQL, DB2 and LUW I have added his feed to my Oracle Blogs Aggregator.

He has two posts around Oracle security each with some presentation slides. The first is in a post titled http://www.authoritybase.com/index.php/oracle-virtual-directory/ - (broken link) Oracle Virtual Directory and it includes a presentation titled http://www.authoritybase.com/files/oracle_ovd.ppt - (broken link) Oracle Virtual Directory - From theory to practice and beyond. The second blog post is called http://www.authoritybase.com/index.php/the-secure-database-presentation/ - (broken link) The Secure Oracle database - howto and this also includes a presentation titled http://www.authoritybase.com/files/db_oracle_security.ppt - (broken link) The twenty-four/seven database - Oracle Database Security.

Whilst this presentation doesn't cover the usual ground that i would (i.e. auditing, internals,forensics,hacking.....) it covers the Oracle products intended to secure the database at a high level and does a good job of putting them all into the right perspective.

I have added his blog to my aggregator so we can keep an eye on new posts more easily.

I saw a post on Paul's Blog the other day and made a note to take a look one evening. It specifically links to a post by Alex Gorbachev over at Pythian that is titled http://www.pythian.com/blogs/388/exploiting-sysdba-invoker-rights-using-trigger-on-database - (broken link) Exploiting SYSDBA Invoker Rights Using Trigger on Database and it talks about an issue with SYSDBA retaining privileges inside definer rights code (specifically a logon trigger). Paul's only comment in his post Sysdba privilege escalation is that it's yet another issue where there are SYSDBA privilege escalations.

Alex also refers to a previous post but doesn't link to it. I found the previous post titled http://www.pythian.com/blogs/352/calling-definer-rights-procedure-as-sysdba-security-hole - (broken link) Calling Definer-Rights Procedure as SYSDBA - Security Hole?. There seems to be some slight issues with the later post (both are quite old posts), the first is that the end game of the post is to grant SYSDBA to U1. The end connection shows a connection as sysdba as U1 but the previous code in the procedure give_sysdba grants the DBA role to U1 not the SYSDBA privilege. The connection in SQL*Plus AS SYSDBA would work in some cases without the grant taking place (i.e. the OS does the authentication) like so:


SQL*Plus: Release 11.1.0.6.0 - Production on Wed Jun 4 18:02:42 2008

Copyright (c) 1982, 2007, Oracle. All rights reserved.

Enter user-name: system/oracle1

Connected to:
Personal Oracle Database 11g Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> connect system/manager as sysdba
Connected.

SQL> select * from v$pwfile_users;

USERNAME SYSDB SYSOP SYSAS
------------------------------ ----- ----- -----
SYS TRUE TRUE FALSE
SCOTT FALSE TRUE FALSE

SQL> sho user
USER is "SYS"
SQL>


The code in the article may or may not have granted the DBA role to U1, there is no check to test this. Although the earlier article mentions that invoker rights/define rights differences depend on compile time and run time system privileges, roles and object access privileges the second doesn't cover it and the first not in enough detail. The basic difference is that definer rights procedures are resolved at compile time and no privilege gained through a role is available. Of course the privileges and access rights used at compile time are those assigned to the owner (and subtely to PUBLIC; any system or object privilege granted to PUBLIC is as good as a direct privilege granted to the user). In the case of Invoker rights the owner must have access to referenced objects to compile but the resolution of privileges is done at run time and roles are available (where they are not in definer rights) as granted to the invoker. This can lead to strange circumstances where code can fail for one user and not another due to lacking grants. This is one of the strenghts and powers of invoker rights code and why they need to be designed correctly.

The second issue I have with Alex's post is that whilst privilege escalation can be attained/obtained it is actually a trojan in essence that is used to gain the privileges. The fact that this issue relates to SYSDBA connections is immaterial as we can arange for any privileged user to run code for a lesser user in any similar circumstance using invoker rights or other methods. A method I suggested in a paper I wrote in 2001 when working at Pentest called Exploiting and protecting Oracle (search with CTRL-F for "identified by" to locate it) shows how a script from the $ORACLE_HOME/rdbms/admin directory could be modified to replace a statement

1alter session set sql_trace true:

to

1alter user sys identified by sys:

The result is similar in nature and is also a trojan. Alex's paper is interesting and there is an anomoly that should be looked into an understood but there but there are also some inconsistencies in the paper as above. Thanks for the pointer Paul!

I mentioned a couple of weeks ago in a post titled "Oracle Application Server 10g ORA_DAV basic authentication bypass" that i subscribe to the bugtraq mailing list over at Security Focus and that I recommend everyone else to do the same to keep up to date with security in general, bugs and exploits and also to be abreast of Oracle security exploits when they occur; or rather are released.

I made a note of a post to this mailing list a couple of weeks ago to go and read the article. The post is An account of the Estonian Internet War and I printed the article referenced in it out and took it to read on our familly holiday to North Wales last week along with the new second edition of Kris Kaspersky's "Hacker Dissassembly Uncovered" which I have to say is much better than the first edition. I will talk about that book again when I have finished reading it although now I am back at work reading time will diminish considerably.

Gadi Evron also wrote an article on the Estonian internet war. This is titled Battling Botnets and online mobs - Estonia's defense efforts during the internet war and is fascinating reading. Its not a deeply technical read but the content and implications are frightening. Whats it got to do with Oracle Security? - not sure at the moment. I think this is a new phenomenon and it will happen again. The article states quite clearly that NATO issued a swift response, George W Bush spoke to the Estonian president and the pentegon sent people there and NATO agreed to establish research facilities to understand how to counter these sorts of attacks. Whats the risk to Oracle databases? - who knows at present. The issue for me is that the number of sites that are creating applications that use Oracle databases as the data store and also expose the application to a wider intranet or even the internet are potentially in the direct firing line of these sorts of attack. The paper talks about key infrastructure being controlled by the net in Estonia such as banking, voting and even parent/teacher relationships. Any application exposed directly or indirectly to the internet could be attacked and if they are backed by an Oracle database my experience of Oracle database security audits shows that an Oracle database in general is a good target!!!