extensible and can be adapted to explore security flaws in any database systems. ... the flaw in security system before hackers exploit and make use of it.
An Extensible Framework for Detecting Database Security Flaws Tran Khanh Dang, Quynh-Chi Truong, Phuong-Ha Cu-Nguyen, Que-Nguyet Tran-Thi Advances in Security & Information Systems Lab Faculty of CSE, HCM University of Technology National University of Ho Chi Minh City, Vietnam {khanh, tqchi, phuongha, ttqnguyet}@cse.hcmut.edu.vn
Abstract: Knowing flaws existing in a database security system is very useful for database protection. Database security flaws come from various sources, not only from network, database management systems, but also from the way an administrator manages a database system. Even then, to the best of our knowledge, existing researches for detecting security flaws mostly focus on the network environment, but database security systems. In this paper, we propose a framework for detecting database security flaws. The proposed framework is extensible and can be adapted to explore security flaws in any database systems. Notably, with this framework we can easily define a new potential database security flaw and an effective method to probe and verify it. The prototype and experimental results with Oracle will confirm our approach’s effectiveness and efficiency. Keywords: Database/information security, database security flaws, database security scanner, penetration testing.
1 Introduction Data is the blood of all organizations so it must be protected from any violation. Information security in a database includes three main aspects [1], [10], [12]: secrecy, integrity, and availability. However, there is another aspect, called non-repudiation, should be concerned with when implementing a database, or any other, security system [4]. Therefore, database security requirements include a combination of four following aspects (cf. Figure 1): Confidentiality (Secrecy): Data should be protected from unauthorized disclosure. The need of keeping information secret comes from the data management in many cases, especially where data is high sensitive. It is the most important property that a secure database system must have. Integrity: Only authorized users are able to modify data. It refers to the correctness and truthfulness of data or resources.
Availability: Data is always available to the authorized users and application programs. Availability differs from the two previous security requirements as it relates to the ability to use database anytime of the users. An unavailable system can be considered as bad as no system at all. Therefore, it is also a vital property of database security.
Database security
Fig. 1. Four aspects of database security
Non-repudiation: the database is able to prevent the effective denial of an action. A non-repudiation system has the ability to prove the origin and delivery of transactions and data-at-rest changes. A database security flaw is one that violates any of the four aspects above of database security. Flaws of popular commercial DBMS can be found in many materials [3], [9], [10]. Although these flaws have been public or even well-known, not all administrators know about them and make necessary updates timely for their database security systems. Besides errors in DBMS itself, for example errors in some system packages, there are security flaws resulted from human mistakes. It could not deny that the heart of security system is people. Therefore, securing a database system should start from the human factor. Some examples illustrating human mistakes are lack of account and privileges management, and misusing security mechanisms such as selecting weak passwords that are easy to guess. This is the main reason why a database security scanner is necessary for all administrators. The scanner will find out most of the security flaws in the database system and show what should be adjusted to achieve a secure system. The rest of this paper is organized as follows: Section 2 briefly introduces previous work. Section 3 presents the main contribution of our paper, an extensible framework for detecting database security flaws. Next, section 4 introduces the prototype and preliminarily experimental results of our proposed framework with Oracle 10g. Finally, section 5 gives concluding remarks and presents future work.
2 Related Work There are many techniques used to detect flaws in database security system. However, the most popular and effective ones are data mining and pentesting (penetration testing) based techniques [5], [8], [13], [14], [15]. In [13], Harper and Jonas have
defined that data mining is the process of searching data for previously unknown patterns and often using these patterns to predict future outcomes. Thus, data mining can be applied to find out new and abnormal data patterns. However, it is difficult to do that because data mining usually needs a large volume of input data in order to bring out a good result. Pentesting [6], [7] is a well-known technique used to evaluate the database security system (or any other security systems) by simulated-intrusion. This technique performs the attack actively to the database security system. If this simulated-intrusion action is successful, this means that there is a flaw in the database security system. Otherwise, it is safe from this kind of attack. The target is to detect the flaw in security system before hackers exploit and make use of it. Although a pentesting solution is simple yet sound, the process of simulated-intrusion must be under control because it can harm the running system. Beside technologies, there are also some commercial systems related to detecting flaws in database security. Notably, Guardium [11] provides a solution to protect data in real time, audit, report, and manage all transactions on database. Thanks to the support of special hardware, Guardium is independent to the DBMS. The disadvantage of Guardium is that the special hardware is required and it does only detect existing security flaws, but not allow users to define and verify new potential security flaws. In section 3, we will present our extensible framework for detecting database security flaws, which addresses these disadvantages.
3 The Framework The goal of our research is to build an extensible framework to scan security flaws in any database systems. Through the result of the scanner, an administrator can determine what flaws are existing in his system and how he can fix them to protect the database. The extensibility feature is to allow users to enlarge the security flaws’ definition repository. According to the above purpose, our framework includes the following core functions: Scanning flaws based on users’ requirements Specifying new potential flaws and the method to detect them Generating report and suggesting solutions In this section, we introduce our approach and the details of this vanguard framework for database security systems.
3.1 An Effective Method for Identifying Database Security Flaws As mention before, pentesting is a simulated-intrusion technique, a method of finding flaws in database security system by trying to attack actively to the system. We choose it as the default method to incorporate into our framework because of its advantages. Pentesting procedure consists of four basic steps (cf. Figure 2): Step 1: Before the tester makes contact with the database to be examined, it should
collect as much information about the DBMS as possible: DBMS vendor, version, port used to communicate, etc. Step 2: The main purpose of this step is to use the information found in the previous step in order to identify security flaws related to the system. Step 3: The scanner will simulate intrusion to the system. It tries to attack the system as the way an attacker does. If the simulation is successful, a flaw exists in the database security system. However, it differs from a genuine intruder: the scanner will not actually install any harmful functions or procedures and will not read or modify any internal data. Step 4: The scanning tool generates a report about all flaws have been detected at the previous step. The report also includes possible solutions for each flaw. Collect information
Identify weakness or flaws
Simulate intrusion
Show results
Fig. 2. Four basic steps of pentesting procedure
We will apply these four steps in our framework to investigate database security flaws. Section 3.3 will elaborate on this approach.
3.2 An Extensible Framework for Detecting Database Security Flaws The framework architecture, as illustrated in Fig. 2, consists of four main layers. The functions of these layers are as follows: User Interface Layer interacts with users, gets requirements for scanning process and specifying process, and shows the results or reports about flaws existing in database security system. Function Layer performs main functions of framework, including scanning, specifying, and reporting. Supporting Layer supplies libraries to assist Function Layer, and plays an intermediary role between Function Layer and Database Layer. Database Layer stands for security flaws’ definition repository, which stores security flaw information, test scripts, and related data. Among these layers, the Function Layer is the most important item because it performs the main tasks of this framework. The rest of this section will explain more detail about the processes of the Function Layer. Specify process is to specify a new potential security flaw of a certain version of DBMS and write a script to test whether it actually exists or not. This module interacts with other modules such as Template Library, SQL Function Library, Script Editor, and the Security Flaw Repository. Repository stores all necessary information about security flaws. Template Library, SQL Function Library and Script Editor assist users in writing test scripts more conveniently. Template Library provides templates for users to define a script. SQL Function Library provides functions and procedures
for users to write a script. Users can gradually enlarge these libraries. Script Editor is an editor used to write test scripts and declare parameters, which is marked by the notation “ ` ”. A test script for a security flaw is a piece of code, which is written in SQL and contains some parameters.
Fig. 3. A general and extensible framework for detecting database security flaws
Scan process is to determine if the database security system contains flaws. First, users must provide necessary information for scanning process. This process collects these requirements from Interface Layer and transfers them to Temporary File Generator. Then, Temporary File Generator creates intermediate scripts (*.sql). Basically, intermediate scripts are test scripts, in which all the parameters are replaced with the existing or user-provided values. This framework calls Execute SQL Engine to execute these scripts. The scanning results are stored in Security Flaw Repository and used for generating reports. To build a DBMS-independent scanner, when scanning a DBMS, Execute SQL Engine uses the command line utility of that DBMS. There are two scanning modes: a user-defined mode in which users choose some flaws to scan, and an automatic mode where all concerned flaws will be scanned automatically. Report process gets results from scanning process that stored in Security Flaw Repository, analyses the data based on some users’ criteria. Then it generates statistical reports with helpful solutions to protect database security systems.
3.3 Test Script Format Scripts are the main means to attack database with respect to the pentesting technique. They are written in Structured Query Language (SQL). SQL is familiar with all users who have some basic knowledge about database theory so it makes users convenient. There are a number of different scripts used to find out different flaws. Sometimes, the variety of scripts may bring trouble to users. Therefore, it is necessary to have a general structure for all scripts. A script used in our proposed framework should have four following parts: Preparing: in this part should be a piece of script that creates some database objects necessary such as accounts, tables, functions and procedures. Attacking: execute one or more procedures to exploit the security system flaws. Checking and writing result: check if the attack is successful or not, and then write the result to a file Recovering: after attacking, the system must keep the context as it was before. Therefore, the duty of this part is to recover the database such as deleting the temporary database objects created before. The four steps are set up according to the pentesting mechanism. A script should obey the order of these stages to ensure the advantages of pentesting, which are scanning security flaws precisely and safely.
4 A Prototype System with Oracle This prototype is built to detect the Oracle database security flaws [2], [3], [9]. We will present the process from specifying to scanning in detail to make our framework clearer. The following is an example of a process detecting a flaw in Oracle 10g: SQL Injection via an Oracle built-in package. Oracle provides the DBMS_METADATA package that includes function GET_DDL to get the metadata for a single object as DDL. By default DBMS_METADATA.GET_DLL function has EXECUTE permission to PUBLIC so any user can exploit this flaw. Exploitation of this flaw allows an attacker to execute arbitrary code. 4.1 Specify Process We assume that this flaw is a new one and not in our Security Flaw Repository. To verify this flaw, users have to define it and its test script. The specify process goes through the following steps (cf. Figure 4): Step 1: Users must specify an instance of DBMS’s version, to which this flaw belongs. If it does not exist in our Security Flaw Repository, users have to define connection script pattern to connect to a certain database of that DBMS. Otherwise, skip this step. In Oracle 10g, the connect script is:
sqlplus `Username/`Password@`Database @`ScanFileName where parameters `UserName, `Password, and `Database are information to identify and authenticate to the database, `Database is name of the database instance users want to connect, and `ScanFileName is the intermediate script *.sql files created by Temporary File Generator.
Fig. 4. Specify process
Step 2: Users provide information about the security flaw, such as flaw type, risk level, solutions, and so on. Step 3: Users write a test script by using Script Editor. Here, users can refer to templates and use functions in the library. Users can also declare parameters in this test script. There are some special parameters without declaration; those are `Username, `Password, `Database with respect to username, password, and database name. Below is an example test script for this flaw: -- Prepare context CREATE USER hacker IDENTIFIED BY hacker; GRANT CREATE SESSION TO hacker; CONNECT hacker/hacker@`Database; CREATE OR REPLACE FUNCTION "HACKER"."ATTACK_FUNC" RETURN VARCHAR2 AUTHID CURRENT_USER AS PRAGMA AUTONOMOUS_TRANSACTION; BEGIN EXECUTE IMMEDIATE 'GRANT DBA TO HACKER'; COMMIT; RETURN ''; END;
-- Inject the function in the vulnerable procedure BEGIN SELECT SYS.DBMS_METADATA.GET_DDL('''|| HACKER.ATTACKER_FUNC()||''','') FROM dual; END; -- check if hacker has dba role CONNECT `Username/`Password@`Database; DECLARE num NUMBER; BEGIN SELECT count(*) INTO num FROM DBA_ROLE_PRIVS WHERE granted_role='DBA' AND grantee=‘HACKER'; IF (num > 0) THEN WRITE_RESULT(true); ELSE WRITE_RESULT(false); END IF; END; -- recover DROP USER hacker CASCADE;
After this flaw and its test script are defined, it is ready for the next procedure. Users can check whether the flaw exists in the database security system due to the scanning process.
4.2 Scan Process The scan process consists of three steps below (cf. Figure 5): Step 1: Users input values for related parameters of the test script. Besides, user must also provide identification and authentication information, which are defined in Oracle 10g connection script. Then, the Temporary File Generator generates corresponding temporary test scripts for scan process. Step 2: With the connection script and temporary test script, the Temporary File Generator creates an executable file, which will call sqlplus.exe to execute all temporary test scripts. For example, users inputs sysman as `UserName, orcl as `Password, orcl as `Database, and flaw1_temp1.sql as `ScanFileName. Then the executable file’s content is: sqlplus sysman/orcl@orcl @flaw1_temp1.sql. Step 3: Scanning function runs this executable file. After simulating attack finished, i.e. all temporary test scripts have been executed, these files must be deleted because they may contain sensitive data. Finally, Report module gets and analyzes the scanning results, then displays them to users.
Fig. 5. Scan process
Using this prototype system and similarly to the above example, we have already deployed to probe most of known database security flaws in Oracle 10g which are public on Oracle exploits website [9]. The prototype works well with Oracle 10g and brings desired results.
5 Conclusion and Future Work Our proposed research offers an effective framework for detecting database security flaws. This framework is extensible because it supports users to define new potential flaws by providing an extensible library of general templates of test scripts. More importantly, our approach is independent of the DBMS, so that it can perfectly work with all commercial DBMS. To the best of our knowledge, such a framework, which do not employ any special hardware, is among the vanguard research results in the database security area. Based on the new proposed framework, we have also implemented a prototype system to define and scan all known database security flaws in Oracle 10g. The preliminarily experimental results have shown that our approach is effective while the system performance has not been much affected. In the future, we have planned to carry out extensive experiments in order to establish the practical value of our vanguard proposed framework. Besides, combining other technologies, e.g., auditing and data mining techniques, to detect new potential flaws is also of our great interest in the future research activities. Last but not least, studying the impact on the system performance with our “without special hardware” approach will also be an interestingly challenging issue.
Acknowledgments We are grateful to all members of “Advances in Security & Information Systems Lab” (ASIS Lab) for their supports and advices to our work.
References 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
13. 14. 15.
Castano, S., Fugini, M.G., Martella, G., Samarati, P.: Database Security, AddisonWesley (1994) Marlene, L., Theriault, M., Newman, A.: Oracle Security Handbook, Oracle Press (2001) Knox, D.: Effective Oracle Database 10g Security by Design, Oracle Press (2004) Bishop, M.: Introduction to Computer Security, Prentice Hall PTR (2004) Litchfield, D., Anley, C., Heasman, J., Grindlay, B.: The Database Hacker's Handbook - Defending Database Servers, Wiley Publishing Inc (2005) James, S.T.: The Ethical Hack – A Framework for Business Value Penetration Testing, CRC Press LLC (2005) Auerbach Publications: Information Security Handbook, CRC Press LLC (2005) Yovits, M.C.: Advances in Computer, Vol. 38, Academic Press (1994) OracleExploits: http://www.red-database-security.com/exploits/oracle_exploits.html SecurityFocus: http://www.securityfocus.com Guardium: http://www.guardium.com Dang, T.K., Le, T.T.H., Truong, D.T.: An Extensible Framework for Database Security Assessment. In Proceedings of the 9th International Conference on Information Integration and Web-based Applications & Services (iiWAS2007), OCG Press, Jakarta, Indonesia (2007), pp. 419-425 Jonas, J., Harper, J.: Effective Counterterrorism and the Limited Role of Predictive Data Mining, URL: http://www.cato.org/pubs/pas/pa584.pdf (2006) Jaquith, A.: Security Metrics-Replacing Fear, Uncertainty, and Doubt. Addison-Wesley (2007) Brancik, K.C.: Insider Computer Fraud-An In-Depth Framework for Detecting and Defending against Insider IT Attacks. Auerbach Publications (2008)
