Database security issues PETRA BILIĆ ALEXANDER SPARBER

Database security issues PETRA BILIĆ ALEXANDER SPARBER

Introduction Database security is one aspect of computer security It uses different information security controls to protect databases Information security controls appropriate to databases: Access control Auditing Authentication Encryption Integrity controls Backups Application security

Database security threats: privilege abuse database platform vulnerabilities SQL injection weak audit trail denial of service weak authentication backup data exposure database communication protocol vulnerabilities SQL rootkits

Privilege Abuse Idea: Access Control Restrict users to minimum required SQL operations and data Define access control mechanisms for each user (ACL) Issues Excessive Privilege Abuse Legitimate Privilege Abuse Privilege Elevation

Excessive Privilege Abuse impossible to keep access control list up to date lack of time lack of information Result: Large groups of users are granted generic default access privileges that far exceed specific job requirements May be abused for malicious purpose.

Excessive Privilege Abuse ACL semantics are too limited select * from AdminUsers where username='john' and password='secret' vs select username, password from AdminUsers

Prevention: Query-Level Access Control Query-Level Access Control select * from AdminUsers where username =? and password =? Normal Usage select * from AdminUsers where username = john and password = smith Detected Abuse select username, password from AdminUsers select * from AdminUsers where username = john and password = idontknow or 1=1 Use automated tool

Legitimate Privilege Abuse abuse of legitimate database privileges for unauthorized purposes Copy large amount of information from database: to trade data for money to have easier access vulnerable to Trojans, laptop theft, etc.

Prevention: Context based Database Access augment access control with context of query Take into consideration usage attributes: Client location (IP address, GPS location) Client type (application) Additional identity attributes (Operating System, OS username) Time of day Take into consideration the consequence Size of result set Query-Level Access Control

Privilege Elevation database platform software vulnerabilities stored procedures, built-in functions, protocol implementations, and even SQL statements Get administrator access privileges find out password convert access privileges from those of an ordinary user Prevention: Use strong authentication Keep software up to date Use query-level access control

Inference When users are able to piece together information at one security level to determine a fact from a higher security level. No good solution: Polyinstantiation Live with inference Flight ID Cargo Hold Content s Classification 1254 A Boots Unclassified 1254 B Guns Unclassified 1254 C Atomic Bomb Top Secret 1254 D Butter Unclassified

SQL rootkit (database rootkit) Operating Systems and Databases are quite similar in the architecture. Both of them have: Users Processes Executables Symbolic Jobs Links

Rootkits are stealthy tools used by hackers to control operating systems Completely unknown to the user, a hacker may install a rootkit by exploiting a vulnerability or cracking a password The rootkit may then be used to hide processes, redirect application I/O, alter specific application programming interfaces or, simply, take over user operating system

To install a simple database rootkit is very easy task, and once it s installed it can be very difficult to uncover It can be used to capturing passwords, stealing data, tampering with user accounts, or performing similar nefarious activities A SQL Server rootkit can take many disguises, but in its simplest form it can be a function whose logic has been subtly altered to return different results

There are several ways to implement SQL rootkits: Modify the (database) object itself Change the execution path Change the SQL statement via VPD PL/SQL Native

Detecting rootkits Generate a baseline of the repository or get the baseline from the vendor Compare the repository against a baseline Check the results of the comparison Checksums must be calculated externally because the internal MD5-checksum could be tampered

SQL Standard language for relational database management systems It consist of two main parts: DML and DDL Differences in syntax Description ORACLE MS SQL Server String length LENGTH DATALENGTH

SQL injection SQL injection is a code injection technique that exploits a security vulnerability occurring in the database layer of an application Very common and very popular attack because of his simplicity With SQL injection attacker is trying to insert his malicious SQL code into some database and force her to execute given command The average web application is attacked at least four times per month by SQL injection techniques.

Point of attack The attacker may input specifically crafted SQL commands with the intent of bypassing the login form barrier and seeing what lies behind it

SQL injection attack Two main steps: a) Discovering how the application handles bad inputs b) Start the real attack Asuming: SELECT field FROM table WHERE email = $email ;

Discovering how the application handles bad inputs SELECT field FROM table WHERE email = hacker@database.com ; If the attacker submit that there are 2 possibilities: 1. The application will first sanitize the input 2. The application will take the input from the attacker and immediately run it as part of the SQL

Start the real attack SELECT field FROM table WHERE field = something OR x = x ; Attacker could get prove that he is able to manipulate the query to his own ends.

SELECT field FROM table WHERE field = x AND email is NULL; -- ; The purpose of this query was to use a proposed field name (email) in the constructed query and find out if the SQL is valid or not If attacker get any kind of valid response like email is not recognized it means that he guessed the name of the field correctly

SELECT email, password, userid, name FROM table WHERE email = x AND 1=(SELECT COUNT(*) FROM tabname); -- ; Purpose of this query is to find out is the name of the table is valid Includes a lot of guessing

SELECT email, password, userid, name FROM users WHERE email = x AND users.email IS NULL; -- ; This query is executed in order to assure that table users is the table that is used in query This query only works for tables that are actually part of this query, not on any table that exists in database

Attacker can try find some users: SELECT email, password, userid, name FROM users WHERE email = x OR name LIKE %Bob% ; or drop entire table: SELECT email, password, userid, name FROM users WHERE email = x ; DROP TABLE users; -- ;

SQL injection prevention Access the database using an account with the least privileges necessary Install the database using an account with the least privileges necessary Ensure that data is valid Do a code review to check for the possibility of second-order attacks Use parameterised queries Use stored procedures Ensure that error messages give nothing away about the internal architecture of the application or the database