Break it while you make it

writing (more) secure software

Leigh HoneywellHackLab.toleigh@hypatia.cahttp://twitter.com/hypatiadotca

About Me

Co-Founder and Board Member of HackLab.TO

Advisor to the SecTor Security Conference

U of T student

Malware Operations Engineer at a major anti-virus vendor (who I am not speaking as a representative of)

Why I'm here

To talk about the core security principles developers need to know

To get you thinking like the people who will try to break your app

To show some nifty tools

Maybe to scare you a little?

To get you breaking your own apps :)

#3hotsecurewords

There are three core pillars of information security:Confidentiality

Integrity

Availability

Confidentiality

Only allow access to data for which the user is permitted.

The user may not be permitted anything!

Sometimes called secrecy or privacy

There are real consequences for failing at this PIPEDA, HIPAA, PCI-DSS, and various other acronyms.

Integrity

Ensure data is not tampered with or altered by unauthorized users.

Availability

Ensure systems and data are available to authorized users when they need it.

Without this, the others don't matter.

Anyone remember Friendster?

Vulnerabilities

Vulnerabilities

A vulnerability is an error made in a program, causing unintended behavior of the program in a way that affects security negatively.FIRST defines a vulnerability as: a bug, flaw, weakness, or exposure of an application, system, device, or service that could lead to a failure of confidentiality, integrity, or availability.

Vulnerabilities

Examples of vulnerabilities:Weak passwords

Insecure permissions

Directory traversal

Buffer overflows

Cross-site scripting and request forgery

Exploits

Exploits

An exploit is a specific example of triggering a vulnerability.

If the vulnerability is a missile, the exploit is the warhead.

Exploits

Examples of exploits:Morris WormAlmost everything at http://www.milw0rm.com/http://www.example.com/displayfile.php?../../../../etc/passwd

Exploits

Easy way to think about it:If typing perl e print A x 10000; makes it crash, youve found a vulnerabilityIf you end up with this, youve got a working exploit:bash-3.00# id uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys), 4(tty), 5(operator), 20(staff), 31(guest), 45(utmp)

The Security Mindset

How many security features are there in a grocery store self-check-out?

How can you break each of them?

What did they forget to think of?

Bruce Schneier on the mindset: http://tinyurl.com/2sj365

The Security Mindset

How many of you opened that tinyurl?What if I'd just dropped a Firefox 0-day on you?

I didn't, don't worry.
That would get me fired.

This is why I suck at programming

I'm immersed in this stuff, and got into it before I had much coding under my belt. Trying to get me to sit down and write extensive code will result in my coming up with every way it won't work.

Finding Balance

Not all "harmless failures" lead to big trouble, but it's surprising how often a clever adversary can pile up a stack of seemingly harmless failures into a dangerous tower of trouble. Harmless failures are bad hygiene. We try to stamp them out when we can.

Ed Felten, Freedom to Tinkerhttp://preview.tinyurl.com/c6ewzv

Security Architecture

The OWASP Secure Coding Principles puts it thus:

Security architecture starts on the day the business requirements are modeled, and never finish until the last copy of your application is decommissioned. Security is a life-long process, not a one shot accident.

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

Right from the Start

When starting a new application or re-factoring an existing application, you should consider each functional feature, and consider:Is the process surrounding this feature as safe as possible? In other words, is this a flawed process?

If I were evil, how would I abuse this feature?

Is the feature required to be on by default? If so, are there limits or options that could help reduce the risk from this feature? (also from OWASP)

Andrew van der Stock calls the above process Thinking Evil, and recommends putting yourself in the shoes of the attacker and thinking through all the possible ways you can abuse each and every feature, by considering the three core pillars and using the STRIDE model in turn

Security in the Bones

Software design, as well as implementation, must consider the three pillars of information security.

Otherwise, you're going to fail.

10 Principles

Minimize attack surface areaEstablish secure defaults

Least privilegeDefense in depth

Fail securelyDont trust services

Separation of dutiesAvoid security through obscurity

Keep security simpleFix security issues correctly

The OWASP guide gives 10 principles for writing secure code:

10 Principles

Minimize attack surface areaGive the attacker the absolute minimum possible to work with when trying to discover an attack. By reducing complexity of an application, the number of possible vulnerabilities is also reduced.

Establish secure defaultsIf a variable level of security is desired, have the default be high, and leave it up to the user to make the decision to lower it. This prevents out of the box insecurities.

Vulnerabilities increase the more code there (duh), but also based on who has access to what. If only logged in users will need the help system, only let them see it decreases surface.

Can be seen as an argument against creeping featurism, but it's more about who sees what.

We've come along way on the second one here today when I install postfix on an Ubuntu or Fedora machine, I know it's not going to be an open relay. It didn't used to be like that.

10 Principles

Least privilegeAny component of a system should have only as much privilege as necessary to function properly. This is best known for permissions on user accounts, but also applies to software components.

Defense in depthAdding on more security methods is a good thing, but they must approach the problem in different ways.

LP is pretty self-explanatory

DID there's little use adding a second lock to your front door it'll only take me a few more seconds to pick it. Add an alarm system though....

Defense in Depth

10 Principles

Fail securelyA system should be designed with the idea of failing securely in mind. At any point, if something goes wrong, the system should not be left in a less secure state.

Dont trust servicesEven if external data is coming from a trustworthy source, give it the same level of validation as any input that isnt trusted.

Allow / Disallow / Exception exception should also disallow.

Just because you trust them now, doesn't mean that their reliability won't change, or that they currently have the same security policy and posture as you do

10 Principles

Separation of dutiesSystem roles should be considered when giving out privileges. Administrators of a system generally arent also users; while some super-user privileges may be needed to run the system, administrators dont necessarily need the ability to do anything.

Avoid security through obscuritySecurity through obscurity isnt real security. Use Kerckhoffs assumption: the attacker knows all of the details as to how the system works.

Sep of duties is a wider concept in information security, but here it refers to what you can do in a system. The shopping card admin shouldn't also be able to buy stuff.

Kerckhoff's principle is a longstanding one in cryptography, and the principle has been established since even before that in locksmithing the original full-disclosure debate.

10 Principles

Keep security simpleSimple things are harder to break. The least complex solution which achieves a goal is probably the better solution.

Fix security issues correctlyAny problem that is being fixed needs to be treated as an actual problem, and not a symptom. The fix must go through the entire security process the same as new code; a fix isnt a real fix if it introduces new problems.

The specific example they use here is of faddish software eng methods which end up using a lot of code vulnerable code to do potentially simple things. Consider complexity when you choose external libraries.

Fix Security Issues Correctly

It was in the news again days later, when it turned out the fix wasn't a fix.

Common Vulnerabilities

C? C++?

Buffer Overflows (stack and heap)

Read this, it's ancient but seminal: http://insecure.org/stf/smashstack.html

Format String Vulnerabilities

Integer Overflows

Memory Management

Race Conditions

Tools

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

http://en.wikipedia.org/wiki/Dynamic_program_analysis

http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

Don't turn off Valgrind unless you know what you're doing (o hai OpenSSL)

Another OWASP List!

Top Ten Most Critical Web Application Security Vulnerabilities2007 Version

A1 Cross Site Scripting (XSS)

XSS flaws occur whenever an application takes user supplied data and sends itto a web browser without first validating or encoding that content. XSS allowsattackers to execute script in the victims browser which can hijack usersessions, deface web sites, possibly introduce worms, etc.

A1 Cross Site Scripting (XSS)

window.alert("meow")

A1 Cross Site Scripting (XSS)

A2 Injection Flaws

Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attackers hostile data tricks the interpreter into executing unintended commands or changing data.

A2 Injection Flaws

A3 - Malicious File Execution

Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users.

A4 - Insecure Direct Object Reference

A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.

Bug in flickr where you could see photos that were marked as private if you browsed to the url

A5 - Cross Site Request Forgery (CSRF)

A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.

Clickjacking is a form of this remember Don't click on this link on twitter?

* Ensure that there are no XSS vulnerabilities in your application (see A1 Cross Site Scripting) * Insert custom random tokens into every form and URL that will not be automatically submitted by the browser. For example,

A6 - Information Leakage and Improper Error Handling

Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks.

A6 - Information Leakage and Improper Error Handling

http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project

Firebug on steroidsHas great documentation

A7 - Broken Authentication and Session Management

Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities.

Is your login page on ssl? Is the rest of your app? Well then you can be hijacked.

If passwords are changed, does this reset all open sessions?

(I'm looking at you, Twitter, and your slow oauth pickup, for encouraging bad practices)

A8 - Insecure Cryptographic Storage

Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.

Most importantly of all, do you store salted + hashed passwords ONLY?

Wordpress issue only started salting recently

PCI-DSS implications

A9 - Insecure Communications

Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.

A9 - Insecure Communications

A10 - Failure to Restrict URL Access

Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.

Guessing and google hacking

Code that evaluates privileges on the client but not on the server

Block access to all file types that your application should never serve (xml, etc)

Free macworld pass from 2007 browser-side validation.

What next?

http://www.owasp.org/index.php/Top_10_2007-Where_to_Go_From_Here

Do some learning

http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project

I can't speak highly enough of this project

http://www.foundstone.com/us/resources-free-tools.asp

Foundstone teaching tools (the HacMe series, in a variety of languages)

http://tinyurl.com/hackarchive

The Hacker Media archive decades / terabytes worth of Defcon and other talks.

Local AppSec Resources

TASK - http://task.to , security user group

OWASP Toronto Chapter - http://www.owasp.org/index.php/Toronto

SECtor Security Conference - http://sector.ca , October 5-7

HackLabTO - http://hacklab.to , free workshops and classes starting this spring

Further Reading

And just about everything on http://www.owasp.org

Writing Secure Code, 2nd Edition: Michael Howard and David LeBlanc, Microsoft Press (2003)

Hacking: The Art Of Exploitation, 2nd Edition: Jon Erickson, No Starch Press (2008)

Thanks

My coworker Seth Hardy, whose appsec notes I built on

SecurityCompass for making awesome tools

OWASP for being such a great resource

Remember one thing!

Never trust user-supplied data.

Any Questions?

Click to edit the title text format