Chap. 20 : Vulnerability Analysis

Presentation on theme: "Chap. 20 : Vulnerability Analysis"— Presentation transcript:

1 Chap. 20 : Vulnerability Analysis
Network Lab 김준수

2 Overview What is a vulnerability? Penetration studies
Flaw Hypothesis Methodology Examples Vulnerability examples Classification scheme RISOS PA NRL Taxonomy Aslam’s Model Network Laboratory Sogang Univ.

3 Definitions Vulnerability, security flaw - failure of security policies, procedures, and controls that allow a subject to commit an action that violates the security policy Subject who attempts to exploit the vulnerability called an attacker Using the failure to violate the policy is exploiting the vulnerability or breaking in 컴퓨터 시스템은 단순히 하드웨어와 소프트웨어로만 구성된 것이 아니라 policy, procedure, organization, control등이 어우러져 이루어진 것이다 따라서 computer system의 vulnerability에 대해 논할때에 후자에 대해서도 고려해야 한다. 이런 관점에서 security 의 vulnerability, flaw는 subject로 하여금 security policy를 위반할 수 있게끔 동기를 부여하는 failure policy, procedure, control and so on 로 정의 할 수 있다. 쉽게 생각하면 뭐 도둑이 들어오게 창문을 열어 놓는 정도? Network Laboratory Sogang Univ.

4 Two types of Vulnerability Testing
Formal Verification Mathematically verifying that a system satisfies certain constraints It can theoretically prove the absence of vulnerabilities Preconditions are state assumptions about the system Postconditions are result of applying system operations to preconditions, inputs Penetration Testing it cannot prove the absence of vulnerabilities but can only prove their existence Formal Verification {Preconditions} Program {Postconditions} Penetration Testing {System characteristics, environment, and state } {System state} preconditions – 주어진 전제, 가정, 가설(어느 부분에서 flaw가 발생할 것인가, flaw의 속성,성질)을 바탕으로 하여 테스터가 취약성이 발생하는 상황을 결정하는 것 Postcnoditions – precondition을 입력으로 하여 시스템을 해석해서 얻어지는 결과에 관한 정보 Security policy와 postconditions 일치하지 않으면(모순이 있으면) 취약성이 존재하는 것 Network Laboratory Sogang Univ.

5 Penetration Studies Test for evaluation the strengths and effectiveness of all security controls on system Also called tiger team attack or red team attack Goal is to violate the site security policy Not a replacement for careful design, implementation, and structured testing Penetration studies는 한마디로 system이 secure 한지를 테스트하는 것입니다. Tiger team attack, red team attack에서 예상할 수 있듯이 tester가 직접 attacker가 되어서 예상되는 Security flaw로 system의 security를 뚫어 보겠다는 겁니다. Network Laboratory Sogang Univ.

6 Penetration Studies(cont.)
Attempt to violate specific constraints in security and/or integrity policy Implies metric for determining success Must be well-defined Example: subsystem designed to allow owner to require others to give password before accessing file (i.e., password protect files) Goal: test this control Metric: did testers get access either without a password or by gaining unauthorized access to a password? Network Laboratory Sogang Univ.

7 Layering of Tests External attacker with no knowledge of system
attackers know the target exists Have enough information to identify it Cannot get information about security of the system External attacker with access to system Attackers have access to the system Either use a access mechanism to login Usually exploits implementation flaws 앞서 Penetration study는 tester가 Attacker가 되어 system의 security policy를 침해하여 security mechanism 이나 control의 효율성을 평가하는 방법이라 했습니다. 이를 위해서 이 연구는 attacker의 관점과 환경에서 진행되어야 합니다. 만일 서로 다른 attacker가 있다면 그들의 환경도 달라집니다. 예를 들어 attack이 내부에서 이루어 진다면 attacker는 system에 대한 access 권한을 가지게 되지만, 외부에서 이루어 진다면 이 attacker는 먼저 system에 대한 access을 획득해야 합니다. 이는 penetration study에 layering model을 적용케 합니다. External & no – 목표로 하는 system 이 존재한다는 것을 알고 있고, 이 system에 접근할 방법을 결정하기에 충분한 정보가 있다. 대부분의 penetration test에서 생략 External & access – 이 단계에서 일어나는 attack는 패서워드를 알아낸다거나 unprotected account를 찾는 다거나 Internal – tests acquire a good knowledge of the target system, its design, its operation Network Laboratory Sogang Univ.

8 Layering of tests (cont.)
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 Network Laboratory Sogang Univ.

9 Methodology Usefulness of penetration study comes from documentation, conclusions Indicates whether flaws are endemic or not It does not come from success or failure of attempted penetration Degree of penetration’s success also a factor In some situations, obtaining access to unprivileged account may be less successful than obtaining access to privileged account Penetration testing methodology는 flaw Hypothesis Methodology에서 비롯된다. 성공적인 Penetration test가 시스템이 secure 하지 못하다는 것을 의미한다 라고 많은 사람들이 이를 잘못 이해하고 있음 – 그건 한번만 테스트가 완료되면 쉽게 결론 내릴 수 있다. Penetration test 가 성공 혹은 실패에 의미가 있는 것이 아님 이를 통해서 system을 좀더 secure 하게 만드는 것이 목적이기 때문에 반드시 이를 문서화하고 토론하는 것이 필요 일반 사용자 계정에 대한 access는 privilege(ex root) 계정에 대한 access 보다 큰 데미지를 주지 못하기 때문에 Network Laboratory Sogang Univ.

10 Flaw Hypothesis Methodology
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) System Development Cooperation에서 개발되었고 Penetration study에 대한 framework를 제공 4단계로 구성되었지만 5단계가 추가 되었음 Network Laboratory Sogang Univ.

11 Information Gathering
Devise model of system and/or components Look for discrepancies in components Consider interfaces among components Need to know system well (or learn quickly!) Design documents, manuals help Unclear specifications often misinterpreted, or interpreted differently by different people Look at how system manages privileged users 말 그대로 정보 수집 단계입니다. 어떤 시스템을 테스트 하기 위해서는 해당 시스템이 어떤 특징을 가지고 있는지, 어떻게 운영되는지, 어떤 서비스를 제공하는지, 사용자 구성은 어떻게 되는지 알아야 함 그 후 이를 바탕으로 system component 간의 모순이나 논리적 오류 등을 먼저 고려. 조금만 신경 쓰면 금방 알 수 있는 오류 때문에 모든 과정을 수행 할 필요는 없음 Network Laboratory Sogang Univ.

12 Flaw Hypothesizing Examine policies, procedures
May be inconsistencies to exploit May be consistent, but inconsistent with design or implementation Examine implementations Use models of vulnerabilities to help locate potential problems Use manuals; try exceeding limits and restrictions; try omitting steps in procedures CAN Network BTS IVIS Terminal Sensor Nodes Actuator Nodes Mobile Phone Client Data/Control (SMS) (IS95B) Vehicle 첫번째 단계에서 얻어진 정보를 기반으로 진행 비록 system design등에서 결점이 발견되지 않더라도 이를 수행하는 절차나, system 설정 혹은 구현시에 사소한 실수를 하거나 문제가 발생하게 된다면 그에 따른 결과로 vulnerability가 드러날 수 있다. 따라서 policy, procedure, implementation 도 확인 Network Laboratory Sogang Univ.

13 Flaw Hypothesizing (con’t)
Identify structures, mechanisms controlling system These are what attackers will use Environment in which they work, and were built, may have introduced errors Throughout, draw on knowledge of other systems with similarities Which means they may have similar vulnerabilities Result is list of possible flaws 이 단계에서 가장 중요한 것이 시스템을 제어하게 되는 구조나 메커니즘입니다. 이것이 중요한 이유는 Network Laboratory Sogang Univ.

14 Flaw Testing Figure out order to test potential flaws
Priority is goal of test Example: to find major design or implementation problems, focus on potential system critical flaws Example: to find vulnerability to outside attackers, focus on external access protocols and programs Figure out how to test potential flaws Best way: demonstrate from the analysis Otherwise, must try to exploit it Tester가 이전 단계에서 어떤 flaw에서 vulnerability가 발생할 것이라는 것을 결정하였다면 이제 Test 순서를 결정해야 한다. 순서를 결정하는데 있어서 가장 중요하게 작용하는 것은 test를 실시하는 목적이다. 예를 들어 test의 목적이 외부에서의 attack을 발견해 내는 것이라면 외부 access 프로토콜에 관련된 flaw가 가장 높은 순위에 놓일 것이고, 내부에서의 attack에만 사용되는 flaw는 낮은 우선순위를 놓일 것이다. Order가 결정이 되면 tester는 이 potential flaw를 어떻게 test 할 것인가를 결정 해야 한다. 만일 이것이 해석을 기반으로 하여 demonstration(증명, 논증) 이 가능하면 가장 Best 좋다. 이는 공통적으로 flaw가 특정 결점, 혹은 디자인과 운영상의 결점에서 비롯될 때 사용가능하다. 하지만 이 같은 방법이 불가능 하다면 flaw가 발생하는 이유를 정확히 이해하고 intrusive manner로 이를 이용하는 것을 시도하는 방법밖에는 없다. 목적은 flaw의 존재 와 system 의 compromise를 유발할 수 있다는 것을 논증(demonstrate) 하고 But demonstrate의 충격을 최소화 하는 것 Network Laboratory Sogang Univ.

15 Flaw Testing (con’t) Design test to be least intrusive as possible
Must understand exactly why flaw might arise Procedure Back up system Verify system configured to allow exploit Take notes of requirements for detecting flaw Verify existence of flaw May or may not require exploiting the flaw Make test as simple as possible, but success must be convincing Must be able to repeat test successfully Network Laboratory Sogang Univ.

16 Flaw Generalization As tests succeed, classes of flaws emerge
Example: programs read input into buffer on stack, leading to buffer overflow attack; others copy command line arguments into buffer on stack  these are vulnerable too Sometimes two different flaws may combine for devastating attack Example: flaw 1 gives external attacker access to unprivileged account on system; second flaw allows any user on that system to gain full privileges  any external attacker can get full privileges Network Laboratory Sogang Univ.

17 Flaw Elimination Usually not included as testers are not best folks to fix this Designers and implementers are Requires understanding of context, details of flaw including environment, and possibly exploit Design flaw uncovered during development can be corrected and parts of implementation redone Don’t need to know how exploit works Design flaw uncovered at production site may not be corrected fast enough to prevent exploitation So need to know how exploit works Network Laboratory Sogang Univ.

18 Penetrating a System Goal: gain access to system
Know its network address and nothing else First step: scan network ports of system ftp /tcp File Transfer telnet /tcp Telnet smtp /tcp Simple Mail Transfer finger /tcp Finger sunrpc /tcp SUN Remote Procedure Call exec /tcp remote process execution (rexecd) login /tcp remote login (rlogind) shell /tcp rlogin style exec (rshd) printer /tcp spooler (lpd) uucp /tcp uucpd nfs /tcp networked file system xterm /tcp x-windows server ☞ protocols on ports 79, 111, 512, 513, 514 and 540 are typically run on unix systems Network Laboratory Sogang Univ.

19 Penetrating a System (cont.)
Assume UNIX system: SMTP agent probably sendmail Sendmail program has had lots of security problem Maybe system running one such version Next step: connect to sendmail on port 25 Determine that the target is using sendmail Ver. 3.1 Network Laboratory Sogang Univ.

20 Output of sendmail 220 zzz.com sendmail 3.1/zzz.3.9, Dallas, Texas, ready at Wed, 2 Apr 97 22:07:31 CST Version 3.1 has the “wiz” vulnerability that recognizes the “shell” command … so let’s try it Start off by identifying yourself helo xxx.org 250 zzz.com Hello xxx.org, pleased to meet you Now see if the “wiz” command works … if it says “command unrecognized”, we’re out of luck wiz 250 Enter, O mighty wizard! It does! And we didn’t need a password … so get a shell shell # And we have full privileges as the superuser, root Network Laboratory Sogang Univ.

21 Penetrating a System (revisited)
Goal: from an unprivileged account on system, gain privileged access Information gathering: examine system It has dynamically loaded kernel Program used to add modules is loadmodule and must be privileged So an unprivileged user can run a privileged program -> this suggests an interface that control this Question: how does loadmodule work? Network Laboratory Sogang Univ.

22 Loadmodule Validates module as being a dynamic load module
Invokes dynamic loader ld.so to actual load; also calls arch to determine system architecture How does loadmodule execute these programs? Easiest way: invoke them directly using system, which does not reset environment when it spawns subprogram Network Laboratory Sogang Univ.

23 Flaw Hypothesis The simplest way to execute program(e.g. ld.so) is to use a library function system This function does not reset any part of the environment When the system call is used, the environment in which we execute loadmodule is passed to the subprocesses These subprocesses are run as root Network Laboratory Sogang Univ.

24 Flaw testing First try Set environment to look in local directory, write own version of ld.so, and put it in local directory This version will print effective UID to demonstrate we succeeded Set search path to look in current working directory before system directories The run loadmodule Nothing is printed Somehow changing environment did not affect execution of subprograms Network Laboratory Sogang Univ.

25 Flaw testing (cont.) What happened
Look in executable to see how ld.so, arch invoked Invocations are “/bin/ld.so”, “/bin/arch” Changing search path didn’t matter as never used Reread system manual page It invokes command interpreter sh to run subcommands Read sh manual page uses IFS environment variable to separate words These are by default blanks…can we make it include a “/” Network Laboratory Sogang Univ.

26 Flaw testing (cont.) Second try Change value of IFS to include “/”
Change name of our version of ld.so to bin Search path still has current directory as first place to look for commands Run loadmodule Print that its effective UID is 0 (root) Success~!!! Network Laboratory Sogang Univ.

27 Generalization Process did not clean out environment before invoking subprocess, which inherited environment So, trusted program working with untrusted environment(input)… result should be untrusted ☞ a general class of flaws would involve failure to sanitize the environment Look for other privileged programs that spawn subcommands Especially if they do so by calling system Network Laboratory Sogang Univ.