This document summarizes common database attack methods and provides recommendations for database protection. It outlines 6 common attack methods: 1) using simple tools, 2) getting credentials, 3) privilege abuse and elevation, 4) SQL injection, 5) protocol attacks, and 6) covering tracks. It then discusses how organizations can implement granular access controls, context-based access controls, connection controls, and anomaly detection to help prevent database attacks and protect sensitive data.

1. Anatomy of a Database Attack
Dana Tamir,
Sr. Manager, Database Solutions
www.Imperva.com

2. Agenda
1. Imperva overview
2. Drivers
3. Attack Methods
1. Using Simple tools
2. Getting credentials
3. Privilege abuse and Privilege Elevation
4. SQL injection
5. Protocol attacks
6. Covering Tracks
4. Q&A
2
BC

3. 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 -3
BC
2008’s CEO of the Year –
SC Magazine
Shlomo Kramer

4. About this presentation
 Based on a studies by Imperva’s research team – the
Application 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

5. Hackers and Insiders go after valuable databases
5

6. Database Attacks
The 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
6
AS

7. Database Attacks
The 5 Step Program
1. Getting the tools
2. Making initial contact
3. Privilege abuse
4. Privilege elevation
5. Covering the tracks
7
AS

8. Database Attacks
Basic 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
8
AS

9. DEMO – The Simplest of Tools
9
AS

10. Database Attacks
Making 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
10
AS

11. Getting the credentials
- CONFIDENTIAL -11

12. 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
12
AS

13. 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
13
AS

14. Privilege Elevation (Example)

15. Privilege Elevation (Example)

16. Privilege Elevation (Example)

17. Privilege Elevation (Example)

18. Privilege Elevation (Example)

19. Database Attacks - Privilege Elevation
SQL 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
20
AS

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

21. Direct Database SQL Injection
Lateral 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
22
AS

22. Direct Database SQL Injection
Lateral 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;
 /
23
AS

23. Direct Database SQL Injection
Lateral SQL Injection - Example
24
AS
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;

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

25. Database Communication Protocol Vulnerabilities
Imperva Confidential
0000
0000
12 01 00 34 00 00 00 00 00 00 15 00 FF 01 00 1b
0000
0010
00 01 02 00 1c 00 0c 03 00 28 00 04 ff 08 00 01
0000
0020
55 00 00 00 4d 53 53 51 4c 53 65 72 76 65 72 00
0000
0030
a8 07 00 00
Record size = 52 Field size = 255
Altering the authentication message (in HEX):

26. Another Protocol Attack Demo
- CONFIDENTIAL -27

27. Database Attacks
Covering 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
28
AS

28. Covering Tracks - Demo
- CONFIDENTIAL -29

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

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
31
AS

31. Mitigation
Granular 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 record
Additional Clause
Data Leakage
via Web Application
Data Leakage
via Database Access
AS
Abnormal query behavior may indicate an attack!

32. Database Protection
Access 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
33
AS

33. Database Protection
Context 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
34
AS

34. 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
35
AS

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

36. Question & Answer
ADC Data Security Webinar Series
AN