lecture overview - benoist.ch€¦ · lecture overview table of ... in a nutshell: “any bad thing...

Lecture overview

  Table of contents:

  Introduction to SW security

  Buffer overflows

  Web Application security

  Malware

  OS security topics

  Code scanning

  Taught by Ulrich Fiedler & Emmanuel Benoist (50% - 50%)

  Lecture with self-study and hands on labs

Software In-Security Overview

Emmanuel Benoist Author: Endre Bangerter

Lecture #7224 - Spring 2010

Agenda

  Basic facts and examples

  Why software is insecure

  Classification of software problems

What is software in-security

  Software insecurity: Unintentional functionality / behavior of software resulting in vulnerabilities that can be exploited by an attacker.

  Typically triggered by an attacker by providing some kind of malicious input

  Software in-security is one of the prevailing security issues and challenges today.

  Software vulnerabilities may result in   Exposure of confidential data   Execution of unauthorized commands   Crash of software, machines etc.   Injection and execution of code   Taking over an OS / machine   Malware infection   Etc.

◊ In a nutshell: “Any bad thing that software can do within its runtime environment can happen”

Number of SW vulnerabilities is growing

  Excerpt form McGraw, Software Security, AWL.

Software is everywhere

  Any type of software is potentially affected:   Office software, PDF viewers: MS Office, Open Office, Adobe Reader, etc.   Web browsers: Internet explorer, Firefox, Opera, Safari, etc.   Operating systems: Windows XP & Vista, OS X, Linux, etc.   Web Applications:   Security software like firewalls, anti-virus etc.   Databases: Oracle, DB2, etc.   Middleware   Applications: SAP etc.   Frameworks: .Net, Java EE, etc.   Libraries: Crypto libraries, graphics libraries etc.   Etc.

  Software is found in abundant number of devices:   PCs, laptops   Servers   Mobile phones   Airplanes, trains, cars   Routers   Smart cards   DVD players   MP3 players   Medical devices   Etc.

Examples of software problems - Buffer overruns

  Cause: Buffer overruns occur when an application writes beyond an allocated buffer (e.g., an array) and thereby overwrites memory locations that control the program flow.

  Effect: Can lead to the execution of arbitrary code supplied by the attacker.

  Example code:

void trouble() {

int a = 32; /*integer*/

char line[128]; /*character array*/

gets(line); /*read a line from stdin*/

}


  To exploit buffer overruns the attacker needs to be able to control the data going into a buffer.   Data is e.g., user input, an image to be displayed etc.

  Buffer overruns are typical for C and C++   trouble() would cause a runtime error in Java   For performance reasons lots of code, e.g., operating systems, is written in C, C++.

Thus, one cannot avoid the problem by porting all SW to Java.

  There are other types of buffer overruns, e.g., by overwriting heap data.

  Buffer overruns are still one of the most important software security problems today.   Overall they rank behind Web Application vulnerabilities.   Still #1 in OS vulnerabilities.

Examples of software problems - Command injection

  Cause: Application contains code that executes commands

  Effect: Injection and execution of commands specified by the attacker in the vulnerable application.

  Example code: #include <stdio.h> #include <unistd.h>

int main(intargc, char **argv) { char cat[] = "cat "; char *command; size_t commandLength;

commandLength = strlen(cat) + strlen(argv[1]) + 1; command = (char *) malloc(commandLength); strncpy(command, cat, commandLength); strncat(command, argv[1], (commandLength - strlen(cat)) );

system(command); return (0); }

Examples of software problems - Command injection

  Exploit:

  Affects all languages, including Java   Runtime.getRuntime().exec( "myprog.exe" );   Class.forName(“MyClass”);

$ ./catWrapper "Story.txt; ls" When last we left our heroes... Story.txt doubFree.cnullpointer.c unstosig.c www* a.out* format.cstrlen.cuseFree* catWrapper*

Examples of software problems -SQL Injections

  Cause: Application assembles SQL queries that are partially made of user inputs.

  Effect: Attacker executes SQL commands of his choice on DB backend.

  Example code (snippet):

String custID = httpRequest.getParameter("custID"); String sql = "Select * From Customer Where CustomerID = '" + custID + "'“;

Examples of software problems -SQL Injections

  Exploit:

Attacker enters for custID in Web form: cust1' or 1=1 –

This results in the query: Select * From Customer Where CustomerID = 'cust1' or 1=1 -- '

  Affects typically Web applications, no matter what language they are written in.

Examples of software problems – Race conditions

  Cause: Assumption that needs to hold true for some period of time, but does not.

  Effect: Cannot be specified exactly – “unexpected behavior”, does not need to be security critical.

  Example code:

import java.io.*; import java.servlet.*; import java.servlet.http.*;

public class Counter extends HttpServlet{

int count = 0;

public void doGet(HttpServletRequest in, HttpServletResponse out)

throws ServletException, IOException {

out.setContentType("text/plain");

Printwriter p = out.getWriter();

count++;

p.println(count + " hits so far!");

} }

Examples of software problems – Race conditions

  See also http://www.owasp.org/index.php/Member_Field_Race_Condition

  Exploit: Let’s have a look in NVD.

  Affects many languages and aspects of SW, e.g., threads, file access, NW access etc.

Examples of software problems – Cross site scripting

  Cause:Application assembles HTTP responses (e.g., HTML pages) that are partially made of user inputs.

  Effect: Attacker can embed arbitrary code in Web pages of seemingly trustworthy sites.

  Example code (JSP snippet):

<c:if test="${param.sayHello}">



Hello ${param.name}!</c:if>

Examples of software problems – Cross site scripting

  Exploit:

If the name parameter has a value such as Walter, the JSP will produce a message that says:

Hello Walter!

But if the name parameter has a value such as

%3Cscript%20src%3D%22 http%3A//example.com/evil.js%22%3E%3C/script%3E

the server will decode the parameter and send the Web browser this:

Hello <script src="http://example.com/evil.js"></script>!

  Affects typically Web applications, no matter what language they are written in.

Examples of software problems - Further examples

  Integer overflows:   When numbers in a computation get larger than the storage space allocated for their

type.   No direct exploitability, since they do not allow direct overwriting of memory or

manipulation of execution flow, but are more subtle.   Indirect exploit, e.g., via buffer overflow when integers that overflow are used as array

indices.   Affects mostly C and C++ code.

  Bad error handling:   Error handling is obviously important since it is about dealing with situations in which

the programmer’s expectations are violated.   A class of software problems, where myriads of things can go wrong and where

exploitability depends on the concrete problem at hand.   Some examples:

  Yielding to much information: Leak information about OS, server version, on logon failure saying “user id not known”, etc.

  Ignoring errors, misinterpreting errors, handling all errors the same: May mean to do the wrong thing upon error. Example: try { doExchange(); } catch (RareException e) { // this can never happen }

  See also http://www.owasp.org/index.php/Uncaught_exception


  Use of magic URLs and hidden form fields:   Some Web Shops use(d) to store session information such as the content of a shopping

cart including prices of items in hidden form fields. This allows the attacker to edit the HTML code and , e.g., to adapt prices.

  Some applications assume wrongly that URLs cannot be decoded or modified by users.

  Improper use of SSL / TLS:   Don’t simply replace an existing network socket with SSL / TLS to make it secure.   Lots of things needs to be handled additionally, such as: Verification of CA signature on

server CERT, check expiration date of CERT, check that target URL matches the one on CERT, check of CRLs, etc.

  Different libraries will handle these things differently. E.g., one library will automatically check the expiration date, while another doesn’t.

  The issue boils down to understanding how CERTs really work, and a bit of the underlying crypto.


  Use of weak password based systems:   Passwords are often weak, because poor choices and management by users. However, a

weak implementation of a password authentication system can add many additional vulnerabilities.

  Don’t store plaintext passwords, only store hash values or other validators, use salt (random values) when creating hashes to avoid brute force attacks.

  Carefully choose password based remote authentication protocols. E.g., even when passwords are encrypted, the ciphertext could be replayed resulting in a successful login.

  Example vulnerabilities: http://nvd.nist.gov/nvd.cfm?cvename=CVE-2005-1505 or http://nvd.nist.gov/nvd.cfm?cvename=CVE-2005-0432


  Failing to store and protect data securely:   Don’t assume that secret passwords and keys in the program code remain secret.

Executables can often be reverse engineered rather easily. Moreover, this introduces a maintenance problem: changing passwords requires update of installed programs.

  A good way is to store secret data in the file system and to use the operating system’s ACL mechanisms to protect the data.

  But using ACL correctly is another source of problems. Trivial errors include letting SUID scripts be writable by regular users, letting PATH information be modifiable, not protecting configuration files properly etc.

  Need to understand the ACL mechanisms of the OS: Unix is relatively straightforward, but limited in expressiveness, Windows is very sophisticated but a mess to understand.

  Some OS like OS X and Windows provide default mechanisms to store secret information – it is a good practice to use those.

  But after all: storing secret data is only as secure as the OS is, which in turn is often insecure. This is one of the reasons why secret keys are stored on smart cards.


  Cryptographically strong random numbers:   Complex topic: To generate pseudo random numbers, the corresponding pseudo random

number generators need to be initialized with short truly random strings. The question: Where to get these strings?

  Researchers have recently found flaws in Windows and Linux pseudo random number generators.

  Fool proof solution is to use dedicated HW to generate pseudo random numbers.   Trivial error is to use a non-crypto random number generator from standard libraries.


  Information leakage / side channel attacks:   Timing attack — attacks based on measuring how much time various computations take

to perform.   Power monitoring attack — attacks which make use of varying power consumption by the

hardware during computation..   Tempest attack — attacks based on leaked electromagnetic radiation which can directly

provide plaintexts and other information.   Example: TENEX login system the system responded faster when first letter of the

password was correct. By performing a timing analysis the attacker can easily find the first character of the password.

  Example: Encryption always leaks length of the plaintext (think of CTR mode). When always only two messages of different length are encrypted, the attacker can figure out messages eventually without decryption.

  Example: Error messages containing network information (e.g., MAC addresses, IP addresses etc.) of host behind firewall.

  Example: Recover of secret keys by measuring of timing of crypto operations.

Examples of software problems

  The software problems discussed so far are a selection of prominent software problems, and are not exhaustive – there are many many more…

  There are two well known descriptions of classes of vulnerabilities:   Howard et al. 19 deadly sins of software security. McGraw-Hill 2005.   OWASP http://www.owasp.org/index.php/Category:Vulnerability

  There are many lists of actual vulnerabilities:   National vulnerability DB: http://nvd.nist.gov/   Open Source Vulnerability DB: http://osvdb.org/   Security focus: http://www.securityfocus.com/vulnerabilities   Etc.

  Common Vulnerabilities and Exposures (CVE) is kind of a “vulnerability – meta list”. It provides standardized names for vulnerabilities from different sources.   http://cve.mitre.org/

Complexity of SW problems varies considerably

  The complexity of the various SW problems varies considerably. Complexity is not strictly defined, but refers to how easy or hard it is to spot SW problems in source and to exploit them.

  Complexity depends on how much code one needs to look at to identify a problem, and thus in how far one needs to understand the application and its runtime environment.

  For instance, buffer overruns are problems of rather low complexity. It can be sufficient to simply search for certain library calls in the source.

  No interdependency with rest of application or its environment.   Can be spotted automatically using SW tools.

  On the other hand, race conditions or side channel attacks are quite complex to find.   Race conditions occur only now and then, and only occur in certain constellations, e.g., need to

understand threading mechanism of runtime environment.   Side channels: Need to understand crypto details and how HW works.   These problems are hard to spot using automatic tools.

  Attackers always go for lowest hanging fruits: for years buffer overruns were exploited, now they go for SQL injections and XSS. Once these are fixed, they will go for the next harder problems.

Software insecurity, malware, and operating systems

  Malware often exploits SW vulnerabilities to attack systems and users.   Not always, remember there are also social engineering attacks (e.g., phishing) which are beyond

technology or are used in combination with SW vulnerabilities.

  What is the special role of operating systems?   Operating systems could prevent or contain the effects of attacks on vulnerable SW. As an example, a

buffer overflow of an application must not automatically lead to the corruption of the entire system – when the operating system properly enforces process isolation and ACLs.

  The problem is that operating system are also software and thus also contain software vulnerabilities (in kernel but also user space applications).

  Big issue are drivers, which are often poorly written and whose code is running in kernel space.   Windows XP and earlier Windows didn’t even make proper use of ACL – everybody was running as

Admin.   Operating system insecurity is a big security issue today.

  Some people claim that current fat kernel cannot be made secure and promote micro kernels.   Companies like MS certainly could produce much more secure OS, but they are constricted by

compatibility requirements to their existing systems. That is why Vista is a bit of a compromise.   Virtualization is a hot topic today: the idea is to have OS isolation by putting another (insecure?)

layer beyond operating systems. After all: VMs are only SW too – back to square one.

  Operating systems are not the only runtime environments anymore – look at Java, .Net and all those (horribly) complex application servers.

  There are layers and layers of insecure SW.

Agenda




Why is SW insecure?

There are four possible main reasons:

  Insufficient SW engineering methodologies. Existing software engineering methodologies (e.g., RUP, extreme programming etc.) don’t take security into account.

  Connectivity. Application are exposed, since they are accessible over the network.

  Complexity. Applications are getting bigger (in terms of lines of code, LOC) and thus harder to understand and analyze.

  Extensibility. Many applications are not closed and thus not static things, but offer extensibility through scripting and configuration. Extension can introduce unforeseen functionality and vulnerabilities.

See also McGraw et al, Exploiting SW, AWL, who refer to the three last points as the trinity of trouble.

Insufficient SW engineering methodologies

  Existing SW engineering methodologies are about getting classical SW quality right (i.e., getting the envisioned functionality right).

  The difference between classical SW quality and security is the addition of of an intelligent adversary.

  As an example, for security shortcoming of existing SW engineering methodologies:   Testing focuses on verifying that requirements are correctly realized.   The requirements phase is about functional and non-functional requirements, but

security requirements are not analyzed systematically.

  Assuring software quality is already a challenge even in absence of an adversary. Many examples of SW failures:   NASA Mars Lander: Conversion of units from English to metric units. On approach to

Mars, the Lander switched off engines to early and crashed.   Denver Airport Automatic Baggage system: Loading of full baggage carts and unloading

of empty ones. Delayed opening of airport by 11 months.   USS Vincennes (warship): Radar tracking system mixed up a jet liner with a fighter jet,

killing 290 innocent people (Iran 1988).   Add any less spectacular SW mess from your professional experience.   See also http://www5.in.tum.de/~huckle/bugse.html

Insufficient SW engineering methodologies

  There are many reasons for insufficient SW quality:   Lack of time   Lack of money   Lack of qualified SW engineers

  Engineering secure software requires more time, money, and qualified SW engineers.

  Some relief is in sight – many players are pushing extensions to existing SW engineering methodologies, which take care of SW security.   Microsoft is leading in that field, as it used to be with bad SW before. MS uses and

promotes SDL (The Trustworthy Computing Security Development Lifecycle).   All new MS SW is run through SDL. E.g., Vista, Office 2007, etc.   MS claims new SW is more secure - might well be, hard to verify.

  Yet, even these new methodologies “only” guarantee more secure, but not 100% secure SW.

Connectivity Adoption rate of technologies (Excerpt from Hoglund and McGraw, Exploiting SW, AWL.):

Connectivity

  Increased numbers of attack vectors and opportunities:   Email attachments, browsers etc.   New devices such as smart phones. Soon cars will be networked. New Boeing

Dreamliner already is: http://it.slashdot.org/article.pl?sid=08/01/05/2057247&from=rss

  New protocols emerge all of the time, e.g., VoIP, etc.   More communication technologies: WLAN, blue-tooth, NFC, etc.   New paradigms: Ad-hoc networking ◊ How to authenticate, e.g., an unknown

printer in an office.

  Ease of attacks   Automation   From remote locations with little risk

Complexity

  Empirical evidence shows that number of software bugs is proportional to the number of lines of code (LOC) of an application.

  Estimates range between 5 – 50 bugs per KLOC (1000 LOC).   Only a fraction of these bugs can be exploited.   Only a fraction of the exploitable bugs can be exploited remotely.

  Yet, given the huge size in LOCS of current SW, there are still plenty of exploitable vulnerabilities in applications. Here are some LOC figures:

Solaris 7 400’000 Netscape 17’000’000 Space station 40’000’000 Space shuttle 10’000’000 Boeing 777 7’000’000 Linux Kernel 1’780’000 Red Hat 7.1 30’000’000 Windows XP 40’000’000 OS X Kernel 790’000

  In complex runtime environment, such as Webapp servers, one has to rely on GBs of code for a simple “Hello World”.

Complexity

  Windows OS complexity in terms of LOCS (Excerpt from McGraw. Software Security. AWL.)

Extensibility

  Most applications functionality can be extended or modified by third parties.   Extensibility is crucial from a usability and software-reuse point of view.

Yet, from security point of view, extensibility is bad, since extensions can alter the behavior of applications in a malicious way.

  Examples of extensible applications:   Web browser plug-ins, e.g., for viewing new types of documents.   Dynamically loadable kernel modules – code going into kernel(!) without recompiling   Office applications featuring scripting languages, e.g., MS Office and Visual Basic   Most major business applications, like SAP, can be customized using some proprietary

extension mechanisms.   Etc.

Extensibility

  A special class of extensions is mobile code, e.g.,   Java applets   Java script   Active X controls   Flash animations   Etc.

  Mobile code is adding the network attack vector to extensibility mechanisms.

  Mobile code sometimes runs with the same privileges as the user who is downloading the code, which means access to all user files etc.

  Sandboxing and code signing techniques are se allow to control what code is run on a platform and the privileges of the code, respectively.

Agenda




On classifying SW problems

  Q: Why to to classify SW problems?

  A: Classification   Is about the understanding of fundamental properties of things. The hope is

that understanding of these fundamental properties allows to the fight the problem.

  Allows us to communicate, quantify etc. SW problems

  There are many classification schemes for SW problems. None of them is the “one and only”. Yet, each classification scheme provides some insight into the problem.

  In the following we have a look at three classification schemes:   Design, implementation, and operation   Nine pernicious kingdoms   CWE – Common Weakness Enumeration

Design, implementation, and operational vulnerabilities

  Design vulnerabilities are vulnerabilities in the architecture and design of the application and prevail no matter how well the system is implemented.   Example: Telnet over insecure network is a vulnerable design.   Example: Windows XP, every user is Admin by default.   Example: Windows tight integration of file explorer with Internet explorer.   Example: Secure channels that are specified to use ECB mode ciphers.   Occur early in the SW development process.   Best to spot by analyzing architecture documentation, not code.   Tend to be expensive to fix: re-design and re-coding. Re-design can affect the entire

architecture of an application.

  Implementation vulnerabilities are code level vulnerabilities.   Examples: Buffer overruns, integer overruns, SQL injections, etc.   Occur only in the coding phase.   Depend on lots of low level details, like run-time environment, programming languages

being used etc.

  Practitioners report that the SW vulnerabilities found in code reviews are 50% design and 50% implementation vulnerabilities.

Design, implementation, and operational vulnerabilities

  Operational vulnerabilities are security problems through the operational procedures and general use of a piece of software in a specific environment.   Example: Faulty configuration of access control (.htaccess file) of a Web server.   Example: Virus scanners not configured for update.   Example: Insecure configuration of a firewall.   Operational vulnerabilities occur late in the SW life cycle, when SW is deployed.   Often beyond control of people who have developed an application.   Depends on how qualified your IT staff is.

  In summary, we see that the classification into design, implementation, and operational vulnerabilities is according to when a vulnerability is introduced in the SW lifecycle.

Seven pernicious kingdoms

  Seven classes (the pernicious kingdoms) of SW vulnerabilities proposed by McGraw et al:   Input validation and representation   API abuse   Security features   Time and state   Errors   Code quality   Encapsulation

  These classes are characterized by root causes of SW vulnerabilities (and not by when in the SW process they are introduced).


  Input validation and representation.   Meta-characters, alternate encodings, and numeric representations cause input

validation and representation problems.   Sometimes people just forget to do any input validation at all.   Big problems result from putting too much trust in input: buffer overflows, cross-site

scripting attacks, SQL injection, cache poisoning, and basically all the low-hanging fruit the script kiddies love so much.

  API abuse.   An API is a contract between a caller and a callee: the most common forms of API

abuse occur when the caller fails to honor its end of the contract. That is, caller makes wrong assumptions about what an API call does, its pre-conditions etc.

  If a program fails to call chdir() after calling chroot(), for example, it violates the contract that specifies how to securely change the active root directory.

  Another good example of library abuse is expecting the callee to return trustworthy DNS information to the caller. In this case, the caller abuses the callee API by making certain assumptions about its behavior.


  Security features.   Software security isn’t security software.   All the magic crypto fairy dust in the world won’t make your code secure, but it’s also

true that you can drop the ball when it comes to essential security features.   Other security features which are often misused: authentication, access control,

confidentiality, privilege management, etc.

  Time and state.   Distributed computation is about time and state—that is, for more than one component

to communicate, state must be shared (somehow), which takes time.   Assuming that a distributed transaction is atomic, when it is not.   Making wrong assumptions about state of parties, before running a protocol.


  Errors.   Want to break software? Throw some junk at a program and see what errors you cause.

Errors are not only a great source of “too much information” from a program, they’re also a source of inconsistent thinking that can be gamed.

  Forgetting to handle errors at all or producing errors that give out way too much information (to possible attackers).

  Code quality.   Security is a subset of reliability / software quality: one cannot expect poor code to be

secure.   Poor code quality leads to unpredictable behavior, and from a user’s perspective, this

often manifests itself as poor usability.   For an attacker, bad quality provides an opportunity to stress the system in unexpected

ways.   Examples: un-initialized variables, procedures that only work for some input

parameters, memory leaks, etc.


  Encapsulation / isolation   Encapsulation is about drawing strong boundaries around things and setting up barriers

between them.   In a Web browser, this might mean ensuring that mobile code can’t access your hard

drive arbitrarily.

Seven pernicious kingdoms vs. some vulnerability lists

CWE - Common Weakness Enumeration

  CWE is conceptually similar to the seven pernicious kingdoms, yet is much more detailed, and interesting (see http://cwe.mitre.org/data/index.html)

  Targeted to developers and security practitioners, the Common Weakness Enumeration (CWE) is a formal list of software weakness types created to:   Serve as a common language for describing software security weaknesses in

architecture, design, or code.   Serve as a standard measuring stick for software security tools targeting these

weaknesses.   Provide a common baseline standard for weakness identification, mitigation, and

prevention efforts. (excerpt from CWE mission statement http://cwe.mitre.org/about/index.html)

  CWE is developed by MITRE in the USA, the same organization which is behind CVE.

Some naming

  From 7221 we know what a vulnerability is.   Vulnerability can be in SW, HW, design, operation, etc.

  In the context of SW security some people use additional terms.

  Software defect = Implementation or design vulnerability in SW.

  Bug = Is a software problem in code.   Bugs may exist in code, but never be executed.   Are bugs vulnerabilities / defects? Don’t know…

  Flaws = Is a software problem in present in code and design.   Flaws may exist in code, but never be executed.   Are flaws vulnerabilities / defects? Don’t know…

Required reading

  McGraw. Software security. http://www.cigital.com/papers/download/bsi1-swsec.pdf

  Katrina Tsipenyuk, Brian Chess, and Gary McGraw, "Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors," http://www.computer.org/portal/site/security/menuitem.6f7b2414551cb84651286b108bcd45f3/index.jsp&pName=security_level1_article&TheCat=1001&path=security/v3n6&file=bsi.xml&

  Software [In]security: Top 11 Reasons Why Top 10 (or Top 25) Lists Don’t Work http://www.informit.com/articles/article.aspx?p=1322398

lecture overview - benoist.ch€¦ · lecture overview table of ... in a nutshell: “any bad thing...

Documents