One of my key issues with Oracle security is to reduce the possible direct access to the database from as many people as possible in any organisation that i work with. I generally call this the "access Issue" as its basically means that anyone who can find out the four pieces of information necessary (The hostname{or IP Address}, Port Number, SID, USERNAME/PASSWORD) can log into the database. As we know the IP address and port number can be found easily within an organisation using port scanners such as nmap or amap. We also know from orldy experience of conducting database security audits for many years that usernames/passwords can be found easilly (some are defaults, some because bad naming conventions occur), passwords in our experience are even easier as we often find most passwords very easily because sites still set them to the username, a default, a simple dictionary word or its too short. This issue is one of the key issues in Oracle security. If you reduce the chance that anyone who should not do so (remember those that should do so should be very small) should not be able to attempt a direct connection to the database. Whilst this does not fix Oracle security it certainly reduces the risk. If you cannot get a connection you cannot run anything or read anything. We of course need to also solve the problem of the legitimate access use as well!. I talked about this subject at the UKOUG conference in my back to basics talk and also in my Oracle security masterclass. The presentations are available on my Oracle Security white papers page.
So the only piece of information that is slightly harder to find is the SID/Service name. Alexandr Polyakov has written an excellent paper on how to find database SID's. I have had a couple of email conversations with him over the last week or so and promised to ppost a link here to his paper. There are SID guess and SID brute force tools out there but this is the first detailed discussion on how to find SID's. This is an excellent paper called "Different ways to guess Oracle database SID"
Blog
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.
A PL/SQL Fuzzer / Fuzzor
Slavik sent me the code to his PL/SQL fuzzer quite some time ago to have a look and a play and he promised to make it available via his blog. The blog post has arrived finally around 10 days ago with a detailed description of the fuzzer, some example run and also the code for download.
Fuzzer or Fuzzor; Slavik uses both terms, I don't know, generally its called a fuzzer in my experience but the name doesn't really matter, it's what it does that matters. Fuzzing started in 1989 by professor Barton Miller who coined the name when he saw the effects of randon characteres on a modem line caused by storms crashing Unix utilities. He then set the task as a graduate project to create a fuzzer, and he coined the name Fuzz. it has nothing to do with fuzzy logic but to do with sending random input to a program with the intention of crashing that program. The idea is different to static code analysis as it is dynamic testing and is aimed at replicating the idea of someone who doesnt read the manuals for an application but instead just randomly bangs away at the keyboard; in this case looking for something to break - a bug - we are interested from a security perspective as we would like to crash a program dynamically to see if it can be expolited from a security perspective.
This is exactly what Slavik's fuzzer does. Its written in PL/SQL, tests PL/SQL packages, functions and procedures and is driven by a set of database tables to hold the configuration and the results. The idea is that you can target a particular package or a complete schema.
The nature of a fuzzer is that it sends random input to a particular function or procedure so its running that code hoping to crash it. Therefore do not run this tool on a production database or any database that you do not want to damage..
To run the fuzzer you must first create the schema. Another reason to not run the code in production is the need to create an additional schema that has some dangerous privileges such as EXECUTE ANY PROCEDURE. Then create the tables for the schema and you then need to create the fuzzer package called "fuzzer". Finally running the fuzzer is as simple as:
SQL> exec fuzzor.run_package(’Test of encode', 'TEST', 'ENCODE1');
PL/SQL procedure successfully completed.
SQL>
Next run a report from the same package with FUZZER.REPORT. This reports the number of objects fuzzed and the number of executions and of course the results. I would change the report to highlight the issues located better to the beginning of the report or to allow exclusion of the "good" values. Clearer reports can be made with SQL scripts in SQL*Plus of course.
The code is available from Slavik's site under PL/SQL Fuzzer Source Code. Finally again; do not run this in a database you need and certainly not in production databases.
Fuzzer or Fuzzor; Slavik uses both terms, I don't know, generally its called a fuzzer in my experience but the name doesn't really matter, it's what it does that matters. Fuzzing started in 1989 by professor Barton Miller who coined the name when he saw the effects of randon characteres on a modem line caused by storms crashing Unix utilities. He then set the task as a graduate project to create a fuzzer, and he coined the name Fuzz. it has nothing to do with fuzzy logic but to do with sending random input to a program with the intention of crashing that program. The idea is different to static code analysis as it is dynamic testing and is aimed at replicating the idea of someone who doesnt read the manuals for an application but instead just randomly bangs away at the keyboard; in this case looking for something to break - a bug - we are interested from a security perspective as we would like to crash a program dynamically to see if it can be expolited from a security perspective.
This is exactly what Slavik's fuzzer does. Its written in PL/SQL, tests PL/SQL packages, functions and procedures and is driven by a set of database tables to hold the configuration and the results. The idea is that you can target a particular package or a complete schema.
The nature of a fuzzer is that it sends random input to a particular function or procedure so its running that code hoping to crash it. Therefore do not run this tool on a production database or any database that you do not want to damage..
To run the fuzzer you must first create the schema. Another reason to not run the code in production is the need to create an additional schema that has some dangerous privileges such as EXECUTE ANY PROCEDURE. Then create the tables for the schema and you then need to create the fuzzer package called "fuzzer". Finally running the fuzzer is as simple as:
SQL> exec fuzzor.run_package(’Test of encode', 'TEST', 'ENCODE1');
PL/SQL procedure successfully completed.
SQL>
Next run a report from the same package with FUZZER.REPORT. This reports the number of objects fuzzed and the number of executions and of course the results. I would change the report to highlight the issues located better to the beginning of the report or to allow exclusion of the "good" values. Clearer reports can be made with SQL scripts in SQL*Plus of course.
The code is available from Slavik's site under PL/SQL Fuzzer Source Code. Finally again; do not run this in a database you need and certainly not in production databases.
January 2009 CPU is out
The latest CPU (Critical Patch Update - read security bug fixes) from Oracle is out. The CPU came out last night, as usual on the second Tuesday of each quarter. The CPU is much more of the the same; I think the two key things we can see from this CPU is that there is an ongoing trend of less fixes for the database. To be honest we need to monitor the changes to numbers over a longer period but the trend does seem to be lowering.
The second thing to note is that there are a lot more new names credited on this CPU. This is interesting; it means that whilst some of the normal "security" names are still there there are a lot of new names; does this mean we have more Oracle security researchers (i.e. people just concentrating on Oracle) - I think, No; I think we are starting to see a change to the more mainstream in that other people are now thinking about security, noticing security issues and reporting them to Oracle. Is this good - yes, is it bad for Oracle, in that more people will find bugs? - no, it has to be good that people are starting to take security of data more seriously.
And the third thing (OK, i said two, this is a bonus!), is that whilst there are less database and app server bugs in terms of trend there are 9 bugs in Oracle secure backup all with a risk of 10.0 (only for Windows, for Linux its 7.5), this signifies a "new target" for researchers. Considering that the database itself has been a target for a long time, will all the new products and features attract a large number of bugs going forward? - a delayed trend? - also as we have said it seems that security bugs are mainstream now and also people are aware of data security much more.
Oracle's advisory Oracle Critical Patch Update Advisory - January 2009 is available.
The second thing to note is that there are a lot more new names credited on this CPU. This is interesting; it means that whilst some of the normal "security" names are still there there are a lot of new names; does this mean we have more Oracle security researchers (i.e. people just concentrating on Oracle) - I think, No; I think we are starting to see a change to the more mainstream in that other people are now thinking about security, noticing security issues and reporting them to Oracle. Is this good - yes, is it bad for Oracle, in that more people will find bugs? - no, it has to be good that people are starting to take security of data more seriously.
And the third thing (OK, i said two, this is a bonus!), is that whilst there are less database and app server bugs in terms of trend there are 9 bugs in Oracle secure backup all with a risk of 10.0 (only for Windows, for Linux its 7.5), this signifies a "new target" for researchers. Considering that the database itself has been a target for a long time, will all the new products and features attract a large number of bugs going forward? - a delayed trend? - also as we have said it seems that security bugs are mainstream now and also people are aware of data security much more.
Oracle's advisory Oracle Critical Patch Update Advisory - January 2009 is available.
