CS 5950/6030 Network SecurityClass 15 (W, 10/5/05)

Leszek LilienDepartment of Computer Science

Western Michigan University

Based on Security in Computing. Third Edition by Pfleeger and Pfleeger.Using some slides courtesy of:

Prof. Aaron Striegel — at U. of Notre DameProf. Barbara Endicott-Popovsky and Prof. Deborah Frincke — at U. Washington

Prof. Jussipekka Leiwo — at Vrije Universiteit (Free U.), Amsterdam, The Netherlands

Slides not created by the above authors are © by Leszek T. Lilien, 2005Requests to use original slides for non-profit purposes will be gladly granted upon a written

request.

2

3. Program Security3.1. Secure Programs – Defining & Testing3.2. Nonmalicious Program Errors3.3. Malicious Code

3.3.1. General-Purpose Malicious Code (incl. Viruses)a. Introduction b. Kinds of Malicious Codec. How Viruses Work – PART 1

c. How Viruses Work – PART 2d. Virus Signaturese. Preventing Virus Infectionsf. Seven Truths About Virusesg. Case Studiesh. Virus Removal and System Recovery After

Infection 3.3.2. Targeted Malicious Code

a. Trapdoors

Class 14

3

3.3.2. Targeted Malicious Code

Targeted = written to attack a particular system, a particular application, and for a particular purpose

Many virus techniques applySome new techniques as well

Outline:a. Trapdoorsb. Salami attackc. Covert channels

4

a. Trapdoors (1) Original def:

Trapdoor / backdoor - A hidden computer flaw known to an intruder, or a hidden computer mechanism (usually software) installed by an intruder, who can activate the trap door to gain access to the computer without being blocked by security services or mechanisms.

A broader definition:Trapdoor – an undocumented entry point to a module

Inserted during code development For testing As a hook for future extensions As emergency access in case of s/w failure

5

Trapdoors (2)

Testing: With stubs and drivers for unit testing (Fig. 3-10 p.

138) Testing with debugging code inserted into tested

modules May allow programmer to modify internal module variables

Major sources of trapdoors: Left-over (purposely or not) stubs, drivers, debugging

code Poor error checking

E.g., allowing for unacceptable input that causes buffer overflow

Undefined opcodes in h/w processors Some were used for testing, some random

Not all trapdoors are bad Some left purposely w/ good intentions

— facilitate system maintenance/audit/testing

6

Class 14 Ended Here

7

3. Program Security3.1. Secure Programs – Defining & Testing3.2. Nonmalicious Program Errors3.3. Malicious Code

3.3.1. General-Purpose Malicious Code (incl. Viruses)...

c. How Viruses Work – PART 2d. Virus Signaturese. Preventing Virus Infectionsf. Seven Truths About Virusesg. Case Studiesh. Virus Removal and System Recovery After

Infection 3.3.2. Targeted Malicious Code

a. Trapdoors

a. Salami attackb. Covert channels

Class 15

Class 14

8

b. Salami attack Salami attack - merges bits of seemingly

inconsequential data to yield powerful results Old example: interest calculation in a bank:

Fractions of 1 ¢ „shaved off” n accounts and deposited in attacker’s account

Nobody notices/cares if 0.1 ¢ vanishes Can accumulate to a large sum

Easy target for salami attacks: Computer computations combining large numbers with small numbers

Require rounding and truncation of numbers Relatively small amounts of error from these op’s

are accepted as unavoidable – not checked unless a strong suspicion

Attacker can hide „salami slices” within the error margin

9

c. Covert Channels (CC) (1) Outline:

i. Covert Channels - Definition and Examplesii. Types of Covert Channelsiii. Storage Covert Channelsiv. Timing Covert Channelsv. Identifying Potential Covert Channelsvi. Covert Channels - Conclusions

10

CC – Definition and Examples (1) So far: we looked at malicious pgms that perform

wrong actions Now: pgms that disclose confidential/secret info

They violate confidentiality, secrecy, or privacy of info

Covert channels = Program that leaks information Examples

1) An old military radio communication network The busiest node is most probably the command center

2) A group of student preparing for Objective type exam

. One of the student understand the course and agrees to help others(by some actions)

3) Secret ways spies recognize each other Holding a certain magazine in hand Exchanging a secret gesture when approaching each other

11

Covert Channels – Definition and Examples (2) How programmers create covert channels?

Uses covert channel to communicate extracted data The attack is based on Trojan horse

Example: pgm with Trojan horse using covert channel Should be:

Protected LegitimateData <------[ Service Pgm ]------> User

Is:Protected LegitimateData <------[ Service Pgm ]------> User

[ with Trojan h. ]

covert channel

Spy(watch secretly) (Spy - e.g., programmer who put Trojan into pgm; directly or via Spy Pgm)

12

How covert channels are created?i.e. how data is hidden.

Example: leaked data hidden in output reports (or displays)

Different ‘marks’ in the report: Varying report format

Changing line length / changing number of lines per page

Printing or not printing certain values, characters, or headings

For example: changing the word TOTAL to TOTALS in the heading would not be noticed, but this creates a one bit of information, that means 1-bit covert channel.

13

ii. Types of Covert Channels Types of covert channels

Storage covert channels Convey info by presence or absence of an

object in storage

Timing covert channels Convey info by varying the speed at which

things happen

14

iii. Storage Channels (1) Example of storage channel: file lock covert channel

in multiuser system A covert channel can signal one bit of information by

whether or not a file is locked.

lock(1) Locked? yes:1 unlock(0) no:0

User can see spy can see

Service program Spy’s programFile

Protected data

15

iv. Timing Channels Timing channels are shared resource channel in

which the shared resource is time.

Simple example of timing channel: Multiprogramming system “slices” processor time

for programs running on the processor 2 processes only: Trojan (Pgm with Trojan) and

Spy Pgm Trojan receives all odd slices

Spy Pgm receives all even slices Trojan signals Xk=1 by using its time slice,

signals Xk=0 by abstaining from using its slice

16

v. Identifying Potential Covert Channels (1)

Covert channels are not easy to identify Otherwise wouldn’t be covert, right?

Two techniques for locating covert channels:1) Shared Resource Matrix2) Information Flow Method

17

Identifying Potential Covert Channels (2)

1) The Shared Resource Matrix method Shared resource is basis for a covert channel

=> identify shared resources and processes reading/writing them

Step 1: Construct Shared Resource Matrix(SRM)Rows — resourcesColumns — processes that access them:

R = observe resource M = modify/set/create/delete resource

Example

Process 1 Process 2

Lock R, M R, M

X (confidential data)

R

18

Identifying Potential Covert Channels (3) ...

Step 2: Look for pattern:

Meaning of this pattern:Process Pj can get value ofResource Rn via Process Pi(and a covert channel)

Pi Pj

Rm

M R

Rn R

Pgm 1 Pgm 2

Lock on FX R, M R, M

X (confid.) R

Q: Do you see such a pattern in SRM above?

19

Identifying Potential Covert Channels (4) ...

Step 2: Look for pattern:

Meaning of this pattern:Process Pj can get value ofResource Rn via Process Pi(and a covert channel)

Q: Do you see such a pattern in SRM above? A: Yes. Process 2 can get value of X via Process 1

(no surprise: Proc. 1 & 2 are Trojan & Spy from earlier example)

i j

m M R

n R

Process 1 Process 2

Lock on FX R, M R, M

X (confid.) R

20

Identifying Potential Covert Channels (5)

2) Information Flow Method Flow analysis of pgm’s syntax

Can be automated within a compiler Identifies non-obvious flows of info between pgm

statements

Examples of flows of info between pgm stmts B:= A – an explicit flow from A to B B:= A; C:=B – an explicit flow from A to C (via B) IF C=1 THEN B:=A

– an explicit flow from A to B– an implicit flow from C to B (bec. B can change iff C=1)

21

Identifying Potential Covert Channels (6)

More examples of flows of info between pgm stmts

[textbook and J. Leiwo]

22

Identifying Potential Covert Channels (7)

Steps of Information Flow Method (IFM)1) Analyze statements2) Integrate results to see which outputs affected by

which inputs

Variants of IFM:1) IFM during compilation2) IFM on design specs

23

Covert Channels - Conclusions Covert channels are a serious threat to

confidentiality and thus security („CIA” = security)

Any virus/Trojan horse can create a covert channel

In open systems — no way to prevent covert channels

Very high security systems require a painstaking and costly design preventing (some) covert channels

Analysis must be performed periodically as high security system evolves

24

End of Class 15

25

Controls against program Security How to control security of pgms during their

development and maintenance

Outline:a. Introductionb. Developmental controls for securityc. Operating system controls for securityd. Administrative controls for securitye. Conclusions

26

a. Introduction „Better to prevent than to cure”

Three types of controls for security (against pgm flaws):1) Developmental controls2) OS controls3) Administrative controls

27

b. Developmental Controls for Security (1)

Nature of s/w development Collaborative effort, involves people with different

skills Team of developers, each involved in 1 of stages:

Requirement specification do “X” do “X” and “nothing more”

Design Implementation Testing Documenting at each stage Reviewing at each stage Managing system development thru all stages Maintaining deployed system (updates, patches, new versions,

etc.)

Both product and process contribute to overall quality

28

Developmental Controls for Security (2) Fundamental principles of s/w engineering

1) Modularity2) Encapsulation3) Info hiding

1) Modularity Dividing a process into subtask Adv.

Maintenance, understandability, reuse, correctness, testing,

Modularity should improve correctness Fewer flaws => better security

29

Developmental Controls for Security (3)

2) Encapsulation Minimizing info sharing with other modules

=> Limited interfaces reduce number of covert channels

Well documented interfaces „Hiding what should be hidden and showing what

should be visible.”

3) Information hiding Module is a black box

Well defined function and I/O Easy to know what module does but not how it does

it Reduces complexity, interactions, covert channels, ...

=> better security

30

Developmental Controls for Security (4)

Techniques for building solid software 1) Peer reviews2) Hazard analysis3) Testing4) Good design5) Risk prediction & mangement6) Static analysis7) Configuration management8) Additional developmental controls

... all discussed below ...

31

Developmental Controls for Security (5)

1) Peer reviews - three types Reviews

Informal Team of reviewers Gain consensus on solutions

before development Walk-throughs

Product is presented to the team to discover flaws in designed document

Inspection Detailed analysis of product against

prepared list of concern Various types of peer reviews can be highly

effective

32

Developmental Controls for Security (6)

2) Hazard analysis= systematic techniques to expose

potentially hazardous system states,including security vulnerabilities

Components of HA Hazard lists System-wide view (not just code) Begins Day 1 Continues throughout SDLC (= s/w dev’t life

cycle)

33

Developmental Controls for Security (7)

3) Testing – phases: Module/component/unit testing of indiv. modules Integration testing of interacting (sub)system modules (System) function testing checking against function

described by requirement specifications (System) acceptance testing – with customer

against customer’s requirements — on seller’s or customer’s premises

(System) installation testing after installation on customer’s system

Regression testing after updates/changes to s/w, system still works without performance degradation.

Types of testing Black Box testing – testers can’t examine code White Box / Clear box testing – testers can examine

design and code, can see inside modules/system

34

Developmental Controls for Security (8)

Configuration management = process of controling system modifications

during development and maintenance Offers security benefits by scrutinizing

new/changed code Lesson from mistake Proof of program correctness.

Program computes the particular result correctly , and does nothing beyond that .

35

Operating System Controls for Security (1)

Developmental controls not always usedOR: Even if used, not foolproof=> Need other, complementary controls, incl.

OS controls

Such OS controls can protect against some pgm flaws

36

Operating System Controls for Security (2)

Trusted software –Code rigorously developed and analyzed so we can trust that it does all and only what specification says Trusted code establishes foundation upon

which untrusted code runs Trusted code establishes security baseline

for the whole system In particular, OS can be trusted s/w

37

Operating System Controls for Security (3)

Key characteristics determining if OS code is trusted1) Functional correctness

OS code consistent with specs2) Enforcement of integrity

OS keeps integrity of its data and other resources even if presented with flawed or unauthorized commands

3) Limited privileges OS minimizes access to secure

data/resources Trusted pgms must have „need to access”

and proper access rights to use resources protected by OS

Untrusted pgms can’t access resources protected by OS

38

Operating System Controls for Security (4)

Ways of increasing security if untrusted pgms present:

1) Mutual suspicion2) Confinement3) Access log

1) Mutual suspicion between programs Distrust other pgms – treat them as if

they were incorrect or malicious Pgm protects its interface data

With data checks, etc.

39

Operating System Controls for Security (5)

2) Confinement OS can confine access to resources by suspected

pgm

Example 1: strict compartmentalization Pgm can affect data and other pgms only

within its compartment

Can limit spread of viruses

40

Operating System Controls for Security (6)

3) Audit log / access log Records who/when/how (e.g., for how long)

accessed/used which objects Events logged: logins/logouts, file accesses,

pgm ecxecutions, device uses, failures, repeated unsuccessful commands (e.g., many repeated failed login attempts can indicate an attack)

Audit frequently for unusual events, suspicious patterns

Forensics – investigation to find who broke law, policies, or rules

41

Administrative Controls for Security (1)

They prohibit or demand certain human behavior via policies, procedures, etc.

They include:1) Standards of program development2) Security audits3) Separation of duties

42

Administrative Controls for Security (2)

1) Standards and guidelines for program development Capture experience and wisdom from previous

projects Facilitate building higher-quality s/w (incl. more secure) They include:

Design S&G – design tools, languages, methodologies S&G for documentation, language, and coding

style Programming S&G - incl. reviews, audits Testing S&G Configuration mgmt S&G

2) Security audits Check compliance with S&G Scare potential dishonest programmer from including

illegitimate code (e.g., a trapdoor)

43

Administrative Controls for Security (3)

3) Separation of duties Break sensitive tasks into 2 pieces to be

performed by different people (learned from banks) Example 1: modularity

Different developers for cooperating modules Example 2: independent testers

Rather than developer testing her own code

44

Conclusions (for Controls for Security)

Developmental / OS / administrative controls help produce/maintain higher-quality (also more secure) s/w

Art and science - no „silver bullet” solutions „A good developer who truly understands security

will incorporate security into all phases of development.”

Summary:Control Purpose Benefit

Develop-

mental

Limit mistakesMake malicious code difficult

Produce better software

OperatingSystem

Limit access to system Promotes safe sharing of info

Adminis-trative

Limit actions of people Improve usability, reusability and maintainability