I have been in discussions and helping with some testing for the latest version of Laszlo Toth's excellent Oracle password cracker woraauthbf. The main page for the cracker describes the various releases and also describes how the cracker works and can be used.
This bugfix release (0.22R2) is to fix a bug in the 11g password hash checking where the brute force mode for 11g stopped working when the pre-loading was added to the cracker.
A pre-compiled version of worauthbf for Windows is available. The C source code for the latest version is also available.
If you are serious about Oracle security you should run my simple sqlplus script that implements an Oracle password cracker in PL/SQL first and then when you are comfortable with the process move to a binary cracker such as woraauthbf to test passwords to a stronger level.
Thanks Laszlo for your great work on this free program.
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.
Writing a password cracker in Perl
I got an e-mail from Tim a few weeks ago asking whether I knew of a resource that showed how to write a password cracker for Oracle in Perl. The only source I knew of was the Perl script written by Ian Redfern referenced on his original TNS paper which is also a published as the elephant protocol on the UK cert website. I replied to Tim and suggested the source but unfortunately I already knew the Perl script was no longer available. Tim quite helpfully replied that he had found a different source for a Perl script that implements the Oracle password algorithm.
This is written by Alun Jones. The Perl script can be found http://users.aber.ac.uk/auj/freestuff/orapass.pl.txt - (broken link) here and is simple to run. Here is an example of running the script with the sample test code provided in the script. Basically the script provides a function called Oracle_hash that performs the hash algorithm. Script also provides a simple loop with for sample users and password hashes that test the function. Here is a sample run:
you can of course modify this quite easily to passing a list of users from the database and also to passing default passwords, dictionary words or to perform brute forcing of the passwords. I don't have any idea of the performance of the code as compared with tools such as worauthbf. Of course my PL/SQL based script is very simple to run in the database directly.
I thought it was worth sharing the link to the PERL based cracker.
This is written by Alun Jones. The Perl script can be found http://users.aber.ac.uk/auj/freestuff/orapass.pl.txt - (broken link) here and is simple to run. Here is an example of running the script with the sample test code provided in the script. Basically the script provides a function called Oracle_hash that performs the hash algorithm. Script also provides a simple loop with for sample users and password hashes that test the function. Here is a sample run:
|
you can of course modify this quite easily to passing a list of users from the database and also to passing default passwords, dictionary words or to perform brute forcing of the passwords. I don't have any idea of the performance of the code as compared with tools such as worauthbf. Of course my PL/SQL based script is very simple to run in the database directly.
I thought it was worth sharing the link to the PERL based cracker.
Accessing Data Outside the data model
I posted two blog entries on the subject of "Instrumentation - a god send for speed freaks - a god send for data thieves" and "Is it possible to steal data with just ALTER SESSION?" over the last few days and in response to the latter post Alex has added a comment linking to a response posted to his blog post.
I just want to cover a few points here. I didn't mean just that utl_file_dir was set to "*" or that DIRECTORY objects exist that point at the trace directories. These were examples; as other scenarios also existed that would allow access to the trace files. I have seen external tables already exposing the alert log and also trace files. I have seen Oracle's SQLTXPLAIN installed in three database in the last year (this also exposes trace directories).
A couple of examples in the last year were a site with somewhere around 10 users that had ALTER SESSION out of around 200 users (so around 5%), in this database the utl_file_dir parameter was set to "*". Another database had around 400 users with ALTER SESSION from around 1800 users (22%); in this database SQLTXPLAIN was installed and every user of the database could access the DIRECTORY object that pointed at udump.
Alex asks whether ALTER SESSION is a bigger issue that access to the file system and suggests that access to the file system is the bigger issue. I would agree as there are a huge number of possibilities to get to the file system (whether they are enabled by default or not is not the issue - as they could be). But i would also agree that both issues are a problem and that we must concentrate on the data first not specific parameters.
The problem with Oracle is the complex heirarchy of privileges and access. Oracle is a complex product and the access paths not just to data but also to the operating system are often complex.
Take a simple table called CREDIT_CARD, it may have privileges granted by the owner to other users, there may also be a heirarchy of views/triggers/ PL/SQL built on top of the table each with their own privilege models. Then take the scenrio presented first in this discussion that there are often other methods to get at the data such as from the SGA, Trace files, redo logs, archive logs, Log-miner, list files, export files, backups, data-files....(there are many more); then take the scenario that the data is actually often duplicated in the database in many tables and then the same heirarchies sit above each of those copies of the data. The problem of securing the data (CREDIT_CARDS in this case) is not a flat world view but one of knowing "where" the data is and taking actions to prevent its theft.
The same ideas can be thought about with the access to the OS. There are many ways to get to the OS from the database, utl_file_dir, DIRECTORY OBJECTS, Java, user C, built-in packages that use Oracles own C functions, Oracle Text that Alex has written about many times, scheduler, external tables, initialisation parameters, classic packages such as UTL_FILE, all the packages that referenence and use UTL_FILE and those that reference those; then do the same exercise for all packages provided by Oracle that allow acess to the OS (using Java, C, DIRECTORY objects or any other method). Then we have the same complexity issue that we have with the data. The access if not there by default is not secure as other users could create the access. Therefore we also need to consider privileges such as the JAVA roles that allow access to the FilePermission JVM privileges, the rights to grant Java privileges, the rights to create Java code and use existing privileges, CREATE ANY DIRECTORY and then a level above the rights that allow granting of the rights we have just discussed such as GRANT ANY PRIVILEGE or GRANT ANY ROLE. we also need to consider default users with bad passwords that allow someone to also either use rights directly or gain those rights indirectly.
A second idea to think about is that DBA type staff already have SYSDBA, OSDBA, the DBA role, IMP_FULL_DATABASE, ALTER USER (change SYS password - in this context ALTER USER is good enough to access a trace file on the file system BUT why would you bother when you can simply log in as SYS?), ALL PRIVILEGES and many more. The issues with security and data theft are not "flat" that is there are many ways to steal and many types of people who may steal. Question: What if the DBA wants to steal credit card data, knows audit is enabled on the credit card table? - maybe he can simply dump the buffers and read them directly and avoid direct table access? -
we must not be blinded by the fact that access is not available to PUBLIC.
This is not any sort of definitive list of issues it is meant to be a discussion of the complexity issues involved in securing Oracle. Securing an Oracle database is complex because we MUST consider the data first not simply follow checklists.
These ideas (many paths to the data and also different routes to the file system) are what I discussed in my 2 hour Oracle Security masterclass at the end of last year in Birmingham at the UKOUG conference.
I just want to cover a few points here. I didn't mean just that utl_file_dir was set to "*" or that DIRECTORY objects exist that point at the trace directories. These were examples; as other scenarios also existed that would allow access to the trace files. I have seen external tables already exposing the alert log and also trace files. I have seen Oracle's SQLTXPLAIN installed in three database in the last year (this also exposes trace directories).
A couple of examples in the last year were a site with somewhere around 10 users that had ALTER SESSION out of around 200 users (so around 5%), in this database the utl_file_dir parameter was set to "*". Another database had around 400 users with ALTER SESSION from around 1800 users (22%); in this database SQLTXPLAIN was installed and every user of the database could access the DIRECTORY object that pointed at udump.
Alex asks whether ALTER SESSION is a bigger issue that access to the file system and suggests that access to the file system is the bigger issue. I would agree as there are a huge number of possibilities to get to the file system (whether they are enabled by default or not is not the issue - as they could be). But i would also agree that both issues are a problem and that we must concentrate on the data first not specific parameters.
The problem with Oracle is the complex heirarchy of privileges and access. Oracle is a complex product and the access paths not just to data but also to the operating system are often complex.
Take a simple table called CREDIT_CARD, it may have privileges granted by the owner to other users, there may also be a heirarchy of views/triggers/ PL/SQL built on top of the table each with their own privilege models. Then take the scenrio presented first in this discussion that there are often other methods to get at the data such as from the SGA, Trace files, redo logs, archive logs, Log-miner, list files, export files, backups, data-files....(there are many more); then take the scenario that the data is actually often duplicated in the database in many tables and then the same heirarchies sit above each of those copies of the data. The problem of securing the data (CREDIT_CARDS in this case) is not a flat world view but one of knowing "where" the data is and taking actions to prevent its theft.
The same ideas can be thought about with the access to the OS. There are many ways to get to the OS from the database, utl_file_dir, DIRECTORY OBJECTS, Java, user C, built-in packages that use Oracles own C functions, Oracle Text that Alex has written about many times, scheduler, external tables, initialisation parameters, classic packages such as UTL_FILE, all the packages that referenence and use UTL_FILE and those that reference those; then do the same exercise for all packages provided by Oracle that allow acess to the OS (using Java, C, DIRECTORY objects or any other method). Then we have the same complexity issue that we have with the data. The access if not there by default is not secure as other users could create the access. Therefore we also need to consider privileges such as the JAVA roles that allow access to the FilePermission JVM privileges, the rights to grant Java privileges, the rights to create Java code and use existing privileges, CREATE ANY DIRECTORY and then a level above the rights that allow granting of the rights we have just discussed such as GRANT ANY PRIVILEGE or GRANT ANY ROLE. we also need to consider default users with bad passwords that allow someone to also either use rights directly or gain those rights indirectly.
A second idea to think about is that DBA type staff already have SYSDBA, OSDBA, the DBA role, IMP_FULL_DATABASE, ALTER USER (change SYS password - in this context ALTER USER is good enough to access a trace file on the file system BUT why would you bother when you can simply log in as SYS?), ALL PRIVILEGES and many more. The issues with security and data theft are not "flat" that is there are many ways to steal and many types of people who may steal. Question: What if the DBA wants to steal credit card data, knows audit is enabled on the credit card table? - maybe he can simply dump the buffers and read them directly and avoid direct table access? -
we must not be blinded by the fact that access is not available to PUBLIC.
This is not any sort of definitive list of issues it is meant to be a discussion of the complexity issues involved in securing Oracle. Securing an Oracle database is complex because we MUST consider the data first not simply follow checklists.
These ideas (many paths to the data and also different routes to the file system) are what I discussed in my 2 hour Oracle Security masterclass at the end of last year in Birmingham at the UKOUG conference.
Blog with Oracle Security posts
I posted yesterday about Chris Gates video from shmoocon in a post titled "Attacking Oracle with Metasploit" and also another of his Oracle videos. Whilst searching I also found his blog carnal0wnage which is quite nice as it includes quite a few Oracle security based posts.
I have added this blog to my Oracle news/blogs aggregator so that we can pick up his posts.
I have added this blog to my Oracle news/blogs aggregator so that we can pick up his posts.
Attacking Oracle with Metasploit
Chris Gates recent fire talk at Shmoocon is available on vimeo. He gave a talk about how to attack Oracle using the metasploit framework. The video is called "Attacking Oracle with the metasploit framework Shmoocon Firetalk demo video". Also on vimeo is another video by Chris titled "Metaploit auxiliary module for Oracle FTP script write/binary download/execute via Oracle packages". Thanks to Paul for the email and link.
Is it possible to steal data with just ALTER SESSION?
I wrote an entry in my blog yesterday titled "Instrumentation - a god send for speed freaks - a god send for data thieves" and immediately got into trouble for making a hash of writing it. I had suggested that just the ALTER SESSION privilege is needed (well actually i didn't say you only needed ALTER SESSION but rather if you had it you could use it to dump data blocks). As i happens I didn't actually mean that. I meant just simply dump data with this privilege via trace.
The main thrust of that post was to suggest that whilst instrumentation is great for tuning and fixing its also great for people who want to steal data. I don't disagree with instrumentation and as suhc the second point was that to protect data you must think of all the possible ways to get at that data.
I made a mess of the blog entry BUT it got me thinking about what is possible with ALTER SESSION. Here are a couple of examples of getting at data or structure with just ALTER SESSION. The first is my old favourite the library cache dump.
Imagine first that some table called CREDIT_CARD exists and that some data has been inserted and selected and updated. A script doing some of this run as SCOTT will illustrate. This would represent real life in terms of a real application where users read and write and change data in the CREDIT_CARD table via application screens. I know its simple and concocted but its an example:
So thats the exmple data and actions. Lets dump the library cache as eviluser:
Let's now find the trace file and have a look at it:
OK, just two examples from a fwe in the trace file from the library cache dump but both show critical data. They may not show complete block dumps of data but they do show data that someone may wish to steal. I did a simple experiment many years ago (2001) and the results are here: - "Revealing clear text passwords from the SGA". That example was about revealing clear text passwords but that is only one form of attack. Not all attacks are about stealing passwords or escalating privileges. Some attacks are about actually stealing data as as we said to protect the data we must consider all ways to get at that data either in or out of the database.
Another useful dump that we could do (remember not all attacks are single vector and not all are about escalting privileges) is to get details of the object in the database. We can do a dictionary cache dump or row cache dump:
As eviluser:
Then we can view the trace file and look for the CREDIT_CARD table:
We can go much further than this simple example and learn about the structure of the database. We have highlighted the object id and owner. There is a lot more information we can gather.
Finally I wanted to show another simple example of what we can do with ALTER SESSION. This time we can do a buffer dump:
Again inspecting the trace file; and wow this is a rich trace file in terms of what we can get from it:
The first example shows block dumps for the USER$ table. The record I have chosen is for the user ORASCAN - the hex 4f 52 41 53 43 41 4e says ORASCAN, the text just below 39 38 33 46 32 41 34 33 44 34 35 35 31 36 35 33 is his password hash that we could now take and crack. We need to just convert the ASCII back into characters. The password hashes of other users are also there, this is 11g so the 11g SHA1 hashes are also present.
So , OK can we dump data blocks from the database with ALTER SESSION? - yes of course:
As one example, the sequence - 46 69 6e 6e 69 67 61 6e - translated from hex to ascii is "F i n n i g a n". The card number is easier to read, simply remove the 3 from the front of each pair of hex digits and you get the decimal. So running some SQL as SCOTT for the table shows the actual data. Compare that to the above and remove the 3 and you can see the cerdit card numbers.
So in summary, the ALTER SESSION system privilege is very dangerous. We can reveal structure, password hashes, actual data, SQL statements including data and we have a huge number of events we can run that would give is VPD predicates, OPI calls, SQL*Net, sorts.... this list goes on.
There is an argument that we (the person abusing the ALTER SESSION privilege) needs to be able to read the trace file generated. OK, there are two angles to this. First in my experience in a lot of databases i have performed Oracle database security audits on have issues that allow access to trace files, such as utl_file_dir set to "*" or the trace directories; systems also have directory objects created to specifically expose trace files; applications such as E-Business Suite do this by default. There are built in packages, Java, C and many methods that can be used to access the file system. This is only one angle to the problem. We must consider the second as well. If someone dumps these traces to the file system and cannot even read them the data is STILL held outside the database, duplicated and possibly much less secure than in the database.
The link above also shows a simple example of reading a trace file remotely in the revealing clear text passwords from the SGA article.
This sort of issue is really about ensuring you understand all the different ways to get to the data and also understand that the problem is not necessarily the fact that you cannot escalate privileges. Just because most example exploits show how to grant DBA to SCOTT or something similar does not mean that any simple exploit that say allows us to read credit card data we are not supposed is not a valid exploit. If you think about this you should be very worried as you will realise that the possible methods / attacks / exploits / whatever are so huge that you must concentrate on the data first; that way you can hope to secure it.
The main thrust of that post was to suggest that whilst instrumentation is great for tuning and fixing its also great for people who want to steal data. I don't disagree with instrumentation and as suhc the second point was that to protect data you must think of all the possible ways to get at that data.
I made a mess of the blog entry BUT it got me thinking about what is possible with ALTER SESSION. Here are a couple of examples of getting at data or structure with just ALTER SESSION. The first is my old favourite the library cache dump.
Imagine first that some table called CREDIT_CARD exists and that some data has been inserted and selected and updated. A script doing some of this run as SCOTT will illustrate. This would represent real life in terms of a real application where users read and write and change data in the CREDIT_CARD table via application screens. I know its simple and concocted but its an example:
|
So thats the exmple data and actions. Lets dump the library cache as eviluser:
|
Let's now find the trace file and have a look at it:
|
OK, just two examples from a fwe in the trace file from the library cache dump but both show critical data. They may not show complete block dumps of data but they do show data that someone may wish to steal. I did a simple experiment many years ago (2001) and the results are here: - "Revealing clear text passwords from the SGA". That example was about revealing clear text passwords but that is only one form of attack. Not all attacks are about stealing passwords or escalating privileges. Some attacks are about actually stealing data as as we said to protect the data we must consider all ways to get at that data either in or out of the database.
Another useful dump that we could do (remember not all attacks are single vector and not all are about escalting privileges) is to get details of the object in the database. We can do a dictionary cache dump or row cache dump:
As eviluser:
|
Then we can view the trace file and look for the CREDIT_CARD table:
|
We can go much further than this simple example and learn about the structure of the database. We have highlighted the object id and owner. There is a lot more information we can gather.
Finally I wanted to show another simple example of what we can do with ALTER SESSION. This time we can do a buffer dump:
|
Again inspecting the trace file; and wow this is a rich trace file in terms of what we can get from it:
|
The first example shows block dumps for the USER$ table. The record I have chosen is for the user ORASCAN - the hex 4f 52 41 53 43 41 4e says ORASCAN, the text just below 39 38 33 46 32 41 34 33 44 34 35 35 31 36 35 33 is his password hash that we could now take and crack. We need to just convert the ASCII back into characters. The password hashes of other users are also there, this is 11g so the 11g SHA1 hashes are also present.
So , OK can we dump data blocks from the database with ALTER SESSION? - yes of course:
|
As one example, the sequence - 46 69 6e 6e 69 67 61 6e - translated from hex to ascii is "F i n n i g a n". The card number is easier to read, simply remove the 3 from the front of each pair of hex digits and you get the decimal. So running some SQL as SCOTT for the table shows the actual data. Compare that to the above and remove the 3 and you can see the cerdit card numbers.
|
So in summary, the ALTER SESSION system privilege is very dangerous. We can reveal structure, password hashes, actual data, SQL statements including data and we have a huge number of events we can run that would give is VPD predicates, OPI calls, SQL*Net, sorts.... this list goes on.
There is an argument that we (the person abusing the ALTER SESSION privilege) needs to be able to read the trace file generated. OK, there are two angles to this. First in my experience in a lot of databases i have performed Oracle database security audits on have issues that allow access to trace files, such as utl_file_dir set to "*" or the trace directories; systems also have directory objects created to specifically expose trace files; applications such as E-Business Suite do this by default. There are built in packages, Java, C and many methods that can be used to access the file system. This is only one angle to the problem. We must consider the second as well. If someone dumps these traces to the file system and cannot even read them the data is STILL held outside the database, duplicated and possibly much less secure than in the database.
The link above also shows a simple example of reading a trace file remotely in the revealing clear text passwords from the SGA article.
This sort of issue is really about ensuring you understand all the different ways to get to the data and also understand that the problem is not necessarily the fact that you cannot escalate privileges. Just because most example exploits show how to grant DBA to SCOTT or something similar does not mean that any simple exploit that say allows us to read credit card data we are not supposed is not a valid exploit. If you think about this you should be very worried as you will realise that the possible methods / attacks / exploits / whatever are so huge that you must concentrate on the data first; that way you can hope to secure it.
Interview with SearchSecurity about Slavik's new Fuzzor
yesterday I was interviewed by Erin Kelly of SearchSecurity.com about Slavik's new Oracle Fuzzor that I mentioned here yesterday in a post titled "New version of Fuzzor available". The interview is :
The complete article is titled "Fuzzing tool helps Oracle DBAs defend against SQL injection" by Erin Kelly
Database security software vendor Sentrigo Inc. released a new open source fuzzing tool, FuzzOr, designed to identify vulnerabilities found in Oracle database software applications.
With FuzzOr, Sentrigo aimed to create a tool that would allow database administrators and programmers to test PL/SQL applications for security vulnerabilities, said Slavik Markovich, co-founder and chief technology officer of Sentrigo.
The complete article is titled "Fuzzing tool helps Oracle DBAs defend against SQL injection" by Erin Kelly
Instrumentation - a god send for speed freaks - a god send for data thieves
I saw a nice post today by Chen Shapira via my Oracle blogs aggregator. The post by Chen is called "Psychology of Instrumentation" and whilst it is not a security post; this is an area I cover in my training class on "how to perform a security audit of an Oracle database". I want in my class to emphasise the non-flat world model of accessing data - in other words if your credit cards are stored in a table called CREDIT_CARD do not be simplistic in thinking the only way to read the credit cards is to perform a select statement against the CREDIT_CARD table. It is almost certainly not the only way.
So, I have to add something negative to Chens article - that just goes with the role of being a security person, being negative that is..:-).
Instrumentation is great, I have written in C, PL/SQL, Perl and many more languages over the years and the usual first peice of code i write is some sort of debug/trace/instrumentation interface so i like instrumentation - BUT - in the case of Oracle we do already have a huge amount of instrumentation, traces, data dumps, file dumps, redo dumps, header dumps, sql*net trace, logs, events, statspack, AWR, ASH.... This list simply goes on....
The downside is whilst this stuff is great for understanding how the system works and why it maybe slow often all of these methods of tracing or instrumenting can undo the good security work done. Imagine a case where we protect and harden access to our CREDIT_CARD table. We ensure only authorised users can select from the table; great we are secure. Imagine that most users have the ALTER SESSION system privilege and therefore they can dump data to trace files by running a trace on a process or program that they have access to run but perhaps can only see a very limited set of data via a screen (of course they would need to be able to read the trace file; in my experience this is often not a problem due to file system access, exposure of trace files through the applications (E-Business Suite is a good example), often DBA's may email trace files to people; imagine that we have secured some data in the table using VPD; this same method (trace) allows bypass of VPD by virtue of certain events allowing the dumping of predicates so that the "rules" applied can be determined, maybe the predicate function can be executed.... Imagine we allow users to set trace and the code does not use binds or it does use binds and setting extended trace is possible, again data can be read perhaps that should not be.
Whilst instrumentation is great we should be cautious and even suspicious and not let these mechansisms be used to get at the data.
[Thanks to Christopher Newman's email and Alex's comments for picking up my lax typing and editing issues - i have editied the post to say what I meant originally]
So, I have to add something negative to Chens article - that just goes with the role of being a security person, being negative that is..:-).
Instrumentation is great, I have written in C, PL/SQL, Perl and many more languages over the years and the usual first peice of code i write is some sort of debug/trace/instrumentation interface so i like instrumentation - BUT - in the case of Oracle we do already have a huge amount of instrumentation, traces, data dumps, file dumps, redo dumps, header dumps, sql*net trace, logs, events, statspack, AWR, ASH.... This list simply goes on....
The downside is whilst this stuff is great for understanding how the system works and why it maybe slow often all of these methods of tracing or instrumenting can undo the good security work done. Imagine a case where we protect and harden access to our CREDIT_CARD table. We ensure only authorised users can select from the table; great we are secure. Imagine that most users have the ALTER SESSION system privilege and therefore they can dump data to trace files by running a trace on a process or program that they have access to run but perhaps can only see a very limited set of data via a screen (of course they would need to be able to read the trace file; in my experience this is often not a problem due to file system access, exposure of trace files through the applications (E-Business Suite is a good example), often DBA's may email trace files to people; imagine that we have secured some data in the table using VPD; this same method (trace) allows bypass of VPD by virtue of certain events allowing the dumping of predicates so that the "rules" applied can be determined, maybe the predicate function can be executed.... Imagine we allow users to set trace and the code does not use binds or it does use binds and setting extended trace is possible, again data can be read perhaps that should not be.
Whilst instrumentation is great we should be cautious and even suspicious and not let these mechansisms be used to get at the data.
[Thanks to Christopher Newman's email and Alex's comments for picking up my lax typing and editing issues - i have editied the post to say what I meant originally]
New version of Fuzzor available
Slavik the CTO of Sentrigo has today released a new version of his free Fuzzor tool. This is a fuzzer (note the "e" in the tool type, the "o" in Slaviks name for it is intended to represent the big "O" from Oracle) that can be used to test PL/SQL code in an Oracle database whether its wrapped or not.
We are quite limited really in terms of free or commercial tools specifically available to test the PL/SQL code we deploy for security vulnerabilities such as SQL Injection. There are two types of tools that could exist; static analysis tools or dynamic tools. Slavik's Fuzzor is a dynamic tool. That means you install it and run it against the code in the database and you basically "see" if you can make the code error by sending large amounts of pseudo random input to the procedures/functions/packages being tested.
The tool is configurable, FREE on the GPL3 license and very easy to use. We must exercise caution here:
This is a great tool that can be run to test the code you have written internally in your organisations or to test third party vendor code. It is very easy to use and the reports are easy to understand. This release version of the tool is now available from Sentrigo's website and involves a simple registration process to get it. There has been a couple of major changes since I last talked about the tool in a post titled "A PL/SQL Fuzzer / Fuzzor". http://www.slaviks-blog.com/2009/02/04/updated-fuzzor/ - (broken link) Slavik summarises these as :
The Fuzzor is available from the download page.
We are quite limited really in terms of free or commercial tools specifically available to test the PL/SQL code we deploy for security vulnerabilities such as SQL Injection. There are two types of tools that could exist; static analysis tools or dynamic tools. Slavik's Fuzzor is a dynamic tool. That means you install it and run it against the code in the database and you basically "see" if you can make the code error by sending large amounts of pseudo random input to the procedures/functions/packages being tested.
The tool is configurable, FREE on the GPL3 license and very easy to use. We must exercise caution here:
Do not run this tool on a production database or any database you would like to keep. It should be run on a specific test system only as its purpose is to dynamically test code by running it
This is a great tool that can be run to test the code you have written internally in your organisations or to test third party vendor code. It is very easy to use and the reports are easy to understand. This release version of the tool is now available from Sentrigo's website and involves a simple registration process to get it. There has been a couple of major changes since I last talked about the tool in a post titled "A PL/SQL Fuzzer / Fuzzor". http://www.slaviks-blog.com/2009/02/04/updated-fuzzor/ - (broken link) Slavik summarises these as :
* Better functionality when working with types (objects, tables, PL/SQL records, etc.)
* A feature to generate automatic Hedgehog security rules from the scanning results. For example, if you find a vulnerability, but you are unable to fix it (ie, you don’t own the code, the code is wrapped or you require lengthy QA cycles) you can now automatically protect the vulnerable code by installing Hedgehog Standard and importing the generated rules.
I’ve also revised the report to be much more concise and readable.
The Fuzzor is available from the download page.
Details of a 10g PL/SQL Unwrapper available
I just saw via my Oracle blogs aggregator that Anton Scheffer has released a nice blog post showing how he has cracked the 10g PL/SQL wrap mechanism or rather how he has found out the one missing bit of information (the substitution table). The 9i and lower wrap mechanism was shown by myself at BlackHat in 2006, i also hinted briefly at the 10g mechanism. My paper can be found on my Oracle security white papers page. David then detailed much more of the 10g wrap mechanism in his book the Oracle hackers hand book. He showed the mechanism/algorithm used but stopped at revealing the substitution table in his book.
Anton has done some research into finding the substitution table but not via reversing the binary but via a simpler method of comparing the clear text (from known PL/SQL) to the compressed text. This is then used to create a complete table that allows unwrapping of PL/SQL for 10g. He has also included some Java code to allow unwrapping of PLB files. This is some nice research. His post is called "Unwrapping 10G wrapped PL/SQL". Also of note is a paper mentioned in his post by three Israeli's http://webcourse.cs.technion.ac.il/236349/Spring2009/ho/WCFiles/final_report.pdf - (broken link) Automatic detection of vulnerabilities in wrapped packages in Oracle
Anton has done some research into finding the substitution table but not via reversing the binary but via a simpler method of comparing the clear text (from known PL/SQL) to the compressed text. This is then used to create a complete table that allows unwrapping of PL/SQL for 10g. He has also included some Java code to allow unwrapping of PLB files. This is some nice research. His post is called "Unwrapping 10G wrapped PL/SQL". Also of note is a paper mentioned in his post by three Israeli's http://webcourse.cs.technion.ac.il/236349/Spring2009/ho/WCFiles/final_report.pdf - (broken link) Automatic detection of vulnerabilities in wrapped packages in Oracle
Google hacking and Oracle database security audits
I have just returned from teaching my class "how to perform a security audit of an Oracle database" in Helsinki, Finland which was fun; having a ride back to the airport in Pasi's Subaru Impreza on icy roads was also fun! -
One of the areas I mention in the material of the course is the issue of google hacking, made famous by Johnny Long some years ago. A key issue for any site undertaking to secure their Oracle databases is containment of data and knowledge on a need to know basis of the databases, administration, problems and anything really that would help someone break into your Oracle database. I was just surfing Google for something else and saw a pdf of a paper by Emin Islam Tatli called "Google hacking for cryptographic secrets". The paper is around three years old but its a good overview of some of the techniques and the one thing I particularly noticed is the useful list of free tools to help people check their own sites. These include the Google hacking database, goolink, sitedigger and Gooscan.
This area is interesting for me, it is not Oracle database security specifically but as I said I always recommend clients do some basic surfing of the net on Google (but not just google, you should also check Metlink, Yahoo, MSN etc as well - or better a search aggregation site such as Dogpile) to test if any of their Oracle architecture is exposed to the net, or any meta data such as architetcure diagrams (physical and logical) or any details of the databases (IP, usernames, SID, Ports, passwords....), particularly are staff posting on forums, newsgroups, mailing lists etc and divulging details of your problems.
This is a worthwhile endevour in these days of people focusing on stealing data and identities. Anyone (someone inside your organisation perhaps) looking for an "angle" to steal your data is going to take the easy option and not only download exploits from the net using search engines to find them but also looking for details of your systems to aid the theft of that data.
Downloading some of the google security tools that use the GHD (Google Hacking database) and testing them against your own site is worthwhile - make sure that your own company policies allow security tools to be installed first though!
One of the areas I mention in the material of the course is the issue of google hacking, made famous by Johnny Long some years ago. A key issue for any site undertaking to secure their Oracle databases is containment of data and knowledge on a need to know basis of the databases, administration, problems and anything really that would help someone break into your Oracle database. I was just surfing Google for something else and saw a pdf of a paper by Emin Islam Tatli called "Google hacking for cryptographic secrets". The paper is around three years old but its a good overview of some of the techniques and the one thing I particularly noticed is the useful list of free tools to help people check their own sites. These include the Google hacking database, goolink, sitedigger and Gooscan.
This area is interesting for me, it is not Oracle database security specifically but as I said I always recommend clients do some basic surfing of the net on Google (but not just google, you should also check Metlink, Yahoo, MSN etc as well - or better a search aggregation site such as Dogpile) to test if any of their Oracle architecture is exposed to the net, or any meta data such as architetcure diagrams (physical and logical) or any details of the databases (IP, usernames, SID, Ports, passwords....), particularly are staff posting on forums, newsgroups, mailing lists etc and divulging details of your problems.
This is a worthwhile endevour in these days of people focusing on stealing data and identities. Anyone (someone inside your organisation perhaps) looking for an "angle" to steal your data is going to take the easy option and not only download exploits from the net using search engines to find them but also looking for details of your systems to aid the theft of that data.
Downloading some of the google security tools that use the GHD (Google Hacking database) and testing them against your own site is worthwhile - make sure that your own company policies allow security tools to be installed first though!
February 2009
- Details of a 10g PL/SQL Unwrapper available - 02/03/2009 by 02/03/2009
- New version of Fuzzor available - 02/04/2009 by 02/04/2009
- Interview with SearchSecurity about Slavik's new Fuzzor - 02/05/2009 by 02/05/2009
- Is it possible to steal data with just ALTER SESSION? - 02/06/2009 by 02/06/2009
- Attacking Oracle with Metasploit - 02/08/2009 by 02/08/2009
- Accessing Data Outside the data model - 02/09/2009 by 02/09/2009
- A new version of woraauthbf is available (The Oracle password cracker) - 02/11/2009 by 02/11/2009
Archives
Syndication
Powered by gm-rss 2.0.0
