Database System Security

Paul Wagner, [email protected] UW-Stout Information and Cyber Security Workshop 8/24/2006

Background
Need

Security curriculum is relatively light in database systems area

Focus currently on protecting information through network configuration, systems administration, application security Need to specifically consider database system security issues

Background (cont.)
Goals

Understand security issues in:

a general database system environment a specific DBMS (Oracle) environment

Consider database security issues in context of general security principles and ideas Consider issues relating to both database storage and database system communication with other applications

Main Message
Database system security is more than securing the database

Secure database Secure DBMS Secure applications / application development Secure operating system in relation to database system Secure web server in relation to database system Secure network environment in relation to database system

Secure databases
Database a domain-specific collection of data; e.g. an Employee database Historical database security topics and issues

Users, Passwords
Default users/passwords

Oracle: sys, system accounts privileged (Oracle 8i and prior - with default passwords) Oracle: scott account well-known account and password, part of public group e.g. public can access all_users table general password policies (length, domain, changing, protection)

Secure Databases (cont.)

Privileges, Roles, Grant/Revoke

Privileges

System - actions Objects data Collections of system privileges Giving (removing )privileges or roles to (from) users

Roles

Grant / Revoke

Secure DBMS
Database Management System (DBMS) the domainindependent set of software used to manage and access your database(s) Possible Holes in DBMS

http://technet.oracle.com/deploy/security/alerts.htm (50+ listed) Majority of problems - buffer overflow problems in (legacy) DBMS code Miscellaneous attacks (Denial of Service, source code disclosure of JSPs, others) Oracle example - UTL_FILE package in PL/SQL
allows read/write access to files in directory specified in utl_file_dir parameter in init.ora possible access through symbolic links

Secure DBMS (2)

Need for continual patching of DBMS

Encourage awareness of issues, continuous vigilance Cost of not patching

SQL Slammer Worm - ~100,000 systems affected

Secure DBMS (3)

US-CERT advisories

List of major software packages currently watched includes Oracle

Secure Application Development

Access to Oracle Database or Environment Through Applications Need to consider security of applications using database as well as security of data in database itself Example: SQL Injection Attack

SQL Injection
SQL Injection

Definition inserting malicious SQL code through an application interface

Often through web application, but possible with any interface

Typical scenario
Three-tier application (web interface, application, database) Overall application tracks own usernames and passwords in database (advantage: can manage users in real time) Web interface accepts username and password, passes these to application layer as parameters

SQL Injection (2)

Example: Application Java code contains SQL statement:

String query = "SELECT * FROM users_table " + " WHERE username = " + " " + username + " " + " AND password = " + " " + password + " " ;

Note: String values must be single quoted in SQL, so application provides this for each passed string parameter Expecting one row to be returned if success, no rows if failure Common variant SELECT COUNT(*) FROM

SQL Injection (3)

Attacker enters:
any username (valid or invalid) password of: Aa OR =

Query becomes: SELECT * FROM users_table WHERE username = anyname AND password = Aa OR = ; Note: WHERE clause => F and F or T => F or T => T
AND has higher precedence than OR

All user/pass rows returned to application If application checking for 0 vs. more than 0 rows, attacker is in

SQL Injection - Prevention

Whats the problem here?

Not checking and controlling input properly

Specifically, not controlling string input

Note: there are a variety of ways SQL injection can happen

Regular inclusion of SQL metacharacters through

Variable interpolation String concatenation with variables and/or constants String format functions like sprintf() String templating with variable replacement

Hex or Unicode encoded metacharacters

SQL Injection Prevention (2)

How to resolve this?

First (Attempted) Solution: Check Content

Client code checks to ensure certain content rules are met Server code checks content as well Specifically dont allow apostrophes to be passed Problem: there are other characters that can cause problems

-; %

// SQL comment character // SQL command separator // SQL LIKE subclause wildcard character

Which characters do you filter (blacklist) / keep (whitelist)?

SQL Injection Variant 1

Any username, password: or 1=1-

Note: -- comments out rest of line, including terminating single quote in application

Query becomes: SELECT * FROM users_table WHERE username = anyname AND password = OR 1=1--;

SQL Injection Variant 2

Any username, password: foo;DELETE FROM users_table WHERE username LIKE % Query becomes: SELECT * FROM users_table WHERE username = anyname AND password = foo; DELETE FROM users_table WHERE username LIKE % Note: system executes two statements

SELECT * FROM users_table WHERE username = anyname AND password = foo; // returns nothing DELETE FROM users_table WHERE username LIKE %

SQL Injection Variant 3

ODBC allows shell injection using | character

|shell(cmd /c echo & char(124) & format c:)|

Similar issue exists with MS SQL Server Extended Stored Procedures

SQL Injection Variant 4

Second-Order SQL Injection

User creates account with user = root-Application escapes and inserts as root-User resets password Your query fetches username from database to verify account exists with correct old password UPDATE users_table SET PASSWORD=pass WHERE username = root-- NOTE: above scenario allows user to reset the password on the real root account

SQL Injection Prevention (3)

Second (better) solution

Use Prepared Statements instead of regular Statements in your SQL code Regular Statements
SQL query is generated entirely at run-time Custom procedure and data are compiled and run

Compilation allows combination of procedure and data, allowing problems with SQL metacharacters

String sqlQuery = null; Statement stmt = null; sqlQuery = "select * from users where " + "username = " + "'" + fe.getUsername() + "'" + " and " + "upassword = " + "'" + fe.getPassword() + "'"; stmt = conn.createStatement(); rset = stmt.executeQuery(sqlQuery);

SQL Injection Prevention(4)

Prepared Statements
SQL query is precompiled with placeholders Data is added in at run-time, converted to correct type for the given fields

String sqlQuery = null; PreparedStatement pStmt = null; sqlQuery = "select * from users where username = ? and upassword = ?"; pStmt = conn.prepareStatement(sqlQuery); pStmt.setString(1, fe.getUsername()); pStmt.setString(2, fe.getPassword()); rset = pStmt.executeQuery();

SQL Injection Prevention (5)

Issues with PreparedStatements

Cannot use them in all situations

Generally limited to replacing field values in SELECT, INSERT, UPDATE, DELETE statements

E.g. our use for username field value, password field value

Example: if also asking user for information that determines choice of table name, cannot use a prepared statement

SQL Injection Prevention (6)

Additional Precautions

Do not access the database as a privileged user

Any user who gains access will have that users privileges

Limit database user to only what they need to do

e.g. reading information from database, no insert/update/delete

Do not allow direct access to database from the internet

Require users to go through your applications

Do not embed database account passwords in your code

Encrypt and store them in a repository that is read at application startup

Do not expose information in error messages

E.g. do not display stack traces

Other Application Issues

Be aware of how information is transmitted between client applications and database Research Project at UWEC

Most common client applications (vendor-supplied or user-programmed) at least encrypt the connection password Some clients encrypt the connection user Certain DBMSs have varying levels of security (e.g. PostgreSQL) One DBMS transmits the connection password length (MS SQL Server 2005 Express)

Secure Application Development

Application Security in the Enterprise Environment

J2EE JDBC, Servlets, JSPs, JNDI, EJBs, .NET many components Assume network filtering most evil traffic Application can control fine-grain behavior, application protocol security

Use of Proxy Applications

Secure Application Development (cont.)

Security Patterns (from J2EE Design Patterns Applied)

Single-Access Point Pattern

single point of entry into system

Check Point Pattern

centralized enforcement of authentication and authorization

Role Pattern
disassociation of users and privileges

Secure Operating System

Interaction of Oracle and OS

Windows
Secure administrative accounts Control registry access Need good account policies Others

Secure Operating System (cont.)

Linux/Unix
Choose different account names than standard suggestions Restrict use of the account that owns Oracle software Secure temporary directory Some Oracle files are SUID (root) Command line SQL*Plus with user/pass parameters appears under ps output Others

Secure Web Server

Interaction of Oracle and Web Server Apache now provided within Oracle as its application server, started by default Apache issues

Standard configuration has some potential problems

See Oracle Security Handbook for more discussion

Ensure secure communication from web clients to web server Use MaxClients to limit possible connections Others

Secure Web Server (cont.)

Internet Information Server (IIS) issues

Integration with other MS products (e.g. Exchange Server) Many known vulnerabilities over recent versions (patches available) Others

Secure Network
Interaction of Oracle and Network

Oracle Advanced Security (OAS) product

Features for:

Authentication Integrity Encryption use of SSL

Oracle server generally behind firewall

Good to separate DB and web servers Connections normally initiated on port 1521, but then dynamically selected

Other Network Issues To Consider

Possibility of hijacking a sys/sysmgr connection Various sniffing and spoofing issues

Miscellaneous Issues
Newer Oracle Security Features

Virtual Private Databases (VPDs) Oracle Label Security Good policy: develop a comprehensive audit system for database activity tracking
Can write to OS as well as into database for additional security, accountability for all working with databases

Auditing

Exercise
Overall Security Examination of Oracle in Networked Environment

1) Database: Set up Oracle client, test known database for:

Privileged access through sys or system accounts Public access through scott, other known/discovered usernames

2) DBMS: Check for known vulnerabilities

Check overall system level, patch level Test for specific problems from Oracle list

3) Application:
Test for SQL Injection, other application weaknesses

Exercise (cont.)

Similar types of tasks for OS, Web Server, Network components Task: develop report, including specifics for all areas

References
Oracle Security Handbook by Theriault and Newman; Osborne/Oracle Press, 2001. Oracle Database Administration: The Essential Reference, Kreines and Laskey; OReilly, 1999. Pete Finnigans Oracle Security web site, http://www.petefinnigan.com/orasec.htm James Waldens SIGCSE 2006 workshop on Software Programming Security: Buffer Overflows and Other Common Mistakes Eric Lobner, Matthew Giuliani, Paul Wagner; Investigating Database Security in a Network Environment, paper published at MICS 2006, www.micsymposium.org