Software Security Explorative Lecture A brief history of security - PDF document

1/30/2020 Software Security Explorative Lecture A brief history of security problems  attacks on multi-user UNIX systems for fun  viruses & worms attacking operating systems  due to buffer overflow, format string attacks, integer overflows,...  response: firewalls & better operating system code  variant: bot-nets  attacks on web-applications  due to SQL injection, XSS, session riding (Cross Site Request Forging), ....  response: intrusion detection systems & application firewalls  attacks on web-browsers  man-in-the-browser attacks ...  2 1

1/30/2020 A brief history of security problems  Trojans & spyware  installed via OS security hole, or silly user  spam  response: spam filters  variants: phishing, spear-phishing & whaling, spit (Spam over Internet Telephony)  ... 3 Trend  move away from hacking for 'fun' (ie vandalism) to hacking for profit  zero-day exploits are worth a lot of money 4 2

1/30/2020 Security Concepts  Security is about imposing countermeasures to reduce risks to assets to acceptable levels  “Perfect security” is not necessary and costly  A security policy is a specification of what security requirements/goals the countermeasures are intended to achieve  secure against what and from whom ?  Security mechanisms to enforce the policy  What actions we should take under an attack? 5 Security Objectives: CIA  Confidentiality (or secrecy)  unauthorized users cannot read information  Integrity  unauthorized users cannot alter information  Availability  authorized users can always access information  Non-repudiation for accountability  authorized users cannot deny actions  Others  Privacy, anonymity… 6 3

1/30/2020 Kinds of undesired behavior  Stealing information: Confidentiality  Corporate secrets (product plans, source code, …)  Personal information (credit card numbers, SSNs, …)  Modifying information or functionality: Integrity  Installing unwanted software (spyware, botnet client, …)  Destroying records (accounts, logs, plans, …)  Denying access: Availability  Unable to purchase products  Unable to access banking information  The aim of Computer security is to preserve the system Confidentiality, Integrity, and Availability What is computer security?  Most developers and operators are concerned with correctness : achieving desired behavior  A working banking web site, word processor, blog, …  Security is concerned with preventing undesired behavior  Considers an enemy/opponent/hacker/adversary who is actively and maliciously trying to circumvent any protective measures you put in place 4

1/30/2020 A Brief History of Notable Hacking (Security breaches)  RSA , March 2011  stole tokens that permitted subsequent compromise of customers using RSA SecureID devices  Adobe , October 2013  stole source code, 130 million customer records (including passwords)  Target , November 2013  stole around 40 million credit and debit cards  … and many others! Defects and Vulnerabilities  Many breaches begin by exploiting a vulnerability  This is a security-relevant software defect that can be exploited to effect an undesired behavior  A software defect is present when the software behaves incorrectly, i.e., it fails to meet its requirements  Defects occur in the software’s design and its implementation  A flaw is a defect in the design  A bug is a defect in the implementation 5

1/30/2020 Example: RSA 2011 breach  Exploited an Adobe Flash player vulnerability  1. A carefully crafted Flash program , when run by the vulnerable Flash player, allows the attacker to execute arbitrary code on the running machine  2. This program could be embedded in an Excel spreadsheet , and run automatically when the spreadsheet is opened  3. The spreadsheet could be attached to an e-mail masquerading to be from a trusted party (spear phishing) Considering Correctness  The Flash vulnerability is an implementation bug!  All software is buggy. So what?  A normal user never sees most bugs, or works around them  Most (post-deployment) bugs due to rare feature interactions or failure to handle edge cases  Assessment: Would be too expensive to fix every bug before deploying  So companies only fix the ones most likely to affect normal users 6

1/30/2020 Considering Security Key difference: An adversary is not a normal user!  The adversary will actively attempt to find defects in rare feature interactions and edge cases  For a typical user, (accidentally) finding a bug will result in a crash, which he will now try to avoid  An adversary will work to find a bug and exploit it to achieve his goals Security Goals  The well-known trio  confidentiality, integrity, avaliability (CIA)  There are more “concrete” goals  traceability and auditing (forensics)  monitoring (real-time auditing)  multi-level security  privacy & anonymity  ...  and meta-property  assurance – that the goals are met  “information assurance” 14 7

1/30/2020 How to Realize Security Objectives? AAAA  Authentication  who are you?  Access control/Authorization  control who is allowed to do what  this requires a specification of who is allowed to do what  Auditing  check if anything went wrong  Action  if so, take action 15 How to Realize Security Objectives?  Other names for the last three A's  Prevention measures to stop breaches of security goals   Detection measures to detect breaches of security goals   Reaction measures to recover assets, repair damage, and prosecute (and deter) offenders   Good prevention does not make detection & reaction superfluous  E.g., breaking into any house with windows is trivial; despite this absence of prevention, detection & reaction still deter burglars 16 8

1/30/2020 Is it enough? Firewalls and anti-virus are Attackers often can bypass like building walls around a outer defenses to attack weak interior weaknesses within Operating System Security  Operating systems mediate a program’s actions!  Aka system calls!  such as reading and writing files,  sending and receiving network packets,  starting new programs, etc.  Enforceable policies control actions  programs run by Alice cannot read files owned by Bob  programs run by Bob cannot use TCP port 80  programs run in directory D cannot access files outside of D 9

1/30/2020 Limitations of OS Security  Cannot enforce application-specific policies , which can be too fine-grained  Example: database management system (DBMS)  Cannot (precisely) enforce info-flow policies!  An operating system typically implements an execution monitor : decisions are based on past and current actions  Information flow policies : A non- action may reveal something about a secret without leaking it directly Firewalls and IDSs  Firewalls and intrusion detection systems (IDSs) observe , block , and filter messages exchanged by programs  Based on their origin, content, frequency, etc.  Examples:  Firewall could block all traffic from particular hosts, or to particular TCP ports  An IDS could filter packets it recognizes are part of a known exploit pattern 10

1/30/2020 Filtering misses attacks  Firewall filtering is coarse-grained, and unsound  Port 80 is assumed to be HTTP (web) traffic, which is assumed benign, but can layer arbitrary traffic over HTTP, e.g., SOAP  Previously benign sources can become malicious  E.g., due to malware infection  IDS patterns fine-grained, but still unsound!  Attack traffic can be slightly modified to work around IDS filters (which are often syntactic, not semantic)  Making filters too fine-grained can hurt performance  Thus compromising availability Anti-virus Scanners  Anti-virus scanners look for signs of malicious behavior in local files  In many ways, anti-virus is related to IDS in looking for patterns  Newer forms of anti-virus scanners are sophisticated, but i n practice are frequently bypassed!  Trade off precision and performance (latter could compromise availability) 11

1/30/2020 Ex: Heartbleed  SSL/TLS is a core protocol for encrypted communications used by the web  Heartbleed is a bug in the commonly used OpenSSL implementation of SSL/TLS, v1.0.1 - 1.0.1f  Discovered in March 2014, it has been in released code since March 2012  A carefully crafted packet causes OpenSSL to read and return portions of a vulnerable server’s memory  Leaking passwords, keys, and other private information Heartbleed, meet SoftSec  Black box security is incomplete against Heartbleed exploits!  Issue is not at the level of system calls or deposited files: nothing the OS or antivirus can do  Basic attack packets could be blocked by IDS, but  “Packet chunking” may bypass basic filters  Exfiltrated data on the encrypted channel; invisible to forensics  Software security methods attack the source of the problem: the buggy code 12

1/30/2020 What about Cryptography? Cryptography is usually not the problem "Using encryption on the Internet is the equivalent of arranging an armored car to deliver credit card information from someone living in a cardboard box to someone living on a park bench." -- Gene Spafford 25 What about Cryptography? 13