Download Dealing with threats to databases

Dealing With Threats to
Databases
OWASP
Sandeep Singh Nain
Security Analyst, IBM Australia
[email protected]
+61-405-369420
AppSec 2008, Australia
February, 2008
Copyright © The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document
under the terms of the OWASP License.
The OWASP Foundation
http://www.owasp.org
About Me
OWASP Member
 Melbourne chapter
Security Analyst
 IBM Australia (www.ibm.com/services/security)
Background
 Application development (ASP, .NET, PHP)
OWASP
2
Agenda
Introduction
Threats to databases
From applications
From configuration flaws
Database rootkits
Auditing and activity monitoring
Questions and answers…
OWASP
3
Introduction?
Every organization has one or more databases
FINANCIAL DATA
CUSTOMER DATA
SENSITIVE INFO
WHICH MUST BE PROTECTED
OWASP
4
Question: Is the protection secure enough???
OWASP
5
A common scenario
And the database is fully secure…
Database security is not limited to firewalls, IPS or IDS…
OWASP
6
The Real Threat
Database trusts the applications and users
interacting with it
OWASP
7
Threats to Databases
from
Applications
1. Application Code Exposure
OWASP
8
Application code exposure
 Attackers / malicious users analyze the
 URL and error messages
 Application code
to determine
 What platform is being used
 What business rules are in place
 And, How is database being accessed i.e.
 connection strings, actual SQL queries etc.
 Helps in launching the database attack
 Directly
 Or through application
OWASP
9
Application Configuration Files
Holds connection details
Contains database server name
And username and password to connect to database
Is it stored securely?
OWASP
10
Application Configuration Files
Huh, Attackers won’t find my configuration file
Why don’t you ask my friend Google
 *Search for
ext:php intext:"$dbms""$dbhost""$dbuser""$dbpasswd""$table_prefix""phpbb_installed“
– (This will search for the configuration files for phpBB, a popular
`php` based bulletin board)
*http://johnny.ihackstuff.com/
OWASP
11
Anatomy of Application Configuration Files
Options to store configuration files
Web.config and global.asa files
UDL files
Registry
Include text files
Hard coding connection string
For microsoft technologies
For all
OWASP
12
Suggestions
 Use windows authentication or LDAP authentication (if
possible) to connect to database over a secure
channel
 Never store the username and password in clear text
 Encrypt the configuration files
 Use DPAPI (for windows 2000 and above)
 Create a baseline
 Monitor the database connections being made
 Make a list of IP Addresses and applications which should be
allowed to access the database
 And deny access to others using a good SQL firewall
OWASP
13
Protecting the code
 Code obfuscation
 Provides security through obscurity
 Converting the intermediate code into a form that makes reverse
engineering very difficult (not impossible though)
 Add code to break decompilers
 Use tools e.g. DashO and HoseMocha for java.
 Don’t store application code in unsecured environments
 Security of development and test environments is as necessary
as of the production environment
 Patch the development and test environments regularly
OWASP
14
Threats to Databases
from
Applications
2. SQL Injection
OWASP
15
SQL Injection
 Famous attack
 September 2004
 The Cardsystems breach incident, where hackers stole 263,000
credit card numbers
 Several million dollars fraudulent credit and debit purchases had
been made with these cards
Ref: http://www.webappsec.org/projects/whid/list_id_2004-17.shtml
 What is it?
 Injecting SQL commands in URL or Form fields (GET or POST
data) to alter the result
 Most effective and popular attack
 Approx 23% of the successful attacks (in 2006)
OWASP
16
SQL Injection
Can be used to
Bypass authentication
– Select USERID from USER where USERID = `` or 1=1; -- and
password=‘a’;
Access sensitive data
– Select username, address, phone from USERS where city=‘Mel’
UNION ALL select name, crdate from sysobjects where
xtype=‘U’
Even shutting down a system
– Select USERID from USER where USERID = ``; SHUTDOWN
with NOWAIT -- ;
And more…
OWASP
17
SQL Injection
Applicable to all the DBMS
SQL Server, Oracle, DB2, Sybase , MySQL & more
Vulnerability lies in the application code and not on
the database server
OWASP
18
SQL Injection
Countermeasures
Limiting application vulnerabilities
 Find the vulnerability and fix the code
 All input must be sanitized
 SQL used to access data must not be formed by string
concatenation
 Prepared statements and parameterized stored procedures
must be used wherever possible
 Add quotes to all user input including numerical data
 Don’t display the database generated error messages
OWASP
19
SQL Injection
Don’t trust the application
 Filter every SQL command sent by the application
– Don’t let application issue any OS level commands
Provide minimal data access
 Granular access control
Create baseline and monitor
 What database objects are being used by the application?
 What commands are being used?
OWASP
20
Threats to Databases
from
Applications
3. Buffer Overflows
OWASP
21
Buffer Overflows
 Database systems are software products
 Just like any other systems they also have vulnerabilities
 Such as buffer overflows
 Risk of buffer overflow
 May allow an unauthorized user to gain root privileges to the
host operating systems.
 Denial of service
 A number of buffer overflow vulnerabilities have been
found in database systems
 Oracle (8, 8i, 9i), SQL Server (7, 2000), DB2 (8.2, 9.1)
OWASP
22
Buffer overflow in system functions / extended
stored procedures
 What is it?
 Injecting an extra long string as a parameter to the system stored
procedures / functions allowing overwriting of the memory buffer with
arbitrary data
 Can be exploited through SQL injection
 Examples
 MS SQL Server: xp_displayparamstmt , xp_proxiedmetadata
 Oracle: BFILENAME, NUMTODSINTERVAL
 Vulnerable servers
 MS SQL Server 7, MS SQL Server 2000, MSDE 1.0, MSDE 2000
 Oracle 8i, 9i
Ref: http://www.appsecinc.com/resources/alerts/mssql/02-0000.html
OWASP
23
Countermeasures
Apply latest patches ASAP
remove or minimize the application’s access to the
vulnerable function
Protect from SQL injection
OWASP
24
Threats to Databases
from
Configuration Flaws
1. Improper Access Control
OWASP
25
Improper access control
Common scenario
Database schema is considered as a part of the
application
Or, Extension to the application
 Therefore, should be controlled by the application itself
– i.e. application has full access to all objects in the schema
Risk
Any security breach that occurs at the application
layer can become a security incident at database level
OWASP
26
Granular access control
Limit application access
Implement fine grained access control (row level
access, table level access)
Make sure database control is at database layer and
not application layer
Create database access baselines
OWASP
27
Threats to Databases
from
Configuration Flaws
2. Insecure Database Links
OWASP
28
Insecure database links
Linked databases
Expose objects in one database to another
Clients can connect to one database and fetch the
data stored in linked database without even knowing
the actual location of the data
Being used in a lot of enterprise applications and
architectures
SO WHAT’S THE PROBLEM???
OWASP
29
Insecure database-to-database communication
Limited access
Full access
OWASP
30
Securing the database to database communications
Never create the links using administrative
privileges
Avoid fixed user links
 Use current user links instead
Monitor the database link usage regularly
Not just the connections but also the content being
communicated
 Only the authorized data should be communicated
OWASP
31
Threats to Databases
from
Configuration Flaws
3. Database doing more than required
OWASP
32
Database doing more than required
Vendors are adding functionalities like
Running shell commands
Inbuilt Web server
HTML Page generation
HTTP endpoints
Helpful but dangerous
Opens up unnecessary attack surface
Let database handle what it is intended to.
 Security vs. Ease
OWASP
33
Threats to Databases
from
Configuration Flaws
4. Unencrypted Data
OWASP
34
Unencrypted Data
 Databases contain
 Confidential and proprietary information
 Therefore, unauthorized database access may lead to
 Privacy breach incidents
 Identity thefts
 How to protect
 Encrypt the confidential data
 Encrypt the data in transit
 Encrypt the data at rest
OWASP
35
Encrypting data in transit
 What to encrypt
 Whole (or parts of the) data in transit is encrypted
 How to encrypt
 Encryption/ Decryption occurs at end points
 Data stored in the database is not encrypted
 Use
 SSL, SSH Tunnels
 Why to encrypt
 protects from MITM attack
 Protects from data being sniffed
 Tools : Ethereal, TCP Dump
OWASP
36
Sniffing the data in transit
User ID
Database name
MS SQL Server traffic
OWASP
37
Encrypting Data at Rest
What to encrypt
Sensitive data stored in the database
 E.g. Credit card info, SSN, passwords etc.
The whole database
Why to encrypt
Additional layer of security
 Protects from unauthorized access
 Can’t be decrypted (easily)
 Unauthorized users can’t read the data even if they have
Administrator access
OWASP
38
Encrypting Data at Rest
 How to encrypt
Encryption at application layer
Using the database encryption tools
 Encryptonizer for MS SQL Server
 Encryption wizard for Oracle
 IBM Database encryption expert for DB2
Encryption at File System layer i.e. file level
encryption
 EFS for NTFS(MS Windows 20000 and above), IBM’s
Encryption Facility for z/OS
 FreeOFTE, DiskCryptor (Open source)
OWASP
39
Database Rootkits
OWASP
40
Database rootkits
 What are rootkits
 A rootkit is a collection of programs that enables and maintains
the administrator-level access to a computer or computer
network
 DB rootkits are similar to OS rootkits
 Purpose
 To create backdoors in databases
 To hide database processes
 To hide database users
 To hide database jobs
 Modify internal functions
OWASP
41
Database rootkits
 Implementation
By modifying the database (system) objects
Changing the execution path
 Creating a local object with the identical name
 Creating a synonym pointing to a different object
OWASP
42
Countermeasures
Use base tables instead of views for critical
objects (e.g. users, processes)
Use absolute execution paths for critical objects
(e.g. SYS.dbms_crypto)
Compare the repository regularly against a
(secure) baseline
For more on rootkits
http://www.red-database-security.com/wp/db_rootkits_us.pdf
OWASP
43
Auditing
and
Activity Monitoring
OWASP
44
Auditing
Is a
Way to ensure proper controls are in place
Ensures compliance
Is not
A method to secure systems
 But tells you what is not secure
 Or what may result in an incident so that you can investigate
OWASP
45
Audit categories
Security assessment (Not covered)
Vulnerability assessment
Penetration testing
Activity monitoring (Using the audit trail)
Helps to identify illicit activity from insiders
(authorized users)
Helps to address unknown threats
Helps in being pro-active rather than reactive
OWASP
46
Audit trail
It answers the questions
Who did it?
What did they do?
When did they do it?
OWASP
47
Audit trail implementation – Must Monitor Events
 DBA actions
 DDL statements, Administration commands
 Access to sensitive data
 Database system tables
 As defined in the organization’s policies
 After hours access
 Remote Administration
 Known attacks
OWASP
48
Deployment considerations for Audit trail
Coverage v/s Volume
Only store useful information
False positives
Too many unnecessary alerts
Integrity of the audit trail
No one should be able to modify the audit trail
Must be stored in secure environment
OWASP
49
Conclusion
OWASP
50
Question Time
OWASP
51