Software and Web Security deel 1 deel 1 sws1 About this course: - - PDF document

Software and Web Security deel 1 deel 1

sws1 1

About this course: people

• Erik Poll

P t S h b

• Peter Schwabe
• Pol van Aubel
• Ko Stoffelen

Ko Stoffelen

sws1 2

About this course: topics & goals g

• Standard ways in which software can be exploited

d t di h h tt k k – understanding how such attacks work – understanding what makes these attacks possible – doing some attacks in practice doing some attacks in practice

• Root cause analysis: why are things so easy to hack?
• This involves understanding

programming languages compilers and operating systems – programming languages, compilers, and operating systems, and the abstractions that they provide – the languages, representations, and interpretations involved – the potential for trouble – in the form of software vulnerabilities - that all this introduces

sws1 3

Software and Web Security - part 1 & 2 y

• part 1

it bl i hi d – security problems in machine code, compiled from C(++) sources (as usual), running on standard CPU and operating system running on standard CPU and operating system

• part 2

– security problems in software for the web, using web browsers and web applications using web browsers and web applications, and typically some back-end database.

sws1 4

Prerequisites

• Imperatief Programmeren

– we won’t use C++, but C

– biggest change: using printf instead of >> ? gg g g p

• Processoren

what is the functionality that a typical CPU offers on which we – what is the functionality that a typical CPU offers, on which we have to run our software written in higher-level languages?

sws1 5

Lectures & lab sessions

• 8 lectures and 6 lab sessions
• Lab sessions Tuesdays 8:45-10:30 in terminal room HG00.075
• Course material will be on

http://www.cs.ru.nl/~erikpoll/sws1

sws1 6

Lab exercises

Weekly lab session with weekly programming/hacking exercise

• Exercises to be done in pairs
• Exercises to be done in pairs
• Doing the exercises is obligatory to take part in the exam;
• Exercises will be lightly graded to provide feedback,

with nsi-regeling: you can have only one exercise niet-serieus-ingeleverd

• But beware: exercises of one week will build on knowledge & skills

from the previous week Also: turning up for the lab sesions might be crucial to sort out

• Also: turning up for the lab sesions might be crucial to sort out

practical problems (with C, gcc, Linux, ...) Eg coming Tuesday at 8:45: a demo of the Linux command line, university servers, ...

sws1 7

Lab exercises

We use C i l t C++

• C as programming language, not C++
• Linux from the command line aka shell
• the compiler gcc

the compiler gcc So no fancy graphical user interfaces (GUIs) for the operating system (OS) or the compiler Why? GUIs are nice but hide what OS and compiler are doing

• GUIs are nice, but hide what OS and compiler are doing
• the command line is clumsy at first,

– using commands instead of pointing & clicking using commands instead of pointing & clicking but gives great power – we can write shell scripts: programs that interact with the OS

sws1 8

Caveat: you are our guinea pigs y g g

• This course is new - to you, to us & the world...

M t i iti ’t t h thi t i l i th fi t Most universities won’t teach this material in the first year

• There are lots of things involved: understanding compilers and
• perating systems, C, pointers, memory management, Linux, the

command line Makefiles scripting command line, Makefiles, scripting, ...

• So please ask if things are not clear!

sws1 9

Intro

sws1 10

Fairy tales: a problem... y

Many discussions of security begin with Alice and Bob

Eve Alice Bob

Problem: how can Alice communicate securely with Bob, when Eve can modify or eavesdrop on the communication?

sws1 11

This is an i i bl interesting problem, but it is not the but it is not the biggest problem

sws1 12

Fairy tales... a bit more realistic y

How can Alice’s computer communicate securely with Bob’s computer when Eve can modify or eavesdrop on the communication? But... even if Alice can trust Bob, can she trust his computer?

sws1 13

Reality & the bigger problem y

Alice’s computer is communicating with some other computer

• n the internet
• n the internet

Alice’s computer possibly malicious input computer

how can we prevent Alice’s computer from being hacked, when it communicates with some other computer? p

NB solving the first problem - securing the communication - does not help here!

sws1 14

Why is this a problem? Why can’t we solve it? y y

• Why can PCs, laptops, tablets, smartphones, web-sites, servers,

routers printers smartcards cars ATMs be hacked? routers, printers, smartcards, cars, ATMs .... be hacked? – Easily & frequently Because there is software inside!

• Software is the most complex artifact mankind has ever created
• The good news:

software is incredibly powerful & flexible, and shaping the world

• The bad news:
• The bad news:

we are not (yet?) capable of producing software without bugs

• By sending malicious input to software, attackers can try to exploit

such bugs

sws1 15

From simple attacks to malware

• You can exploit vulnerabilities in software

t i l h – to simply crash a program – to reveal or corrupt some data on that computer – to interfere with services offer by that computer to interfere with services offer by that computer

• To do more interesting damage, you want to get some software

running on your victim’s computer. malware = software with some malicious intent malware = software with some malicious intent NB here the power & flexibility of software is used against us..

sws1 16

A brief history of malware

sws1 17

pre-history of hacking y g

In 1950s, Joe Engressia showed the telephone network ld b h k d b h h ki could be hacked by phone phreaking:

• ie. whistling at right frequencies

http://www.youtube.com/watch?v=vVZm7I1CTBs p y

In 1970s, before founding Apple together with Steve Jobs, St W i k ld Bl B f h h ki t i it Steve Wozniak sold Blue Boxes for phone phreaking at university

sws1 18

(Aside: a modern variant is hacking phones via SMS)

Using an USRP (Universal Software Radio Peripheral) we can send malicious SMS messages via GSM to attack your phone

sws1 19

history of malware y

• 1982: First computer virus spread via floppy disks

Hi h h l t d t Ri k S t t th Elk Cl Highschool student Rick Scrent wrote the Elk Cloner, a computer virus for Apple II that spread via floppy disk

• 1988. First internet worm, the Morris worm,

University student Robert Morris wrote a program that could replicate itself

• ver the internet Unintentionally it crashed 10% of the internet
• ver the internet. Unintentionally, it crashed 10% of the internet.

This led to the first conviction under the 1986 US Computer Fraud and Abuse Act.

• late 1990/early 2000s: many more viruses and worms

– Email viruses: I Love You Kournikova Email viruses: I Love You, Kournikova, ... – Worms: Slammer, Nimda, ..

Later viruses also spread via XSS on social networking websites

sws1 20

Slammer Worm (Jan 2003) ( )

Pictures taken from The Spread of the Sapphire/Slammer Worm, by David Moore, Vern Paxson, Stefan Savage, Colleen Shannon, Stuart Staniford, Ni h l W

21

Nicholas Weaver

Slammer Worm (Jan 2003) ( )

Pictures taken from The Spread of the Sapphire/Slammer Worm, by David Moore, Vern Paxson, Stefan Savage, Colleen Shannon, Stuart Staniford, Ni h l W

22

Nicholas Weaver

malware: worms, viruses,Trojans j

The only goal of early malware was to spread (and crash things). i f f h d l

• worm – piece of software that can spreads automonously
• virus – require some user interaction to spread

eg clicking an email attachment eg clicking an email attachment

• Trojan – apparently benign program with hidden malicious

functionality so the victim will willingly install it Modern malware is much more versatile, so the distinction between i d i l i t ti i d d l viruses and worms is no longer so interesting – or indeed clear.

Eg is spreading an XSS worm just by looking at a webpage user interaction?

Some modern malware is not meant to spread, eg. targetted attacks

• n one person, by a PDF attachment sent by email or via linkedin

sws1 23

history of malware: turning professional y g

After hacking for “fun” (if massive DoS attacks can be consider “fun”) h k t d d d t d f i l hackers went underground and turned professional Malware evolved to do more interesting - and profitable – things Malware evolved to do more interesting and profitable things besides crashing things, eg.

• stealing user data (usernames & passwords, credit card no’s, ...)
• sending spam, eg for phishing
• interfering with internet transactions (eg internet banking)
• infecting other computers
• infecting other computers
• new business models for making money:

adware, scareware, or ransomware

• creating botnets, large collections of infected computers (bots),

that can then be used for all of the above

sws1 24

example scareware

sws1 25

malware trends: cybercrime as a service y

• Professional cybercriminals are specialising, offering “cybercrime as

a service” with different parties selling a service , with different parties selling – malware – zero-day-exploits (new vulnerabilities for attacking systems) y p ( g y ) – malware toolkits to create or customise malware – (CPU time on) infected machines – internet traffic (access to infected website to infect visitors of that website) – call centre services (for social engineering) – call centre services (for social engineering)

• Another trend: not just attacking PC and laptops (or mobiles), but

also other embedded computers (cars, cash registers, printers, ...)

sws1 26

Stuxnet (2010) ( )

• Highly advanced malware spread via USB sticks to stealthily target

embedded software (SCADA systems in a Iranian nucleair facility) embedded software (SCADA systems in a Iranian nucleair facility). This used multiple zero day vulnerabilities

Ralph Langer on stuxnet: http://www.youtube.com/watch?v=CS01Hmjv1pQ

sws1 27

Duqu, Flame, Gauss,...

• Variants of the StuxNet malware have already appeared
• This is all military grade malware targeting industrial control systems.

– After already more than a year of research it is still unclear systems for instance Gauss is targetting or what it tries to do....

sws1 28

Evolution of the attacker

Example: internet banking banking fraud: 36Meuro in 2012 hacker, 2000s hacker,1983 StuxNet, Chinese government, [movie War Games]

29

g , NSA, ... hacker, 2000s

malware today! y

Websites reporting security vulnerabilities http://www.us-cert.gov/ncas/alerts/ http://www.securitytracker.com/ http://www.securitytracker.com/ http://www.securityfocus.com/vulnerabilities Such sites can use different policies, eg

• publishing all vulnerabilities

(possibly only after some waiting period for responsible disclosure) (possibly only after some waiting period for responsible disclosure)

• nly publishing weaknesses that are known to be exploited
• nly publishing weaknesses for which there is a patch
• nly publishing weaknesses for which there is a patch

sws1 30

How come there are so many How come there are so many software security vulnerabilities?

sws1 31

Some non-technical causes (out of scope for this course)

Besides the fundamental problems of the complexity of software: it l biliti ft d ’t h i l

• security vulnerabilities often don’t show up in normal use

– and can go unnoticed for long time

• programmer is not motivated to find and fix bugs

programmer is not motivated to find and fix bugs

• company is not motivated either

– security problems are often an externality for the company,

• ie. the company does not bear the cost

Externality is a term from economics; Externality is a term from economics; the classic example an externality is pollution

Eg, security problems in Adobe’s flash plugin for a web browser are primarily a problem for user, not for Adobe

sws1 32

warning: confusing terminology g g gy

Common use of terminology can be very confused & confusing: (security) weakness, flaw, vulnerability, bug, error, coding defect, ... ( y) , , y, g, , g , We can make a distinction between

• a security weakness/flaw:

a security weakness/flaw: something that is wrong or could be better

• a security vulnerability

a weakness/flaw that can actually be exploited by an attacker, a weakness/flaw that can actually be exploited by an attacker, This requires the flaw to be 1. accessible - attacker has to be able to get at it 2 exploitable – attacker has to be able to do some damage with it 2. exploitable attacker has to be able to do some damage with it

Eg by unplugging your network connection, some vulnerabilities become flaws

Flaws, weaknesses, and vulnerabilities are not always related to software, but bugs and coding defects are

sws1 33

Levels at which things can go wrong g g g

Software vulnerabilities can be introduced at different “levels” d i fl

• design flaws

– fundamental error in the design

• implementation flaws or coding error

focus of this course

implementation flaws or coding error – introduced when implementing The precise border is not precise: for some flaws it is debatable whether they are design or implementation flaws Vulnerabilities can also arise on higher levels (out of scope for this course) Vulnerabilities can also arise on higher levels (out of scope for this course)

• configuration flaw when installing software on a machine
• the user
• unforeseen consequence of the intended functionality (eg. spam)

sws1 34

Example design flaw: the USB-connected e.dentifier2

Untrusted PC, possibly infected. USB internet more trustworthy device Untrusted PC, possibly infected. Display cannot be trusted

On original version of the e.dentifier2 , some of the security-critical functionality g , y y (namely: pressing “OK” ) could be performed from the untrusted PC, and not only by the physical button on the trusted device

sws1 35

Different kinds of implementations flaws

1. Some implementation flaws can be spotted just by looking at the program itself (and understanding what it is meant to do!) program itself (and understanding what it is meant to do!)

– eg. , simple typos, confusing two program variables, off-by-one errors in a for-loop or array access, ... – sometimes called logic errors, as opposed to syntax errors, sometimes called logic errors, as opposed to syntax errors,

• r an error in the program logic

2 Some lower level implementation flaws can only be spotted if you

focus of this course

2. Some lower-level implementation flaws can only be spotted if you understand how the underlying platform of the program in execution works.

i th f ft i l hi th l tf

–

in the case of software running on a normal machine, the platform consists of CPU, OS, memory (RAM+disk), and I/O peripherals – in the case of software interacting over the web, this platform is “the web” (IP/HTTP/ ) plus on the client side (the web browser) and on the web (IP/HTTP/...) plus on the client side, (the web browser) and on the server side some wthis is the platform to interact over the web between a web browser and a web-server (incl. some back-end database)

sws1 36

Spot the flaws in chipknip.c

i t b l int balance; void decrease(int amount) ( ) { if (balance <= amount) { balance = balance – amount; } else { printf(“Insufficient funds\n”); } } void increase(int amount) { balance = balance + amount; { ; }

sws1 37

Spot the flaws in chipknip.c

<= should be >=

i t b l int balance; void decrease(int amount)

what if amount is negative?

( ) { if (balance <= amount) { balance = balance – amount; } else { printf(“Insufficient funds\n”); } } void increase(int amount) { balance = balance + amount; { ; }

what if this sum is too large for an int?

sws1 38

Different kinds of implementation flaws

1. possible lack of input validation of (untrusted) user input

what if amount is negative?

( ) p – could be a design flaw rather than an implementation flaw? – more “fundamental” than the flaws

is negative?

more fundamental than the flaws below 2 simple mistake in the program logic

<= should be >=

2. simple mistake in the program logic

what if this sum is

3. potential problem depending on how the underlying hardware reacts in case of an integer overflow; “l l l” th th fl b

what if this sum is too large for an int?

– “lower level” than the flaws above

sws1 39

Common theme in flaws: untrusted input

A very common source of security problems is assuming that input values will be `sensible’ assuming that input values will be sensible . If an attacker can control the inputs, this assumption is false. M it fl d t t d i t th t t Many security flaws are caused untrusted inputs that are not checked aka validated

Eg

• a numerical input can be negative
• a numerical input might even not be numerical
• an image file (eg a JPEG) may be malformed
• a user might choose a 1 Mbyte long username or email address

The only safe default is treating all input as untrusted Moral of the story: it is good to be paranoid!

sws1 40

Ironically, the jpg is digitally signed; is digitally signed; but of course the jpg file is fed to the graphics the graphics library before the digital signature is checked....

41

More fundamental common theme: implicit assumptions

Dangerously assuming that inputs are “sensible” is an example

• f a more general problem:
• f a more general problem:

Many security flaws arise because of the program(mer) makes some implicit assumptions , which the attacker can break.

For example, in addition to dangerously assuming that input is ok:

• When programming, you typically assume that there is enough memory and

disk space; in reality, programs can crash because memory runs out; an attacker may be able to exploit this to create a Denial-of-Service (DoS).

• The Morris worm unintentionally crashed machines because it generated

more processes than the OS could support more processes than the OS could support.

• When adding two integers in a program, you typically assume there will not

be an integer overflow; an attacker may be able to exploit integer overflow in a banking application for financial gain in a banking application for financial gain. Moral of the story: it is good to be paranoid!

sws1 42

Another theme: complex platforms

• Software is built on top of a complicated “platforms”, using lots of

languages formats and libraries incl languages, formats, and libraries, incl. – OS, compiler, file system, web browser, web server, SQL database,... – (programming) languages and data formats: C,C++, HTML, XML,

TCP/IP, email addresses, javascript, PDF, Word, jpg, mp3, mp4, ...

– libraries or APIs (application programming interfaces) to talk to libraries or APIs (application programming interfaces) to talk to the OS, to talk to peripherals, to handle all these formats,

• Platforms try to hide some complexity, providing convenient

abstractions, to help the programmer

• But these abstractions can be misleading or broken

But these abstractions can be misleading or broken ...

sws1 43

evil input error in program logic

program in execution

evil input

• utput

program logic

execution

lots of . interactions lower-level error, platform-dependent

complex “platform”

interactions .

The platform can be

focus of part 1

– CPU, OS, memory, peripherals – web-browser and web-application server

part 1 focus of part 2

sws1 44

Typical software security vulnerabilities y y

0%

Security bugs found in Microsoft’s first security bug fix month (2002)

17% 0%

buffer overflow input validation

37%

input validation code defect design defect

26%

crypto

20%

Here buffer overflows are platform-specific. Some of the code defects and input validation problems might also be. Crypto problems are much rarer, but can be more devastating when they occur.

45 sws1

yp p , g y

Recap

• Software is the no 1 cause of security problems
• Malware – malicious software – has evolved and continues to do so
• Common root causes of security flaws are

– implicit assumptions of a program(mer)

• in particular assuming that input is not malicious

– complexity of the underlying platform

sws1 46

Recap

• Security flaws in code can be

d i fl – design flaws – implementation flaws

• If they can be exploited, they become vulnerabilites
• Implementation flaws can be

– logic errors, “local” to the program, or lower level coding defects caused by strange interaction – lower-level coding defects caused by strange interaction between program and the underlying platform, which can be

• “the computer” (ie CPU, OS, memory, ... )
• “the web” (ie HTTP, browser, web-application server ... )

sws1 47

Next week

A standard computer ith OS d C(++) with OS and C(++) as platform Under the hood

• f the programming

language and language and

• perating system

sws1 48