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.
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:
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.
There has been 5 Comments posted on this article
Simply connect PFCLScan to your Oracle database and it will automatically discover the security issues that could make your Oracle database vulnerable to attack and to the potential loss of your data.
PFCLObfuscate is the only tool available that can automatically add license controls to your PL/SQL code. PFCLObfuscate protects your Intellectual Property invested in your PL/SQL database code.
PFCLTraining is a set of expert training classes for you, aimed at teaching how to audit your own Oracle database, design audit trails, secure code in PL/SQL and secure and lock down your Oracle database.
Choose PFCLServices to add PeteFinnigan.com Ltd to your team for your Oracle Security needs. We are experts in performing detailed security audits, data security design work and policy creation