Commercial Database Security Issues

1
Commercial Database Security Issues

• James Hamilton
• JamesRH_at_microsoft.com
• Microsoft SQL Server
• 2002.10.16

2
Agenda

• Introduction
• Growing Problem S/W security
• DB Security the Battleground shifts
• Evolving DB Threat Environment
• DB Attacker Toolkit Well Armed
• Who Cracks Databases?
• Attack VectorsHow are DBs cracked?
• 7 DB Attack Examples
• Defense Mechanisms
• DB Developers Administrators
• DB Implementers

3
Growing Problem S/W Security

• Survivability the capability of a system to
  fulfill its 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

4
Cracking Not New Phenomena

• 1981 Kevin Mitnick (Condor) cracks LA School
  System PacBell
• steals passwords
• 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
• Sendmail buffer overrun -- over 6,000 systems
  infected
• 1988 Mitnick cracks MCI DECnet
• Steals VMS source code
• 1989 Fry Guy cracks McDonalds
• 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
• Credit card reports and numbers
• 1994 Richard Pryce (DataStream Cowbow) cracks
  USAF Rome Lab,

5
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

Source http//www.cert.org/stats/cert_stats.html
6
Particularly Damaging Attacks

• Love Bug worm
• Damages estimated at 8.75 billion
• Code Red virus
• Infected 1 million machines
• Damages estimated at 2.6 billion (newer
  estimates much higher)
• SirCam virus
• Infected 2.3 million machines
• Damages 1.2 billion
• Klez virus
• Infected 900,000 machines
• Nimda virus
• Damages estimated at 700 million

Source Bill Wall, Harris computer Corp
7
S/W Security Problem

• O/S security alerts since Jan 2002
  --www.securitytracker.com
• Windows 636
• Linux 759
• 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
• 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

8
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
• 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
• 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
• 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

9
Evolving DB Threat Environment

• A decade ago, databases were
• Physically secure
• Housed in central data centers not distributed
• External access mediated through customer service
  reps, purchasing managers, etc.
• Security issues rarely reported
• Now increasingly DBs externally accessible
• Suppliers directly connected
• Customers directly connected
• Customers partners directly sharing data
• Data is most valuable resource in application
  stack
• 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.securitytrac
  ker.com
• Two database issues on SANS/FBI top 20 list
  http//www.sans.org/top20/

10
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
• Symbols typically available for problem
  determination
• Leveraging cracked systems
• Credentials leverage escalate by steps
• Compute power host distributed denial of service
• DB Security/cracking tools consulting
• NGSSoftware (http//www.nextgenss.com/)
• Internet Security Services (http//www.iss.net/)
• Application Security Inc. (http//www.appsecinc.co
  m)
• And many others
• Community shared resources
• Exploit, risk, data sharing the community
• E.g. NTBugTraq (http//www.ntbugtraq.com/)

11
Who Cracks DBs? tale of two crackers

• Who Cracks DBs?
• Black Hats in search of gain or damage
• Security Professional Services
• Individuals in search of fame
• I encounter many of these folks although
  typically not black hats
• They dont often report issues to a vendor
• Most commercial DB security issues not found in
  operational systems
• Examples from people Ive worked with
• Consulting Firm, a company establishing their
  name as security experts
• Individual, a programmer making mark in security
  circles

12
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
• Cant afford to be perceived as Black Hats by
  potential customers
• Usually give time for problems to be fixed before
  disclosure
• Some learn that its 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

13
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

14
DB Attack Admin Error

• Impossible to cover all forms of attack
• Numerous and some not yet known
• Well 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
• DBs should enforce strong password policy

15
DB Attack Buffer Overrun

• Buffer Overrun
• Any command that takes an argument or bounded
  buffer has overflow risk
• Overflow data can be crafted to include
  executable but how to force execution?
• Stack smashing
• Register hijacking
• Local pointer subterfuge
• V-Table hijacking
• C EH clobbering
• SEH clobbering
• Parameter pointer subterfuge
• Lets look at some examples

16
DB Attack Buffer Overrun Exploits
Previous functions stack frame

• x86 stacks grow downward
• Buffer overrun on stack can rewrite
• Return address
• Frame pointer
• EH frame
• Exploit usually involves privilege escalation

Function arguments
Return address
Frame pointer
EH frame
Local variables andlocally declaredbuffers
Callee saveregisters
Garbage
17
DB Attack SQL Injection

• Exploiting SQL comment
• Select from customers where nameinput
• With input JamesRH or 11 --
• Select from customers where nameJamesRH or
  11 -
• Exploiting multiple commands and SQL comment
• Select from customers where nameinput
• With input or 11 exec xp_cmdshell
  NT_command --
• Select from customers where nameor 11 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

18
DB Attack Code Patching

• Innovative attack that cant 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 cant 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
• Source http//www.nextgenss.com/papers/violating_
  database_security.pdf

19
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
• Fail bad passwords slowly with min-resources
  consumed
• Can do IP tracking but spoofable
• Distributed denial of services uses many machines
  to attack target
• 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

20
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
• It takes too long for a password to fail (built
  in delays are often employed)
• Failed password attempts are typically audited
• 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/Ss
• 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 isnt 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

21
DB Attack PWs in files

• Very common attack vector through DB passwords
  stored on other systems
• Web-server may store logins
• Should run webserver as low priv account and use
  NT authentication at DB
• Install programs can store logins
• 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

22
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

23
Defense Dev Admin Actions

• Weak service account
• Cracked DB wont get access to rest of enterprise
• Weak access accounts
• Mid-tier account only capable of min needed to
  run app
• Two-tier users with min access
• Smallest possible admin groups
• Dont put all enterprise admins in one group
• Never place DB unprotected on public net
• Nor on private net
• Firewall protected
• S/W mediating database access
• Use NT authentication rather than DB auth
• Leading DBs all provide both
• Strong PWs with enforcement
• 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.

24
Defense Dev Admin Actions

• Track usage pattern changes
• E.g. TP systems should NEVER table scan
• Future direction for DB security will exploit
  tracking unusual access patterns
• Media security including backups
• Assume damage possible and have aggressive backup
  policy
• Test disaster recovery system
• Only install and configure needed features
• Replication, management tools, stored procedures,
  
• Full audit of all failed events
• 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
• Never trust user input
• Dont show developer quality error messages to
  users
• Bound user input size and test application at max
  size

25
Defense DB Implementation

• Secure default Installation
• Weak defaults result from ease of use focus and
  past reduced threat environment
• Best practices scanner (Microsoft Baseline
  Security Analyzer)
• Secure examples in books, documentation, and all
  customer communications
• Support sub-set feature installs
• Minimize attack surface area
• Support auto-update for security fixes
• E.g. Windows update delivery of server-side
  security fixes
• Simplify security sub-systems
• Admin error common cause of failure
• Provide fine grained, policy based access
  controls
• E.g. Row level security
• Support multi-tier security W/O fully provisioned
  DB tier
• Most applications dont provision all users in DB
  tier
• Defense in depth avoid single failure security
  exposures

26
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

27
Defense DB Implementation

• Use great tools Compiler runtime, code
  generation and host operating system support
• Operating System Support Example
• .Net Server enforces that exception handlers be
  marked by the compiler as handlers
• Prevents exception handling hijacking
• Compiler Support Example
• 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
• Wont 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

28
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

29
Summary

• S/W vulnerability report frequency increasing
• Database is the most valuable asset
• Black Hats know it
• Database vulnerability reports becoming common
  this year
• DB vulnerabilities unusual in even recent past
• Need multi-tier protection
• Application developer administrator best
  practices
• Simplification of security featuresFewer 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

30
Microsoft