Software Security Explorative Lecture A brief history of security - - PDF document

1/30/2020 1

Software Security

Explorative Lecture

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 (Cross Site Request Forging), ....  response: intrusion detection systems & application firewalls

 attacks on web-browsers

 man-in-the-browser attacks 

...

1/30/2020 2

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 (Spam over Internet Telephony)

 ...

4

Trend

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

to hacking for profit

 zero-day exploits are worth a lot of money

1/30/2020 3

5

Security Concepts

 Security is about imposing countermeasures to reduce risks to

assets to acceptable levels

 “Perfect security” is not necessary and costly

 A security policy is a specification of what security

requirements/goals the countermeasures are intended to achieve

 secure against what and from whom ?

 Security mechanisms to enforce the policy

 What actions we should take under an attack? 6

Security Objectives: CIA

 Confidentiality (or secrecy)

 unauthorized users cannot read information

 Integrity

 unauthorized users cannot alter information

 Availability

 authorized users can always access information

 Non-repudiation for accountability

 authorized users cannot deny actions

 Others

 Privacy, anonymity…

1/30/2020 4

Kinds of undesired behavior

 Stealing information: Confidentiality

 Corporate secrets (product plans, source code, …)  Personal information (credit card numbers, SSNs, …)

 Modifying information or functionality: Integrity

 Installing unwanted software (spyware, botnet client, …)  Destroying records (accounts, logs, plans, …)

 Denying access: Availability

 Unable to purchase products  Unable to access banking information

 The aim of Computer security is to preserve the system

Confidentiality, Integrity, and Availability

What is computer security?

 Most developers and operators are concerned with

correctness: achieving desired behavior

 A working banking web site, word processor, blog, …

 Security is concerned with preventing undesired behavior

 Considers an enemy/opponent/hacker/adversary who is actively and

maliciously trying to circumvent any protective measures you put in place

1/30/2020 5

A Brief History of Notable Hacking (Security breaches)

 RSA, March 2011

 stole tokens that permitted subsequent compromise of customers

using RSA SecureID devices

 Adobe, October 2013

 stole source code, 130 million customer records (including

passwords)

 Target, November 2013

 stole around 40 million credit and debit cards

 … and many others!

Defects and Vulnerabilities

 Many breaches begin by exploiting a vulnerability

 This is a security-relevant software defect that can be exploited to

effect an undesired behavior

 A software defect is present when the software behaves

incorrectly, i.e., it fails to meet its requirements

 Defects occur in the software’s design and its implementation

 A flaw is a defect in the design  A bug is a defect in the implementation

1/30/2020 6

Example: RSA 2011 breach

 Exploited an Adobe Flash player vulnerability

 1. A carefully crafted Flash program, when run by the vulnerable

Flash player, allows the attacker to execute arbitrary code on the running machine

 2. This program could be embedded in an Excel spreadsheet, and

run automatically when the spreadsheet is opened

 3. The spreadsheet could be attached to an e-mail masquerading

to be from a trusted party (spear phishing)

Considering Correctness

 The Flash vulnerability is an implementation bug!

 All software is buggy. So what?

 A normal user never sees most bugs, or works around them

 Most (post-deployment) bugs due to rare feature interactions or

failure to handle edge cases

 Assessment: Would be too expensive to fix every bug before

deploying

 So companies only fix the ones most likely to affect normal users

1/30/2020 7

Considering Security

 The adversary will actively attempt to find defects in rare

feature interactions and edge cases

 For a typical user, (accidentally) finding a bug will result in a crash,

which he will now try to avoid

 An adversary will work to find a bug and exploit it to achieve his

goals

Key difference:

An adversary is not a normal user!

14

Security Goals

 The well-known trio

 confidentiality, integrity, avaliability (CIA)

 There are more “concrete” goals

 traceability and auditing (forensics)  monitoring (real-time auditing)  multi-level security  privacy & anonymity  ...

 and meta-property

 assurance – that the goals are met

 “information assurance”

1/30/2020 8

15

How to Realize Security Objectives? AAAA

 Authentication

 who are you?

 Access control/Authorization

 control who is allowed to do what  this requires a specification of who is allowed to do what

 Auditing

 check if anything went wrong

 Action

 if so, take action

16

How to Realize Security Objectives?

 Other names for the last three A's

 Prevention



measures to stop breaches of security goals

 Detection



measures to detect breaches of security goals

 Reaction



measures to recover assets, repair damage, and prosecute (and deter) offenders

 Good prevention does not make detection & reaction superfluous

 E.g., breaking into any house with windows is trivial; despite this absence

• f prevention, detection & reaction still deter burglars

1/30/2020 9

Is it enough?

Firewalls and anti-virus are like building walls around a weak interior Attackers often can bypass

• uter defenses to attack

weaknesses within

Operating System Security

 Operating systems mediate a program’s actions!

 Aka system calls!  such as reading and writing files,  sending and receiving network packets,  starting new programs, etc.

 Enforceable policies control actions

 programs run by Alice cannot read files owned by Bob  programs run by Bob cannot use TCP port 80  programs run in directory D cannot access files outside of D

1/30/2020 10

Limitations of OS Security

 Cannot enforce application-specific policies, which can be

too fine-grained

 Example: database management system (DBMS)

 Cannot (precisely) enforce info-flow policies!

 An operating system typically implements an execution monitor:

decisions are based on past and current actions

 Information flow policies: A non-action may reveal

something about a secret without leaking it directly

Firewalls and IDSs

 Firewalls and intrusion detection systems (IDSs) observe,

block, and filter messages exchanged by programs

 Based on their origin, content, frequency, etc.

 Examples:

 Firewall could block all traffic from particular hosts, or to particular

TCP ports

 An IDS could filter packets it recognizes are part of a known exploit

pattern

1/30/2020 11

Filtering misses attacks

 Firewall filtering is coarse-grained, and unsound

 Port 80 is assumed to be HTTP (web) traffic, which is assumed

benign, but can layer arbitrary traffic over HTTP, e.g., SOAP

 Previously benign sources can become malicious

 E.g., due to malware infection

 IDS patterns fine-grained, but still unsound!

 Attack traffic can be slightly modified to work around IDS filters

(which are often syntactic, not semantic)

 Making filters too fine-grained can hurt performance

 Thus compromising availability

Anti-virus Scanners

 Anti-virus scanners look for signs of malicious behavior in

local files

 In many ways, anti-virus is related to IDS in looking for

patterns

 Newer forms of anti-virus scanners are sophisticated, but in

practice are frequently bypassed!

 Trade off precision and performance (latter could compromise

availability)

1/30/2020 12

Ex: Heartbleed

 SSL/TLS is a core protocol for encrypted

communications used by the web

 Heartbleed is a bug in the commonly used OpenSSL

implementation of SSL/TLS, v1.0.1 - 1.0.1f

 Discovered in March 2014, it has been in released code since March 2012

 A carefully crafted packet causes OpenSSL to read and return

portions of a vulnerable server’s memory

 Leaking passwords, keys, and other private information

Heartbleed, meet SoftSec

 Black box security is incomplete against Heartbleed

exploits!

 Issue is not at the level of system calls or deposited files: nothing the

OS or antivirus can do

 Basic attack packets could be blocked by IDS, but

 “Packet chunking” may bypass basic filters  Exfiltrated data on the encrypted channel; invisible to forensics

 Software security methods

attack the source of the problem: the buggy code

1/30/2020 13

25

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

What about Cryptography?

What about Cryptography?

1/30/2020 14

27

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, ...

28

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, ...

1/30/2020 15

29

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?

30

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

1/30/2020 16

31

"The only system which is truly secure is one which is switched

• ff 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

To ensure security, we must

eliminate bugs and design flaws, and/or

make them harder to exploit

Software Security

1/30/2020 17

Software Security

 Software security is a kind of computer security that focuses

• n the secure design and implementation of software!

 Using the best languages, tools, methods

 Focus of study:

the code

 By contrast: Many popular approaches to security treat

software as a black box (ignoring the code)

 OS security, anti-virus, firewalls, etc.

What will you learn?

 This course is primarily aimed at people interested in secure

software development, who will

 Design software systems that should be secure  Write code that should be secure  Review code that should be secure  Test code that should be secure

 Much of our focus will be on the software, and how

to develop it to be secure

1/30/2020 18

Expected background

 Roughly: knowledge of a junior-level undergraduate majoring in

computer science!

 Knowledge with the following (we will not review)

 Programming in general (two semesters’ equivalent of instruction, e.g., in

Java)

 C programming language details (one semester course), including memory

allocation (both stack and heap), pointers, arrays, loops, function calls, etc.

 C tutorial: https://www.tutorialspoint.com/cprogramming/index.htm

 Familiarity with the following (we will do some review):

 Unix/Linux including the command-line shell and gdb  The web (HTML, HTTP, TCP, network communications)  Intel x86 assembly language and architecture

Learning Software Security

 Our goal is learn how to make more secure software

 Better design  Better implementation  Better assurance

 How should we go about this?

1/30/2020 19

37

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

38

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

1/30/2020 20

low-level

40

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

1/30/2020 21

41

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?

42

Functionality vs Security

1/30/2020 22

43

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

 ...

44

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 given infrastructure.

1/30/2020 23

45

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,

• perating 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

46

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

• verflow attacks?



insist on use of eg. PreparedStatement?  PHP

 PHP is a convenient way to quickly build a website...

1/30/2020 24

47

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]

48

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, ...

1/30/2020 25

49

OWASP Top 10 of web application vulnerabilities

1.

Unvalidated Input

2.

Broken Access Control

3.

Broken Authentication and Session Management

4.

Cross Site Scripting (XSS) Flaws

5.

Buffer Overflows

6.

Injection Flaws

7.

Improper Error Handling

8.

Insecure Storage

9.

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

50

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

1.

buffer overflow (overruns)

2.

format string problems

3.

integer overflows

4.

SQL injection

5.

command injection

6.

failing to handle errors

7.

XSS

8.

failing to protect network traffic

9.

use of magic URLs or hidden form fields

• 10. improper use of TLS, SSL
• 11. weak passwords
• 12. failing to store & protect data securely
• 13. information leakage
• 14. improper file access
• 15. trusting network name resolution
• 16. race conditions
• 17. unauthenticated key exchange
• 18. weak random numbers
• 19. poor usability

1/30/2020 26

51

Classification of Software Security Errors

1.

Input Validation and Representation

2.

API Abuse

3.

Security Features

4.

Time and State

5.

Errors

6.

Code Quality

7.

Encapsulation *. Environment



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

52

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

1/30/2020 27

53

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

1/30/2020 28

55

Security concepts [as used in Common Criteria]

• wners

attackers countermeasures risks availability/ usefulness assets vulnerabilities threats want to maximise

• f

to want to minimise impose increase want to abuse give rise to may have require exploit increase lead to reduce

56

Starting point for ensuring security

 Any discussion of security should start with an inventory of

 the stakeholders,  their assets, and  the threats to these assets by possible attackers  employees, clients, script kiddies, criminals

 Any discussion of security without understanding these issues

is meaningless

1/30/2020 29

57

Threat Modeling

Aka security/risk/requirements analysis A 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 58

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

1/30/2020 30

59

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 useful See also http://msdn2.microsoft.com/en-us/library/aa302419.aspx

60

Techniques to migitate these threats



Spoofing Identity

 authentication, protect keys & passwords, ... 

Tampering with Data

 access control, hashes, digital signatures, MACs (message authentication codes), write-

• nce 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, ...

1/30/2020 31

61

Security in Software Development Life Cycle

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

62

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  ...

1/30/2020 32

63

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)

64

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, ...

1/30/2020 33

Learning Software Security

 Our goal is learn how to make more secure software

 Better design  Better implementation  Better assurance

 How should we go about this?

Black Hat, White Hat

What are the security-relevant defects that constitute vulnerabilities?

• How are they exploited?

Black hat White hat How do we prevent security-relevant defects (before deploying)?

• How do we make vulnerabilities we don’t

manage to avoid harder to exploit? During the course we will wear both hats

1/30/2020 34

Low-level Vulnerabilities

 Programs written in C and C++ are susceptible a variety of

dangerous vulnerabilities

 Buffer overflows!

 On the stack  On the heap  Due to integer overflow  Over-writing and over-reading

 Format string mismatches!  Dangling pointer dereferences  All violations of memory safety

 Accesses to memory via pointers that don’t own that memory

Attacks!

• Stack smashing
• Format string attack
• Stale memory access
• Return-oriented

Programming (ROP)

Ensuring Memory Safety

 The easiest way to avoid these vulnerabilities is to use a memory-

safe programming language

 Better still: a type-safe language

 For C/C++, use automated defenses!

 Stack canaries  Non-executable data (aka W+X or DEP)  Address space layout randomization (ASLR)  Memory-safety enforcement (e.g., SoftBound)  Control-flow Integrity (CFI)

 and safe programming patterns and libraries!

 Key idea: validate untrusted input

1/30/2020 35

Securing the WWW

 Cybersecurity battles rage on the world wide web!  There are new vulnerabilities and attacks

 SQL injection  Cross-site scripting (XSS)  Cross-site request forgery (CSRF)  Session hijacking

 The defenses have a similar theme!

 Careful who/what you trust: Validate input!  Reduce the possible damage, make exploitation harder

Secure Software Development

 Consider security throughout software lifecycle

 Requirements  Design  Implementation  Testing/assurance

 Corresponding activities

 Define security requirements, abuse cases,  Perform architectural risk analysis (threat modeling) and security-

conscious design

 Conduct code reviews, risk-based security testing, and penetration

testing

1/30/2020 36

Requirements and Design

 Identify sensitive data and resources and define security

requirements for them, like confidentiality, integrity, and availability

 Consider expected threats and abuse cases that could violate

these requirements

 Apply principles for secure software design

 To prevent, mitigate, and detect possible attacks  Main categories: Favor Simplicity, Trust with Reluctance, and

Defend in Depth.

 Exemplar: Very Secure FTP daemon

Rules and Tools

 Apply coding rules to implement secure design

 With similar goals of preventing, mitigating, or

detecting possible attacks

 Apply automated code review techniques to find

potential vulnerabilities in components

 Static analysis, and symbolic execution (which

underlies white box fuzz testing)

 Apply penetration testing to find potential flaws in

the real system, in a deployment environment

 Fuzz testing, perhaps employing attack patterns

1/30/2020 37

Software Security

 Instructor: Hassen Sallay; email: hmsallay@gmail.com  Textbook: Software Security: Building Security in  Others references will be posted in the website  Acknowledgment: Course materials are combined from several

courses from EPFL, MIT, Maryland, RU, UCC

 Course materials will be posted on

http://amansystem.com/?c=people/sallay/SS

 Assessment: Final Exam 40%; Mid term exam 20%; Quizzes 10%;

Projects 20%; Lab projects 20%

Software Security