Chapter 20: Vulnerability Analysis

Chapter 20: Vulnerability Analysis
김재환 Database Lab.

Contents Introduction Penetration studies Vulnerability examples
Flaw Hypothesis Methodology Examples Vulnerability examples Classification schemes RISOS PA NRL Taxonomy Aslam’s Model Database Laboratory

Introduction Vulnerability, security flaw Formal Verification
Subject (attacker)의 security policy를 위반하는 행위로 인한 security policy, procedures, and controls이 fail이 되는 것. Formal Verification Mathematically verify System은 일정한 제약조건들을 만족해야 한다. Preconditions : system에 대한 기본적 가정Postconditions : preconditions 상태에서 system operations을 수행한 결과 Required: postconditions satisfy constraints Database Laboratory

Introduction Penetration Testing
System이 constraint를 만족하는지 를 test system의 특징, 환경, vulnerability 가 발생할 수 있는 가상의 상황을 정의 해결된 상태를 결과로 내보냄 vulnerability 가 발생할 수 있는 가상의 상황에서 해결된 상태로 이동하기 위한 test . Penetration testing is a testing technique, not a verification technique vulnerability 의 존재를 증명할 뿐, 제거 할 수는 없다. Database Laboratory

Penetration Studies System의 security policy가 얼마나 효과적으로 작동하는지를 평가.
Also called tiger team attack or red team attack Goal: violate site security policy System 전체를 test. Includes procedural, operational controls Database Laboratory

Penetration Studies Goals
security 또는 integrity policy의 constraints를 위반해 본다. 침투를 시도 해 봄으로써 취약한 부분을 찾음 Example 1 : subsystem에서 어떤 user가 임의의 파일을 접근하려 할 때 file의 owner는 user에게 password를 요구한다. (i.e., password protect files) Goal: test this control Metric: tester는 password 없이 또는 password 정보에 접근하여 file을 access go 해본다. Database Laboratory

Penetration Studies Goals (cont’s)
Vulnerabilities의 수, 또는 vulnerabilities 가 발생하는 시점을 찾는다. 어떤 vulnerabilities 인지 찾게 되면 system의 design, implementation, 그리고 operation에 이 부분을 유의한다. Example 2 : 어떤 document에 대해 confidential을 가지고 있다가 한달 후 그 document를 web에 공개. Goal: 30일 이내에 document에 접근~! Alternate goal: 시간에 구애받지 않고 언제든지 파일에 접근. (a Trojan horse would give access for over 30 days) Database Laboratory

Penetration Studies Layering of Tests
External attacker with no knowledge of system Locate system, learn enough to be able to access it External attacker with access to system Can log in, or access network servers Often try to expand level of access Internal attacker with access to system Testers are authorized users with restricted accounts (like ordinary users) Typical goal is to gain unauthorized privileges or information Database Laboratory

Penetration Studies Layering of Tests (cont’s)
Studies는 attacker의 관점에서 수행된다. Environment는 attacker가 활동할 수 있도록 갖추어져 있다. If information about a particular layer irrelevant, layer can be skipped Example: penetration testing during design, development skips layer 1 Example: penetration test on system with guest account usually skips layer 2 Database Laboratory

Methodology at Each Layer
Usefulness of penetration study comes from documentation, conclusions Indicates whether flaws are endemic or not 특정 system에서만의 특징인지 지적해야 한다. penetration 의 성공/실패 여부에 의한 결과물이 아니다. Degree of penetration’s success also a factor 어떤 특정 data의 접근을 성공하는 것 보다는 어떤 data 집합을 접근 할 수 있는 privileges를 획득하는 것이 더 성공적이라고 할 수 있다. Penetration testing Methodology는 Flaw Hypothesis Methodology에 그 기원을 둔다. Database Laboratory

Flaw Hypothesis Methodology
Penetration studies의 framework를 제공한다 Four step Information gathering Become familiar with system’s functioning Flaw hypothesis Draw on knowledge to hypothesize vulnerabilities Flaw testing Test them out Flaw generalization Generalize vulnerability to find others like it (maybe) Flaw elimination Testers eliminate the flaw (usually not included) Database Laboratory

Information Gathering and Flow Hypothesis Information Gathering System의 component사이의 interface를 관찰하여 component간의 모순을 찾아본다 Need to know system well (or learn quickly!) Design documents나 system의 manuals 을 참고하여 완벽하지 않은 부분을 찾아본다. 여러 designer가 여려 component를 설계한 경우, document에 불확실하게 설명된 부분들은 빈틈이 있을 가능성이 높다. Look at how system manages privileged users He may reveal flaw~! Database Laboratory

Information Gathering and Flow Hypothesis (cont’s) Flow Hypothesis Examine policies, procedures that maintain System System의에서 잘못 수행이나 부정확한 install의 결과는 vulnerabilities를 잠재하고 있다. Examine implementations vulnerabilities 을 지닌 model에는 문제점이 잠재되어 있다. 이 model로 design된 system은 문제가 발생하기 쉽다. Use manuals! Manual에 있는 여러 제약 사항들을 위반하거나 , 일련은 과정 중 하나를 무시함으로써 flaw를 야기시킬 수도 있다. Database Laboratory

Information Gathering and Flow Hypothesis (cont’s) Flow Hypothesis (cont’s) Identify structures, mechanisms controlling system These are what attackers will use Debugger, compiler 등 system을 control 하기 위한 tool의 결함은 system에 문제를 일으킬 수 있고, tester는 이 부분에서 flaw의 가능성을 발견 할 수 있다. 지금까지의 과정을 통하여 system에 대한 경험을 얻을 수 있다. 다른 system에서도 비슷한 vulnerabilities가 있다. 이 단계의 결과를 차후 vulnerabilities classification에 활용. Database Laboratory

Flaw Testing test할 flaw의 순서를 결정 Priority : test의 목표의 기능 system의 design 이나 implementation의 문제점을 발견하기 위해선 design상의 문제나 system의 핵심 code에 대한 test에 높은 우선순위를…. outside attacker에 대한 vulnerabilities를 분석하기 위해서는 access protocol에 대한 test에 중점을 둔다. 어떻게 test 할 것인지 결정 Best way: demonstrate from the analysis Specification, design, operation의 flaw일 경우 분석을 통하여 발견. Otherwise, must try to exploit it Attack 해 본다! Database Laboratory

Flaw Testing (cont’s) Design test to be least intrusive as possible Must understand exactly why flaw might arise Procedure Back up system System이 test를 위해 configure되었음을 입증 Flaw를 찾기 위한 요구사항들을 기록 Flaw의 존재를 입증 Flaw를 이용 하고서도, 이용하지 않고서도 가능 되도록 간결하게…, 하지만 flaw를 성공적으로 사용하여 표현 할 수 있도록. Must be able to repeat test successfully Database Laboratory

Flaw Generalization Test를 성공하면 flaw의 class가 발생한다. Tester는 flaw를 인지 하도록 하고 다른 두 flaw이 조합하여 심각한 attack을 야기 할 수 있음을 주지 시켜야 한다. Example In windows NT Flaw1 : unprivileged account를 획득 외부 attacker의 침입 Flaw 2: 일반 user가 admin privilege를 이용. System의 어떤 user도 full privilege를 가질 수 있다. Flaw1+Flaw2 : system에 접근할 수 있는 모든 user는 supervisor가 될 수 있다. 어떤 외부 attacker도 full privilege를 획득 할 수 있다. Database Laboratory

Flaw Elimination Often omitted Because not part of penetration Correction을 위해선 flaw와 그 이용에 대해 자세히 숙지해야 한다. Development 단계에서 해결하지 못한 design flaw를 수정 할 수 있다. Flaw가 어떻게 이용되는지는 중요치 않다. Production site에서 해결하지 못한 design flaw은 attack을 예방 할 수 있을 만큼 빨리 수정하기 힘들다. Flaw가 어떻게 이용되었는지 알아야 한다. 이 정보를 통해 flaw를 수행하는 경로를 차단하고, 어떤 attacker가 flaw를 수행하려는지 알 수 있다. Database Laboratory

Example: Penetration of the Michigan Terminal System
General-purpose OS running on IBM 360, 370 systems A graduate computer science class exercise at the University of Michigan Goal: gain access to terminal control structures Had approval and support of center staff Began with authorized account (level 3) [cf.slide 8] Layering of Tests External attacker with no knowledge of system External attacker with access to system Internal attacker with access to system Database Laboratory

Step 1 : Information Gathering Learn details of system’s control flow and supervisor When program ran, memory split into segments 0-4: supervisor, system programs, system state Protected by hardware mechanisms 5: system work area, privilege level 등 process의 정보를 담고 있다. Process는 이 부분을 수정 할 수 없어야 한다. 6 on: user process information Process가 수정할 수 있는 부분이다. Segment 5는 가상 메모리의 protection system에 의해 보호 받는다. System mode: process가 segment 5에 있는 data를 접근하고 수정 할 수 있는 mode. Supervisor call을 할 수 있다. User mode: segment 5의 process address space를 공개하지 공개하지 않는다. 따라서 이 부분의 data를 process는 수정 할 수 없다. User code는 user mode 에서 실행 된다. User code가 system call을 수행하게 되면 이 system call은 supervisor call을 한다. supervisor, system program, system state 1 2 3 4 5 System work area 6 user process information Database Laboratory

How to Make a Supervisor Call User process  system call supervisor call System code는 parameter를 check하여 system이 허가 받은 위치만 접근 하는지 확인한다. Address list로 전달되는 Parameters (X, X+1, X+2) 는 user segment (segment 6)에서 구성된다. Address of list (X) passed via register Figure 20-2 X, X+1, X+2는 실제 parameter의 address를 담고 있다. X+1에는 X+2의 address를 가지고 있고, X는 X+1의 address를 담고 있다. X  X+1  X+2 : parameter list 결국 parameter list의 맨 마지막 address가 실제 parameter의 위치이다. Database Laboratory

Step 2 : Flaw Hypothesis User mode에서 system mode로 전환하는 상황 System mode requires supervisor privileges Found: parameter는 다른 parameter list의 element를 point 한다. X+2에 담고 있는 정보는 X+1의 address System이나 supervisor가 parameter의 address를 수정할 수 있는 위험이 있다. Figure 20-2 Database Laboratory

Step 3 : Flaw Testing Find a system routine that: System call 있어야 하고 적어도 2개의 parameter를 지니고 하나는 수정하는 routine. Parameter의 어떠한 값도 바꿀 수 있는 routine (such as an address in segment 5) Chose line input routine Returns line number, length of line, line read Setup: Line number를 저장하는 위치의 address를 line length를 저장하는 위치의 address로 setting 한다. Database Laboratory

Step 4 : Execution System routine은 parameter에 문제가 없음을 확인 모든 parameter는 user segment에 있기 때문… Supervisor read input line Line number가 저장되어야 하는 segment 5 위치에 line length가 저장된다. Line number stored in parameter list Line number는 segment 5의 address로 setting 된다. Line read를 수행 하면 line number가 기록 된 후 line length가 덮어 쓰여 진다. Segment 5 부분의 data가 훼손. Database Laboratory

Step 5: Flaw Generalization segments 0-4 hardware에 의해 write가 보호 된다. Tester는 segment 5의 privilege level은 supervisor call 을 할 수 있음을 발견. Effect: 이 flaw는 attacker가 memory의 값들을 수정 할 수 있고 따라서 computer를 제어 할 수 있음을 밝히고 있다. Database Laboratory

Example: Compromise of a Burroughs System
Burroughs B6700 System architecture: based on strict file typing Entities: ordinary users, privileged users, privileged programs, OS tasks Ordinary users tightly restricted Other 3 can access file data without restriction but constrained from compromising integrity of system No assemblers; compilers output executable code Data files, executable files have different types Only compilers can produce executables Writing to executable or its attributes changes its type to data Class exercise: obtain status of privileged user Database Laboratory

Step 1: Information Gathering System had tape drives Writing file to tape preserved file contents Header record prepended to tape that indicates file attributes including type Data could be copied from one tape to another If you change data, it’s still data Step 2: Flaw Hypothesis System cannot detect change to executable file if that file is altered off-line Database Laboratory

Step 3: Flaw Testing Write small program to change type of any file from data to executable Compiled, but could not be used yet as it would alter file attributes, making target a data file Write this to tape Write a small utility to copy contents of tape 1 to tape 2 Utility also changes header record of contents to indicate file was a compiler (and so could output executables) Creating the Compiler Run copy program As header record copied, type becomes “compiler” Reinstall program as a new compiler Write new subroutine, compile it normally, and change machine code to give privileges to anyone calling it (this makes it data, of course) Now use new compiler to change its type from data to executable Write third program to call this Now you have privileges Database Laboratory

Example: Penetrating of a Corporate Computer System
Goal: determine whether corporate security measures were effective in keeping external attackers from accessing system Testers focused on policies and procedures Both technical and non-technical Step 1: Information Gathering Searched Internet Got names of employees, officials Got telephone number of local branch, and from them got copy of annual report Constructed much of the company’s organization from this data Including list of some projects on which individuals were working Database Laboratory

Step 2: Get Telephone Directory Corporate directory would give more needed information about structure Tester impersonated new employee Learned two numbers needed to have something delivered off-site: employee number of person requesting shipment, and employee’s Cost Center number Testers called secretary of executive they knew most about One impersonated an employee, got executive’s employee number Another impersonated auditor, got Cost Center number Had corporate directory sent to off-site “subcontractor” Database Laboratory

Step 3: Flaw Hypothesis Controls blocking people giving passwords away not fully communicated to new employees Testers impersonated secretary of senior executive Called appropriate office Claimed senior executive upset he had not been given names of employees hired that week Got the names Step 4: Flaw Testing Testers called newly hired people Claimed to be with computer center Provided “Computer Security Awareness Briefing” over phone During this, learned: Types of comnputer systems used Employees’ numbers, logins, and passwords Called computer center to get modem numbers These bypassed corporate firewalls Database Laboratory

Example: Penetrating a UNIX System
Goal 1: gain access to system (layer 1) Just know network address of target First step: scan network ports of system Figure 20-3 In UNIX system Sendmail : SMTP agent Sendmail has had lots of security problems 현재는 많이 개선 됨 System은 문제가 있는 구 버전의 sendmail을 실행 한다고 가정. Next step: connect to sendmail on port 25 Database Laboratory

ftp 21/tcp File Transfer telnet 23/tcp Telnet smtp 25/tcp Simple Mail Transfer finger 79/tcp Finger sunrpc 111/tcp SUN Remote Procedure Call exec 512/tcp remote process execution (rexecd) login 513/tcp remote login (rlogind) shell 514/tcp rlogin style exec (rshd) printer 515/tcp spooler (lpd) uucp 540/tcp uucpd nfs /tcp networked file system xterm /tcp x-windows server Figure The output of the UNIX port scan. These are the ports that provide Database Laboratory

220 zzz.com sendmail 3.1/zzz.3.9, Dallas, Texas, ready at Wed, 2 Apr 97 22:07:31 CST sendmail Ver.3.1에는 “shell” command “wiz”가 있다. “wiz” command는 root –owned shell을 이용하도록 해준다. helo xxx.org 250 zzz.com Hello xxx.org, pleased to meet you sendmail Ver.3.1 이면 “wiz“ command가 정의되어 있지 않기 때문에 “command unrecognized” message가 뜰 것이다. wiz 250 Enter, O mighty wizard! It does! And we didn’t need a password … so get a root shell shell # And we have full privileges as the superuser, root Figure A successful accessing of a UNIX system Database Laboratory

Goal 2:unprivileged account 를 가지고 있는 상태에서 privileged account를 획득. (layer 3) First step: examine system System은 부팅이 된 후 종료되기 전까지는 kernel을 dynamic 하게 load 한다. Loadmodule이라는 program이 kernel에 추가. loadmodule must be privileged. unprivileged user 는 kernel의 loadmodule 를 통해서 privileged program을 실행할 수 있다. Question: how does loadmodule work? Loadmodule Dynamic하게 load 되는 module이 문제가 없는지 판단. invoke dynamic loader ld.so Check, but only privileged user can call ld.so How does loadmodule execute these programs? Library function “system(3)”을 사용: environment를 reset시키지 않음. System call이 사용되면 loadmodule를 수행하던 environment가 subprocess에 전달되고, 이 process는 root로 수행 된다. ld.so program이 수행되는데 필요한 shared library를 찾아서 load하여 program이 실행될 수 있게 한다. system(3) shell command를 수행 Database Laboratory

First Try UID를 print하는 program을 작성하고 “ld.so”라고 이름 짓는다. 이 program을 현재 working directory에 옮기고 PATH에 등록. Hypothesis : loadmodule 를 수행하면 dynamic loader “ld.so”를 수행 하려는 것이 PATH 정보를 보고 앞에서 작성한 프로그램을 수행하여 UID를 print 할 것이다. Then run loadmodule Nothing is printed PATH정보 (environment)를 수정한 것이 영향을 주지 않는다. 이유는?? Database Laboratory

What Happened? Look in executable to see how ld.so invoked Invocations are “/bin/ld.so”, full path~! PATH를 수정하더라도 소용없음. Reread system(3) manual page Subcommands를 수행하기 위해 command interpreter sh를 invoke 한다. Read sh(1) manual page IFS environment 값을 이용하여 word를 나눈다. These are by default blanks … IFS에 ‘/’를 추가하면 sh 는 “/bin/ld.so”를 “bin”과 “ld.so”로 나누기 때문에 “bin” 과 “ld.so”의 분리된 두 command로 인식. Database Laboratory

Second Try Change value of IFS to include “/” UID를 출력하는 program의 파일 이름을 “bin”으로 설정. Run loadmodule “bin” 과 “ld.so”의 분리된 두 command로 인식하여 root 권한으로 “bin”을 수행. Prints that its effective UID is 0 (root) Success! Generalization Process는 subprocess를 invoke 할 때 environment를 정리하지 않고 그대로 상속한다. 때문에 trusted program이라도 environment가 untrustedgkaus 결과가 trusted 하다고 할 수 없다. Subcommand를 spawn할 수 있는 다른 privileged program을 찾아야 한다. Database Laboratory

Example: Penetrating a Windows NT System
Goal: gain access to system We know its network address and nothing else First step: scan network ports of system Protocols on ports 17, 135, and 139 are typically run on Windows NT server systems qotd 17/tcp Quote of the Day ftp /tcp File Transfer [Control] loc-srv 135/tcp Location Service netbios-ssn 139/tcp NETBIOS Session Service [JBP] Figure 20-5 Database Laboratory

First Try Probe for easy-to-guess passwords administrator password 가 “Admin”인 local system을 찾는다. Now have administrator (full) privileges on local system Now, go for rights to other systems in domain Next Step Domain administrator 는 domain admin privilege program을 각 local system에 service program을 설치 한다. Memory 공간에 service account password가 기록 된다. Local security authority database를 dump하는 program을 획득하여 수행한다. This gives us service account password 이 정보를 활용하여 domain admin privilege를 획득하고 domain system에 접속. Database Laboratory

Generalization 민감한 account의 password를 추측하기 쉬운 것으로 선택하면 위험하다. 각 system에서 사용되는 passwords 중 추측하기 쉬운 것들이 있는지 check. security policies 를 재점검 하여 system administrator에 전달하고 mechanisms에 적용한다. Database Laboratory

Debate of Penetration Studies
User, environment의 상호작용에 의해 error를 발견 Especially errors from incorrect maintenance and operation Examines system, site through eyes of attacker Problem Flaw Hypothesis Methodology는 tester가 flaw를 가정하고 generalize 하는 능력에 달려있다. Flaw Hypothesis Methodology 는 system이 조직적인지를 시험하지는 못한다. Vulnerability classification schemes help here Database Laboratory

Vulnerability Classification
Vulnerability Classification frameworks는 다양한 시각으로 flaw를 표현한다. Goals Specify, design, implement computer system without vulnerabilities Analyze computer system to detect vulnerabilities Address any vulnerabilities introduced during system operation Detect attempted exploitations of vulnerabilities Database Laboratory

Two Security Flaws First one: race condition (xterm) Second one: 주입된 code의 수행이 stack의 buffer overflow를 일으키는 경우. (fingerd) Flaw 1: xterm xterm emulates terminal under X11 window system Must run as root user on UNIX systems Log feature: user can log all input, output to file User names file If file does not exist, xterm creates it, makes owner the user If file exists, xterm checks user can write to it, and if so opens file to append log to it Database Laboratory

Flaw 1: xterm (cont’s) Check that user can write to file requires special system call Because root can append to any file, check in open will always succeed Check that user can write to file "/usr/tom/X“  [1]user’s account if (access("/usr/tom/X", W_OK) == 0) { Open "/usr/tom/X" to append log entries  [2]root account if ((fd = open("/usr/tom/X", O_WRONLY|O_APPEND))< 0) { /* handle error: cannot open file */ } Database Laboratory

Flaw 1: xterm (cont’s) Access가 수행 한 후 open이 수행되기 전까지의 시간인 [2]에서 file을 삭제하고 link를 password file과 같은 system filefh 바꿔놓으면 unprivileged user가 system file의 정보를 얻게 된다. Figure 20-6 Database Laboratory

Flaw #2: fingerd Exploited by Internet Worm of 1988 지금까지도 많은 영역에서 재발. finger daemon Sever program fingerd 가 client에 대한 정보를 요청하면 client program finger 는 그 정보를 fingerd 에보내 준다. Request is name of at most 512 chars What happens if you send more? –Buffer Overflow Database Laboratory

Flaw #2: fingerd (cont’s) Buffer Overflow Extra chars overwrite rest of stack, as shown 512번째 이후 over되는 부분에 buffer의 시작 주소를 return 하는 routine을 삽입. 이 routine이 shell을 spawn 한다면 attacker는 target system의 shell을 획득하게 된다. Figure 20-7 Database Laboratory

Frameworks Goals: represent structure of classification scheme
Guide development of attack tool  focus is on steps needed to exploit vulnerability Help software development process  focus is on design and programming errors causing vulnerabilities 하나의 현상이 기준에 따라 여러 vulnerability로 분류 되기도 한다. Database Laboratory

The RISOS Study RISOS : Research Into Operating System
Goal: computer와 system manager가 OS들의 security issue들을 이해하도록 돕고, system security를 향상시키는데 얼마나 많은 노력이 필요한지를 결정하는데 도움을 준다. 문제점을 발견하는 분류법과 software 개발하고, 문제점들을 피하거나 개선하는 기술의 개발한다. Examined Multics, TENEX, TOPS-10, GECOS, OS/MVT, SDS-940, EXEC-8 Database Laboratory

The RISOS Study Classification Scheme Incomplete parameter validation
Inconsistent parameter validation Implicit sharing f privileged/confidential data Asynchronous validation/inadequate serialization Inadequate identification/authentication/authorization Violable prohibition/limit Exploitable logic error Database Laboratory

The RISOS Study Incomplete parameter validation
Parameter not checked before use Check for type, format, range of values, access rights, presence (or absence) Inconsistent Parameter Validation 각 routine에서 parameter check 조건이 일치하지 않는 경우. Implicit Sharing of Privileged / Confidential Data OS가 user와 process들을 명확히 구분 짓지 않아서 서로 접근하지 말아야 하는 부분을 침범하여 발생하는 문제. Password 관리. Database Laboratory

The RISOS Study Asynchronous Validation / Inadequate Serialization
Time of check to time of use flaws, intermixing reads and writes to create inconsistencies Example: xterm flaw discussed earlier Inadequate Identification / Authorization / Authentication User를 잘못 identify 하거나, 엉뚱한 privilege를 부여하거나, authentication 없이 program의 실행이 허용되는 경우. Database Laboratory

The RISOS Study Violable Prohibition / Limit Exploitable Logic Error
Boundary conditions not handled properly Example: system process와 user process 간의 사용하는 memory boundary. Exploitable Logic Error Problems not falling into other classes Incorrect error handling, unexpected side effects, incorrect resource allocation, etc. Database Laboratory

The RISOS Study Legacy of RISOS
First funded project examining vulnerabilities Flaw들의 성질을 보는 가치 있는 관점 Vulnerabilities를 발견하고 고치기 위한 연구에 박차를 가하게 된다. Database Laboratory

Program Analysis Model
Goal: develop techniques to find vulnerabilities 문제점을 다룰 수 있는 작은 단위로 나누려고 노력. General한 전략들을 개발하여 몇몇 OS에 적용. 이전까지 알려지지지 않은 vulnerabilities를 발견. Database Laboratory

Classification Scheme Improper protection domain initialization and enforcement Improper choice of initial protection domain Improper isolation of implementation detail Improper change Improper naming Improper deallocation or deletion Improper validation Improper synchronization Improper indivisibility Improper sequencing Improper choice of operand or operation Database Laboratory

Improper protection domain initialization and enforcement Improper Choice of Initial Protection Domain Privilege나 security, integrity class를 를 잘못 할당. Example: on boot, protection mode of file containing identifiers of all users can be altered by any user Under most policies, should not be allowed Improper Isolation of Implementation Detail Covert channel (chapter 16) User가 OS를 거치지 않고 I/O location에 직접 write하는 경우. Database Laboratory

Improper protection domain initialization and enforcement (cont’s) Improper Change Data is inconsistent over a period of time Example: xterm flaw Meaning of “/usr/tom/X” changes between access and open Improper Naming Multiple objects with same name Example: Trojan horse loadmodule attack discussed earlier; “bin” could be a directory or a program Example: multiple hosts with same IP address Messages may be erroneously routed Database Laboratory

Improper protection domain initialization and enforcement (cont’s) Improper Deallocation or Deletion Failing to clear memory or disk blocks (or other storage) after it is freed for use by others Example: program that contains passwords that a user typed dumps core Passwords plainly visible in core dump Improper Validation Inadequate checking of bounds, type, or other attributes or values Example: fingerd’s failure to check input length Database Laboratory

Improper synchronization Improper Indivisibility Interrupting operations that should be uninterruptable Often: “interrupting atomic operations” Example: mkdir flaw (UNIX Version 7) Created directories by executing privileged operation to create file node of type directory, then changed ownership to user On loaded system, could change binding of name of directory to be that of password file after directory created but before change of ownership Attacker can change administrator’s password mknod(“xxx”, directory) -- root acount chown(“xxx”,user,group) Database Laboratory

Improper synchronization (cont’s) Improper Sequencing Operation의 순서를 매겨 처리해야 하는 상황에서 그러지 못하는 경우. Example: one-time password scheme System runs multiple copies of its server Two users try to access same account Server 1 reads password from file Server 2 reads password from file Both validate typed password, allow user to log in Server 1 writes new password to file Server 2 writes new password to file Sever 1에서 write 한 후 read가 수행 되기 전에 server 2에서 read를 하게 되면 server 1의 write이 완료 되기 전에 read를 수행하게 되는 상황이 발생하여 fail이 될 수 있다. Database Laboratory

Improper Choice of Operand or Operation Calling inappropriate or erroneous instructions Example: cryptographic key generation software calling pseudorandom number generators that produce predictable sequences of numbers Legacy of Program Analysis Model First to explore automatic detection of security flaws in programs and systems Methods developed but not widely used Procedure 부분은 automated 되지 않음. Complexity System에 독립적인 일반적인 pattern의 flaw를 찾는 procedure는 불완전 하다. Database Laboratory

The NRL Taxonomy Goals: 3 different schemes used:
Determine how flaws entered system Determine when flaws entered system Determine where flaws are manifested in system 3 different schemes used: Genesis of flaws Time of flaws Location of flaws Database Laboratory

The NRL Taxonomy Genesis of Flaws
Inadvertent (unintentional) flaws classified using RISOS categories; not shown above If most inadvertent, better design/coding reviews needed If most intentional, need to hire more trustworthy developers and do more security-related testing Figure 20-8 Database Laboratory

The NRL Taxonomy Time of Flaws
Development phase: all activities up to release of initial version of software Maintenance phase: all activities leading to changes in software performed under configuration control Operation phase: all activities involving patching and not under configuration control Figure 20-9 Database Laboratory

The NRL Taxonomy Location of Flaw
Focus effort on locations where most flaws occur, or where most serious flaws occur Figure 20-10 Database Laboratory

The NRL Taxonomy Legacy Analyzed 50 flaws
50개의 sample flaw를 분석한 결과로 class들간의 관계를 연구할 수 있게 되었다. Developer들은 비슷한 성격의 flaw들에 집중할 수 있게 되었다. 50가지 sample flaw에 해당하지 않는 부분에 대한 정보가 더 필요하다. Database Laboratory

Aslam’s Model Goal: vulnerabilities를 faults로 간주하고 faults tree에 기반하여 개발한 scheme. Focuses specifically on UNIX flaws Classifications unique and unambiguous Organized as a binary tree, with a question at each node. Answer determines branch you take Leaf node gives you classification Suited for organizing flaws in a database Database Laboratory

Aslam’s Model Synchronization errors Coding Faults
Top level Coding Faults Emergent faults Synchronization errors Condition validation errors Configuration errors Environmental faults Database Laboratory

Aslam’s Model Top Level Coding Faults
Coding faults: software 개발단계에서의 faults Example: fingerd’s failure to check length of input string before storing it in buffer Emergent faults: application의 잘못된 초기화나 사용에 의한 fault. Example: allowing message transfer agent to forward mail to arbitrary file on system (it performs according to specification, but results create a vulnerability) Coding Faults Synchronization errors: improper serialization of operations, timing window between two operations creates flaw Example: xterm flaw Condition validation errors: bound가 check되지 않았거나, access right가 무시되었거나, input이 유효하지 않거나, authorization 또는 authentication이 fail 안 경우. Example: fingerd flaw Database Laboratory

Aslam’s Model Emergent Faults Configuration errors
program installed incorrectly Installed in wrong pace Wrong initialization information Wrong permissions Example: tftp daemon installed so it can access any file; then anyone can copy any file Environmental faults faults introduced by environment Example: old version UNIX system에서 shell의 이름의 첫 character가 “-”인 경우 그 shell은 interactive 하다. Attacker는 setuid shell script를 “--getch”에 link 시킨다. 이것을 실행 시면 root shell로 setuid를 가져 올 수 있다. Database Laboratory

Aslam’s Model Legacy Tied security flaws to software faults
정밀한 classification scheme을 제공 Each vulnerability belongs to exactly 1 class of security flaws Decision procedure well-defined, unambiguous Database Laboratory

Comparison and Analysis
Point of view If multiple processes involved in exploiting the flaw, xterm, fingerd flaws depend on interaction of three processes (trusted process + attacker’s procss + OS process) 어느 process를 기준으로 하느냐에 따라 분석되는 flaw가 달라진다. How does that affect classification? Levels of abstraction How does flaw appear at different levels? Levels are abstract, design, implementation, etc. 어느 level에서 분석하느냐에 따라 분석된 flaw가 달라진다. Let see example! Database Laboratory

The xterm Log Flaw xterm & PA Implementation level xterm: improper change attacker’s program: improper deallocation or deletion operating system: improper indivisibility Consider higher level of abstraction: point of view of the OS where directory is simply an object create, delete files maps to writing; read file status, open file maps to reading operating system: improper sequencing During read, a write occurs, violating Bernstein conditions Consider even higher level of abstraction : point of view of the design attacker’s process: improper choice of initial protection domain Should not be able to write to directory containing log file Semantics of UNIX users require this at lower levels Database Laboratory

The xterm Log Flaw (cont’s) xterm & RISOS Implementation level xterm: asynchronous validation/inadequate serialization attacker’s process: exploitable logic error and violable prohibition/limit operating system: inconsistent parameter validation Consider higher level of abstraction, where directory is simply an object (as before) all: asynchronous validation/inadequate serialization Consider even higher level of abstraction attacker’s process: inadequate identification/authentication/authorization Directory with log file not protected adequately Semantics of UNIX require this at lower levels Database Laboratory

The xterm Log Flaw (cont’s) xterm & NRL Time, location unambiguous Time: during development Location: Support:privileged utilities Genesis: ambiguous If intentional: Lowest level: inadvertent flaw of serialization/aliasing If unintentional: Lowest level: nonmalicious: other At higher levels, parallels that of RISOS Database Laboratory

The xterm Log Flaw (cont’s) xterm & Aslam’s Implementation level attacker’s process: object installed with incorrect permissions attacker’s process can delete file xterm: access rights validation error xterm doesn’t properly validate file at time of access operating system: improper or inadequate serialization error Access와 open 사이에 deletion와 creation이 산재되어 있어서는 안된다. Note: in absence of explicit decision procedure, all could go into class race condition Database Laboratory

The xterm Log Flaw (cont’s) The Point The schemes lead to ambiguity Different researchers may classify the same vulnerability differently for the same classification scheme Not true for Aslam’s, but that misses connections between different classifications xterm is race condition as well as others; Aslam does not show this Database Laboratory

The fingered Buffer overflow Flaw fingerd & PA Implementation level fingerd: improper validation attacker’s process: improper choice of operand or operation operating system: improper isolation of implementation detail Consider higher level of abstraction, where storage space of return address is object operating system: improper change Because it doesn’t validate the type of instructions to be executed, mistaking data for valid ones Consider even higher level of abstraction, where security-related value in memory is changing and data executed that should not be executable operating system: improper choice of initial protection domain Database Laboratory

The fingered Buffer overflow Flaw (cont’s) fingerd & RISOS Implementation level fingerd: incomplete parameter validation attacker’s process: violable prohibition/limit operating system: inadequate identification/authentication/authorization Consider higher level of abstraction, where storage space of return address is object operating system: asynchronous validation/inadequate serialization fingerd: inadequate identification/authentication/authorization Consider even higher level of abstraction, where security-related value in memory is changing and data executed that should not be executable Database Laboratory

The fingered Buffer overflow Flaw (cont’s) fingerd & NRL Time, location unambiguous Time: during development Location: support: privileged utilities Genesis: ambiguous Known to be inadvertent flaw Parallels that of RISOS fingerd & Aslam’s Implementation level fingerd: boundary condition error attacker’s process: boundary condition error operating system: environmental fault If decision procedure not present, could also have been access rights validation errors Database Laboratory

Summary Classification schemes requirements
Decision procedure for classifying vulnerability Each vulnerability should have unique classification Above schemes do not meet these criteria Inconsistent among different levels of abstraction Point of view affects classification Database Laboratory

Chapter 20: Vulnerability Analysis

Similar presentations

Presentation on theme: "Chapter 20: Vulnerability Analysis"— Presentation transcript:

Similar presentations

About project

지원

로그인

Auth with social network:

Chapter 20: Vulnerability Analysis

Similar presentations

Presentation on theme: "Chapter 20: Vulnerability Analysis"— Presentation transcript:

Similar presentations

About project

지원