Software and Web Securityy
deel 1deel 1
sws1 1
About this course: people
• Erik PollP t S h b• Peter Schwabe
• Pol van Aubel• Ko StoffelenKo Stoffelen
sws1 2
About this course: topics & goalsg
• Standard ways in which software can be exploitedd t di h h tt k k– understanding how such attacks work
– understanding what makes these attacks possible– doing some attacks in practicedoing some attacks in practice
• Root cause analysis: why are things so easy to hack?
• This involves understandingprogramming 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 & 2y
• part 1it bl i hi d– security problems in machine code,
compiled from C(++) sources (as usual), running on standard CPU and operating systemrunning on standard CPU and operating system
• part 2– security problems in software for the web,
using web browsers and web applicationsusing 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 weekAlso: 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 useC i l t C++• C as programming language, not C++
• Linux from the command line aka shell• the compiler gccthe 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 & clickingusing commands instead of pointing & clickingbut gives great power – we can write shell scripts: programs that interact with the OS
sws1 8
Caveat: you are our guinea pigsy 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 tMost universities won’t teach this material in the first year
• There are lots of things involved: understanding compilers and operating systems, C, pointers, memory management, Linux, the command line Makefiles scriptingcommand 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 blinteresting problem,
but it is not thebut it is not the biggest problem
sws1 12
Fairy tales... a bit more realisticy
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 problemy
Alice’s computer is communicating with some other computeron the interneton the internet
Alice’s computer
possibly malicious inputcomputer
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 softwaret i l h– to simply crash a program
– to reveal or corrupt some data on that computer– to interfere with services offer by that computerto 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 intentmalware = 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 hackingy g
In 1950s, Joe Engressia showed the telephone network ld b h k d b h h kicould be hacked by phone phreaking:
ie. whistling at right frequencies
http://www.youtube.com/watch?v=vVZm7I1CTBsp y
In 1970s, before founding Apple together with Steve Jobs, St W i k ld Bl B f h h ki t i itSteve 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 malwarey
• 1982: First computer virus spread via floppy disks Hi h h l t d t Ri k S t t th Elk ClHighschool 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 over the internet Unintentionally it crashed 10% of the internetover 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 KournikovaEmail 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,Trojansj
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 spreadeg clicking an email attachmenteg 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 lviruses 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 on one person, by a PDF attachment sent by email or via linkedin
sws1 23
history of malware: turning professionaly g
After hacking for “fun” (if massive DoS attacks can be consider “fun”)h k t d d d t d f i lhackers went underground and turned professional
Malware evolved to do more interesting - and profitable – thingsMalware 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 servicey
• Professional cybercriminals are specialising, offering “cybercrime as a service” with different parties sellinga 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:internetbankingbankingfraud:36Meuro in 2012
hacker, 2000s
hacker,1983StuxNet,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)• only publishing weaknesses that are known to be exploited• only publishing weaknesses for which there is a patchonly publishing weaknesses for which there is a patch
sws1 30
How come there are so manyHow 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 bugsprogrammer 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 terminologyg 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 it2 exploitable – attacker has to be able to do some damage with it2. 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 wrongg 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.
USBinternet
more trustworthydevice
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,
or 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 theweb (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 lint 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 lint balance;
void decrease(int amount)
what if amountis 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 amountis 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 isassuming 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 tMany 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 untrustedMoral 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 graphicsthe graphics library before the digital signature is checked....
41
More fundamental common theme: implicit assumptions
Dangerously assuming that inputs are “sensible” is an exampleof a more general problem:of 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 supportmore 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 gainin 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 incllanguages, 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 tolibraries 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 brokenBut these abstractions can be misleading or broken ...
sws1 43
evil inputerror in program logicprogram
in execution
evil input
output
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 validation37%
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.
45sws1
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 hoodof the programming language andlanguage and operating system
sws1 48