32
Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

Embed Size (px)

Citation preview

Page 1: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

Tuomas AuraT-110.4206 Information security technology

Software security

Aalto University, autumn 2011

Page 2: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

2

Outline Security bugs Buffer overrun SQL injection Web vulnerabilities Input validation

There is no one simple solution that would make programs safe must learn about all the things that can go wrong

Page 3: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

3

Untrusted input Software is typically specified with use cases, which focus on desired

functionality, not on handling exceptional situations Network input is untrusted network software must also be able to

handle malicious input– Malformed input from the network can crash computers, or circumvent access

control What is network software?

Computers are now used mostly for communication and sharing of information practically all software is exposed to untrusted input– Documents, media streams, messages, photos can all be untrusted– Network access key part of application functionality– Intranet hosts, backend databases, office appliances etc. are directly or indirectly

exposed to input from the Internet

→ All software must handle malformed and malicious input Unix was a network OS from the beginning; Windows only connected to the

Internet from Win95

Page 4: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

4

Types of flaws Some typical security flaws:– Buffer overflows in stack or heap– Integer overflows or signed/unsigned confusion– Injection of untrusted input into the command line,

SQL, Javascript, HTML, XML, format string, file path etc.

– Logical errors, e.g. time of check—time of use– Crypto mistakes

Most software bugs first seem harmless but eventually someone figures out how to exploit them

Page 5: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

5

BUFFER OVERRUN

Page 6: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

Buffer overrun Bug: failure to check for array boundary

#define MAXLEN 1000

char *process_input (char *input) { char buffer[MAXLEN]; int i; for (i = 0; i++; buffer[i] = input[i]); ...

Loops until a null character found; should check also for i < MAXLEN

Page 7: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

Stack smashing Why are buffer overflows

a security issue?

#define MAXLEN 1000

char *process_input (char *input) { char buffer[MAXLEN]; int i; for (i = 0; i++; buffer[i] = input[i]); ...

Too long inputoverwrites the function

return address and previous stack frames

Loops until a null character found; should check also for i < MAXLEN

Function arguments

Return address

Local variables

Function arguments

Return address

Local variables

Function arguments

Return address

bufferi

Anything

Call stack

Page 8: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

Stack smashing Why are buffer overflows

a security issue?

#define MAXLEN 1000

char *process_input (char *input) { char buffer[MAXLEN]; int i; for (i = 0; i++; buffer[i] = input[i]); ...

When the function returns, execution will jump to the new return address, which points to attack code

Loops until a null character found; should check also for i < MAXLEN

Function arguments

Return address

Local variables

Function arguments

Return address

Local variables

Function arguments

Return address

bufferi

Call stack

Attack code

Attack code address

Anything

Page 9: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

9

Buffer overruns Buffer overruns may cause– data modification unexpected program behavior– access violation process crashing– malicious data modification or code injection

How attacker gains control:– Stack overruns may overwrite function return address or

exception handler address– Heap overruns may overwrite function pointer or virtual

method table How difficult to write an exploit?– Instructions and code widely available– Attackers are standing by in hope of new vulnerabilities

ever shorter time to exploits

Page 10: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

Another example Vulnerabilities can be difficult to spot

#define BUFLEN 4

void vulnerable(void) { wchar_t buf[BUFLEN]; int val;

val = MultiByteToWideChar( CP_ACP, 0, "1234567", -1, buf, sizeof(buf)); printf("%d\n", val);}

Should calculate target buffer size as sizeof(buf)/sizeof(buf[0])

[Example thanks to Ulfar Erlingsson]

Page 11: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

Buffer overrun prevention Preventing buffer overruns:

– Type-safe languages (e.g. SML, Java, C#)– Programmer training, code reviews – Avoiding unsafe and difficult-to-use libraries:

strcpy, gets, scanf, MultiByteToWideChar, etc.– Fuzz testing– Static code analysis: proving safety

No complete protection need to also mitigate consequences Stack cookies

– store an unguessable value on the top of the stack frame in function prologue; check before returning

– implemented in compilers: GCC -fstack-protector-all, Visual Studio /GS NX bit in IA-64, AMD64

– set the stack and heap memory pages as non-executable– breaks some code, e.g. JIT compilation

Memory layout randomization11

Page 12: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

NX and memory layout randomization “Return to libc” attack:

– Because of NX, attacker cannot insert new executable code

script existing code, e.g. libc functions

When function returns, execution jumps to the return address in stack

Function arguments

Return address

Local variables

Function arguments

Return address

Local variables

Function arguments

Return address

Local variables

Function arguments

Return address

Local variables

Anything

Call stack

Page 13: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

NX and memory layout randomization “Return to libc” attack:

– Because of NX, attacker cannot insert new executable code

script existing code, e.g. libc functions

When function returns, execution jumps to the return address in stack– Point the return addresses to the

beginning of library functions– Set arguments as desired

Typical script creates a new executable page, copies attack code there and runs it

Combine NX with memory layout randomization:load libc and other library code at a random memory offset attacker does not know where to jump

Function arguments

Return address

Local variables

Function arguments

Return address

Local variables

Function arguments

Return address

Local variables

Function arguments

Return address

Local variables

Anything

Function 3 args

Anything

Zeros for fun 3 locals

Function 2 args

Function 3 address

Zeros for fun 2 locals

Function 1 args

Function 2 address

Zeros for fun 2 locals

Anything

Function 1 address

AnythingBufferoverrun

Libraryfunctionsto beexecutedin order1,2,3

Call stack

Page 14: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

Integer overflow Integers in programming languages are not ideal

mathematical integers Vulnerable code:

nBytes = (nBits + 7) >> 3;if (nBytes <= bufferSize) copyBits(input, buffer, nBits);

Attacker sends input:nBits = UINT_MAX

The buffer-overflow check is evaluated:nBytes = (UINT_MAX + 7) >> 3 = 6 >> 3 = 0 (nBytes <= bufferSize) is true! buffer overflow

14

Page 15: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

SQL INJECTION

15

Page 16: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

16

[XKCD]

Page 17: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

17

SQL injection example SQL statement:

"SELECT * FROM users WHERE username = '" + input + "';"

Attacker sends input:"alice'; DROP TABLE users; --"

The query evaluated by the SQL database:SELECT * FROM users WHERE username = 'alice'; DROP TABLE users; --';

Page 18: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

18

SQL injection example 2 Application greets the user by first name:

"SELECT firstname FROM users WHERE username = '"

+ input + "';"

Attacker enters username:"nobody' UNION SELECT password FROM users WHERE username = 'alice'; --"

The query evaluated by the SQL database:SELECT firstname FROM users WHERE username = 'nobody' UNION SELECT password FROM users WHERE username = ‘alice'; --';

This is why we should always assume that the attacker can read the password database

Page 19: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

Swedish parlamentary election 2010

19

Some hand-written votes scanned by machine:

http://www.val.se/val/val2010/handskrivna/handskrivna.skv

Page 20: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

20

Preventing SQL injection Minimum privilege: set tables as read-only; run

different services as different users Sanitize input: allow only the necessary characters

and string formats Escape input strings with ready-made functions, e.g.

mysql_real_escape_string() in PHP Stored procedures: precompile SQL queries instead

of concatenating strings at run time– Prepared statements are similar to stored procedures

Disable SQL error messages to normal users harder to build exploits

Page 21: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

WEB VULNERABILITIES

21

Page 22: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

22

Cross-site request forgery (CSRF) Web browsers implement the same-origin security policy: two web

pages with different hostname, protocol or port cannot interact Common exception: clicking on a hyperlink or submitting a form

causes a GET or POST method to be invoked on another site Fictional CSRF example:

– Users of social.net are often permanently logged in (with a cookie)– JavaScript on Bob’s page

<script type="text/javascript"> frames['hidden'].window.location='http://social.net/AddFriend.php?name=Bob';</script>

causes the browser to invoke a GET method that adds Bob to the user’s friends on social.net

Preventing CSRF:– Server checks referrer field in HTTP requests– Add a random session id to all URLs and forms for logged-in users

Page 23: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

23

Cross-site scripting (XSS) Web sites that allow users to post content must filter it;

otherwise, one could post malicious scripts– Another way to circumvent the same-origin policy: insert the

malicious content to the target web site Fictional XSS example:

– Social.net has a blog where users can post comments– Instead of a comment, Bob posts a script:

<b onmouseover="window.location='http://social.ne

t/AddFriend.php?name=Bob';">See here!<b> – When another user reads the blog and moves mouse over the text,

Bob will be added to the user’s friends Preventing XSS:

– Filter user-posted content for <tags> or Javascript– Filter out or escape all angled brackets

Page 24: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

24

Another XSS example Page with XSS vulnerability (e.g. on social.net):

<html> <body> <? php print “Page not found: " . urldecode($_SERVER["REQUEST_URI"]); ?></body> </html>

Typical output:Page not found: /foo

Bob set his own site to redirect browsers to this link:http://testsite.test/<script>window.location='http://social.net/AddFriend.php?name=Bob';</script>

Page 25: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

INPUT VALIDATION

25

Page 26: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

26

File path vulnerability File names and paths are typical input, e.g. URL path Vulnerable code:

char docRoot[] = "/usr/www/";char fileName[109];strncpy (docRoot, fileName, 9);strncpy (input, fileName+9, 100);file = fopen(fileName, "r");// Next, send file to client

Attacker sends input:"../../etc/password“

The same file path has many different representations should allow only one canonical representation

Online services should be executed in a sandbox to limit their access: chroot, virtual machines

Page 27: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

27

Sanitizing input Sanitizing input is not easy Escape sequences enable many encodings for

the same character and string:– URL escapes: %2e%2e%2f2e%2e%2f = ../../– HTML entities: &#60;&#83;&#67;&#82;&#73;&#80;&#84;&#62; = <SCRIPT>

Cannot simply filter “..” or “<“

Page 28: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

28

International character set issues Bad implementations or Unicode UTF-8 allow

multiple encodings for the same character:0x0A The only correct encoding for Linefeed0xC0 0x8A 0xE0 0x80 0x8A 0xF0 0x80 0x80 0x8A 0xF8 0x80 0x80 0x80 0x8A 0xFC 0x80 0x80 0x80 0x80 0x8A

User may not see the difference between similar-looking characters, e.g. in the URL– Α vs A vs А

Page 29: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

How to produce secure code? Programming:– Learn about bugs and vulnerabilities by example– Adopt secure coding guidelines– Use safe languages, libraries and tools– Code reviews, static checkers– Fuzz testing, penetration testing

Software process:– Threat modelling– Define security requirements– Define quality assurance process

29

Page 30: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

Security principles Keep it simple Minimize attack surface Sanitize input and output Least privilege Defense in depth Isolation Secure defaults Secure failure modes Separation of duties No security through obscurity Fix potential bugs

30

Page 31: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

31

Reading material Dieter Gollmann: Computer Security, 2nd ed., chapter

14 Stallings and Brown: Computer security, principles and

practice, 2008, chapter 11-12 Michael Howard and David LeBlanc, Writing Secure

Code, 2nd ed. Online:

– TOP 25 Most Dangerous Software Errors, http://www.sans.org/top25-software-errors/ – SQL Injection Attacks by Example, http://unixwiz.net/techtips/sql-injection.html– OWASP, https://www.owasp.org/– The CERT Oracle Secure Coding Standard for Java, https://

www.securecoding.cert.org/confluence/display/java/The+CERT+Oracle+Secure+Coding+Standard+for+Java

– Aleph One, Smashing The Stack For Fun And Profit, http://inst.eecs.berkeley.edu/~cs161/fa08/papers/stack_smashing.pdf

Page 32: Tuomas Aura T-110.4206 Information security technology Software security Aalto University, autumn 2011

32

Exercises Find examples of actual security flaws in different

categories. Try to understand how the attacks work. Which features in code may indicate poor quality and

potential security vulnerabilities? How may error messages help an attacker? Buffer overrun in Java will raise an exception. Problem

solved — or can these still cause security problems? What security bugs can occur in concurrent systems, e.g.

multiple web servers that use one shared database? Find out what carefully designed string sanitization

functions, such as mysql_real_escape_string or the OWASP Enterprise Security API, actually do.