Commercial Database Security Issues

1. Commercial Database Security Issues James Hamilton JamesRH@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 Vectors—How 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 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

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,… • 1994: Vladimir Levin cracks CitBank network Source: Bill Wall, Harris computer Corp

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 • Source: IDC 2001

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 DB’s 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.securitytracker.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.com) • And many others… • Community shared resources: • Exploit, risk, & data sharing the community • E.g. NTBugTraq (http://www.ntbugtraq.com/)

11. Who Cracks DB’s?: 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 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: • 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 • 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

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

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 • Let’s look at some examples

16. DB Attack: Buffer Overrun Exploits Previous function’s 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 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

18. 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 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/S’s • 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

21. DB Attack: PW’s 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 won’t 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 • Don’t 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 • Don’t 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 don’t 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 • 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

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

30. Microsoft