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 modification

• 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

• Insufficient authorization

• Insufficient authentication

• Information leakage

http://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 day

http://www.webappsec.org/projects/whid/list_year_2007.shtml

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

http://news.bbc.co.uk/2/hi/technology/6943385.stm

UN's website breached by hackers

ADODB.Recordset.1 error '80004005'

SQLState: 37000Native Error Code: 8180SQLState: 37000Native Error Code: 105[MERANT][ODBC SQL Server Driver][SQL Server]Unclosed quotation mark before the character string ''.[MERANT][ODBC SQL Server Driver][SQL Server]Statement(s) could not be prepared.

/apps/news/infocus/sgspeeches/statments_full.asp, line 26

http://www.un.org/apps/news/infocus/sgspeeches/statments_full.asp?statID=105'

As you can easily verify by opening this URL, the site is vulnerable to an attack called SQL Injection.This is a very well known kind of vulnerability, fairly easy to avoid and very surprising to find in such a high profile web site. [3]

http://hackademix.net/2007/08/12/united-nations-vs-sql-injections/

While most of us may agree with the message, many will object to the spelling, and specifically to the dont used instead of don’t.There’s a technical reason for the missing apostrophe, though, because messing with this very character (’) is part of the technique apparently used by the attackers.

If only prepared SQL statements were used properly*, this embarrassing incident would have been easily prevented.And yes, prepared statements are available even in the very obsolete ASP “Classic” + ADODB Microsoft setup they’ve got. (screenshot)*properly means strictly constant statement strings and type checked bound parameters, see Roland Bouman’s comment and my answer below.

I will write some other time about prepared statements and database layer security.In the meanwhile, if you’re a planetary organization and you’re planning to cut the budget for the security training of your web developers staff, please dont… er… do not ;)

SQL Injection

• Main attack; part of most attacks

• Basic SQL Injection

• Blind SQL Injection

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

www.watchfire.com

12 most common, 7-12

• forceful browsing

• http response splitting

• stealth

• 3rd party misconfiguration

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

• Separate users

• Separate privileges

Don’t trust servicesMany organizations utilize the processing capabilities of third party partners, who more than likely have differing security policies and posture than you. It is unlikely that you can influence or control any external third party, whether they are home users or major suppliers or partners.

Therefore, implicit trust of externally run systems is not warranted. All external systems should be treated in a similar fashion.

For example, a loyalty program provider provides data that is used by Internet Banking, providing the number of reward points and a small list of potential redemption items. However, the data should be checked to ensure that it is safe to display to end users, and that the reward points are 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

http://web.mit.edu/Saltzer/www/publications/protection/Basic.html

“Keep the design as simple and small as possible. This well-known principle applies to any aspect of a system, but it deserves emphasis for protection mechanisms for this reason: design and implementation errors that result in unwanted access paths will not be noticed during normal use (since normal use usually does not include attempts to exercise improper access paths). As a result, techniques such as line-by-line inspection of software and physical examination of hardware that implements protection mechanisms are necessary. For such techniques to be successful, a small and simple design is essential.”

Fix security issues correctlyOnce a security issue has been identified, it is important to develop a test for it, and to understand the root cause of the issue. When design patterns are used, it is likely that the security issue is widespread amongst 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 balance by adjusting their cookie. The fix seems to be relatively straightforward, but as the cookie handling code is shared amongst all applications, a change to just one application will trickle through to all otherapplications. The fix must therefore be tested on all affected applications.

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 possible

http://www.owasp.org/index.php/How_to_write_insecure_code

How to write unmaintainable code

http://mindprod.com/jgloss/unmain.html

In the interests of creating employment opportunities in the Java programming field, I am passing on these tips from the masters on how to write code that is so difficult to maintain, that the people who come after you will take years to make even the simplest changes. Further, if you follow all these rules religiously, you will even guarantee yourself a lifetime of employment, since no one but you has a hope in hell of maintaining the code. Then again, if you followed all these rules religiously, even you wouldn't be able to maintain the code!

You don't want to overdo this. Your code should not look hopelessly unmaintainable, just be that way. Otherwise it stands the risk of being rewritten or refactored.

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 has your giant program. He has no time to read it all, much less understand it. He wants to rapidly find the place to make his change, make it and get out and have no unexpected side effects from the change.

He views your code through a toilet paper tube. He can only see a tiny piece of your program at a time. You want to make sure he can never get at the big picture from doing that. You want to make it as hard as possible for him to find the code he is looking for. But even more important, you want to make it as awkward as possible for 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 a magnifying 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 dedicated to enabling organizations to develop, purchase, and maintain applications that can be trusted. All of the OWASP tools, documents, forums, and chapters are free and open to anyone interested in improving application security. We advocate approaching application security as a people, process, and technology problem because the most effective 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 allows us to provide unbiased, practical, cost-effective information about application security. OWASP is not affiliated with any technology company, although we support the informed use of commercial security technology. Similar to many open-source software projects, OWASP produces many types of materials in a collaborative, open way. The OWASP Foundation is a not-for-profit entity that ensures the project's long-term success.

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) never passed

Be careful out there!