How to Destroy a Database

How to destroy a database John Ashmead

Six dumbest ideas in computer security • default permit • enumerating badness • penetrate & patch (turd polishing) • hacking is cool • educating users • action is better than inaction http://www.ranum.com/index.html

• Attacks• Defenses• Principles• How to write insecure code• Where to go for more

Attacks• Unauthorized information release• Unauthorized information modiﬁcation• Unauthorized denial of use

Attackers• Disgruntled staff or developers• “Drive by attacks”, i.e. side effects of malware• Criminal attacks• Defacers• Script kiddies

Most common attacks• SQL Injection• Insufﬁcient authorization• Insufﬁcient authentication• Information leakagehttp://www.webappsec.org/projects/whid/statistics.shtml

40 incidents in media for 2007 • Defacement • Money • Medical data • Budget for US spy agencies • Personal data (i.e. SS#’s) • Unauthorized snow dayhttp://www.webappsec.org/projects/whid/list_year_2007.shtml

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 screenshothttp://news.bbc.co.uk/2/hi/technology/6943385.stm

http://hackademix.net/2007/08/12/united-nations-vs-sql-injections/As 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 ﬁnd in such a high proﬁleweb site. [3]http://www.un.org/apps/news/infocus/sgspeeches/statments_full.asp?statID=105ADODB.Recordset.1 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

While most of us may agree with the message, many willobject to the spelling, and speciﬁcally 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 ;)

SQL Injection • Main attack; part of most attacks • Basic SQL Injection • Blind SQL Injectionsee also: Advanced SQL Injection - Victor Chapela - at OWASP

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;

12 most common attacks, 1-6• cookie poisoning• hidden field manipulation• parameter tampering• buffer overflow• cross-site scripting• backdoor & debug optionswww.watchfire.com

12 most common, 7-12• forceful browsing• http response splitting• stealth• 3rd party misconﬁguration• known vulnerabilities• xml & web services vulnerabilities

Privilege escalation • Horizontal privilege escalation • Vertical privilege escalation www.watchfire.com

Defenses • Good code is a prerequisite for secure code • Build security in from the start • Use existing tools as much as possible

Taint mode• pert -T• data from outside has to be scrubbed before it can be used unsafely• plumbing model of data: data presumed dirty

Data Validation Strategies• Exact match• Known good• Reject known bad• Sanitize• Prayer

Quoting• Sanitize strategy• Use database supplied function; do not role your own• Consider rejection

Bind variables• Use with prepared SQL (also a good idea)• Takes advantage of built in type-checking• In accord with “trust no-one”

Perl’s DBI• generic interface• prepare & bind calls available• logging available• much better than building your own!www.cpan.org

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

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

What to log• Session open/close• Authentication• Authorization requests• CUD: Create, Update, Delete• Errors & exceptions

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!

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

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

Principles • Good code establishes foundation for secure code • Build security in from start • Trust no one

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

Complete mediation• Check every access• Be able to track every authorization (i.e. in logs)• Be skeptical of worries about performance (usually over-stated)

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

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

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!

Separation • Separate users of duties • Separate privileges

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 inﬂuence 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.http://www.owasp.org/index.php/Secure_Coding_Principles

Avoid security by obscurity • Assume they have your source code • In fact, if the source code is public, outside reviewers can check!

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.”http://web.mit.edu/Saltzer/www/publications/protection/Basic.html

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

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 possiblehttp://www.owasp.org/index.php/How_to_write_insecure_code

How to write unmaintainable codeIn the interests of creating employment opportunities in the Javaprogramming ﬁeld, I am passing on these tips from the masters onhow to write code that is so difﬁcult 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.http://mindprod.com/jgloss/unmain.html

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 ﬁnd 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 ﬁnd 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.

Where to go next • Use the web, Luke! • www.owasp.org • Security articles on MySQL, Perl,...

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 http://www.owasp.org.OWASP 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 afﬁliated 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-proﬁt entity that ensures the projects long-termsuccess.

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

Be careful out there!

How to Destroy a Database

by akmed13

Accessibility

Categories

Upload Details

Usage Rights

Statistics

How to Destroy a Database Presentation Transcript