Dealing With Threats to Databases

1. Dealing With Threats to Databases Sandeep Singh Nain Security Analyst, IBM Australia sannain@au1.ibm.com +61-405-369420 AppSec 2008, Australia February, 2008

2. About Me • OWASP Member • Melbourne chapter • Security Analyst • IBM Australia (www.ibm.com/services/security) • Background • Application development (ASP, .NET, PHP)

3. Agenda • Introduction • Threats to databases • From applications • From configuration flaws • Database rootkits • Auditing and activity monitoring • Questions and answers…

4. Introduction? Every organization has one or more databases CORPORATE DATABASE FINANCIAL DATA CUSTOMER DATA SENSITIVE INFO WHICH MUST BE PROTECTED

5. Question: Is the protection secure enough???

6. A common scenario NO IT'S NOT And the database is fully secure… Database security is not limited to firewalls, IPS or IDS…

7. The Real Threat • Database trusts the applications and users interacting with it

8. Threats to Databases from Applications 1. Application Code Exposure

9. 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

10. Application Configuration Files • Holds connection details • Contains database server name • And username and password to connect to database • Is it stored securely?

11. 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/

12. 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

13. 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

14. 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

15. Threats to Databases from Applications 2. SQL Injection

16. 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 • 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) Ref: http://www.webappsec.org/projects/whid/list_id_2004-17.shtml

17. 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 withNOWAIT-- ; • And more…

18. 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

19. 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

20. 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?

21. Threats to Databases from Applications 3. Buffer Overflows

22. 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)

23. 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

24. Countermeasures • Apply latest patches ASAP • remove or minimize the application’s access to the vulnerable function • Protect from SQL injection

25. Threats to Databases from Configuration Flaws 1. Improper Access Control

26. 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

27. 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

28. Threats to Databases from Configuration Flaws 2. Insecure Database Links

29. 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???

30. Insecure database-to-database communication Limited access Full access

31. 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

32. Threats to Databases from Configuration Flaws 3. Database doing more than required

33. 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

34. Threats to Databases from Configuration Flaws 4. Unencrypted Data

35. 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

36. 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

37. Sniffing the data in transit User ID Database name MS SQL Server traffic

38. 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

39. 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)

40. Database Rootkits

41. 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

42. 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

43. 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

44. Auditing and Activity Monitoring

45. 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

46. 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

47. Audit trail • It answers the questions • Who did it? • What did they do? • When did they do it?

48. 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

49. 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

50. Conclusion