1

Program Security

2Program Security – Outline

3.1. Secure Programs – Defining & Testing Introduction Judging S/w Security by Fixing Faults Judging S/w Security by Testing Pgm Behavior Judging S/w Security by Pgm Security Analysis Types of Pgm Flaws

3.2. Non malicious Program Errors Buffer overflows Incomplete mediation Time-of-check to time-of-use errors Combinations of non malicious program flaws

3Program Security – Outline

3.3. Malicious Code3.3.1. General-Purpose Malicious Code incl.

Viruses Introduction Kinds of Malicious Code How Viruses Work Virus Signatures Preventing Virus Infections Seven Truths About Viruses Case Studies Virus Removal and System Recovery After Infection

3.3.2. Targeted Malicious Code Trapdoors Salami attack Covert channels

4Program Security – Outline

3.4. Controls for Security Introduction Developmental controls for security Operating System controls for security Administrative controls for security Conclusions

5

Program Security Program security – Our first step on how to

apply security to computing Protecting programs is the heart of

computer security All kinds of programs, from apps via OS,

DBMS, networks Issues:

How to keep pgms free from flaws How to protect computing resources from pgms

with flaws

6

What is Program Security? Depends on who you ask

user - fit for his task programmer - passes all her tests manager - conformance to all specs

This difference occurs because the importance of the characteristics depends on who is analyzing the software.

Developmental criteria for program security include: Correctness of security & other requirements Correctness of implementation Correctness of testing

7

Fault tolerance terminology Error - may lead to a fault Fault - cause for deviation from intended

function Failure - system malfunction caused by

fault

Faults - seen by ”insiders” (e.g., programmers)

Failures - seen by „outsiders” (e.g., independent testers, users)

8

Fault tolerance terminology Error/fault/failure example:

Programmer’s indexing error, leads to buffer overflow fault

Buffer overflow fault causes system crash (a failure)

Two categories of faults w.r.t. duration Permanent faults Transient faults – can be much more difficult to

diagnose

9

Testing Security An approach to judge s/w security:

penetrate and patch Red Team / Tiger Team tries to crack s/w. If you

withstand the attack => security is good. Is this true? Rarely.

Too often developers try to quick-fix problems discovered by Tiger Team Quick patches often introduce new faults due

to: Pressure – causing narrow focus on fault, not context Non-obvious side effects System performance requirements not allowing for

security overhead

10

Testing Security A better approach to judging s/w

security: testing pgm behaviour Compare behaviour vs. requirements Program security flaw = inappropriate

behaviour caused by a pgm fault or failure Flaw detected as a fault or a failure

11

Testing Security Important: If flaw detected as a failure (an

effect), look for the underlying fault (the cause)

Recall: fault seen by insiders, failure – by outsiders

If possible, detect faults before they become failures

12

Testing Security Any kind of fault/failure can cause a

security incident Misunderstood requirements / error in

coding / typing error In a single pgm / interaction of k pgms Intentional flaws or accidental (inadvertent)

flaws

13

Testing Security Therefore, we must consider security

consequences for all kinds of detected faults/failures Even inadvertent faults / failures Inadvertent faults are the biggest source of

security vulnerabilities exploited by attackers

14

Problems with program behaviour testing

Limitations of testing Can’t test exhaustively Testing checks what the pgm should do - Can’t often

test what the pgm should not do Complexity – malicious attacker’s best friend

Too complex to model / to test Exponential # of pgm states / data combinations

Evolving technology New s/w technologies appear Security techniques catching up with s/w technologies

(Programming and software engineering techniques change and evolve far more rapidly than do computer security techniques)

15

Types of Program Flaws Taxonomy of pgm flaws: Flaws can be

Intentional or Unintentional

Intentional Malicious Nonmalicious

16

Types of Pgm Flaws Unintentional

Validation error (incomplete or inconsistent) Domain error (variable value outside of its

domain) Serialization and aliasing

serialization – e.g., in DBMSs or OSs aliasing - one variable or some reference, when

changed, has an indirect (usually unexpected) effect on some other data

Inadequate ID and authentication (Section 4—on OSs)

Boundary condition violation Other exploitable logic errors

17

Nonmalicious Program Errors Buffer overflows Incomplete mediation Time-of-check to time-of-use errors Combinations of nonmalicious program

flaws

18

Buffer Overflows Many languages require buffer size

declaration C language statement: char sample[10]; Execute statement: sample[i] = ‘A’; where

i=10 Out of bounds (0-9) subscript – buffer overflow

occurs Some compilers don’t check for exceeding

bounds Similar problem caused by pointers. No

reasonable way to define limits for pointers

19

Buffer Overflows, cont. Where does ‘A’ go? Depends on what is

adjacent to ‘sample[10]’ Affects user’s data - overwrites user’s data Affects users code - changes user’s

instruction Affects OS data - overwrites OS data Affects OS code - changes OS instruction

This is a case of aliasing

20

21

Buffer Overflows, cont. Implications of buffer overflow: Attacker

can insert malicious data values/instruction codes into ”overflow space”

Suppose buffer overflow affects OS code area: Attacker code executed as if it were OS code

Attacker might need to experiment to see what happens when he inserts A into OS code area

Can raise attacker’s privileges (to OS privilege level) when A is an appropriate instruction

Attacker can gain full control of OS

22

Buffer Overflows, cont. Other types of overflow

Buffer overflow affects a call stack area Web server attack similar to buffer overflow

attack: pass very long string to web server Buffer overflows still common

Used by attackers to crash systems to exploit systems by taking over control

Large # of vulnerabilities due to buffer overflows

23

Incomplete Mediation Sensitive data are in exposed,

uncontrolled condition Example

URL to be generated by client’s browser to access server, e.g.: http://www.things.com/ order/final&custID=101&part=555A&qy=20&price=10&ship=boat&shipcost=5&total=205

Instead, user edits URL directly, changing price and total cost as follows: http://www.things.com /order/final&custID=101&part=555A&qy=20&price=1&ship=boat&shipcost=5&total=25

24

Incomplete Mediation, cont . Unchecked data are a serious

vulnerability!

Possible solution: anticipate problems Don’t let client return a sensitive result (like

total) that can be easily recomputed by server Use drop-down boxes / choice lists for data

input Prevent user from editing input directly Check validity of data values received from

client

25

Time-of-check to Time-of-use Errors

Also known as synchronization flaw / serialization flaw

Synchronization - mediation with “bait and switch” in the middle

Non-computing example: Swindler shows buyer real Rolex watch (bait) After buyer pays, switches real Rolex to a

forged one In computing:

Change of a resource (e.g., data) between time access checked and time access used

26

time-of-check to time-of-use flaw because it exploits the delay between the two times. That is, between the time the access was checked and the time the result of the check was used, a change occurred, invalidating the result of the check.

27

To understand the nature of this flaw, consider a person's buying a sculpture that costs $100. The buyer removes five $20 bills from a wallet, carefully counts them in front of the seller, and lays them on the table. Then the seller turns around to write a receipt. While the seller's back is turned, the buyer takes back one $20 bill. When the seller turns around, the buyer hands over the stack of bills, takes the receipt, and leaves with the sculpture. Between the time the security was checked (counting the bills) and the access (exchanging the sculpture for the bills), a condition changed: What was checked is no longer valid when the object (that is, the sculpture) is accessed.

28

Time-of-check to Time-of-use Errors, cont .

Prevention of TOCTTOU errors Be aware of time lags Use digital signatures and certificates to

”lock” data values after checking them

29

Malicious Code Can Do Much (Harm)

Malicious code can do anything any other program can, such as writing a message on a computer screen, stopping a running program, generating a sound, or erasing a stored file. Or malicious code can do nothing at all right now; it can be planted to lie dormant, undetected, until some event triggers the code to act. The trigger can be a time or date, an interval (for example, after 30 minutes), an event (for example, when a particular program is executed), a condition (for example, when communication occurs on a network interface), a count (for example, the fifth time something happens), some combination of these, or a random situation. In fact, malicious code can do different things each time, or nothing most of the time with something dramatic on occasion.

30

Malicious Code Kinds of malicious code

Viruses Trojan horses Logic bombs Trapdoor (backdoor) Worms Rabbits

31Trapdoors

Trojan Horses

Bacteria

Logic BombsWorms

Viruses

XFile

s

32

Virus A virus is a program that attaches itself into

one or more files and then performs some (possibly null) action

Transient virus A transient virus has a life that depends on the life

of its host Runs when the attached program runs Terminates when that program terminates

Resident virus Locates itself in memory

Remain active even when the attached program ends

33

Trojan Horses A Trojan horse is malicious code that, in addition

to its primary effect, has a second, non-obvious malicious effect.

Trojan horse - A computer program that appears to have a useful function, but also has a hidden and potentially malicious function that evades security mechanisms, sometimes by exploiting legitimate authorizations of a system entity that invokes the program

34

Logic Bombs A logic bomb is a program that performs an

action that violates the security policy when some external event occurs Example

Erase all the employee records when John Smith is no longer an active employee

Time bomb: a logic bomb whose trigger is a time or date

35

Trapdoor (Backdoor) A feature in a program by which

someone can access the program other than by the obvious way, perhaps with special privilege Example

An ATM allows anyone entering 990099 on the keypad to get all the transactions

36

Worm A worm is a program that spreads copies

of itself through a network Different from viruses

Viruses depend on other programs Worms are usually standalone applications Viruses usually trick people into

propagating them Worms can hack into vulnerable systems

and spread without depending on others

37

Rabbits (Bacteria) A bacterium or a rabbit is a program that

absorbs all of some class of resource Could be a virus or worm

Example Exhaust disk space Exhaust inode tables

38

39

How does Virus Work Two phases

Insertion phase The virus inserts itself into a file (or files)

Execution phase The virus executes

Usually trick human users to execute the virus This is necessary for the virus to take control Examples

Email attachments Hide in boot sector of bootable medium

40

Places to Insert Virus Code Virus appended to a program

Virus instruction first executed Original program executed after the last virus instruction

41

Places to Insert Virus Code (Cont’d)

Virus that surround a program Has control before and after the virus execution Example: modify the output of the original program

42

Places to Insert Virus Code (Cont’d) Virus integrated in the original program

The virus writer has to know the exact structure of the original program

Targeted infection; Rare

43

How Virus Gain Control Boot sector infectors

The boot sector is the part of a disk used to bootstrap the system.

Code in a boot sector is executed when the system “sees” the disk for the first time.

1. Move the disk interrupt vector 13H to 6DH 2. Set 13H to invoke Brian virus3. Load the original boot sector

Brian Virus

44

Boot Sector Infector (Cont’d)

1. Copy the old boot sector to alternative place;2. Insert itself into the boot sector.

45

How Virus Gain Control (Cont’d) Executable infectors

Triggered if an infected program is executed Infect executables

COM and EXE

Executable code and dataHeader

VirusHeader Executable code and data

First program instruction

46

Terminate and Stay Resident (TSR) Virus

TSR virus Stays active in memory after the application (or

bootstrapping) has terminated.

1. Move the disk interrupt vector 13H to 6DH 2. Set 13H to invoke Brian virus3. Load the original boot sector

Brian Virus

New disks will be infected as long as the virus is in memory.

47

Viruses (Cont’d) Stealth viruses

Conceal the infection of files Make itself difficult to detect

Polymorphic viruses Encrypt itself with a random key Avoid detection by anti-virus programs,

which search for patterns of viruses. Metamorphic viruses

Change its form each time it inserts itself into another program.

48

Viruses (Cont’d) Document (Macro) viruses

Viruses composed of instructions that are interpreted, rather than executed.

Examples Word viruses Email viruses

MS Office suite is the most popular target.

49

Virus Signature and Virus Scanner Virus code must be stored somewhere Virus signature

Characteristics of a virus Virus scanner

Program that looks for virus signatures A virus scanner is effective only if it is kept

up-to-date with the current virus signatures Examples

Symantec AntiVirus Norton AntiVirus

50

Virus Signatures Storage patterns

A virus needs to take control of the program Attach to a file ==> increased file size

Remove a part of the original file ==> program function impaired

51

Truths and Misconceptions about Virus

Virus can only infect Microsoft Windows system

Viruses can modify “hidden” or “read only” files

Viruses can appear only in data files, or only in Word documents, or only in programs

Viruses spread only on disks or only in email

Viruses cannot remain in memory after a complete power off/power on reboot

Viruses cannot infect hardware Viruses can be malevolent, benign, or

benevolent

52

The Internet Worm Morris Worm, Nov 2nd, 1988

The first worm Robert T. Morris, Jr.

23 years old Cornell grad student

Wrote a self-propagating program as a “test concept” Exploited Unix vulnerabilities in sendmail and

fingerd Released at MIT Bug in the worm caused it to go wild

Probably wouldn’t have caused much damage otherwise!

53

The Internet Worm (Cont’d) Targeted at Sun 3 and VAX Workstations running

BSD based Unix operating systems Infected about 6,000 Unix hosts

About 10% of the 60,000 hosts on the Internet Reactions

People didn’t know what to do, so they panicked Disconnected from net Unable to receive patches!

Morris fined $10k, 3 yrs probation, 400 hrs community service

CERT was created

54

The Internet Worm (Cont’d) Code accomplishes three objectives

1. Determine to where it could spread Offline password guessing (use the dictionary

for the spell checker) Buffer overflow vulnerability in fingerd ==>

remote shell Sendmail vulnerability (debug mode) to execute

arbitrary commands2. Spread its infection

First a bootstrap loader to the target machine Bootstrap loader fetch the rest of the worm

Use a one-time password to authenticate the bootstrap loader

55

The Internet Worm (Cont’d) Code accomplishes three objectives

(Cont’d) Remain undiscovered and undiscoverable

If worm fetching runs into a transmission error, the bootstrap loader deletes all the code already transferred

Once worm is received, it loads the code into memory, encrypt it, and delete all the original copies

Periodically change its name and process id Definitely discoverable: The huge traffic

resulting from the spread!!!

56

Code Red Appeared in July and August in 2001 Exploit a buffer overflow vulnerability in

Microsoft’s Internet Information Service (IIS) Buffer in the dynamic link library idq.dll

Three versions Code Red I version 1 Code Red I version 2 Code Red II

Substantial rewrite

57

Code Red I Version 1 Easy to spot

Deface the websiteHELLO!Welcome to

:// . .http www worm com! Hacked by Chinese!

Activities determined by date Day 1 to 19 of the month

Scan and compromise vulnerable computers, starting at the same IP

Day 20 to 27 Distributed denial of service (DDoS) attacks against

www.whitehouse.gov Day 28 to end of month

Do nothing

58

Code Red I Version 2 Discovered near the end of July 2001

Did not deface the website Propagation is randomized and optimized to

infect servers more quickly

59

Code Red II Discovered on August 4, 2002 Inject a Trojan hose in the target Modify software to ensure a remote attacker can

execute any command on the server Copy cmd.exe to four places

C(D):\inetpub\scripts\root.ext C(D):\progra~1\common~1\system\MSADC\root.exe

Its own copy of explorer.exe Modify the registry to disable certain file protection Reset the registry every 10 minutes

Automatically stop propagating in October 2002 Reboot the server after 24 or 48 hours, wiping itself

from memory but leaving the Trojan horse