cs 392/681 - computer security - isis

CS 392/681 - Computer Security

Module 16 – Vulnerability Analysis

11/13/2003 Module 16 - Vulnerability Analysis 2

Course Policies and Logistics

n Homework 5 due tonightn Homework 6 postedn Read Chapter 23


Some definitionsn Computer system

n A computer system consists of software, hardware, policies and people

n Vulnerabilityn Failure or weakness in a computer system that leads to

violations of its policies, procedures and integrity

n Exploitn Use of vulnerability to violate the policies, procedures

n Attackern One who attempts to exploit a vulnerability


Two types of Vulnerability Testingn Formal Verification:

n In formal verifications preconditions give the constrains of thestate of the system when the program is run, and the postconditions state the effect of running the program

n Formal verification can theoretically prove the absence of vulnerabilities

n Penetration Testing:n In penetration testing preconditions describe the state of the

system in which hypothesized security flaw can be exploited and the postconditions are the result of testing.

n If the postconditions are inconsistent with the security policies the hypothesis is correct- in other words a vulnerability exists.

n Cannot prove the absence of vulnerabilities but can only prove their existence


Why Penetration Analysis?n If formal verification can prove existence of

vulnerabilities why not use it instead of penetration testing?

n Formal verification is applied to software components.

n Formal verifications do not capture flaws in the policies, procedures and people!

n Penetration analysis attempts to capture flaws in the whole computer system

n However, penetration analysis is not a substitute to rigorous design and implementation of computer systems


Penetration Testing (PenTest)n Also known as

n Penetration analysis (PentAn)n Tiger team attackn Read team [Blue team]

n Ultimate goal of the test is to violate a site’s security policies

n However, usefulness of the study comes from degree of penetration, documentation and conclusions of the study not from the success or failure of the attempted penetrationn For example: successful compromise of user data is not

equivalent to privilege escalation in a computer system


Layered Model for Penetration Testing1. External attacker with no knowledge

n Testers know the target existsn Have enough information to identify itn No access, they have to figure this out social engineeringn Cannot get information about security of the systemn Usually not part of penetration testing

2. External attacker with access to the systemn Attackers have access to the systemn Either use a access mechanism to loginn Usual attacks: guessing passwords, look for unprotected

accounts (guest)n Attack network serversn Usually exploits implementation flaws


Layered model contd.

3. Internal attacker with access to systemn Testers have an authorized account on the

systemn Tests involve gaining unauthorized privilegesn Exploits design, operational and implementation

flaws


Flaw Hypothesis Methodology

n Penetration testing methodology springs from flaw hypothesis methodology

n Developed by System Development Cooperation and provides a framework for penetration studiesn Information gatheringn Flaw hypothesisn Flaw testingn Flaw generalizationn Flaw elimination


Information Gatheringn Design and implementation of the system is

analyzedn Design specifications and manualsn Operating systemn Servicesn Users

n Fingerprinting: Identifying system parametersn Active fingerprintingn Passive fingerprinting

n Testers should identify policies that govern the system


Flaw Hypothesis

n Testers use the knowledge gathered in previous step

n Identify flaws in similar systemsn Prior records of testingn CERT documentsn Newsgroupsn Faulty configurations and defaults

n Hypothesize flaws in current system


Flaw Testing

n Prioritize the flaw hypothesisn Priority is a function of goals of the test

n External access to systemn Privilege escalationn Internal access

n Demonstrate the flaw either through analysis or proof of conceptn Proof of concept code segments can be found on

the Internet, Newsgroups etc.


Flaw Generalization

n Generalize the flaws by categorizationn Buffer overflowsn Setuid flaws n Etc.

n Different category flaws alone may be benign but a combined flaw can be devastating

n See Secure Programming lectures for examples

n Analyze the system for similar flaws or flaws of same family


Flaw Elimination

n Vulnerability analysis, testing usually does not fix flaws

n Recommendations are made to development team based on flaws and exploits


Goals of VA

n Develop ability to specify, design and implement information systems without vulnerabilities

n Develop techniques to analyze information systems for vulnerabilities

n Develop ability to address any vulnerabilities introduced during the operation of the information system

n Develop techniques to detect attempted exploits


VA Frameworks

n Frameworks are abstractions developed by classifiers to achieve certain goals.

n Frameworks present different perspectives.n Frameworks we will cover

n Research Into Secure Operating System (RISOS)n Protection Analysis Modeln NRL Taxonomyn Aslam’s Model


RISOSn Goal: help information systems managers

understand security issues in OS and help estimate the effort required to enhance system security

n Flaw Classes1. Incomplete parameter validation2. Inconsistent parameter validation3. Implicit sharing of privileged data4. Asynchronous validation5. Inadequate authentication6. Violable prohibition7. Exploitable logic error


RISOS Classesn Incomplete parameter validation

n Parameters are not checked properly before usen Check parameters for type, value, access permissions and

their presence or absencen E.g: buffer overflows

n Inconsistent parameter validationn Data validation is done on inconsistent data formatn E.g: delimiters of one routine may be data to another

n Implicit sharing of privileged datan Failure to isolate processes and users properlyn E.g: password guessing on TENEX

n Asynchronous validationn Race conditions


RISOS Classes

n Inadequate authenticationn Failure to properly authenticating usersn E.g: guest accounts, Trojan Horses

n Violable prohibitionn Failure to handle bounds conditions properlyn E.g: failure in array bound checks, pointer

arithmetic

n Exploitable logic errorn Flaws that don’t fall into any of the above classes


Protection Analysis Model

n Goal: attempted to break the operating system into smaller manageable pieces to reduce the required expertise in dealing with operating systems


Protection Analysis Modeln Flaw classes

n Improper protection domain initialization and enforcementn Improper choice of initial protection domainn Improper isolation of implementation detailn Improper changen Improper namingn Improper deallocation or deletion

n Improper validationn Improper synchronization

n Improper indivisibilityn Improper sequencing

n Improper choice of operand or operation


Protection Analysis Modeln Improper protection domain initialization and

enforcementn Flaws raising from initialization of the system or programs

and enforcement of security requirementsn Improper choice of initial protection domain

n Bad umask valuesn Improper isolation of implementation details

n Failure to provide proper abstractionsn Improper change

n Change in property bindings. E.g: access-open callsn Improper naming

n Collisions in names of objects in a systemn E.g: naming a user file ‘ls’

n Improper deallocationn Inadequate garbage collection E.g: failure to free memory


Protection Analysis Modeln Improper validation

n Improper validation of parameters and datan E.g: bounds checking– buffer overflows

n Improper synchronizationn Occurs when designers fail to synchronize events properlyn Improper indivisibility

n Failure to provide atomic operationsn Improper sequencing

n Inadequate logic sequences in eventsn E.g: flaws in some one-time password schemes

n Improper choice of operand or operationn Inappropriate or erroneous calls to functionsn E.g: calling rand() without seeding it!


The NRL Taxonomyn Goal: a taxonomy to help designers and

operators of the system enforce security.n Three questions to answer…

n How did the flaw enter the system?n When did it enter the system?n Where in the system is it manifest?

n Built three different sets of flaw classes to answer the above questionsn Flaw by Genesisn Flaw by Time of Introductionn Flaw by Location


NRL: Flaws by Genesis

n Maliciousn Trojan Horse

n Non-replicatingn Replicating

n Trapdoorn Logic/Time Bomb

n Non-Maliciousn Covert Channel

n Storagen Timing

n Other


NRL: Flaws by Time of Introduction

n Developmentn Requirementsn Source Coden Object Code

n Maintenancen Operation


NRL: Flaws by Locationn Software

n Operating Systemn System initalizationn Memory managementn Process managementn Device managementn File managementn Authenticationn Other/unknown

n Supportn Privileged utilitiesn Unprivileged utilities

n Application

n Hardwaren Faulty APIs


Aslam’s Model

n Goal: Group security flaws in Unix by similar faults without ambiguity to store in databases

n Flaw Classesn Coding faults

n Synchronization errorsn Condition validation errors

n Emergence faultsn Configuration errorsn Environment faults


Gupta’s and Gligor’s Theoryn A formal analysis technique to detect vulnerabilities

arising from failure to perform adequate checksn Hypothesis

n Of Penetration Patterns“System flaws that cause a large class of penetration patterns can be identified in system source code as incorrect/absent condition checks or integrated flaws that violate the intentions of the system designers”

n Of Penetration-Resistant Systems“A system is largely resistant to penetration if it adheres to aspecific set of design properties”

n Some properties chosen to formalize the model


Properties chosen in the modeln System isolation and tamperproofness

n User must not be able to tamper with the systemn System interaction must be through well-defined

abstractions

n System noncircumventabilityn System checks all references to objectsn User cannot circumvent any system checks

n Consistency of global objects of the systemn With respect to timing and storage objects are consistent

n Elimination of undesirable system and user dependencies


Further readings

n Chapter 23n A Taxonomy of Security Faults in the Unix

Operating System, Tamir Aslamn Vulnerabilities Analysis, Matt Bishopn Use of A Taxonomy of Security Faults, Taimur

Aslam, Ivan Krsul, Eugene Spafford

cs 392/681 - computer security - isis

Documents