Top 10 Database. Misconfigurations.

Transcription

1 Top 10 Database Vulnerabilities and Misconfigurations Mark Trinidad

2 Some Newsworthy Breaches From

3 In Hackers carry 2011 momentum in 2012 Data theft, hacktivism, espionage Databases continue to be the primary target Same old attack vectors continue to yield success SQL injection here to stay? New attacks emerge Costs associated with data breaches continues to rise 3

4 Database Risks for 2012 Organizations have long focused their security efforts on the perimeter and endpoints This approach has left the data center highly vulnerable to anyone who can gain access via: 1. SQL Injection 2. Spear Phishing 3. Malware / Drive by downloads 4. Advanced Persistent Threats 5. Insider Attacks / Mistakes 6. Social Engineering 4

5 Data Breach Costs Are On The Rise $214 Over 535 million DBMS records have $204 $202 been compromised since 2008 $197 Cost per record estimated at $214- $318 for 2010 Annual losses valued at over $388 Billion $7.2 Million is the average cost of a data breach $ Cost Per Exposed Record Sources: Ponemon Institute, Symantic/Norton, Verizon Business Data Breach Report 5

6 Database Risks for 2012 Full of Holes Team SHATTER and others keep finding high risk vulnerabilities for database vendors to patch Exploit scripts posted to the web within hours of every patch release Fully patched but misconfigured databases are another easy target Database attacks bypass traditional network and host intrusion prevention mechanisms Public exploit code + slow patch cycle = High risk DBMS exposure 6

7 Already in Million Accounts 2 Fixes (only 5 in Oct 2011) 7

8 Top 10 DB Vulnerabilities and Misconfigurations 8

9 DB1: Default and Weak Passwords Default accounts are never good Not only DBMS have own default accounts, but applications install them too Weak passwords can be cracked Just google <database type> password cracker dozens of them out there Names, places, dictionary words make poor passwords Rainbow tables make anything under 7 or 8 characters weak Database login activity seldom monitored If you re not watching, an attacker can guess passwords all day 9

10 Default Account Examples User: system / Password: manager User: sys / Password: change_on_install User: scott / Password: tiger User: SA / Password: null User: db2admin / Password: db2admin User: db2as / Password: ibmdb2 User: SA / Password: null User: root / Password: null User: admin / Password: admin User: myusername / Password: mypassword User/Password the Same: DATABASE SECURITY DBSNMP NOT MY PROBLEM 10

12 DB2: SQL Injection in the DBMS Same concept as at Web App Specific functions in the DBMS are vulnerable to SQL injection Patching is needed for the fix Since the weaknesses are in the DBMS itself, vendor patches are required to remediate Typically takes 6+ months to patch a database 12

13 Exploiting SQL Injection Attack Target: Oracle 11g Privilege Level: Any Login with CREATE PROCEDURE Outcome: Access to all Database Data! Attacker can run any SQL as WMSYS Vulnerabilities Exploited: Privilege Escalation via SQL Injection in [WM]SYS.LT.ROLLBACKWORKSPACE 13

14 14

15 15

16 16

18 DB3: Excessive User & Group Privileges Theory of least privilege Great in theory; hard in practice Entitlements hard to manage Users can gain access by way of a role that is granted another role that is granted another role Often default database privilege grants are excessive and dangerous 18

19 How Did the User Get The Privilege? User Role Role Role Role Role 19

20 Exploiting Excessive Privileges Attack Target: Oracle 11g Release 1 Privilege Level: Anyone with CREATE SESSION privilege Outcome: Gain DBA access & complete OS control Vulnerabilities Exploited: Default PUBLIC privilege to execute DBMS_JVM_EXP_PERMS.IMPORT_JVM_PER PERMS PER MS 20

21 No users have ALL FILES - full OS access Attempt to execute OS command fails 21

22 Setup the JVM access control policy The attack in action. PUBLIC can import JVM permissions! 22

23 USER1 has full OS access OS commands run successfully New OS file created by our exploit 23

24 Freely Available Exploit Code! 24

26 DB4: Unnecessary Enabled DBMS Features Minimize Attack Surface Attackers will only have more to use against you Powerful Features are Good and Bad Integrated Java and other extensible languages Various levels of OS access available 26

27 Minimize Attack Surface Java UTL_FILE xp_cmdshell CREATE _ NOT _ FENCED (allows logins to create SPs) OLEDB Ad Hoc Query OPENROWSET OPENDATASOURCE xp_cmdshell Permissions on User Table (mysql.user) 27

29 DB5: Broken Configuration Management Configuration Option Overload Beginning Name the instance, choose the data storage location Now Advanced feature sets, add-on modules, specific security settings, etc. What s the right configuration? 1 st What is our current configuration? 2 nd What should be our configuration? 29

30 Misconfigurations Are Potential Threats Oracle Configuration Management (OCM) stores configuration data about sysaudits table If properly hostnames, usernames, datafile configured audit records can be lost locations, etc. TRUST_ALLCLNTS configuration parameter If set to default (which is YES) all clients attempting to connect will be considered trusted Default TCP Ports 1433 and

32 DB6: Buffer Overflows Crash or Exploit Simple: crash the server Advanced: load and run malicious code Only a vendor patch fixes the issue Like a SQL Injection vulnerability Need vendor fix 32

33 Example: Attacking DB2: Denial of Service Attack Target: IBM DB2 LUW 9.1 Fix Pack 8 Privilege Level: Any database user Outcome: Crash database server Vulnerabilities Exploited: Heap buffer overflow in built-in scalar function REPEAT Patched by Database Vendor: IBM DB2 LUW 9.1 Fix Pack 9 33

34 Connect to the database Run the exploit. No privileges needed! 34

35 No more database. 35

36 Freely Available Exploit Code 36

38 DB7: Privilege Escalation I am now DBA Vulnerabilities can lead to low- privileged users becoming DBA Only a vendor patch fixes the issue Risk management when considering patch rollout 38

39 Exploiting Privilege Escalation Attack Target: Oracle11g Release 2 Pi Privilege il Level: CREATE PROCEDURE and EXEC on MDSYS.RESET_INPROG_INDEX Outcome: Full control of the database (assume DBA role) Vulnerabilities Exploited: Privilege escalation in MDSYS.RESET_INPROG_INDEX Patched by Database Vendor: Oracle January 2011 CPU 39

40 The Attack Step by Step 1. Setup a) Create procedure myproc containing code to grant my account DBA b) Create function myfn containing code to create a trigger in the system schema 2. Exploit a) Exploit the vulnerability, causing MDSYS to run myfn. Creates the trigger. 3. Reap Rewards a) Use PUBLIC privileges to run a SQL statement that causes the trigger to fire. System runs the trigger, which calls myproc which grants my account DBA. 40

41 Create a new user (user1) and grant privileges. 41

42 Setup step 1: Create attack code (myproc) to grant DBA privileges to user1 42

43 Setup Step 2: Create a function (myfn) that creates an evil trigger that calls the attack code (myproc) 43

44 Run the exploit. Causes MDSYS to run myfn and create the evil trigger. Insert statement causes the evil trigger to run myproc and grants DBA 44

45 Attacker is now DBA 45

46 Google Told Me All About It.. 46

48 DB8: DoS Remember the SQL Slammer Worm? 75,000 victims in 10 minutes Microsoft had the patch 6 months prior Again, patch management for DBMS is crucial 48

49 Exploiting Denial of Service Attack Target: IBM DB2 LUW 9.7 Fix Pack 1 Privilege Level: Anyone on the network Outcome: No access to DB2 database Vulnerabilities Exploited: Denial of Service in the Tivoli DB2 monitoring agent Patched by Database Vendor: IBM DB2 LUW 9.7 Fix Pack 2 49

50 DB2 Monitoring Agent has crashed. Run the exploit. No database login needed! 50

51 Attacking DB2: Denial of Service Outcome: DB2 9.7 Database is unavailable Vulnerabilities Exploited: DoS in the Tivoli DB2 monitoring agent How Did We Do It? Freely available exploit code Google: KUDDB2 remote denial of service 51

53 DB9: Unpatched Database Vulnerable the day the patch is released Exploit/POC code emerges quickly What s the difference compared to a zero-day vulnerabilities? What do we patch first? Citi Critical lbusiness systems??low risk systems? 53

55 DB10: Unencrypted Data At Rest and In Motion Data at Rest File system encryption Transparent Data Encryption (TDE) Data In Motion SSL Oracle ASO Kerberos 55

57 DB11: Not Doing Anything Reliance on Perimeter Protection Only Does Not Work Sony, Epsilon etc. Who s responsible for DB Security? Who are the stakeholders? DBA? Security? 57

58 Database Security Tips for Devise a Database Security Plan 2. Locate Sensitive e Information 3. Minimize Attack Surface 4. Fix Default, Blank and Weak Passwords 5. Regularly Patch Databases 6. Implement Least Privileges 7. Encrypt Sensitive Data in Rest and in Motion 8. Train and Enforce Corporate Best Practices 58

59 Database Security Tips for 2012 Devise a Database Security Plan Start with an established DBMS checklist DISA STIG is an excellent starting point DISA publishes detailed guidelines on how to secure and configure MS SQL server and Oracle Customize to meet your orgs needs. There may be industry regulations to follow PCI, SOX, HIPAA Once a DBMS security policy is established, build a roll-out out plan Pick one or two of the highest priority issues to remediate first As you progress, layer on additional checks and tests 59

60 Database Security Tips for 2012 Locate Sensitive Information Determine where all sensitive info resides Secure those databases first Minimize Attack Surface The DBMS ships with many features that are not used Some of these features have functionality that render a DBMS vulnerable to attack Where possible, disable unused DBMS features 60

61 Database Security Tips for 2012 Fix Default, Blank and Weak Passwords Ensure all databases require complex passwords Eliminate default, blank and weak passwords Use different passwords for each system External authentication systems can be a great option Regularly Patch Databases Critical patches insure that vulnerabilities are remediated on a regular basis Patching in conjunction with auditing and monitoring increases DBMS protection 61

62 Database Security Tips for 2012 Implement Least Privileges Ensure employees only have access to the sensitive data required to do their jobs Map job functions to privileges on IT assets Never assign privileges il to guest accounts or PUBLIC Untangle the web of user entitlements Encrypt Sensitive Data at Rest and in Motion Never er store sensitive e data in clear text t in a DBMS where any DBA/IT staff can access it Ensure the data is encrypted and not allowed to travel unencrypted on the network 62

63 Database Security Tips for 2012 Train and Enforce Corporate Security Best Practices Ensure all employees are aware of the orgs. security best practices Create a training i program and consistently reinforce policy Extend critical protections at the network and application layer to the DBMS Perform regular DBMS audits, pen tests and misconfiguration checks Activity monitoring to ensure sensitive data is not downloaded or transferred 63

64 Last Thoughts Attackers are targeting the data center, your defenses should be focused there Most breaches in 2011 were simple attacks that exploited common flaws or the result of human error/failure Almost all were avoidable through simple controls In 2012, improve security AND improve education (re-educate) security and non- security professionals 64

65 References Team SHATTER Top 10 Database Vulnerabilities Book Security Heuristics of Application Testing Technology for Enterprise Research Practical Oracle Security By Josh Shaul CTO, Application Security, Inc. Mark Trinidad Sr. Product Manager Application Security, Inc blog.appsecinc.com 65