Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

20101017 program analysis_for_security_livshits_lecture03_security


Published on

  • Be the first to comment

20101017 program analysis_for_security_livshits_lecture03_security

  1. 1. Introduction to Systems Security<br />Ben Livshits<br />10/16/2010<br />Some slides are borrowed from CS 155 at Stanford<br />
  2. 2. Organization<br />General introduction to security<br />What is system security?<br />Threats<br />Trends<br />Approaches to finding vulnerabilities<br />Security vulnerabilities<br />Memory-based exploits<br />Web application vulnerabilities<br />
  3. 3. What is Security?<br />System correctness<br />If user supplies expected input, system generates desired output<br />Security<br />If attacker supplies unexpected input, system does not fail in certain ways<br />Goal of the attacker is to make the system fail in “interesting ways”<br />
  4. 4. What is security?<br />System correctness<br />Good input  Good output<br />Think “verification”<br />Security<br />Bad input  Bad output<br />Think “not exploitable”<br />
  5. 5. What is security?<br />System correctness<br />More features: better<br />Security<br />More features: can be worse<br />
  6. 6. Security properties<br />Confidentiality <br />Information about system or its users cannot be learned by an attacker<br />Integrity<br />The system continues to operate properly, only reaching states that would occur if there were no attacker<br />Availability<br />Actions by an attacker do not prevent users from having access to use of the system<br />
  7. 7. General picture<br />System<br />Attacker<br />Alice<br />Security is about<br />Honest user (e.g., Alice, Bob, …)<br />Dishonest Attacker<br />How the Attacker <br />Disrupts honest user’s use of the system (Integrity, Availability)<br />Learns information intended for Alice only (Confidentiality)<br />
  8. 8. Network security<br />Network Attacker<br />Intercepts and controls network communication<br />System<br />Alice<br />
  9. 9. Web security<br />System<br />Web Attacker<br />Sets up malicious site visited by victim; no control of network<br />Alice<br />
  10. 10. Operating system security<br />OS Attacker<br />Controls malicious files and applications<br />Alice<br />
  11. 11. System<br />Attacker<br />Alice<br />Confidentiality: Attacker does not learn Alice’s secrets<br />Integrity: Attacker does not undetectably corrupt system’s function for Alice<br />Availability: Attacker does not keep system from being useful to Alice<br />
  12. 12. Current Trends<br />
  13. 13. Historical hackers (prior to 2000)<br />Profile:<br />Male<br />Between 14 and 34 years of age<br />Computer addicted<br />No permanent girlfriend<br />No Commercial Interest !!!<br />Source: Raimund Genes<br />
  14. 14. Typical Botherder: 0x80" (pronounced X-eighty)<br />Washington Post: Invasion of the Computer Snatchers<br />High school dropout<br />“…most of these people I infect are so stupid they really ain't got no business being on the Internet in the first place.“<br />Working hours: approx. 2 minutes/day to manage Botnet<br />Monthly earnings: $6,800 on average<br />Daily Activities: <br />Chatting with people while his bots make him money<br />Recently paid $800 for an hour alone in a VIP room with several dancers<br />Job Description: <br />Controls 13,000+ computers in more than 20 countries <br />Infected Bot PCs download Adware then search for new victim PCs<br />Adware displays ads and mines data on victim's online browsing habits.<br />Bots collect password, e-mail address, SS#, credit and banking data<br />Gets paid by companies like,, Loudcash, or 180Solutions.<br />14<br />
  15. 15. Some things in the news<br />Nigerian letter (419 Scams) still works:<br />Michigan Treasurer Sends 1.2MUSD of State Funds !!!<br />Many zero-day attacks<br />Google, Excel, Word, Powerpoint, Office …<br />Criminal access to important devices<br />Numerous lost, stolen laptops, storage media, containing customer information<br />Second-hand computers (hard drives) pose risk<br />Vint Cerf estimates ¼ of PCs on Internet are bots<br />15<br />
  16. 16. Trends for 2010<br />Malware, worms, and Trojan horses<br />spread by email, instant messaging, malicious or infected websites<br />Botnets and zombies<br />improving their encryption capabilities, more difficult to detect<br />Scareware – fake/rogue security software <br />Attacks on client-side software<br />browsers, media players, PDF readers, etc. <br />Ransom attacks<br />malware encrypts hard drives, or DDOS attack<br />Social network attacks <br />Users’ trust in online friends makes these networks a prime target. <br />Cloud Computing - growing use will make this a prime target for attack. <br />Web Applications - developed with inadequate security controls <br />Budget cuts - problem for security personnel and a boon to cyber criminals. <br />Texas CISO, Feb 2010<br />Same list in Oklahoma Monthly Security Tips Newsletter<br />
  17. 17. Trends<br />
  18. 18. Operating system vulnerabilities<br />
  19. 19. Reported Web Vulnerabilities "In the Wild"<br />Data from aggregator and validator of  NVD-reported vulnerabilities<br />
  20. 20. Web vs System vulnerabilities<br />XSS peak<br />
  21. 21. Web attack toolkit: MPack<br />Basic setup<br />Toolkit hosted on web server<br />Infects pages on that server<br />Page visitors get infected<br />Features<br />Customized: determines exploit on the fly, based on user’s OS, browser, etc<br />Easy to use: management console provides stats on infection rates<br />Customer care toolkit can be purchased with one-year support contract!<br />21<br />
  22. 22. Finding Vulnerabilities <br />Static analysis<br />Abstract interpretation<br />Dataflow<br />Pointer analysis<br />etc.<br />Runtime analysis <br />Fuzzing<br />Testing<br />Simulation<br />Symbolic execution<br />Model checking<br />
  23. 23. Necessary BackgroundonMemory Exploits and Web Application Vulnerabilities<br />23<br />
  24. 24. Outline<br />24<br />Memory safety attacks<br />Buffer overruns<br />Format string vulnerabilities<br />Web application vulnerabilities<br />SQL injections<br />Cross-site scripting attacks<br />
  25. 25. Buffer Overflows<br />25<br />
  26. 26. Buffer Overrun Example<br />26<br />Frame 1<br />Frame 2<br />str<br />ret<br />sfp<br />local<br />str<br />ret<br />sfp<br />local<br />void lame (void) { <br />char small[30]; <br /> gets(small); <br />printf("%s ", small); <br />}<br />
  27. 27. Input Validation<br />Classifying vulnerabilities:<br />Buffer overflows can be viewed as an example of improper input validation<br />Another related type of vulnerability is information leaks<br />Other notable examples:<br />Format string vulnerabilities<br />SQL injection attacks<br />Cross-site scripting attacks<br />Mechanisms to prevent attacks<br />Better input validation<br />Safe programming techniques<br />Techniques for detecting potential buffer overflows in code<br />Static analysis<br />Runtime analysis<br />Fuzzing/penetration testing<br />Write-box fuzzing<br />etc.<br />27<br />
  28. 28. Secure Programming Techniques<br />Validate all input<br />Easier said than done<br />Why is that?<br />Avoid buffer overflows<br />Use safe string manipulation functions <br />Careful length checking<br />Avoid statically declared arrays<br />etc.<br />Or use a memory-safe language<br />Java or C#<br />JavaScript (not type-safe)<br />28<br />
  29. 29. Validating Input<br />Determine acceptable input, check for match --- don’t just check against list of “non-matches”<br />Limit maximum length<br />Watch out for special characters, escape chars.<br />Check bounds on integer values<br />Check for negative inputs<br />Check for large inputs that might cause overflow!<br />29<br />
  30. 30. Avoid strcpy, …<br />We have seen that strcpy is unsafe<br />strcpy(buf, str) simply copies memory contents into buf starting from *str until “” is encountered, ignoring the size of buf<br />Avoid strcpy(), strcat(), gets(), etc.<br />Use strncpy(), strncat(), instead<br />Still, computing proper bounds is difficult in practice<br />Easy to mess up, off-by-one errors are common<br />30<br />
  31. 31. Static and Dynamic Analysis<br />Static analysis: run on the source code prior to deployment; check for known flaws<br />e.g., flawfinder, cqual<br />Or Prefix/Prefast<br />Or Coverityor Fortify tools<br />Will look at some more recent work in this course as well as older stuff<br />Dynamic analysis: try to catch (potential) buffer overflows during program execution<br />Soundness<br />Precision<br />Comparison?<br />Static analysis very useful, but not perfect<br />False positives<br />False negatives<br />Dynamic analysis can be better (in tandem with static analysis), but can slow down execution<br />Historically of great importance, drove adoption of type-safe languages such as Java and C#<br />31<br />
  32. 32. Dynamic analysis: Libsafe<br />Very simple example of what can be done at runtime<br />Intercepts all calls to, e.g., strcpy(dest, src)<br />Validates sufficient space in current stack frame: |frame-pointer – dest| > strlen(src)<br />If so, executes strcpy; otherwise, terminates application<br />32<br />
  33. 33. Preventing Buffer Overflows<br />Operating system support:<br />Can mark stack segment as non-executable<br />Randomize stack location<br />Problems:<br />Does not defend against `return-to-libc’ exploit<br />Overflow sets ret-addr to address of libc function<br />Does not prevent general buffer overflow flaws, or heap overflow<br />Basic heap overflows can be helped with ALSR<br />33<br />
  34. 34. Heap-based Buffer Overruns and Heap Spraying<br />34<br />Buffer overruns consist of two steps<br />Introduce the payload<br />Cause the program to jump to it<br />Can put the payload/shellcode in the heap<br />Arbitrary amounts of code<br />Doesn’t work with heap randomization<br />Location of the payload changes every time<br />Heap spraying:<br />Allocate multiple copies of the payload<br />When the jump happens, it hits the payload with a high probability<br />
  35. 35. StackGuard<br />Embed random “canaries” in stack frames and verify their integrity prior to function return<br />This is actually used!<br />Helpful, but not foolproof…<br />Frame 1<br />Frame 2<br />str<br />ret<br />sfp<br />local<br />canary<br />str<br />ret<br />sfp<br />local<br />canary<br />35<br />
  36. 36. More Methods …<br /> Address obfuscation<br />Encrypt return address on stack by XORing with random string. Decrypt just before returning from function<br />Attacker needs decryption key to set return address to desired value<br />36<br />
  37. 37. More Input Validation Flaws<br />37<br />
  38. 38. Format String Vulnerabilities<br />What is the difference between printf(buf);andprintf(“%s”, buf);?<br />What if buf holds %x ?<br />Look at memory, and what printf expects…<br />38<br />
  39. 39. Format String Exploits<br />Technique:<br />Declare a variable of type int in line 4 and call it bytes_formatted<br />Line 6 the format string specifies that 20 characters should be formatted in hexadecimal (“%.20x”) using buffer<br />When this is done, due to the “%n” specifier write the value 20 to bytes_formatted<br />Result:<br />This means that we have written a value to another memory location<br />Very definition of violating memory safety<br />May be possible to gain control over a program’s execution<br />#include <stdio.h><br />int main() {<br />intbytes_formatted=0;<br /> char buffer[28]=”ABCDEFGHIJKLMNOPQRSTUVWXYZ”;<br /> printf(“%.20x%n”,buffer,&bytes_formatted);<br />printf(<br /> “ The number of bytes formatted in the previous printf statement <br /> was %d ”,bytes_formatted);  return 0;<br />} <br />39<br />
  40. 40. Other Input Validation Bugs<br />Integer overflow…<br />Consider the code:strncpy(msg+offset, str, slen);<br /> where the adversary may control offset<br />By setting the value high enough, it will wrap around and be treated as a negative integer!<br />Write into the msg buffer instead of after it<br />40<br />
  41. 41. Web Application Vulnerabilities<br />41<br />
  42. 42. SQL Injection Attacks<br />Affect applications that use untrusted input as part of an SQL query to a back-end database<br />Specific case of a more general problem: using untrusted input in commands<br />42<br />
  43. 43. SQL Injection: Example<br />Consider a browser form, e.g.:<br />When the user enters a number and clicks the button, this generates an http request like<br />43<br />
  44. 44. Example Continued…<br />Upon receiving the request, a Java program might produce an SQL query as follows:<br />A normal query would look like:<br />sql_query<br /> = "SELECT pizza, quantity, order_day "<br /> + "FROM orders " <br /> + "WHERE userid=" + session.getCurrentUserId() + " AND order_month= "<br /> + request.getParameter("month");<br />SELECT pizza, quantity, order_day<br />FROM orders<br />WHERE userid=4123 AND order_month=10<br />44<br />
  45. 45. Example Continued…<br />What if the user makes a modified http request:<br />(Parameters transferred in URL-encoded form, where meta-characters are encoded in ASCII)<br />This has the effect of settingrequest.getParameter(“month”)equal to the string0 OR 1=1<br />45<br />
  46. 46. Example Continued<br />So the script generates the following SQL query:<br />Since AND takes precedence over OR, the above always evaluates to TRUE<br />The attacker gets every entry in the database!<br />SELECT pizza, quantity, order_day<br />FROM orders<br />WHERE userid=4123 AND order_month=0 OR 1=1<br />(<br />)<br />46<br />
  47. 47. Even Worse…<br />Craft an http request that generates an SQL query like the following:<br />Attacker gets the entire credit card database as well!<br />SELECT pizza, quantity, order_day<br />FROM orders<br />WHERE userid=4123 AND order_month=0 OR 1=0UNION SELECT cardholder, number, exp_dateFROM creditcards<br />47<br />
  48. 48. More Damage…<br />SQL queries can encode multiple commands, separated by ‘;’<br />Craft an http request that generates an SQL query like the following:<br />Credit card table deleted!<br />DoS attack<br />SELECT pizza, quantity, order_day<br />FROM orders<br />WHERE userid=4123 AND order_month=0 ;DROP TABLE creditcards<br />48<br />
  49. 49. More Damage…<br />Craft an http request that generates an SQL query like the following:<br />User (with chosen password) entered as an administrator!<br />Database owned!<br />SELECT pizza, quantity, order_day<br />FROM orders<br />WHERE userid=4123 AND order_month=0 ;INSERT INTO admin VALUES (‘hacker’, ...)<br />49<br />
  50. 50. May Need to be More Clever…<br />Consider the following script for text queries:<br />Previous attacks will not work directly, since the commands will be quoted<br />But easy to deal with this…<br />sql_query<br /> = "SELECT pizza, quantity, order_day "<br /> + "FROM orders " <br /> + "WHERE userid=" + session.getCurrentUserId() + " AND topping= ‘ "<br /> + request.getParameter(“topping") + “’”<br />50<br />
  51. 51. Example Continued…<br />Craft an http request where request.getParameter(“topping”)is set toabc’; DROP TABLE creditcards; --<br />The effect is to generate the SQL query:<br />(‘--’ represents an SQL comment)<br />SELECT pizza, quantity, order_day<br />FROM orders<br />WHERE userid=4123 AND toppings=‘abc’;DROP TABLE creditcards ; --’<br />51<br />
  52. 52. Source:<br />52<br />
  53. 53. Solutions?<br />Blacklisting<br />Whitelisting<br />Encoding routines<br />Prepared statements/bind variables<br />Mitigate the impact of SQL injection<br />53<br />
  54. 54. Blacklisting?<br />I.e., searching for/preventing ‘bad’ inputs<br />E.g., for previous example:<br />…where kill_chars() deletes, e.g., quotes and semicolons<br />sql_query<br /> = "SELECT pizza, quantity, order_day "<br /> + "FROM orders " <br /> + "WHERE userid=" + session.getCurrentUserId() + " AND topping= ‘ "<br /> + kill_chars(request.getParameter(“topping")) + “’”<br />54<br />
  55. 55. Drawbacks of Blacklisting<br />How do you know if/when you’ve eliminated all possible ‘bad’ strings?<br />If you miss one, could allow successful attack<br />Does not prevent first set of attacks (numeric values)<br />Although similar approach could be used, starts to get complex!<br />May conflict with functionality of the database<br />E.g., user with name O’Brien<br />55<br />
  56. 56. Whitelisting<br />Check that user-provided input is in some set of values known to be safe<br />E.g., check that month is an integer in the right range<br />If invalid input detected, better to reject it than to try to fix it<br />Fixes may introduce vulnerabilities<br />Principle of fail-safe defaults<br />56<br />
  57. 57. Prepared Statements/bind Variables<br />Prepared statements: static queries with bind variables<br />Variables not involved in query parsing<br />Bind variables: placeholders guaranteed to be data in correct format<br />57<br />
  58. 58. A SQL Injection Example in Java<br />PreparedStatementps =<br />db.prepareStatement( "SELECT pizza, quantity, order_day "<br /> + "FROM orders WHERE userid=? AND order_month=?");<br />ps.setInt(1, session.getCurrentUserId());<br />ps.setInt(2, Integer.parseInt(request.getParameter("month")));<br />ResultSet res = ps.executeQuery();<br />Bind variables<br />58<br />
  59. 59. There’s Even More<br />59<br />Practical SQL Injection: Bit by Bit<br />Overall, SQL injection is easy to fix by banning certain APIs<br />Prevent queryExecute-type calls with non-constant arguments<br />Very easy to automate<br />See a tool like LAPSE that does it for Java<br />
  60. 60. Cross-site Scripting<br />60<br />If the application is not careful to encode its output data, an attacker can inject script into the output<br />out.writeln(“<div>”);<br />out.writeln(req.getParameter(“name”));<br />out.writeln(“</div>”);<br />name: <br /><script>…; xhr.send(document.cookie);</script><br />Simplest version called reflected or type-1 XSS<br />
  61. 61. Memory Exploits and Web App Vulnerabilities Compared<br />Buffer overruns<br />Stack-based<br />Return-to-libc, etc.<br />Heap-based<br />Heap spraying attacks<br />Requires careful programming or memory-safe languages <br />Don’t always help as in the case of JavaScript-based spraying<br />Static analysis tools<br />Format string vulnerabilies<br />Generally, better, more restrictive APIs are enough<br />Simple static tools help<br />Cross-site scripting<br />XSS-0, -1, -2, -3<br />Requires careful programming<br />Static analysis tools<br />SQL injection<br />Generally, better, more restrictive APIs are enough<br />Simple static tools help<br />61<br />