anatomy of a database attack - oracle dba – tips and...
TRANSCRIPT
Anatomy of a Database Attack
Dana Tamir,
Sr. Manager, Database Solutions
www.Imperva.com
Agenda
1. Imperva overview2. Drivers3. Attack Methods
1. Using Simple tools2. Getting credentials3. Privilege abuse and Privilege Elevation4. SQL injection5. Protocol attacks6. Covering Tracks
4. Q&A
2BC
Imperva Background
Founded in 2002 by Shlomo Kramer (Founder of Check Point Firewall)
Headquartered in Redwood Shores CA – global presence
Thousands of organizations are protected by Imperva
Commercial and Government Customers in 50 countries+ Including the world’s leading…
+ Financial services company, Telecommunications company
+ Payment card provider, Desktop and notebook PC manufacturer
+ Disk and storage systems manufacturer, Food and beverage company
Holistic solution for compliance, security & audit
Award Winning Products & 3rd Party Validation
- CONFIDENTIAL -3BC
2008’s CEO of the Year –SC Magazine
Shlomo Kramer
About this presentation
Based on a studies by Imperva’s research team – theApplication Defense Center (ADC)
+ Internationally recognized research organization focused on security and compliance
+ Led by Imperva’s CTO – Amichai Shulman
+ Discovered dozens of commercial application vulnerabilities
+ Issued numerous security advisories
+ Offers exceptional insight into both published and unpublished security threats
More information: www.Imperva.com/resources/adc/adc.html
CONFIDENTIAL4
Hackers and Insiders go after valuable databases
5
Database AttacksThe Perfect Criminal Setup
Motivation+ Databases are at the core of an organization’s operations
+ Disclose organization’s confidential information
+ Disclose clients’ confidential information
+ Disrupt operation
Means+ VERY simple and accessible tools
+ Some more sophisticated tools are gaining traction
Opportunity+ Thick clients
+ Loose internal network security
+ Applications not implemented securely
6AS
Database AttacksThe 5 Step Program
1. Getting the tools
2. Making initial contact
3. Privilege abuse
4. Privilege elevation
5. Covering the tracks
7AS
Database AttacksBasic Tools
The Problem:+ Most internal users are not Hackers
+ Organizations have strict controls over user software
The Solution:+ Common software packages provide DB
front-end– E.g. Microsoft Excel – Part of any Office
deployment
+ DB client software– E.g. SQL Query Analyzer – Default with MS-SQL
– E.g. Oracle SQL*Plus – Default with Oracle
– Similar client for other database vendors
8AS
Database AttacksMaking Initial Contact
Network access+ Lax internal network access controls
+ Thick-client applications
Obtain valid credentials+ Brute Force Attacks / Exhaustive Search
+ Thick Clients
+ Default Accounts and Passwords
+ Social Engineering
10AS
Getting the credentials
- CONFIDENTIAL -11
Database Attacks Privilege Abuse
Definition+ User has privileges to access database for specific purpose
+ Abuses access privileges to retrieve data in an uncontrolled manner
Example – Abusing Application Privileges+ Order processing application must access credit card information
+ Application with access control must access authentication / authorization information
Hard to Protect+ Granular and accurate column level and row level access control
+ Requires tight colaboration between DBA, programmer and Security Officer during the life cycle of an application
12AS
Database Attacks Privilege Elevation
Definition – Privilege Elevation
+ User exploit database vulnerabilities to gain admin privileges
Methods
+ Buffer overflow
+ Direct database SQL injection
+ SQL parsing mistakes
+ Communication protocol flaws
Built-in Functions
+ Access cannot be restricted, available to any user
+ E.g. pwdencrypt () – Encrypt input text
– Implementation is susceptible to buffer overflow
– Pwdencrypt crashes system when buffer overflow
– Only requires connect privileges
+ Approx. 10 vulnerabilities in recent years
13AS
Privilege Elevation (Example)
Privilege Elevation (Example)
Privilege Elevation (Example)
Privilege Elevation (Example)
Privilege Elevation (Example)
Database Attacks - Privilege ElevationSQL Injection
Definition – SQL Injection
+ Insert unauthorized SQL through a SQL data channel
Database Stored Procedures
+ Executed in the security context of their owner (by default)
– If created by dba then user running it has dba permissions
+ Useful for restricted access to privileged functions
Some Susceptible to SQL Injection
+ Pass SQL statement as parameter to stored procedures
– E.g. ‘grant dba to scott’
+ Executes SQL statement in the context of the owner
– e.g. SYS
+ Susceptible system stored procedures publicly available
20AS
SQL Injection - Example
21
CREATE PROCEDURE general_select2 @tblname nvarchar(127),
@key varchar(10) AS
EXEC('SELECT col1, col2, col3
FROM ' + @tblname + '
WHERE keycol = ''' + @key + '''')
AS
Direct Database SQL InjectionLateral SQL Injection
Looking for SQL injection in stored procedures traditionally involves parameters of character nature (CHAR, VARCHAR2, etc.)
Note that parameters of type DATE and even NUMERIC are susceptible for SQL Injection
The technique is based on the use of NLS_DATE_FORMAT
For more information, see David Litchfield’s “Lateral SQL Injection” white paper at: http://www.databasesecurity.com/dbsec/lateral-sql-injection.pdf
22AS
Direct Database SQL InjectionLateral SQL Injection - Example
create or replace function bad_date return number is
num number;
str varchar2(200);
begin
str := 'select count(*) from scott.emp where hiredate < ''' || sysdate || '''';
dbms_output.put_line(str);
execute immediate str;
return num;
end;
/
23AS
Direct Database SQL InjectionLateral SQL Injection - Example
24AS
create or replace function get_dba return varchar2 authid current_user is
PRAGMA AUTONOMOUS_TRANSACTION;
begin
execute immediate ('grant dba to scott');
end;
/
ALTER SESSION SET NLS_DATE_FORMAT = '"'' and scott.get_dba=''a''--';
SELECT bad_date FROM dual;
Database Protocol Attacks
Definition – Database Protocol Attacks+ Tampering with db related network protocol
messages
Proprietary protocols to communicate between clients and server
+ Complex, Obscure, (almost) no public documentation, Backwards compatibility
Allow for different types of attacks+ Circumventing authentication, DoS, Buffer
overflow
Hacker friendly:+ Attacker only needs network access to server
+ No trace in native audit trail
25AS
Database Communication Protocol Vulnerabilities
Imperva Confidential
00000000
12 01 00 34 00 00 00 00 00 00 15 00 FF 01 00 1b
00000010
00 01 02 00 1c 00 0c 03 00 28 00 04 ff 08 00 01
00000020
55 00 00 00 4d 53 53 51 4c 53 65 72 76 65 72 00
00000030
a8 07 00 00
Record size = 52 Field size = 255
Altering the authentication message (in HEX):
Database AttacksCovering Tracks
Many databases not audited so audit evasion not an issue…
Often only security failures are audited
+ Most of the previously mentioned attacks will not be audited
Attacker can tamper with audit if have elevated privileges
+ Attacker that gains elevated privileges
+ DBA or other legitimate user with elevated privileges
Some vulnerabilities in auditing mechanism
28AS
DB Attack Prevention
Let’s call the DBA and have him fix everything+ DBA does not have extra time!
+ Multiple database vendors = – Multiple DBAs
– Different Capabilities
– Different Syntax and Semantics
– Different Policies
+ Partial tools for some of the issues
+ No SoD – full control of administrative user
+ Inherently vulnerable to database vulnerabilities
30
Bad Guys
DB Attack Prevention
What should be on your wish list:+ Vulnerability / Compliance assessment
+ Query Based ACLs
+ Context Based ACLs and Connection Control
+ Virtual Patching & Protocol Validation
+ Independent Audit
+ Separation of Duties
+ Consolidation of policies and control
31AS
MitigationGranular Access Controls Are Needed
32
Privilege Abuse
Select * from orders where order_id > 1
Normal Usage
Select * from users where username = ‘john’ and password = ‘smith’
SQL Injection
Select * from users where username = ‘john’ and password = ‘smith’ or 1=1
Normal Usage
Select * from orders where order_id = 60
More than 1 recordAdditional Clause
Data Leakagevia Web Application
Data Leakagevia Database Access
AS
Abnormal query behavior may indicate an attack!
Database ProtectionAccess Control Based on ‘Normal Usage’
Models Database Usage Structure+ Profile queries and business activities
+ Profile privileged operations usage
+ Profile access to system objects
Monitor and Protect Based on Usage Dynamics
+ Verifies real-time usage vs. policy
+ Alert on deviations from policy
Learns as Usage Expands or Changes+ Notifies Administrators as changes occur
33AS
Database ProtectionContext Based Access and Connection Control
Access controls augmented with the context of query+E.g. Client machine, client software, time-of-day
Access controls augmented with results of query+Affected records
+Amount of sensitive data extracted
Threats detected+Suspicious usage pattern
+Misuse of credentials
+Credentials theft
34AS
Database Attacks – The Bottom Line
DB Attacks are not science fiction+ Tools are available, steps are simple
Using some free DBA tools is not enough+ Lack of DBA resources
+ Lack of capabilities
+ Inherent Deficiencies
More comprehensive solutions are needed + Enable both DBAs and security professionals
+ Provide missing capabilities
+ Assure resilience and timely response
35AS
More Information: Imperva.com
Blog blog.imperva.com
iTunes/Podcasts www.imperva.com/resources/podcasts.asp
YouTube www.youtube.com/user/ImpervaChannel
Twitter twitter.com/Imperva
Linkedin www.linkedin.com/companies/Imperva
Facebook www.facebook.com/group.php?gid=24630194480
BC
More Information: www.imperva.com
Question & AnswerADC Data Security Webinar Series
AN