(software) security erik poll digital security group radboud university nijmegen

(Software) Security

Erik PollDigital Security group

Radboud University Nijmegen

2

A brief history of security problems

• attacks on multi-user UNIX systems for fun• viruses & worms attacking operating systems

– due to buffer overflow, format string attacks, integer overflows,...

– response: firewalls & better operating system code– variant: bot-nets

• attacks on web-applications– due to SQL injection, XSS, session riding, .... – response: intrusion detection systems & application

firewalls• attacks on web-browsers

– man-in-the-browser attacks• ...

3

A brief history of security problems

• Trojans & spyware– installed via OS security hole, or silly user

• spam– response: spam filters– variants: phishing, spear-phishing & whaling, spit

• ...

4

Trend

• move away from hacking for 'fun' (ie vandalism)

to hacking for profit

– zero-day exploits are worth a lot of money

5

Causes

Important causes of these security problems • bad software

– buggy OS software, web-application software, ...

– solution: patching?• gullible & stupid users

– too easy to just blame users: if they are gullible and stupid, they should be protected

– solution: user education?

6

Security is about people (users, employees, sys-admins,

programmers,...), incompetence, confusion, lethargy, stupidity, mistakes, access control, passwords, biometrics, cryptology,

protocols, policies & their enforcement, monitoring, auditing, legislation, persecution, liability, risk management, complexity, software, bugs, verification, hackers, viruses, hardware, operating systems, networks, databases, public relations, public perception, conventions,

standards, physical protection, data protection, ...

7

Security is about people (users, employees, sys-admins,

programmers,...), incompetence, confusion, lethargy, stupidity, mistakes, access control, passwords, biometrics, cryptology,

protocols, policies & their enforcement, monitoring, auditing, legislation, persecution, liability, risk management, complexity, software, bugs, verification, hackers,

viruses, hardware, operating systems, networks, databases, public relations, public perception, conventions,

standards, physical protection, data protection, ...

8

Cryptography is usually not the problem

"Using encryption on the Internet is the equivalent of arranging an armored car to deliver credit card information from someone living in a cardboard box to someone living on a park bench."

-- Gene Spafford

9

Root cause analysis

• Security is always a secondary concern– primary goal of software is to provide some

functionality or services– managing the associated risks is only a

derived or secondary concern

• There is often a trade-off/conflict between – security– functionality & convenience

10

"The only system which is truly secure is one which is switched off and unplugged, locked in a titanium-lined safe, buried in a concrete bunker, and surrounded by nerve gas and very highly paid armed guards.

Even then, I wouldn't stake my life on it”

-- Gene Spafford

11

What goes wrong?

• at a high-level– not understanding the security

requirements and threats

• at a low-level– silly little program bugs or flaws that

introduce vulnerabilities

12

How can we improve things?

• at a high-level– seriously looking at security requirements

and threats when (prior to) building systems

• at a low-level– train programmers to be aware of pitfalls

associated with programming language, OS, platform

– improve these languages, OSs, platform• making them less error-prone

low-level

14

Security as secondary concern

• in programming languages– Algol 60 introduces array bound checks, in

1960– C doesn't use this, in 1970s ...

– ... 3 decades later, we're still trying to get rid of buffer overflows

– early 2000s: people start using safestr.h

15

Security as secondary concern

• in training– many students learn programming in C(++)– nobody tells them about buffer overflows or

safestring libraries

– a case of criminal negligence?

16

Functionality vs security

Lost battles?• operating systems

– huge OS, with huge attack surface (API),

• programming languages– buffer overflows, format strings, ... in C– lots of things in PHP

• webbrowsers– plug-ins for various formats, javascript, VBscript, ...

• email clients– ...

17

Software infrastructure

Applications are built on top of very complex "infrastructure" consisting of

• operating system• programming

language/platform/APIs/middleware• other applications & utilities

– eg SQL database

This infrastructure provides security mechanisms,but is also a source of security pitfalls.You need to understand both to develop secure

applications on a give infrastructure.

18

Threats & vulnerabilities

• Knowledge about threats & vulnerabilities crucial– my first dynamic webpage, with a cgi-bin script, was

hopelessly insecure

• Vulnerabilities can be specific to programming language, operating system, database,... used, and are continuously evolving, so we cannot hope to cover all vulnerabilities.

• “Fortunately” people keep making the same mistakes– and the same security problems keep

reappearing

19

The bad news:people keep making the same mistakes

• when writing programs & when designing programming languages or other infrastructure

• SQL injection– string concatenation is a convenient way to

build SQL queries...• will we be chasing SQL injection faults in 30 years,

just as we're still chasing buffer overflow attacks?• insist on use of eg. PreparedStatement?

• PHP– PHP is a convenient way to quickly build a

website...

20

Functionality vs security : PHP

"..., I've come to the conclusion that it is basically impossible for normal programmers to write secure PHP code.

It takes far too much effort. .... PHP's raison d'etre is that it is simple to pick up and make it do something useful. There needs to be a major push ... to make it safe for the likely level of programmers - newbies. Newbies have zero chance of writing secure software unless their language is safe. "

[http://www.greebo.cnet]

21

The "good" news:people keep making the same mistakes

• We can make checklists for common mistakes• We can teach students about common mistakes• We can implement tools that check them

– source code analysers aka static analysis tools

• Static analysis tools for C(++)– Coverity, Fortify, jTest, PolySpace, PREfast, PREfix, ...

• C/C++ checkers focus on memory-related issues

and for Java– CheckStyle, Findbugs, PMD, Fortify, jTest, IntelliJ, ...

22

OWASP Top 10 of web application vulnerabilities

1. Unvalidated Input 2. Broken Access Control 3. Broken Authentication and Session Management4. Cross Site Scripting (XSS) Flaws 5. Buffer Overflows6. Injection Flaws7. Improper Error Handling8. Insecure Storage9. Denial of Service 10.Insecure Configuration Management

Lots of info on web-application security on OWAPS.org

Anyone building a web-application should know

about these vulnerabilities:

•how they work, •how they arise, and •how they can be avoided

23

19 Deadly sins of software security [Howard, LeBlanc, Viega]

1. buffer overruns2. format string problems3. integer overflows4. SQL injection5. command injection6. failing to handle errors7. XSS8. failing to protect network

traffic9. use of magic URLs or

hidden form fields10.improper use of TLS, SSL

11.weak passwords12.failing to store & protect

data securely13.information leakage14.improper file access15.trusting network name

resolution16.race conditions17.unauthenticated key

exchange18.weak random numbers19.poor usability

24

Classification of Software Security Errors

1. Input Validation and Representation 2. API Abuse 3. Security Features4. Time and State 5. Errors6. Code Quality 7. Encapsulation *. Environment

• [Katrina Tsipenyuk, Brian Chess, Gary McGraw, Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors]

25

Two sides to software security: do’s & dont’s

• What are the methods and technologies,available to us if we want to provide security? – security in the software development lifecycle– engineering & design principles– security technologies

• What are the methods and technologies available to the enemy who wants to break security ?ie. what are the threats and vulnerabilities

we’re up against

26

How to improve software security?

• Awareness & knowledge of vulnerabilities (don'ts)– general (input validation, ...)

– specific to a kind of application (SQL injection, XSS, ...), or– specific to a kind of programming language (buffer

overflows, ...)

• Awareness & knowledge of countermeasures (do's) at different points in the development lifecycle at level of application, programming language, or platform Eg security technologies such as

– access control, session management– untrusted code security

• type-safe languages, sandboxing, code-based access control

– runtime monitoring– program analyses: typing, information flow, static analysis,

verification But beware that security software ≠ software security

high-level

28

Security concepts [as used in Common Criteria]

owners

attackers

countermeasures

risks

availability/usefulness

assets

vulnerabilities

threats

want to maximise

of

to

want to minimise

impose

increase

want to abuse

giverise to

may have

require

exploit

increase

lead to

reduce

29

Starting point for ensuring security

• Any discussion of security should start with an inventory of– the stakeholders, – their assets, and – the threats to these assetsby possible attackers– employees, clients, script kiddies, criminals

• Any discussion of security without understanding these issues is meaningless

30

Threat Modeling

Aka security/risk/requirements analysisA first step, not just for software• Identify assets & stakeholders• Consider architecture of application & its environment• Brainstorm about known threats• Define security assumptions• Rank threats by risk

≈ impact x likelihood • Decide which threats to respond to• Decide how to migitate these threats

– which techniques & technologies

31

Countermeasures and more vulnerabilities

Countermeasures can lead to new vulnerabilities• eg. if we only allow three incorrect logins, as a

countermeasure to brute-force attacks, which new vulnerability do we introduce?

If a countermeasure relies on software, bugs in this software may mean• that it is ineffective, or• worse still, that it introduces more weaknesses

32

STRIDE

Simple approach to threat modelling developed at Microsoft, as part of SDL (Secure Development Lifecycle process)

• Spoofing Identity• Tampering with Data• Repudiation• Information Disclosure• Denial of Service• Elevation of Privilige

These and other checklists can be usefulSee also http://msdn2.microsoft.com/en-us/library/aa302419.aspx

33

Techniques to migitate these threats

• Spoofing Identity– authentication, protect keys & passwords, ...

• Tampering with Data– access control, hashes, digital signatures, MACs

(message authentication codes), write-once storage...

• Repudiation– logging, audit trails, digital signatures, ...

• Information Disclosure– access control, encryption, not storing secrets, ...

• Denial of Service– graceful degradation, filtering

• Elevation of Privilige– access control, esp. least privilige, sandboxing, ...

34

Security in Software Development Life Cycle

[Source: Gary McGraw, Software security, Security & Privacy Magazine, IEEE, Vol 2, No. 2, pp. 80-83, 2004. ]

35

Security principles

• keep it simple• secure the weakest

link• defence in depth• principle of least

privilige• minimise attack

surface• compartementalise• secure defaults

• identify & question your assumptions

• fail securely• promote privacy• hiding secrets is hard• use community

resources – ie find out about

attacks and countermeasures

• be reluctant to trust• ...

Conclusions

37

Conclusions

• Security problems growing, because of – more networks – more software– growing importance of services provided by

these• more money to be made by attacker!

• People will always concentrate on functionality first, and worry about security later (if at all)

38

Conclusions

To prevent security problems, you must• understand the security requirements & the

threats that attackers pose– aka threat modeling– think like an attacker!

• know the technologies you use– operating system– programming language & platform– ...

and their security problems (do's & don'ts)– buffer overflows, SQL injection, ...

Questions?