CS 5950/6030 Network SecurityClass 14 (M, 10/3/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 Errors

a. Buffer overflows – PART 1

a. Buffer overflows – PART 2b. Incomplete mediationc. Time-of-check to time-of-use errorsd. Combinations of nonmalicious program

flaws

3.3. Malicious Code

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

a. Introduction b. Kinds of Malicious Codec. How Viruses Work – PART 1

Class13

3

3.2. Nonmalicious Program Errors Outline

a. Buffer overflowsb. Incomplete mediationc. Time-of-check to time-of-use errorsd. Combinations of nonmalicious program flaws

4

3.3. Malicious Code Malicious code or rogue pgm is written to exploit flaws in pgms

Malicious code can do anything a pgm can Malicious code can change

data other programs

Malicious code has been „oficially” defined by Cohen in 1984 but virus behavior known since at least 1970 Ware’s study for Defense Science Board (classified, made public in 1979)

Outline for this Subsection:3.3.1. General-Purpose Malicious Code (incl.

Viruses)3.3.2. Targeted Malicious Code

5

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

Outlinea. Introductionb. Kinds of Malicious Codec. How Viruses Work – PART 1

6

c. How Viruses Work (1) Pgm containing virus must be executed to spread virus

or infect other pgms Even one pgm execution suffices to spread virus

widely

Virus actions: spread / infect

Spreading – Example 1: Virus in a pgm on installation CD User activates pgm contaning virus when she runs

INSTALL or SETUP Virus installs itself in any/all executing pgms present

in memory Virus installs itself in pgms on hard disk

From now on virus spreads whenever any of the infected pgms (from memory or hard disk) executes

7

How Viruses Work (2)

Spreading – Example 2: Virus in attachment to e-mail msg User activates pgm contaning virus (e.g. macro in

MS Word) by just opening the attachment => Disable automatic opening of

attachments!!! Virus installs itself and spreads ... as in Example 1...

Spreading – Example 3: Virus in downloaded file File with pgm or document (.doc, .xls, .ppt, etc.) You know the rest by now...

Document virus Spreads via picture, document, spreadsheet, slide

presentation, database, ... E.g., via .jpg, via MS Office documents .doc, .xls, .ppt, .mdb

Currently most common!

8

How Viruses Work (3) Kinds of viruses w.r.t. way of attaching to infected

pgms1) Appended viruses

Appends to pgm Most often virus code precedes pgm code

Inserts its code before the 1st pgm instruction in executable pgm file

Executes whenever program executed2) Surrounding viruses

Surronds program Executes before and after infected program

Intercepts its input/output Erases its tracks

The „after” part might be used to mask virus existenceE.g. if surrounds „ls”, the „after” part removes listing of virus file produced by „ls” so user can’t see it

... cont. ...

9

How Viruses Work (4)... cont. ...

3) Integrating viruses Integrates into pgm code

Spread within infected pgms

4) Replacing viruses Entirely replaces code of infected pgm file

10

How Viruses Work (5)

Virus V gains control over target pgm T by: Overwriting T on hard disk

OR Changing pointer to T with pointer to V

OS has file directory File directory has an entry that points to file with code for

T Virus replaces pointer to T’s file with pointer to V’s file

In both cases actions of V replace actions of T when user executes what she thinks is „T”

11

Class 13 Ended Here

12

3. Program Security3.1. Secure Programs – Defining & Testing3.2. Nonmalicious Program Errors

a. Buffer overflows – PART 1

a. Buffer overflows – PART 2b. Incomplete mediationc. Time-of-check to time-of-use errorsd. Combinations of nonmalicious program flaws

3.3. Malicious Code3.3.1. General-Purpose Malicious Code (incl. Viruses)

a. Introduction b. Kinds of Malicious Codec. How Viruses Work – PART 1c. 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 13

Class14

13

How Viruses Work (6)

Characteristics of a ‘perfect’ virus (goals of virus writers) Hard to detect Not easily destroyed or deactivated Spreads infection widely Can reinfect programs Easy to create Machine and OS independent

14

How Viruses Work (7)

Virus hiding places1) In bootstrap sector – best place for virus

Bec. virus gains control early in the boot process Before detection tools are active!

2) In memory-resident pgms TSR pgms (TSR = terminate and stay resident) Most frequently used OS pgms or specialized

user pgms=> good place for viruses (activated very often)

...cont...

[Fig. cf. J. Leiwo & textbook]

Before infection:

After infection:

15

How Viruses Work (8)...cont...

3) In application pgms Best for viruses: apps with macros

(MS Word, MS PowerPoint, MS Excel, MS Access, ...)One macro: startup macro executed when app startsVirus instructions attach to startup macro, infect document files

Bec. doc files can include app macros (commands)

E.g., .doc file include macros for MS WordVia data files infects other startup macros, etc. etc.

4) In libraries Libraries used/shared by many pgms => spread

virus Execution of infected library pgm infects

5) In other widely shared pgms Compilers / loaders / linkers Runtime monitors Runtime debuggers Virus control pgms (!)

16

d. Virus Signatures (1) Virus hides but can’t become invisible – leaves behind a

virus signature, defined by patterns:1) Storage patterns : must be stored

somewhere/somehow (maybe in pieces)

2) Execution patterns: executes in a particular way3) Distribution patterns: spreads in a certain way

Virus scanners use virus signatures to detect viruses (in boot sectior, on hard disk, in memory)

Scanner can use file checksums to detect changes to files

Once scanner finds a virus, it tries to remove it i.e., tries to remove all pieces of a virus V from target pgm T

Virus scanner and its database of virus signatures must be up-to-date to be effective!

Update and run daily!

17

Virus Signatures (2)

Detecting Virus Signatures (1) Difficulty 1 — in detecting execution patterns:

Most of effects of virus execution (see next page) are „invisible”

Bec. they are normal – any legitimate pgm could cause them (hiding in a crowd)

=> can’t help in detecion

18

Virus Signatures (3)Detecting Virus Signatures (2)

Virus Goal How AchievedAttach to executable

Modify file directory / Write to executable pgm file

Attach to data/control file

Modify directory / Rewrite dataAppend to data / Append data to self

Remain in memory

Intercept interrupt by modifying interrupt handler address table / Load self in non-transient memory area

Infect disks Intercept interrupt /Intercept OS call (e.g., to format disk)Modify system file / Modify ordinary executable pgm

Conceal self Intercept system calls that would reveal self and falsify results / Classify self as “hidden” file

Spread self Infect boot sector / Infect systems pgmInfect ordinary pgm / Infect data ordinary pgm reads to control its executable

Prevent deactivation

Activate before deactivating pgmand block deactivationStore copy to reinfect after deactivation

[cf. textbook & B. Endicott-Popovsky]

19

Virus Signatures (4)Detecting Virus Signatures (3)

Difficulty 2 — in finding storage patterns: Polymorphic viruses:

changes from one „form” (storage pattern) to another

Simple virus always recognizable by a certain char pattern

Polymorphic virus mutates into variety of storage patterns

Examples of polymorphic virus mutations Randomly repositions all parts of itself and randomly

changes all fixed data within its code Repositioning is easy since (infected) files stored as chains of data

blocks - chained with pointers

Randomly intersperses harmless instructions throughout its code (e.g., add 0, jump to next instruction)

Encrypting virus: Encrypts its object code (each time with a different/random key), decrypts code to run ... More below ...

20

Virus Signatures (5)Detecting Virus Signatures (4)

Encrypting virus structure (informal pseudo-code)array decr_key;procedure decrypt(virus_code, decr_key)

...end /* decrypt */

begin /* virus V in target pgm T */decrypt (V, decr_key);

infect: if infect_condition met thenfind new target pgms NT to infect;mutate V into V’ for copying;encrypt V’ with random key into V”;save new key in file for V”;attach V” to NT;hide modification of NT (with

stealthcode of V);

damage: if damage_condition met thenexecute damage_code of V

else start Tend /* virus V in target pgm T */

sto-reden-cryp-ted

21

Virus Signatures (6)Detecting Virus Signatures (5)

Encrypting virus: Encrypts its object code (each time with a different/random key), decrypts code to run

Q: Is there any signature for encryption virus that a scanner can see?

Hint: consider 3 parts of encryption virus: „proper” virus code (infect/damage code) decr_key procedure decrypt

22

Virus Signatures (7)Detecting Virus Signatures (6)

... Q: Q: Is there any signature for encryption virus

that a scanner can see? A: Lets’ see:

„proper” virus code – encrypted with random key – polymorphic

decr_key – random key used to encrypt/decrypt – polymorphic

procedure decrypt (or a pointer to a library decrypt procedure) – unencrypted, static=> procedure decrypt of V is its signature

visible to a scanner But: Virus writer can use polymorphic techniques on

decryption code to make it „less visible” (to hide it) Virus writers and scanner writers challenge each other

An endless game?

23

e. Preventing Virus Infections Preventing Virus Infections

Use commercial software fromtrustworthy sources

But even this is not an absoluteguarantee of virus-free code!

Test new software on isolated computers Open only safe attachments Keep recoverable system image in safe place Backup executable system files Use virus scanners often (daily) Update virus detectors daily

Databases of virus signatures change very often

No absolute guarantees even if you follow all the rules – just much better chances of preventing a virus

[cf. B. Endicott-Popovsky]

24

f. Seven Truths About Viruses Viruses can infect any platform Viruses can modify “hidden” / “read only” files Viruses can appear anywhere in system Viruses spread anywhere sharing occurs Viruses cannot remain in memory aftera complete

power off/power on on reboot But virus reappears if saved on disk (e.g., in the boot sector)

Viruses infect software that runs hardware There are firmware viruses (if firmware writeable by s/w)

Viruses can be malevolent, benign, or benevolent Hmmm...

Would you like a benevolent virus doing good things (like compressing pgms to save storage) but without your knowledge?

[cf. B. Endicott-Popovsky]

25

g. Case Studies (1) The Internet Worm

Attacked on 11/2/1988 Invaded VAX and Sun-3 computers running versions

of Berkeley UNIX Used their resources to attack still more computers Within hours spread across the U.S Infected hundreds / thousands of computers – serious

damage to Internet Some uninfected networks were scared into disconnecting

from Internet => severed connections stopped necessary work

Made many computers unusable via resource exhaustion

Was a rabbit – supposedly by mistake unintended by its writer

Perpetrator was convicted in 1990 ($10,000 fine + 400 hrs of community service + 3-year suspended jail sentence)

Caused forming Computer Emergency Response Team (CERT) at CMU [cf. textbook & B. Endicott-Popovsky]

26

Case Studies (2)

Other case studies [textbook – interesting reading] The Brain (Pakistani) Virus (1986) Code Red (2001)

Denial-of-service (DoS) attack on www.whitehouse.gov Web Bugs (generic potentially malicious code on

web pages) Placing a cookie on your hard drive Cookie collects statistics on user’s surfing habits Can be used to get your IP address, which can then be

used to target you for attack Block cookies or delete cookies periodically (e.g., using

browser command; in MS IE: Tools>Internet Options-General:Delete Cookies)

Tool: Bugnosis from Privacy Foundation – locates web bugs

27

h. Virus Removal andSystem Recovery After Infection

Fixing a system after infection by virus V:1) Disinfect (remove) viruses (using antivirus pgm)

Can often remove V from infected file for T w/o damaging T

if V code can be separated from T code and V did not corrupt T

Have to delete T if can’t separate V from T code

2) Recover files:- deleted by V- modified by V- deleted during disinfection (by antivirus pgm)

=> need file backups! Make sure to have backups of (at least)

important files

28

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

29

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

30

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

31

End of Class 14