Understanding Attacks and Vulnerabilities: Classifications and Examples, Study notes of Computer Science

Download Understanding Attacks and Vulnerabilities: Classifications and Examples and more Study notes Computer Science in PDF only on Docsity! CS626: Classes of Attacks and Vulnerabilities • Pascal Meunier, Ph.D., M.Sc., CISSP • Purdue University, March 6, 2008 • Based on a chapter I wrote for the Handbook of Science and Technology for Homeland Security (Wiley) Plan • Problem Statement • Popular Vulnerability Classifications • Popular Attack Classifications • Scientific Classifications • Enumeration of Attack and Vulnerability Types • Future Research Typical Classification Issues • Not objective – Depends on some point of view or abstraction level • Not reproducible or ambiguous – Different people will classify a vulnerability in different categories Typical Classification Issues (cont.) • Multiple category memberships (overlaps) • Simultaneously • Different times • Some things can't be classified • Unstable: category changes greatly when a bit more information is uncovered – from one tree branch to one far away Other Problems • Classes of different and mixed natures at the same level. You are asked to choose between: – a consequence or impact – a kind of mistake – an exploit method – a goal, property or invariant – etc... Vulnerability Example policy: the content on a web site is restricted to authenticated users. Flaw: the web site relies on JavaScript to be executed on the client browser for access control Vulnerability: JavaScript needs to be enabled, and can be trivially disabled at the client An abundance of vulnerable sites exist Popular Vulnerability Classifications • Exploitability • Software Development LifeCycle (SDLC) phase • Genesis • Location in object models • Affected technology • Errors or mistakes • Enabled attack scenario Popular Vulnerability Classifications (cont.) • CLASP • Seven Kingdoms • Disclosure process • Vulnerabilities in systems –Configuration issues –Exposures –System vulnerabilities –Proper vulnerabilities Latent Vulnerabilities Sometimes, a vulnerability can be protected by a change that leaves the vulnerable code in place: –some change external to the application (firewall) –a configuration change (disabling an option) –a code wrapper that blocks exploit attempts  Discovery of another exploit path results in yet another advisory for the same issue Potential Vulnerabilities Things that are associated with vulnerabilities or tend to lead to vulnerabilities – Bad practices – Quality defects – Other flaws Safe within a specific code unit Not affected by changes in other code units Example • Defect in a private method of an object that is usually recognized as a vulnerability • All externally callable methods (e.g., public) call that method safely – not exploitable as long as no code changes are made to the object • Regardless of all external code changes • Could be exposed by a child class defining a new public method SDLC Phase • Classical phases: 1)Feasibility study 2)Requirements definition 3)Design 4)Implementation 5)Integration and testing 6)Operations and maintenance ● In which phase was the vulnerability introduced? Variations • Simpler model – Design (first 3 groups) – Implementation – Operation and maintenance • Appeals to academics to distinguish: – a correct, good algorithm or protocol, badly implemented – a vulnerable algorithm or protocol, correctly implemented Problems • Choice in number of phases • Many software engineering models – Which model was used to develop software X? • Depends on level of abstraction – How specific is the design? – A design issue is sometimes an implementation issue for someone else – Common for programs to abstract issues away in other units or “layers” Location in Object Models • Idea: in which layer, entity, object or sub-system is the vulnerability located? • Example: OSI reference model for networking (7 layers) – The vulnerability belongs to which layer? • Reality: some vulnerabilities depend on the specific interactions between layers – not always applicable Case Study • CVE-1999-0144 – Denial of service in Qmail by specifying a large number of recipients with the RCPT command. • Qmail claims it's a configuration problem in UNIX-like operating systems – configuration option could prevent the vulnerability • OS guys say it's not their problem Who's Fault Is It? • Ill-defined responsibilities make it difficult to “pin the blame” on a specific layer or object – Recurring theme in vulnerability analysis • Current issue – browsers vs plug-ins, extensions, controls – Who's responsible for security? Resource Exhaustion • Limited computer resources that can be “hogged” – abused maliciously to limit system functionality • a.k.a. Denial of Service (DoS) • Examples – SYN-flood attacks – Memory leaks – Algorithmic complexity attacks Limitations • The name of the technology is a useful and descriptive reference, but • Some vulnerabilities aren't specific to a technology • Flaw causing the vulnerability may have a weak relationship to the technology that is vulnerable Errors or Mistakes • Cause • Nature of their impact • Type of change or fix made to remove the error • Examples – “Use of weak password-based systems” – “Failing to store and protect data securely” – “Double-free” memory management error Limitations • “Denial-of-Service vulnerabilities” isn't useful because – many different kinds of vulnerabilities can result in DoS – DoS is a consequence, not really an attack scenario • What is an attack scenario? Case Study • Vulnerabilities in network protocols – Linked to “tests” (attack techniques) and countermeasures – Enumeration, probably incomplete but still useful – Pothamsetty and Akyol Vulnerabilities in Network Protocols 1.Clear text communication 2.Non-robust protocol message parsing 3.Insecure protocol state handling 4.Inability to handle abnormal packet rates 5.Vulnerability arising from replay and reuse 6.Protocol field authentication 7.Entropy problems CLASP • Comprehensive, Lightweight Application Security Process – Set of activities aiming to improve security – Focused on enumerating errors – Simultaneously includes events and “conditions” • Ambiguous, multiple membership possible CLASP • Range and type errors – Buffer overflows – Format string problems – Write-what-where condition • Ability to write an arbitrary value to an arbitrary location • Environmental problems – Events such as the failure of a random number generator CLASP • Synchronization and timing errors – Includes statistical attacks (?) – Includes capture-replay (?) • Isn't that a protocol weakness? • Protocol errors – Using a broken or risky cryptographic algorithm Usefulness of CLASP • Goal is to discuss which kinds of vulnerabilities may be found during various activities – Do your activities provide complete coverage? • What should you do to catch X and Y? – Not directly applicable to a collection of vulnerabilities Seven Kingdoms • Input validation and representation • API abuse • Security features • Time and state • Error handling • Code quality • Encapsulation • Environment (mostly configuration) Seven Kingdoms • Simultaneously includes causes, consequences and bad practices • A vulnerability can – belong to several categories at once – be classified differently depending on the abstraction level • API abuse category especially ambiguous • 0-day States • Secret – Not shared • Private – Shared in small groups • Disclosed (end of life) – Admins try to mitigate consequences – Vendor scrambles to provide low-quality patch (downgrade to latent vulnerability) – More potential attackers learn about it Why do we Care? • Ethical implications for security researcher • Responsible disclosure – Give the vendor a chance to create a good quality fix for a vulnerability before it becomes public • If the vulnerability is being exploited, there is reason to give less time or no time at all to the vendor Vulnerabilities in Systems • Configuration issues • Exposures • System vulnerabilities • Proper vulnerabilities Analysis of System Vulnerabilities • Needs to reference a violated security policy – Policies appropriate for different organizations can result in two different lists of vulnerabilities – Policy is defined externally to the system • not an intrinsic property • Analyze the relevant interactions between various parts “Generic” System Vulnerabilities • Reasonable expectation that a relevant policy would be deployed somewhere • Example: MITRE Common Configuration Enumeration (CCE) – Use hardening configuration guides as policy examples – Identify configuration settings that are of interest to policies, in a generic fashion • “This value should be set appropriately” Proper Vulnerabilities • Are apparent defects when comparing the software artifact to its requirements, design and security goals – Intrinsic properties of the artifact • doesn't matter where, when, how or by who the software is used – Analysis more objective and reproducible • unless researcher has to guess the design and security goals Limitations • FTP server wu-ftpd (CVE-1999-0997) – conversion option • allows compressing with “tar” – It's a system vulnerability, because it appears through the interaction of various software artifacts – It's a software artifact vulnerability because wu-ftpd was designed to call other programs with the conversion option Popular Attack Classifications • Perspective problem – Origin – Goal – Mechanism – Motivation • Purpose of an attack may be clear to the attacker but can appear as something else to the defender DARPA IDS Evaluation 1.Probe or surveillance ● Information gathering 2.Denial of service ● Consequence of an attack... 3.R2L (remote to local) remote access 4.U2R (user to root) user gains root 5.Data: “exfiltrate” confidential files Transactional Attack Scenario • Describe attack based on the transactions between participants – Replay attacks – Man-in-the-middle – XSS (with 3rd party host) – Eavesdropping • Useful for communication protocols Impact • Used in the Common Vulnerability Scoring System (CVSS) – none – partial – complete • Worst attack enabled by a vulnerability – Can we really know what is the worst possible thing that could happen? Attack Language • Tool used • Vulnerability targeted • Events – actions – targets • Unauthorized result (perhaps attempted) Malicious Code • Attack code • Parasitic code • Back-doors • Trojans • Self-propagating code • Spyware • Logic/Time triggered code • Rootkit • Distributed code Self-Propagating Code • Viruses – Parasitic • Attaches to files – documents » macro-viruses (scripts inside documents) – executables • Worms – Spread on their own, duplicating their code and re-spawning their processes Scientific Classifications • Objectivity – based on observable property of object • Determinism – clear and explicit procedure • Repeatability • Specificity – unique and unambiguous value How to Construct • Domain of validity (scope) • Purpose (viewpoint) – e.g., web services • Use technical taxonomic criteria – avoid speculation Violated Program Invariants • Assumptions • Invariants • Pre-conditions • Post-conditions • High cardinality • Formal methods can help – Spark Enumerations • Idea: if we can't classify everything, let's start by identifying – forms test cases for a successful classification – a priori (top-down) was unsuccessful, let's see what can be accomplished with – a posteriori (bottom up) classification attempt • PLOVER Ontology Types • Common ontologies – Restricted domain • Upper ontologies – wide range of domains – much more difficult to create UNIVERSITY Questions? CEI “BAS Neto: //woyvaesrias. ours selty