Detection of Malicious User in Oracle 10g DBMS ... - Semantic Scholar

Int'l Conf. Security and Management | SAM'08 |

387

Detection of Malicious User in Oracle 10g DBMS and Cost of Elimination Md. Saifuddin Khalid, Md. Ruhul Amin School of Engineering and Computer Science, Independent University, Bangladesh, Dhaka, Bangladesh

Abstract - One major difficulty faced by organizations is the protection of data against malicious access. Six security mechanisms, namely, authentication, authorization, access control, auditing, encryption and integrity control are available in Oracle 10g database management systems (DBMS). These are implemented for protecting data. These typical database security mechanisms are not able to detect and handle many data security attacks. This research resulted identification of a new security vulnerability in Oracle 10g database, coined with the name, ‘Hidden User’. We propose a new mechanism for the detection of malicious transactions by the ‘Hidden User’ and simulate solutions. Keywords: Data security, database management systems, database searching, database scheduling, security.

1

Introduction

Information security, privacy and protection of corporate assets and data are of fundamental importance in any business [1]. Insecurity of company’s database system can harm both the company itself and the customer. Another important reason for database security is that an insecure database is not only harmful for the database itself, but also for the operating system and other trusted systems running on it. The intruders first get access in the database and then use powerful built-in database features to access to the local operating system and all other trusted system if the database has relationship with them. The Computer Security Institute’s (CIS) eighth annual Computer Crime and Security Survey reported on May 29, 2003 that corporations lost nearly $202 million due to security breaches [2]. In 2006, the 11th year of their survey, CIS published results based on the responses of 616 computer security practitioners in U.S. corporations, government agencies, financial institutions, medical institutions and universities. It identifies insider abuse of Net access to be 42%, unauthorized access 32%, and system penetration 15%, abuse of wireless network 14% and misuse of public web application 6% accumulates a large source of financial loss [2], which indicates vulnerability to database security

breaches and enforces strengthening database security for protection from intruders. Database security mechanisms [3] include but not limited to: authentication [3], authorization [4], access control [5], auditing [6], encryption [7], and integrity control [8]. Presently there are big concerns about database security. They are: “unauthorized data observation, incorrect data modification, and data unavailability [9]”. This research addresses these by implementing all available features of Oracle 10g database and attempted to break each by expert oracle users.

2

Problem Statement and Motivation

Significant number of the large corporate, banks and information management oriented organizations are presently using Oracle database [10]. Presently Oracle 10g is the most recent version of Oracle. According to many database security-certifying organizations, Oracle is the most reliable database software in terms of security issues [10]. However, significant amount of research has not been conducted to identify security flaws available after using patch updates given by Oracle. A study is to be conducted to implement all the security features available in Oracle database; possible options of breaking security issues of Oracle 10g are searched. This research attempted to detect the security loopholes of Oracle in the banking environment, as it is being used extensively in banking sector of Bangladesh, including the multinational banks. It was identified that some of the banks do not audit all users and even if audit records are stored those are not traced for identifying malicious users. Management tends to trust both the product and the DBAs. This motivated the researchers to question the reliability of the product.

3

Literature Review

There are two important components of IT security evaluations: The criteria, against which the evaluations are performed, and the schemes or methodologies, which govern how and by whom such evaluations can be officially performed [11]. Different security standards providing

388

Int'l Conf. Security and Management | SAM'08 |

organization provides database security levels, which have been described previously. Oracle has obtained many database security certificates. The Table I summarizes Oracle security evaluation accomplishments and work in progress [12]. Oracle has fully embraced the Common Criteria (CC) as its de facto evaluation criteria and shall thus, not participate in the TCSEC or the ITSEC any more. TABLE I ORACLE SECURITY EVALUATIONS [11] Product Oracle 8i

Release 8.1.7

Level EAL4

Criteria ISO15408

Oracle 8 Oracle 7 (CC) Oracle 7 (CC)

8.0.5 7.2.2.4.1 3 7.2.2.4.1 3

EAL4 EAL4

ISO15408 C.DBMS PP C.DBMS. PP

Trial EAL4

Platform Solaris 2.6, NT 4.0 NT 4.0 NT 3.51 NT 3.51

The evaluations provide the commercial product’s typical security capabilities. However, typical database security mechanisms are not able to detect and handle many data security attacks [13]. Therefore, organizations need to adopt database security policies and procedures to identify malicious activities.

4

Hidden User in Oracle DBMS

In most cases, Oracle security may be breached if all security patches are not installed. One can easily visit Oracle.metalink.com to identify probable security vulnerabilities and find solutions to those. To get these solutions or patches one must have a licensed copy. In this research, a new security breach has been found which is not known to the group of DBAs in the Oracle discussion forum or the Oracle vendor. Let this be called, access of “Hidden User.”

4.1

Creation of Hidden User

SYS is a user name, which is created by default, during installation of current versions of Oracle. This is the most powerful user of Oracle database administration. SYS is the only powerful user who can access all the resources of Oracle at any level. A “USER$” table contains all the information regarding all the users of Oracle database. SYS is the only user who has access to this table by default, i.e. from the time of installation. SYS user access is provided to all the DBAs of an organization. DBAs are Database Administrators who are responsible for different or same databases(s) created in Oracle. For maximum level of security for each database there are different SYS users, unique and singular for each database. SYS user having access to “USER$” table by default during creation of database, can also grant or assign access to any other user as SYS user and such enables them to have insert, delete, and update privilege to the “USER$”

table. Usually DBAs see the list of current users from the “DBA_USERS” view. Let us now consider that, A SYS user of one of the databases of a bank, who was employed as a DBA, has access to the “USER$” table, which holds all the information regarding database users. When he decided to switch the job, he played a trick to keep access to the database for realizing ill intention, without being caught. The trick is, he logs in as SYS user, creates a new user named “Sam,” whom he gives DBA privilege and all other privileges those he had during the service life. Now to create a hidden user named “Sam”, he deletes Sam’s record from “USER$” table. Then he leaves the job, but continues to have access to the database as a DBA, a probable threat to the database security with be massive power of database destruction. Interestingly, SYS user will not find the user name “Sam” in “USER$” table as it has been deleted or will not find the name in the view named “DBA_USERS”. Therefore, there is no way that any of the top level administrators of Oracle database to catch “Sam”.

4.2

Threats of Hidden User

A hidden user has access to database according to the access privileges provided by the user creator. If a hidden user has DBA privilege then he could even destroy the entire database. Including DBA role there are more than 100 different roles in Oracle 10g, which if given as privilege to a hidden user, will be able to perform anything and everything.

4.3

Explored Solution

It was found that restarting the database solves the problem. This is not an as easy task as it sounds. Oracle is such a database, which is not restarted or shut down even for decades. Without formal and direct order from top-most management Oracle server is not feasible to restart. For a medium size bank in Bangladesh it was found that there are 6000 ATM transactions per day, i.e. the number of ATM transaction probable per minute is approximately 5. Even if management agrees to restart the database, accepting the penalty, to remove the malicious hidden user, the question is when will the management decide to restart the database? Because even a SYS user, the ultimate super administrative power of Oracle cannot find an unexpected user from the “DBA_USERS” view or “USER$” table. Therefore, one has to find a way to detect a hidden user.

4.4

Detecting a Hidden User

One of the ways of detecting a hidden user in Oracle, is, audit by session. When a user login to the database a session is created for a user, recorded against his user name. This audit record per session includes the time of login and time of logout, application used to login, address of the machine from which the user has logged in etc. There is table in Oracle named “AUD$” where these records are stored. This audit by

Int'l Conf. Security and Management | SAM'08 |

389

TABLE III GROWTHS OF DATABASE SIZE AND NO. OF RECORDS

session is not done in all the organizations using Oracle database. The reasons are: x each session record takes 176 bytes x login time and logout time increases Assuming that audit by session is activated for all the users. In this case, for each login and logout all the preset details for each user login are stored as individual records in “AUD$” table. If user names existing in the “USER$” table are cross-checked with “AUD$” table by one-to-one basis, there would be some records with unknown user name. Therefore, following algorithm was followed for writing the PL/SQL script. x Count number of records per known user in the audit table x Sum number total number of records against known users x Count total number of records in audit table x If (total No. of records in audit table)  (total no. of records for known users) then x “Hidden user exists”, x Else “hidden user does not exist” x Delete records of known users from audit table [Note: for reducing search time] x Identify names in remaining records of audit table

4.5

Database Growth for Auditing Users and Hidden User Searching Time

For each audit by session record in the audit table, the storage requirement is 176 bytes. Table II shows a moderate size bank’s Oracle database’s number of different types of users, growth of database size and searching time required to find existence of a hidden user. The table is constructed based on a simulation of Oracle database 10g audit records and given user details. The computer system had Intel Pentium 4 with 3.0 GHz processor and 1 GB RAM, Windows XP Professional, and version 2002 with service pack 2. TABLE II SIMULATION OUTPUT FOR DATABASE GROWTH FOR AUDITING AND HIDDEN USER SEARCH TIME User Type No. of Users Login Freq. Record /day /day s/day ATM 130,000 6000 1 6000 Operator 1,000 1000 10 10000 DBA 30 30 30 900 Total 131030 16900 Table II shows that if audit by session is recorded each day for the given number of different users and associated frequency of logins per day 16,900 records will be created everyday, each of size 176 Bytes. Table III and Fig. I show the growth of database and searching time growth to find hidden user(s). Table III shows that at the end of one year the database will include audit record of 1021.18 MB i.e. 0.9972 GB.

Months

Size Of Record (MB)

Records

1

85.10

507000

2

170.20

1014000

3

255.29

1521000

4

340.39

2028000

5

425.49

2535000

6

510.59

3042000

7

595.69

3549000

8

680.79

4056000

9

765.88

4563000

10

850.98

5070000

11

936.08

5577000

12

1021.18

6084000

A PL/SQL script was on a database server of previously mentioned configuration, which took more than four minutes to find existence of hidden user from a total of 6084000 records created after one year. Since execution time is not a big problem and the hidden user search time shows a linear relationship with increase in number of months it does not pose any complexity in storing audit records. Job scheduling was programmed to run in after every five minutes to detect hidden user and delete audit records in case if hidden any ‘hidden user’ is not found. This is expected to reduce the risk of posed threat and saves space.

4.6

Recommendations

A ‘hidden user’ could be created even by mistake and for such all the DBAs must be informed and Oracle Corporation should take this responsibility. Periodic run of job scheduling for hidden user detection should be made as part of security policy as long as prevention process is not identified. Keeping separate system for storing audit records and detection process run in about every five minutes could be implemented. If a hidden user access is identified, the database should be restarted as early as possible, depending on the type of risk expected.

5

References

[1] E. Bertino and R. Sandhu, “Database Security-Concepts, Approaches, and Challenges,” IEEE Transactions on Dependable and Secure Computing, Vol. 2, No.1, pp. 2-19.

390

[2] Cyber Attacks Continue, but financial losses are down, Retrieved on Saturday, May 12, 2007, http://www.gocsi.com/press/20030528.html [3] J.G. Steiner, C. Neuman, And J.I. Schiller, “Kerberos: An Authentication Service for open network systems, “USENIX Conf . Proc., PP. 191-202, Dallas, Winter 1988 [4] E. Brtino, and p. Samarati, and S. Jajodia , “ Authorization in relational database management systems,” proc . First ACM Conf. Computer and Comm. Security, Fairfax, VA., Nov.1993 [5] TF. Lunt, “Access control policies for database systems,” Database security, II: Status and prospects, C.E. Landwehr,ed., north-Holand:Elsevier Science publisher B.V., pp.41-52, 1989. [6] Donald K. Burleson, Database Auditing for Risk Management and Regulatory Compliance Best Practices and New Methods, Retrieved on Saturday, May 12, 2007, [7] http://www.dba-oracle.com/art_lumigent_whitepaper.htm [8] Jingmin He and Min Wang, “Cryptography and Relational Database Management Systems,” ideas, p. 0273, 2001 International Database Engineering & Applications Symposium (IDEAS ’01), 2001 [9] Martin Rennhackkamp, Integrity Control, Retrieved on Saturday, May 12, 2007,http://www.dbmsmag.com/9608d17.html [10] N. Aaron, Oracle Database Security, Last Retrieved on Sunday, August 05, 2007, URL: http://www.infosecwriters.com/text_resources/pdf/Oracle_NAaron. pdf [11] Oracle and Navy, Retrieved on Saturday, May 12, 2007,http://www.dlt.com/oracle/pdf/NV_Navy_Tech/2-OracleDatabase-10g.pdf

[12] Security Standard levels of Oracle 10g, Last Retrieved on: 18 March 2007, URL: http://www.oracle.com/technology/deploy/security/seceval/p df/seceval_wp.pdf

Int'l Conf. Security and Management | SAM'08 |