OWASPAU08_Session_16_Nain.ppt
Upcoming SlideShare
Loading in...5
×
 

OWASPAU08_Session_16_Nain.ppt

on

  • 822 views

 

Statistics

Views

Total Views
822
Views on SlideShare
822
Embed Views
0

Actions

Likes
0
Downloads
8
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Organizations are spending loads of money on security controls but is that protection secure enough..
  • So we have to deal with Threats from applications using databases Web services, customer web portals, intranet sites Threats from database users with malicious intentions Authorized users Unauthorized users
  • By reviewing the application generated error messages By reviewing the URL of the web application Downloading the code placed in production environments (ASP, JSP, PHP) Directory listing and directory traversal attack can help in getting the source code for server side scripts including ASP, JSP and PHP Some bugs have been identified in web servers and applications server which let the attackers to view the application code Even the pseudo (or intermediate code) such as CIL or MSIL created by java and .net compilers can be decompiled using the special tools E.g. JAD, Mocha, Salamander .Net decompiler
  • Provides additional layer of security Its safer to have attackers accessing the encrypted data than clear text Types of encryption Encrypt the data in transit Encrypt the data at rest
  • Who is getting connected Remote IP, Application, login time, logoff time, user_id, NO PASSWORDS What data is being accessed Who is making changes to the schema User id, object name, object type, timestamp,owner Use database audit features External auditing system Compare schema snapshots Database errors Userid, sesionid, host, timestamp, error details Stored procedure code change Database links related actions Updates to sensitive information
  • Database should be able to protect itself from the unauthorized users

OWASPAU08_Session_16_Nain.ppt OWASPAU08_Session_16_Nain.ppt Presentation Transcript

  • Dealing With Threats to Databases Sandeep Singh Nain Security Analyst, IBM Australia [email_address] +61-405-369420 AppSec 2008, Australia February, 2008
  • About Me
    • OWASP Member
        • Melbourne chapter
    • Security Analyst
        • IBM Australia ( www.ibm.com /services/security )
    • Background
        • Application development (ASP, .NET, PHP)
  • Agenda
    • Introduction
    • Threats to databases
      • From applications
      • From configuration flaws
      • Database rootkits
    • Auditing and activity monitoring
    • Questions and answers…
  • Introduction?
    • Every organization has one or more databases
    FINANCIAL DATA CUSTOMER DATA SENSITIVE INFO CORPORATE DATABASE WHICH MUST BE PROTECTED
    • Question: Is the protection secure enough???
  • A common scenario And the database is fully secure… NO IT'S NOT Database security is not limited to firewalls, IPS or IDS…
  • The Real Threat
    • Database trusts the applications and users interacting with it
    • Threats to Databases
    • from
    • Applications
    • 1. Application Code Exposure
  • 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
  • Application Configuration Files
    • Holds connection details
      • Contains database server name
      • And username and password to connect to database
    • Is it stored securely?
  • 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 /
  • 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
  • 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
  • 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
    • Threats to Databases
    • from
    • Applications
    • 2. SQL Injection
  • 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
  • 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…
  • 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
  • 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
  • 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?
    • Threats to Databases
    • from
    • Applications
    • 3. Buffer Overflows
  • 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)
  • 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
  • Countermeasures
    • Apply latest patches ASAP
      • remove or minimize the application’s access to the vulnerable function
    • Protect from SQL injection
    • Threats to Databases
    • from
    • Configuration Flaws
    • 1. Improper Access Control
  • 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
  • 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
    • Threats to Databases
    • from
    • Configuration Flaws
    • 2. Insecure Database Links
  • 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???
  • Insecure database-to-database communication Limited access Full access
  • 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
    • Threats to Databases
    • from
    • Configuration Flaws
    • 3. Database doing more than required
  • 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
    • Threats to Databases
    • from
    • Configuration Flaws
    • 4. Unencrypted Data
  • 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
  • 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
  • Sniffing the data in transit User ID Database name MS SQL Server traffic
  • 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
  • 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)
    • Database Rootkits
  • 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
  • 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
  • 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
    • Auditing
    • and
    • Activity Monitoring
  • 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
  • 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
  • Audit trail
    • It answers the questions
      • Who did it?
      • What did they do?
      • When did they do it?
  • 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
  • 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
    • Conclusion
    • Question Time