1 / 42

Aaron Newman CTO/Founder Application Security, Inc.

Oracle Forensics: Collecting Evidence after an Attack. Aaron Newman CTO/Founder Application Security, Inc. Agenda. Overview of Database security Forensics in the Database Forensic DEMO – Buffer overflow Forensics in the Listener Forensic DEMO – tnscmd attack

corina
Download Presentation

Aaron Newman CTO/Founder Application Security, Inc.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Oracle Forensics: Collecting Evidence after an Attack Aaron NewmanCTO/Founder Application Security, Inc.

  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 • Oracle Root Kits • Forensic DEMO • SQL Injection • 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. Secret Formula Internet CRM Internet Financial HR Accounting Barrier Defense Is No Longer Enough Web Proxy Firewall Main Office Network Business Partner’s Network Firewall Firewall VPN VPN Remote Employees Remote Office Network

  6. Firms Need it • “…with growing incidence of intrusions across industries and strong regulatory requirements to secure private data, enterprises need to make DBMS security a top priority.” Forrester on Database Security Source: Comprehensive Database Security Requires Native DBMS Features And Third-Party Tools, Forrester Research, Inc., March 29, 2005

  7. Attackers focusing on databases http://news.softpedia.com/news/Toying-with-Microsoft-s-breaches-is-no-longer-fun-for-hackers-1603.shtml .. until now the hackers have mostly targeted Microsoft’s software products, starting with this year, it seems their attention has been draw to other products and services ... According to a recently published study, ...it’s clear they are exploring new territories besides the old Windows .. the software products developed by Oracle Corp ... have started to be more and more targeted by hackers.

  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. Oracle Root Kits

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

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

  26. Forensic Demo – Root kit

  27. SQL Injection

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

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

  30. Example JSP Page Package myseverlets; String sql = new String(“SELECT * FROM WebUsers WHERE Username=’” + request.getParameter(“username”) + “’ AND Password=’” + request.getParameter(“password”) + “’” stmt = Conn.prepareStatement(sql) Rs = stmt.executeQuery()

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

  32. 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!

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

  34. Sample ASP Page Dim sql Sql = “SELECT ProductName FROM Products WHERE ProductCategory=’” & request.form[“product_category”] & “’” Set rs = Conn.OpenRecordset(sql) ‘ return the rows to the browser

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

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

  37. 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;

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

  39. Forensic Demo – SQL Injection

  40. Resources, Conclusion, and Questions

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

  42. Questions? Thank you • Questions on • Forensics • Vulnerabilities • Locking down the database

More Related