Transcript SQL Server 7.0 Strategy Deck

Commercial Database
Security Issues
James Hamilton
[email protected]
Microsoft SQL Server
2002.10.16
Agenda

Introduction






DB Attacker Toolkit: Well Armed
Who Cracks Databases?
Attack Vectors—How are DBs cracked?


Growing Problem: S/W security
DB Security: the Battleground shifts
Evolving DB Threat Environment
7 DB Attack Examples
Defense Mechanisms:


DB Developers & Administrators
DB Implementers
2
Growing Problem: S/W Security


Survivability: the capability of a system to fulfill it’s
mission, in a timely manner, in the presence of
attacks, failures, and accidents - Lipson, Howard & Fisher, 1999
Survivability challenge:



Previous focus primarily on S/W failure, human error, &
natural disaster
Primary security measure was physical:

Keep external bad guys away

Protection against insiders primarily via legal
protection & data isolation
Industry shifts:



Shift from mediated access to direct application access

Vendors, customers, & partners
Shift from central admin to distributed
Shift from survivability focus largely ignoring security to
being prime concern
3
Cracking Not New Phenomena

1981: Kevin Mitnick (Condor) cracks LA School System & PacBell








1992: 414 Gang cracks Los Alamos & cancer center
1983: Mitnick (Condor) cracks Pentagon Computers
1984: Kevin Poulsen (Dark Dante) cracks into ARPAnet
1986: Pakistani Brain virus – 1st malicious virus
1996: Chaos Computing Club hacks LBL
1987: Jerusalem Virus – 1st infecting files
1988: Robert Morris releases 1st internet worm





Credit cards and $6,000 in cash and product
1991: Michelangelo virus
1991: Justin Petersen (Agent Steal) cracks bank computer & transfers funds
1992: Morty Rosenfeld (Storm Shadow) cracks TRW


Steals VMS source code
1989: Fry Guy cracks McDonalds


Sendmail buffer overrun -- over 6,000 systems infected
1988: Mitnick cracks MCI DECnet


steals passwords
Credit card reports and numbers
1994 Richard Pryce (DataStream Cowbow) cracks USAF Rome Lab,…
1994: Vladimir Levin cracks CitBank network
Source: Bill Wall, Harris computer Corp
4
Incidents Reported


CERT/CC incident statistics 1988 through 2002
Incident: single security issue grouping together all
impacts of that that issue


e.g. LoveLetter worm defined to be a single “incident”
Issue: disruption, DOS, loss of data, misuse, damage, loss
of confidentiality
80000
70000
60000
50000
40000
30000
20000
10000
'0
2
'0
0
'9
8
'9
6
'9
4
'9
2
'9
0
'8
8
0
5
Source: http://www.cert.org/stats/cert_stats.html
Particularly Damaging Attacks

Love Bug worm


Code Red virus




Infected 2.3 million machines
Damages $1.2 billion
Klez virus:


Infected 1 million machines
Damages estimated at $2.6 billion (newer estimates much higher)
SirCam virus:


Damages estimated at $8.75 billion
Infected 900,000 machines
Nimda virus:

Damages estimated at $700 million
6
Source: Bill Wall, Harris computer Corp
S/W Security Problem

O/S security alerts since Jan 2002 --www.securitytracker.com



Paradoxically under invested:




“Less than 0.0025% of corp revenue invested in security”
“If you spend more on coffee than on IT security, then you will
be hacked”
Source: Richard Clarke, Special security advisor to president, 2002
Problem gaining recognition:

90% detected computer security breaches over last year
80% acknowledged financial losses due to breaches
34% reported the intrusions to law enforcement

Source: 2002 Computer Crime & Security Survey– Computer Security Institute



Windows: 636
Linux: 759
Investment Situation Improving:

Intrusion detection & vulnerability assessment market:

$1B by 2003 with CAGR of 34%


Source: IDC 2001
Authentication, Authorization, & Administration:

$2.8B in 2000

CAGR of 28% growing to $7.7B

Source: IDC 2001
7
DB Security: Battleground Shifts


Most apps of value have persistent data
Data valuable to company, organization, or even individual
typically also has value to others


Even ephemeral data has significant value, when trends
analyzed and understood:



Decreased storage & data management costs enables it
Competitive pressure demands it
Where there is value, there are bad guys


Information is becoming the most valuable asset in many
industries

E.g. Charles Schwab & Wal-Mart both identify mgmt of info
asset as key competitive advantage
And professional services guys, and press guys, & industry
analysts, …
Battleground evolving to include the database

“Port 1433 [SQL Server] regularly registered as one of the top
scan ports in the Internet Storm Center” –Source: http://www.sans.org/top20
8
Evolving DB Threat Environment

A decade ago, databases were:





Now increasingly DB’s externally accessible:




Suppliers directly connected
Customers directly connected
Customers & partners directly sharing data
Data is most valuable resource in application stack



Physically secure
Housed in central data centers – not distributed
External access mediated through customer service reps,
purchasing managers, etc.
Security issues rarely reported
Value increases with greater integration & aggregation
Opportunities for data theft, modification, or destruction
DB security a growing problem:


101 DB alerts since January 2001--www.securitytracker.com
Two database issues on SANS/FBI top 20 list –http://www.sans.org/top20/
9
DB Attack Toolkit: Well Armed





Brute force & dictionary-based password crackers
Network sniffers and Port scanners
Object code de-compilers
Application Source code often (illegally) available
Quality debuggers


Leveraging cracked systems:



Credentials: leverage & escalate by steps
Compute power: host distributed denial of service
DB Security/cracking tools & consulting:





Symbols typically available for problem determination
NGSSoftware (http://www.nextgenss.com/)
Internet Security Services (http://www.iss.net/)
Application Security Inc. (http://www.appsecinc.com)
And many others…
Community shared resources:


Exploit, risk, & data sharing the community
E.g. NTBugTraq (http://www.ntbugtraq.com/)
10
Who Cracks DB’s?: tale of two crackers

Who Cracks DBs?




I encounter many of these folks although typically
not black hats



Black Hats in search of gain or damage
Security Professional Services
Individuals in search of fame
They don’t often report issues to a vendor
Most commercial DB security issues not found in
operational systems
Examples from people I’ve worked with:
1.
2.
Consulting Firm, a company establishing their name as
security experts
Individual, a programmer making mark in security circles
11
Who Cracks DBs?: Consulting Firm


A security-focused professional services company
They sell security services to customers and, when not
billing, crack software



Shows that there really is a security problem out there to attract
customers
Shows potential customers that they are security experts
Most professional security services companies responsible



Can’t afford to be perceived as Black Hats by potential
customers

Usually give time for problems to be fixed before disclosure
Some learn that it’s easier to attempt to bill DB vendors directly

Looks to me a lot like “selling protection”
Extract from a recent note from Consulting Firm:
…FictitiousInc have now considered that building
succesful business relationships with companies such as
yourself and Oracle, out strips the private vulnerability
research. We are very much more keen to go down this
path, if this means not talking about a specific product
fine. There are many many more products out there IBM
for starters:)…


Some responsible, some less so, but generally helping
customers by finding issues yielding product fixes
Issues found often contrived but not without value
12
Who Cracks DBs?: An Individual

Overview of this system cracker:






Living outside the US
Attending college studying Computer Science
Working as a database application developer
More productive than most full time software testers
Communicates with me via Instant Messaging
Generally principled:





wants fame
wants security bugs fully disclosed
wants a security S/W related job
not trying to get “bought off” by industry
Many people are less highly principled:




Not all just looking for fame rather than financial gain
Skills appropriate for full spectrum from information theft,
vandalism, through terrorism
Many live in other jurisdictions
Visibility of Black Hats numbers difficult
13
DB Attack: Admin Error

Impossible to cover all forms of attack



Numerous and some not yet known
We’ll sample the attack space
Administrative Error



No system administrator password and database
unprotected on the public network
SQL Server Worm (Spida) based upon this issue

Old versions of SQL allowed null SA password on
installation

SQL2000 fixed but many upgrades retain blank PW

SQL2000 Service Pack 3 prompts for non-null SA
password
Lessons:

Default install must be secure

Databases should never be directly on public net

DB’s should enforce strong password policy
14
DB Attack: Buffer Overrun

Buffer Overrun


Overflow data can be crafted to include
executable but how to force execution?








Any command that takes an argument or
bounded buffer has overflow risk
Stack smashing
Register hijacking
Local pointer subterfuge
V-Table hijacking
C++ EH clobbering
SEH clobbering
Parameter pointer subterfuge
Let’s look at some examples
15
DB Attack: Buffer Overrun Exploits
Previous function’s
stack frame
Function arguments
Return address
Frame pointer
x86 stacks grow
downward
 Buffer overrun on stack
can rewrite:

EH frame

Local variables and
locally declared
buffers

Callee save
registers
Garbage


Return address
Frame pointer
EH frame
Exploit usually involves
privilege escalation
16
DB Attack: SQL Injection

Exploiting SQL comment:
Select * from customers where name=$input
With $input = JamesRH’ or 1=1 -Select * from customers where name=‘JamesRH’ or
1=1 –-’

Exploiting multiple commands and SQL comment:
Select * from customers where name=$input
With $input = ‘ or 1=1 exec xp_cmdshell NT_command -Select * from customers where name=‘’or 1=1 exec
xp_cmdshell NT_command --’


Making comment illegal is not sufficient protection
Only answer is to not ever execute user input

No sane programer would accept prog lang source code
from user, SQL should never be accepted either
17
DB Attack: Code Patching


Innovative attack that can’t be directly applied

shows how multi-step attacks are constructed
With (even temporary) ability to run code in SQL Server
address space:

Find FHasObjPermissions()

Internal SQL Server object security access check function
Call VirtualProtect to enable code segment modification

Change FHasObjPermissions() implementation to return 1
(true)
As long as the SQL Server is running

If they can log on, they will have admin rights
Technically not interesting since can’t be exploited without
access to SQL Server address space

At that point, anything is possible

I show the example more to show how deep crackers will
dig rather than claiming that this is a real exploit
But, once made, even if attacker no longer has direct access
to SQL address space, they can exploit SA privs




18
Source: http://www.nextgenss.com/papers/violating_database_security.pdf
DB Attack: DOS & DDOS



Denial of service attacks involve attacks consuming all or
most system resources
For authenticated users, resource governor is only full
defense
Defense for non-authenticated users:



Distributed denial of services uses many machines to attack
target


Fail bad passwords slowly with min-resources consumed
Can do IP tracking but spoofable
Usually part of a multi-step crack in that attacking machines are
usually also cracked
An unusual DOS attack:

Sending \x02 to SQL Monitor (port 1434)

SQL Monitor responds with \x02

Attacker spoofs source IP to port 1434 on another SQL
server and they ping back and forth --source: David Litchfield

Not particularly effective in that few resources are
consumed but interesting approach
19
DB Attack: Brute Force PW


Bruce force or dictionary-based password cracking remains
an old favorite
When run against a system directly it usually fails:



When run against a password file, success is more likely:


Unix removed hashed password from /etc/passwd for this
reason and hashed version can only be read by administrators
DB have same protections as modern O/S’s


It takes too long for a password to fail (built in delays are often
employed)
Failed password attempts are typically audited
No passwords stored and cryptographically hashed passwords
only accessible to admin
Direct attack is only exploitable when:





Password file is given to non-admin user
Passwords are weak
NT authentication isn’t used
not an elevation of privilege attack:

Only admins can access hashed PWs & they have full rights
One of the reasons why passwords are changed frequently on
well-managed systems
20
DB Attack: PW’s in files


Very common attack vector through DB passwords
stored on other systems
Web-server may store logins


Install programs can store logins




Should run webserver as low priv account and use NT
authentication at DB
Remove all *.iss files or remove stored passwords

SQL Server Killpwd utility
File system should be locked down
SQL Server should run as a low priv account
Administrators sometimes store passwords in
admin scripts
21
Defense Mechanisms

“Brakes, they only slow you down” –
Enzo Ferrarri

Similarly, security only gets in the way





Increases administrative costs
Can make development more difficult
Can make programs more difficult to use
Can make Black Hat access more difficult
Industry challenge: blocking Black Hats without
unduly slowing intended users, developers &
administrators
22
Defense: Dev & Admin Actions

Weak service account


Weak access accounts





Leading DBs all provide both
Strong PWs with enforcement




Nor on private net
Firewall protected
S/W mediating database access
Use NT authentication rather than DB auth


Don’t put all enterprise admins in one group
Never place DB unprotected on public net


Mid-tier account only capable of min needed to run app
Two-tier users with min access
Smallest possible admin groups


Cracked DB won’t get access to rest of enterprise
Force all PWs to comply with enterprise policy
Default action if using NT auth
Never store a PW in a file for any reason
Physical security

Protect all related systems, media, backups, etc.
23
Defense: Dev & Admin Actions

Track usage pattern changes



Media security including backups







Configure system to audit failed logins, failed authentication, …
Drive alerts on audit events to page admins
Apply all latest QFEs
Alert to page admins on vendor security releases
Never build SQL with unchecked user input


Replication, management tools, stored procedures, …
Full audit of all failed events


Assume damage possible and have aggressive backup policy
Test disaster recovery system
Only install and configure needed features:


E.g. TP systems should NEVER table scan
Future direction for DB security will exploit tracking unusual
access patterns
Never trust user input
Don’t show “developer quality” error messages to users
Bound user input size and test application at max size
24
Defense: DB Implementation

Secure default Installation




Secure examples in books, documentation, and all customer
communications
Support sub-set feature installs


E.g. Row level security
Support multi-tier security W/O fully provisioned DB tier


Admin error common cause of failure
Provide fine grained, policy based access controls


E.g. Windows update delivery of server-side security fixes
Simplify security sub-systems


Minimize attack surface area
Support auto-update for security fixes


Weak defaults result from ease of use focus and past reduced
threat environment
Best practices scanner (Microsoft Baseline Security Analyzer)
Most applications don’t provision all users in DB tier
Defense in depth: avoid single failure security exposures
25
Defense: DB Implementation

Understand crackers:




All SQL Server personal attend Security education
Everyone: Development, User Education, Program
Management, Test, Quality Assurance, Performance
engineering
Understand how systems are cracked, what tools are
used, what tools can stop, common vulnerabilities, how
competitors have been cracked
Aggressive program of code hygiene




SQL Server engineering spent 3 months focused
exclusively on security
Threat models produced for every S/W component

Reviewed the entire code base with respect to threat
models & code review methodology

Test targeted each component using threat model
Security section required on all new designs
Across all Microsoft products $100 million spent on this
security education & code review program
26
Defense: DB Implementation


Use great tools: Compiler runtime, code generation and host
operating system support
Operating System Support Example:



Compiler Support Example:





.Net Server enforces that exception handlers be marked by the
compiler as handlers
Prevents exception handling hijacking
VS7 compiler puts invocation unique bit pattern on stack
between local variable and return address
Prevents return address hijacking
Each execution uses a different cryptographically randomly
generated set of bits to protect return address
Won’t use the return address unless protection bits correct
More compiler work soon to ship but no silver bullet

Good code still required – just one more level of protection
27
Defense: DB Implementation

Aggressive application of security tools research


Developers very effective in finding innovative exploits
but not good at searching 5 mloc to find others of same
general form
Microsoft Research compiler tools framework used
to produce security tools





Based upon basic block transform system
Tracks control and data flow
Operates on compiler intermediate form
Has interface to allow new search modules to be written
Example checks:

Uses of error prone functions

Assignments in asserts (likely intended equivalence)

Custom code annotation warnings
28
Summary


S/W vulnerability report frequency increasing
Database is the most valuable asset


Database vulnerability reports becoming common this year


Black Hats know it
DB vulnerabilities unusual in even recent past
Need multi-tier protection:








Application developer & administrator best practices
Simplification of security features—Fewer admin errors
Finer grained control of security
DB team education
DB team development practices
DB engineering team tracking cracker tools and practices
Great tools: source code compiler and hosting O/S
Advanced security tools
29
Microsoft