How to Destroy a Database


Published on

Talk on threats to database security. The title is, of course, deadly serious. Wile E. Coyote & other experts on correctness & security are enlisted to help make key points.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

How to Destroy a Database

  1. 1. How to destroy a database John Ashmead
  2. 2. Six dumbest ideas in computer security • default permit • enumerating badness • penetrate & patch (turd polishing) • hacking is cool • educating users • action is better than inaction
  3. 3. • Attacks• Defenses• Principles• How to write insecure code• Where to go for more
  4. 4. Attacks• Unauthorized information release• Unauthorized information modification• Unauthorized denial of use
  5. 5. Attackers• Disgruntled staff or developers• “Drive by attacks”, i.e. side effects of malware• Criminal attacks• Defacers• Script kiddies
  6. 6. Most common attacks• SQL Injection• Insufficient authorization• Insufficient authentication• Information leakage
  7. 7. 40 incidents in media for 2007 • Defacement • Money • Medical data • Budget for US spy agencies • Personal data (i.e. SS#’s) • Unauthorized snow day
  8. 8. UNs website breached by hackers The United Nations web site has been defaced this morning. The speeches of the Secretary-General Ban Ki-Moon [2] have been replaced with the following lines: Hacked By kerem125 M0sted and Gsy That is CyberProtest Hey Ýsrail and Usa dont kill children and other people Peace for ever No war screenshot
  9. 9. you can easily verify by opening this URL, the site isvulnerable to an attack called SQL Injection.This is a very well known kind of vulnerability, fairly easyto avoid and very surprising to find in such a high profileweb site. [3] error 80004005SQLState: 37000Native Error Code: 8180SQLState: 37000Native Error Code: 105[MERANT][ODBC SQL Server Driver][SQL Server]Unclosed quotationmark before the character string .[MERANT][ODBC SQL Server Driver][SQL Server]Statement(s) couldnot be prepared./apps/news/infocus/sgspeeches/statments_full.asp, line 26
  10. 10. While most of us may agree with the message, many willobject to the spelling, and specifically to the dont used insteadof don’t.There’s a technical reason for the missing apostrophe, though,because messing with this very character (’) is part of thetechnique apparently used by the attackers.If only prepared SQL statements were used properly*, thisembarrassing incident would have been easily prevented.And yes, prepared statements are available even in the veryobsolete ASP “Classic” + ADODB Microsoft setup they’ve got.(screenshot)*properly means strictly constant statement strings and typechecked bound parameters, see Roland Bouman’s commentand my answer below.I will write some other time about prepared statements anddatabase layer security.In the meanwhile, if you’re a planetary organization and you’replanning to cut the budget for the security training of your webdevelopers staff, please dont… er… do not ;)
  11. 11. SQL Injection • Main attack; part of most attacks • Basic SQL Injection • Blind SQL Injectionsee also: Advanced SQL Injection - Victor Chapela - at OWASP
  12. 12. Basic SQL Injectionselect * from items where owner = `$hacker’and itemname = `$itemname’;name’ or ‘a’ = ‘a’;--select * from items where owner =‘hacker’ and itemname = ‘ name’or ‘a’ = ‘a’;--’;select * from items;
  13. 13. 12 most common attacks, 1-6• cookie poisoning• hidden field manipulation• parameter tampering• buffer overflow• cross-site scripting• backdoor & debug
  14. 14. 12 most common, 7-12• forceful browsing• http response splitting• stealth• 3rd party misconfiguration• known vulnerabilities• xml & web services vulnerabilities
  15. 15. Privilege escalation • Horizontal privilege escalation • Vertical privilege escalation
  16. 16. Defenses • Good code is a prerequisite for secure code • Build security in from the start • Use existing tools as much as possible
  17. 17. Taint mode• pert -T• data from outside has to be scrubbed before it can be used unsafely• plumbing model of data: data presumed dirty
  18. 18. Data Validation Strategies• Exact match• Known good• Reject known bad• Sanitize• Prayer
  19. 19. Quoting• Sanitize strategy• Use database supplied function; do not role your own• Consider rejection
  20. 20. Bind variables• Use with prepared SQL (also a good idea)• Takes advantage of built in type-checking• In accord with “trust no-one”
  21. 21. Perl’s DBI• generic interface• prepare & bind calls available• logging available• much better than building your own!
  22. 22. Stored procedures• isolate users from database changes• isolate database from hostile users• makes it easy to install gatekeeper functions• makes it easy to log all access• only practical way to get SOX compliance
  23. 23. Do not use dynamic SQL• Often a sign of poor design• Hard to debug• Easy to corrupt, especially if the table names are dynamic• Use stored procedures or, at a minimum, prepared SQL and bind variables
  24. 24. What to log• Session open/close• Authentication• Authorization requests• CUD: Create, Update, Delete• Errors & exceptions
  25. 25. How to manage logs• Logs have to be highly secure• Don’t write user-supplied data into the logs• Automate log scanning: everything not uninteresting is interesting!
  26. 26. Error handling• Uniform error handling (i.e. library routines)• Don’t tell the user stuff he/she doesn’t need to know• Review error logs
  27. 27. Backup & restore• Last resort recovery (in case of defacement and the like)• Intruder tracking (old versus new)• Backup data must be protected as well as original data
  28. 28. Principles • Good code establishes foundation for secure code • Build security in from start • Trust no one
  29. 29. Minimize attack surface area • Every feature weakens the system • Do not show the outside world more than you need to • Code that doesn’t exist can’t break
  30. 30. Complete mediation• Check every access• Be able to track every authorization (i.e. in logs)• Be skeptical of worries about performance (usually over-stated)
  31. 31. Least privilege• every user gets only the privileges they need• reduces damage from errors• reduces complexity of interactions, making system more reliable• makes incident response easier
  32. 32. Defense in depth• Fortress principle• Assume client data is corrupt• Assume client-side code is corrupt• Assume network has been penetrated• Assume server has been hacked• And don’t trust yourself, either
  33. 33. Fail securely• Default should be to deny access• If you have been over-rigid, that will show up quickly in testing.• But if you are under-rigid, that will not show up in testing!
  34. 34. Separation • Separate users of duties • Separate privileges
  35. 35. Don’t trust servicesMany organizations utilize the processing capabilities of third partypartners, who more than likely have differing security policies andposture than you. It is unlikely that you can influence or control anyexternal third party, whether they are home users or major suppliers orpartners.Therefore, implicit trust of externally run systems is not warranted. Allexternal systems should be treated in a similar fashion.For example, a loyalty program provider provides data that is used byInternet Banking, providing the number of reward points and a small listof potential redemption items. However, the data should be checked toensure that it is safe to display to end users, and that the reward pointsare a positive number, and not improbably large.
  36. 36. Avoid security by obscurity • Assume they have your source code • In fact, if the source code is public, outside reviewers can check!
  37. 37. KISS“Keep the design as simple and small as possible. Thiswell-known principle applies to any aspect of a system,but it deserves emphasis for protection mechanisms forthis reason: design and implementation errors that resultin unwanted access paths will not be noticed duringnormal use (since normal use usually does not includeattempts to exercise improper access paths). As a result,techniques such as line-by-line inspection of software andphysical examination of hardware that implementsprotection mechanisms are necessary. For suchtechniques to be successful, a small and simple design isessential.”
  38. 38. Fix security issues correctlyOnce a security issue has been identified, it is important to develop atest for it, and to understand the root cause of the issue. When designpatterns are used, it is likely that the security issue is widespreadamongst all code bases, so developing the right fix without introducingregressions is essential.For example, a user has found that they can see another user’s balanceby adjusting their cookie. The fix seems to be relativelystraightforward, but as the cookie handling code is shared amongst allapplications, a change to just one application will trickle through to allotherapplications. The fix must therefore be tested on all affectedapplications.OWASPGuide2.0.1.pdf
  39. 39. How to write insecure code• Use dynamic code• Rely on security being done elsewhere• Use logs to debug• Build your own encryption/authentication• Validation is for wusses• Make development as complex & free form as possible
  40. 40. How to write unmaintainable codeIn the interests of creating employment opportunities in the Javaprogramming field, I am passing on these tips from the masters onhow to write code that is so difficult to maintain, that the people whocome after you will take years to make even the simplest changes.Further, if you follow all these rules religiously, you will even guaranteeyourself a lifetime of employment, since no one but you has a hope inhell of maintaining the code. Then again, if you followed all these rulesreligiously, even you wouldnt be able to maintain the code!You dont want to overdo this. Your code should not look hopelesslyunmaintainable, just be that way. Otherwise it stands the risk of beingrewritten or refactored.
  41. 41. H2RiteUnMCd “Quidquid latine dictum sit, altum sonatur.” “Whatever is said in Latin sounds profound.”To foil the maintenance programmer, you have to understand how he thinks. He hasyour giant program. He has no time to read it all, much less understand it. He wantsto rapidly find the place to make his change, make it and get out and have nounexpected side effects from the change.He views your code through a toilet paper tube. He can only see a tiny piece of yourprogram at a time. You want to make sure he can never get at the big picture fromdoing that. You want to make it as hard as possible for him to find the code he islooking for. But even more important, you want to make it as awkward as possiblefor him to safely ignore anything.Programmers are lulled into complacency by conventions. By every once in a while,by subtly violating convention, you force him to read every line of your code with amagnifying glass.You might get the idea that every language feature makes code unmaintainable --not so, only if properly misused.
  42. 42. Where to go next • Use the web, Luke! • • Security articles on MySQL, Perl,...
  43. 43. OWASPAbout The Open Web Application Security Project(Redirected from About OWASP)OverviewThe Open Web Application Security Project (OWASP) is an open community dedicatedto enabling organizations to develop, purchase, and maintain applications that can betrusted. All of the OWASP tools, documents, forums, and chapters are free and open toanyone interested in improving application security. We advocate approachingapplication security as a people, process, and technology problem because the mosteffective approaches to application security include improvements in all of these areas.We can be found at is a new kind of organization. Our freedom from commercial pressures allowsus to provide unbiased, practical, cost-effective information about application security.OWASP is not affiliated with any technology company, although we support theinformed use of commercial security technology. Similar to many open-source softwareprojects, OWASP produces many types of materials in a collaborative, open way. TheOWASP Foundation is a not-for-profit entity that ensures the projects long-termsuccess.
  44. 44. A study conducted by Sanctum(acquired by Watchfire in 2004) ofover 100 applications at largecorporate and government sitesplaces some hard numbers onsecurity failure rates. The studyfound that 92 percent of allapplications failed securitytesting conducted in theintegration or production stages.The average time to fix the errorswas 2.5 months, and the cost tothe business team averaged $25M.When the failed applicationswere tested again, 20 percent (16percent of the total) securitytesting failed a second time. Halfof these re-failed applications (8 percent of the total) neverpassed
  45. 45. Be careful out there!
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.