Aaron Newman CTO

2. Agenda Overview of Database security Forensics in the Database Forensic DEMO � Buffer overflow Forensics in the Listener Forensic DEMO � tnscmd attack Forensic DEMO � Listener Password attack SQL Injection Forensic DEMO Oracle Root Kits Forensic DEMO Resources, Conclusion, and Wrap Up

3. Overview of Database Security

4. Database Vulnerabilities A decade ago, databases were Physically secure Housed in central data centers � not distributed External access mediated Security issues rarely reported Now, databases are externally accessible Suppliers directly connected Customers directly connected Customers and partners directly sharing data Data is the most valuable resource in application stack Value increases with greater integration and aggregation But so does the threat of data theft, modification, or destruction

5. Barrier Defense Is No Longer Enough

6. Forrester on Database Security

7. Attackers focusing on databases

8. External threats Exposing a database to the Internet DO NOT DO THIS! Behind a firewall Recommend data be served through web app Still vulnerable to application level attacks Still vulnerable to internal attacks

9. Internal threats Need to focus less on people getting through perimeter Need to focus more on securing data at the source Attacks from DBAs, sysadmins, and legitimate users Need to focus not only on vulnerabilities Be able to see who is doing what in your applications Providing auditing and accountability for users and database administrators Being able to identify malicious activity http://www.thesmokinggun.com/archive/0623042aol1.html �JUNE 23--An AOL software engineer was arrested today for stealing the company's entire subscriber list--totaling 92 million screen names--and selling it to a 21-year-old Las Vegas spammer. �

10. Forensics in the Database

11. After the Attack You have discovered you have been attacked Now what??? Need to collect as much data about attack as possible When did it occur How did it occur Where did it come from Databases write auditing data in numerous locations Collect all those locations into a single repository Correlate events to get a better picture of what happened

12. Forensics of an Oracle database First consideration We don�t want to lose any forensic evidence Be prepared to restore to a state before forensic work was started Backup everything you can Operating system including the ORACLE_HOME directory Database system Before doing anything else Take a snapshot of dynamic memory Shutting down database clears this information Save copy of v$sql table � particularly if attack was recent Contains a copy of latest SQL statements executed

13. What To Look For Attacks typically require multiple tries Look for evidence of trial or error Normalize all you data Find what is typical and then eliminate that Look through what is not typical Typically find clusters of errors reflecting an attack Narrow down time period attack most likely occurred Focus in on event around that time/date Look at events from multiple source to piece together what might have happened Determine most likely source of the attack Hacker using a password attack or buffer overflow Customer using privilege escalation Employee using special access Do not rule out any attack vector out

14. Files with Forensics Evidence Within $ORACLE_HOME/admin/<SID> pdump/alert_<SID>.log - cdump/<SID>core.log � raw stack dumps resulting form buffer overflow attacks Look for malicious payload in this file Groupings of attacks udump/<SID>_s001_4382.trc � user trace file might contain user errors Within $ORACLE_HOME/network/log Listener.log file contains connections to the listener service Agntsvrc.log, etc� contains logs on components of database Files may be anywhere on the system Sqlnet.log files � show network traffic from the client SQL*Net trace files � cli_3736.trc

15. Do you have some form of auditing enabled? Best case scenario - you have auditing enabled One type - Native Oracle auditing Records data in system tables or operating system files Configured using AUDIT_TRAIL in the init.ora file Need to appropriately set what to audit Check AUDIT_SYS_OPERATIONS enabled Records all activities of the SYS account Equivalent of the root account Written to value of AUDIT_FILE_DEST in the init.ora file Audits everything SYS does

16. Advantages of Off-database Auditing Native Oracle auditing has its disadvantages Incurs overhead in the database No separation of controls � Can use new Vault features Native auditing Can be disabled or deleted by attacker in the database Most databases have NO auditing configured still 3rd-party security tools provide improved auditing Network-based auditing and monitoring Host-based auditing and monitoring

17. Forensic Demo:Buffer overflow

18. Forensics in the Listener

19. Forensic Demo:tnscmd

20. Easily-guessed Passwords Passwords can be �guessed� Attacking a single account with 100k passwords Attacking many accounts with a few very common passwords People leave test/test or password same as username Password dictionaries http://www.openwall.com/passwords/wordlists/ The wordlists are intended primarily for use with password crackers � Third-party default passwords http://www.petefinnigan.com/default/default_password_list.htm List of 600 default usernames/passwords

21. Password Management features It is important that you have all the proper safeguards against password crackers� Listener does not have Account Lockout Listener.log activity is seldom monitored Scripts and Tools for exploiting weak identification control mechanisms and default passwords are widely available

22. Forensic Demo:Listener Password Attack

23. SQL Injection

24. Can attacks go through a firewall? YES!!! Firewall configuration Block access to any database port Only allow traffic to port 443, 80 Block UDP as well as TCP SQL Injection Not specific to Oracle a web programming problem

25. How Does It Work? Try to modify the query Change: Select * from my_table  where column_x = �1� To: Select * from my_table  where column_x = �1� UNION select credit_card_number from orders where �q�=�q�

26. Example JSP Page

27. Valid Input If I set the username and password to: Username: Bob Password: Hardtoguesspassword The SQL statement is: SELECT * FROM WebUsers WHERE Username=�Bob� AND Password=�Hardtoguess�

28. Hacker Input Instead enter the password: Aa� OR �A�=�A The SQL statement now becomes: SELECT * FROM WebUsers WHERE Username=�Bob� AND Password=�Aa� OR �A�=�A� The attacker is now in the database!

29. SELECT from other tables SELECT arbitrary data Name the tables to SELECT against UNION statement Adds/executes second SQL statement Column types and number must match

30. Sample ASP Page

31. Valid Input Set the product_category to : DVD Player� The SQL Statement is now: SELECT ProductName FROM Products WHERE ProductCategory=�DVD Player�

32. Hacker Input Set the product_category to : test� UNION select credit_card_number from CUSTOMERS where �a� = �a The SQL Statement is now: SELECT ProductName FROM Products WHERE ProductCategory=�test� UNION select credit_card_number from CUSTOMERS where �a�=�a�

33. Reverse Engineering Database Schema Hacker doesn�t know the database schema Can they figure it out? Yes!!! UNION SQL statement with objects from system catalog Retrieving the list of tables UNION select object_name from sys.all_objects; Retrieving the list of columns UNION select column_name from sys.all_tab_columns;

34. Preventing SQL Injection Bind variables � don�t concatenate SQL strings Right way String sql = new string( �UPDATE EMPLOYEE SET BONUS=?�) Wrong way String sql = new string( �UPDATE EMPLOYEE SET BONUS=� + request.getParameter(�bonus�))

35. Forensic Demo � SQL Injection

36. Oracle Root Kits

37. What is a root kit? Creates a back door on a computer system Have been used on operating system for many years Create a copy of a system command Place hackers commands in new replacement system commands Root kit is used after breaking into a system Allows the hacker to come back later And to stay totally cloaked Change system to not show that the hacker is logged in not log what the hacker does to allow hacker to do anything

38. Oracle Root Kits Apr 2005 demonstrated at BlackHat Security conference By Alexander Kornbrust Introduced the idea of creating root kits for Oracle Full copy of presentation available at: http://www.red-database-security.com/wp/db_rootkits_us.pdf Demonstrated hiding users granted DBA Modified the DBA_USERS and ALL_USERS views Demonstrated hiding connection Modified the v$session view

39. 2nd generation Oracle Root Kits Summer 2006 announcing release of 2nd generation At BlackHat Security conference By Alexander Kornbrust http://www.eweek.com/article2/0,1895,1914465,00.asp New �improved� hard-to-detect versions Based on modifying memory of executing stored proc Root kit can�t be detected by looking in system tables We will see this summer!

40. Forensic Demo � Root kit

41. Resources, Conclusion, and Questions

42. How Do You Address These Vulnerabilities? Stay Patched Stay on top of all the security alerts and bulletins Defense in Depth Multiple Levels of Security Regularly perform audits and penetration tests on your database Encryption of data-in-motion / data-at-rest / data-in-use Monitor database activity log files Implement database intrusion detection and auditing Especially if you can�t stay patched!

43. How Do You Address These Vulnerabilities? �I�m running auditing, vulnerability assessment, and IDS tools for the network/OS. Am I secure?� NO!!!! Databases are extremely complex beasts Databases store your most valuable assets Significantly more effort securing databases is necessary �If your workstation gets hacked, that�s bad. But if your database gets hacked, you�re out of business.� http://www.devx.com/dbzone/Article/11961

45. Submit to present for the IOUG! Share your expertise with the greater Oracle community. Solidify your reputation as an Oracle expert! The IOUG is looking for presentations in the following tracks: Architecture, Database, Development, and Middleware. Submit your abstracts no later than November 17. If selected, you will receive a FREE COLLABAORATE 07 conference registration, industry and peer recognition and much more! Submit today at www.ioug.org

46. Questions? Thank you Questions on Forensics Vulnerabilities Locking down the database Email me at: anewman@appsecinc.com