Top Banner
1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004
71

1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

Dec 20, 2015

Download

Documents

Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

1

Introduction to Computer Security

Lecture 12

Dr. Richard SpillmanPacific Lutheran University

Summer 2004

PLUSummer 2004

Page 2: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

2

Last Lecture

• Computer Crimes

• History

• Passwords

• Buffer Overflow Attacks

• Introduction to unix

Page 3: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

3

Review – Buffer Overflow

• The overall goal of a buffer overflow attack is to subvert the function of a privileged program so attacker can take control of that program– The attacker then gains all the privileges

assigned to the compromised program– The attack is typically against a program with

root privileges from which the attacker runs code similar to “exec(sh)” to get a root shell

Page 4: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

4

Review – Buffer Overflow Requirements

• To achieve the goal, the attacker must first achieve two subgoals:– Arrange for suitable code to be available

in the program’s address space

– Get the program to jump to that code, with suitable parameters loaded into registers and memory

Page 5: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

5

Outline

•Computer Crimes

•History

•unix Security

•Kerberos

Page 6: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

6

CyberAttacks

• the 20 most frequent scans detected against companies – The frequency of

different types of scans provides a high-level snapshot of the types of reconnaissance activity in which attackers engaged over the past six months.

– Similar to previous reports, 99.9% of scanning activity was concentrated on only 20 services

Results of the Symantec Internet Security Threat Report: AttackResults of the Symantec Internet Security Threat Report: AttackTrends for Q3 and Q4 of 2002Trends for Q3 and Q4 of 2002

Page 7: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

7

Top 10 Signs Your Co-worker is a Hacker

10: You ticked him off once and your next phone bill was for $20,000.9: He's won the Publisher's Clearing House sweepstakes 3 years

running.8: When asked for his phone number, he gives it in hex.7: Seems strangely calm whenever the office LAN goes down.6: Somehow gets HBO on his PC at work.5: Mumbled, "Oh, puh-leeez" 95 times during the movie "The Net".4: Massive 401k contribution made in half-cent increments.3: His video dating profile lists "public-key encryption" among turnons.2: For his welcome voice on AOL, you hear, "Good Morning, Mr.

President".1: You hear him murmur, "Let's see you use that Visa now, Professor-I-

Don't-Give-A's-In-Computer-Science!"

Page 8: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

8

Crimes 1

• AV vendors are warning users to steer clear of a Valentine's Day e-greeting from [email protected]. – Clicking the link connects them to a site to download

an 800 kb file, but the software apparently also changes browsers' default search engine.

– No one's called it malicious code yet, but at the very least, AV vendors say, it hogs bandwidth and apparently drops an unidentified DLL program in Windows systems.

Page 9: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

9

Crimes 2

• Two hackers who broke into Riverside County, Calif., court computers and electronically dismissed a variety of pending cases pleaded guilty to the crime.

• Both William Grace and Brandon Wilson were sentenced to nine years in jail after pleading guilty to 72 counts of illegally entering a computer system and editing data, along with seven counts of conspiracy to commit extortion.

Page 10: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

10

Crimes 3

• Transport experts have warned that a new website showing how to hack into traffic light computer systems could wreak havoc in London.– The site gives step-by-step information on how to break through

security checks and rephase individual signals or groups of lights.

– It even tells drivers how to use a car-based laptop to turn red lights green to speed their journey.

– Experts who studied the website today warned a skilled hacker could easily use it to cause chaos.

– It gives a glossary of terms used by traffic engineers and explains how traffic light systems - including those in the capital - work.

– It includes diagrams explaining how traffic signals are controlled, and instructs hackers how to get "inside" control systems by obtaining confidential phone numbers.

Page 11: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

11

Censorship during WWII

• During WWII, the US set up a censorship service– By the end of the war it had over 14,000 employees at 90 sites

throughout the country– It opened over 1 million pieces of mail a day– It listened to phone conversations, scanned movies, magazines

and radio scripts

• To plug up steganographic channels it banned in advance whole classes of mail– Chess games by mail– Crossword puzzles– Newspaper clippings– One letter containing knitting instructions was held up until the

examiner could actually knit the sweater– Loose stamps were replaced by others of equal value but of a

different number and denomination

Page 12: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

12

Null Ciphers

• One type of open code that was used to get by the censors was a null cipher where only certain words or letters are significant– Every fifth word– The first letter of every word

• Example of a letter sent by a German spy during WWI

President’s embargo ruling should have immediate notice.Grave situation affecting international law. Statementforshadows ruin of many neutrals. Yellow journals unifyingnational excitement immensely.

Pershing sails from NY June 1

President’s embargo ruling should have immediate notice.Grave situation affecting international law. Statementforshadows ruin of many neutrals. Yellow journals unifyingnational excitement immensely.

Page 13: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

13

Missed Opportunities 1

• The allies had set up jargon coded messages to send to the underground in Europe– When the BBC broadcast “It is hot in Suez” the

Resistance was to put into effect the Green Plan which called for sabotaging railroad tracks and equipment

• The most famous of these jargon code messages was the one announcing D-Day which the Nazis intercepted, recognized and ignored.

Page 14: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

14

Missed Opportunities 2

• Abwehr headquarters had discovered that D-Day would be signaled to the underground by a certain piece of music– So, the German 15th Army set up a special 30-man

interception crew to listen for the signal headed by Colonel Meyer

– On June 1 at 9 pm Sergeant Walter Reichling of the team heard the signal and reported it to Colonel Meyer

– Colonel Meyer telephoned the two German headquarters charged with the defense of France

– But nothing was done about it – each headquarters had assumed that the other would sound the alarm

Page 15: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

15

Unix & Security

• In the beginning, Unix was a very insecure system. – Security was maintained by locking the system and

the terminals with access into it behind closed doors.

• In the words of Dennis Ritchie, one of the creators of Unix, " It was not designed from the start to be secure. It was designed with the necessary characteristics to make security serviceable."

Page 16: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

16

Basics

• Threat - an undesirable event

• Vulnerability - a condition of a missing or ineffectively administered safeguard or control that allows a threat to occur with a greater impact or frequency or both.

• Losses - these include direct and indirect loss– Disclosure– Integrity– denial of service

• Countermeasures are methods designed to reduce the risk and loss associated with a threat or vulnerability

Page 17: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

17

Counter Measure Processes

• There are five steps to establishing countermeasures– Risk assessment– Vulnerability assessment– Vulnerability reduction– System Documentation– Stay current

• This is an on-going process

Page 18: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

18

Risk Assessment

R/A is the study of vulnerabilities, threats, likelihood, impact, and theoretical effectiveness of countermeasures. Risk can be mitigated through the actions of a

security administrator, threats can not.

We assess the risk to a system to help us: Determine expected losses Establish a degree of acceptability Determine effectiveness of countermeasures Redesign and improve our security

Page 19: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

19

Calculating Risk

• There are a number of different formulas for risk– One is: Risk = Threat * Vulnerability * Cost– If Threat = 0 or Vulnerability = 0 or Cost = 0

then the Risk = 0– We have no control over threats– We have little control over costs– We have a lot of control over vulnerability

Page 20: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

20

Vulnerability Assessment

• Determine the system’s vulnerability using scanning and probing software/hardware to identify potential weaknesses– Look for unauthorized equipment– Look for flaws in your system

• Use tools such as – Crack– SATAN– . . .

Page 21: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

21

Vulnerability Types

There are 3 classes of Vulnerabilities Design

Weakness in the underlying design or specification. Even

implemented exactly to specs will yield the weakness.e.g. using XOR-encryption to protect data

ImplementationWeakness in the target as a result of errors or poorpractices on the part of the author.

e.g. using strcpy() instead of strncpy() Configuration

Weakness in the system as a result of incorrect parameters or improper hardware.e.g. unused services, world read permissions, etc.

Page 22: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

22

Sources of Vulnerability Information

• Free Sources– Bugtraq

• www.securityfocus.com

– NTbugtraq• www.ntbugtraq.com

– VulnWatch• www.vulnwatch.com

• Commercial Sources– E-Security Online from E&Y

– DeepSight from Symantec

Should vulnerabilities be reported at all?

Page 23: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

23

Penetration Testing

• Also known as– Penetration analysis (PentAn)– Tiger team attack– Red team [Blue team]

• Ultimate goal of the test is to violate a site’s security policies

• However, usefulness of the study comes from degree of penetration, documentation and conclusions of the study not from the success or failure of the attempted penetration– For example: successful compromise of user data is not

equivalent to privilege escalation in a computer system

Page 24: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

24

Review – Growth in Vulnerabilities

• 90% growth in vulnerabilities– About 4000 in 2002, expecting 8000 in 2003– Caused by increasing code complexity– More and better investigations

0

1000

2000

3000

4000

5000

6000

7000

8000

1995 1996 1997 1998 1999 2000 2001 2002 2003e0

1000

2000

3000

4000

5000

6000

7000

8000

1995 1996 1997 1998 1999 2000 2001 2002 2003e

Page 25: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

25

Vulnerability Reduction

• Work to eliminate the vulnerabilities

• Create system documentation and system operating procedures

• Stay current on exploits and all system patches

Page 26: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

26

Unix Weakness

• Login process – one weak password can compromise the entire system

• Trusted host – allows access to local resources without password authentication– .rhosts and hosts.equiv file services– X-window allow remote system access– Trust is your enemy

• As unix grows and is modified, new holes appear

Page 27: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

27

General Weakness 1

• A version of the Buffer Overflow Attack designed to deny service.

• Overwrites a buffer with more data than it can hold, so that the function return address or other pointers stored in the program stack are corrupted

• Causes the program to attempt execution or access of an invalid memory location

• Causes a fault that can crash the application, or even crash the machine on which the application runs

Page 28: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

28

General Weakness 2

• Invalid Input Attacks

• Method of creating input data that causes an application to execute commands it would not normally execute

• Similar to buffer overflow attacks, but... – Exploit lack of input validation rather than lack of bounds checking– Seek to trick the application into executing commands rather than

exploiting the ability to overlay the stack

• Most common vulnerabilities are in CGI scripts

Page 29: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

29

General Weakness 3

• Remote Shell Access Attack

• Use brute force or data driven attack to coerce remote system into opening a connection back to the attacker

• Exploit misconfigured or otherwise vulnerable service to obtain more direct access

• Common methods– X Windows– Back channels

Page 30: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

30

General Weakness 4

• Social Engineering– I’m with security

• We have a problem, and need your help. Give us your password• Need to update your virus definitions, have the users give me

their screensaver passwords

– Problem with payroll• I’m from accounting. I can’t get on the system to execute the job

to process paychecks.

– A personalized tour• I’m new, show me how things work

– Trust me, I’m with the phone company• I’m looking for a problem.

Page 31: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

31

Social Engineering Information

• Hackers get their information for social engineering from:– Employee directory – often on company homepages. Name, email,

phone, depts clicks away– Company phone systems – often having ways to list employee

names– Lobby directories – offices, names, titles, etc.– Usenet posts & email list archives – get employee name. Email

signatures often have title and contact info. Going over multiple entries can give insight into person writing style

– Online databases – phone numbers & email address free from many locations.

– Personal Home pages – people often will give info like where they work, where they went to school, who their friends are, what foods they like, etc. All available from the source.

– Public DNS information – databases of what names are mapped to what IP addresses will have contact info for system administrators.

Page 32: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

32

Unix Attacks

• In addition to the general weaknesses of unix there are a large number of specific unix weaknesses which can be and have been exploited

• The next few slides will outline some of the common problems – most but not all have been patched– Some require the system administrator to take

specific actions

Page 33: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

33

Shared Libraries

• Allow dynamically linked programs to access code from common libraries– The system dynamic linker (ld.so or ld.so.1) makes the referenced

code available to the program at run-time (when it’s executed)– The main benefit is that programs do not need to be rebuilt when the

libraries are updated

• If attackers can modify a shared library, or provide an alternate library through one of the LD_ environmental variables, they could gain root access through any dynamically-linked program that executes with root privileges

Page 34: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

34

Access Validation Error

• An access validation error is a condition where a validation check takes place, but due to incorrect logic, inappropriate access is given.

• Sample Vulnerability [froot bug, AIX 3.2, Administrator Access]– The command:

$ rlogin victim.com -l –froot

allows root access remotely without validation because of a parsing error in the way that substitutes “root” as the name of the person being validated. Likewise, the login is always successful regardless of the password due to missing condition logic.

Page 35: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

35

suid/sgid

• Question: John wrote a program. Bob starts it. Whose files can it access?– Answer: Normally Bob's unless the set-user-id (suid) or set-

group-id (sgid) bits are set.– A program with suid or sgid is executed \on behalf of the owner"!

• Files set to SUID/SGID allow normal users to run them with higher user permissions.

• Problem: Most SUID/SGID files allow programs/scripts to be run as root. – This can be very dangerous and insecure in a server

environment. A hacker can easily exploit many of these files to gain “root” access

Page 36: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

36

Why suid for root?

• Unix mechanisms for changing your user identity and group identity– Either indefinitely or for the run of a single program– Created to deal with inflexibilities of the Unix access control model– Users need superuser privilege to execute certain OS functions

(but should not receive superuser status)– But the source of endless security problems

• The print queue is essentially a file– Someone must own that file– How will other people put stuff in the print queue? Without making

the print queue writeable for all purposes– Typical Unix answer is to run the printing program setuid to the

owner of the print queue

Page 37: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

37

Important suid Programs

• /bin/passwd – change password

• /bin/login – login program

• /bin/at – batch job submission

• /bin/su – change UID program

Page 38: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

38

Install Weakness

• One program that has had a number of problems with security is the install program, which by default on many platforms was setuid root. Although it was argued for a long time that the security inside of install was good enough to prevent abuse, eventually the setuid bit was removed.

• Sample Vulnerability [install, general, Administrator Access]

% echo “intruder::0:0:The Intruder:/:/bin/sh” >> /etc/passwd

% cp /etc/passwd /tmp/passwd Save the current password file

% cp /tmp/passwd /etc/password

Add a root level user

% install –d –o <username> /etc Install a home file with root privilege (because install is suid)

Restore old password file

Page 39: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

39

Core File Weakness

• Core files are created by the system when a program encounters an error from which it can’t recover

• Contain a memory image normally used to debug the program

• A core file from an SUID program may contain encrypted passwords or other sensitive information

Page 40: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

40

Bad Login Weakness

• The file /etc/btmp keeps track of failed login attempts by incorrect login name

• It is not uncommon for someone to type in their password instead of their login name– By looking for a failed login followed by a

good login at a terminal– Since the user most likely corrected the

mistake a good user name/password pair is revealed

Page 41: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

41

File Name Weakness

• File name attacks involve creating a file whose name will be interpreted by the system as something else by embedding command delimiters into the file name– unix has no restrictions on what characters

can be used in a file name– For example: core; rm – r /*

If this file is processed by any command that uses the shellto expand the file name, the part of the name after the semicolonwill be executed as a command – it this case a command to deleteall the files on the computer

Page 42: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

42

Unix Advice

• There is a lot of advice regarding security on unix systems available in books, articles, or on the web

• The next few notes will highlight just a few issues that may prove useful in maintaining any unix system

Page 43: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

43

root Passwords

• Always use a STRONG root password

• Limit root access to the minimum number of users or programs – Provide access on an as needed basis– This practice should limit accidental or

intentional misuse of root privileges

• Capture all root activities through logging/accounting mechanisms

• DO NOT have .rhosts file in the root directory

Page 44: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

44

Protecting System Accounts

• System accounts are not associated with a specific user– Default system accounts, such as sys, bin, uucp, or lp,

are used by the system to run system applications or manage its operation

– Delete, if possible, accounts (such as demo, test, guest, or help) created by application programs to prevent exploits against the accounts

• If the accounts cannot be deleted, consider – Disabling or changing the password– Providing a false shell that does nothing when

executed

Page 45: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

45

Guest Accounts

• Provided as a convenience to visitors– If possible, don’t have them– If necessary:

• Change the password daily and issue as needed

• Keep the guest account in a restricted file system (chroot)

• Using restricted shells are an alternative to Guess Accounts

Page 46: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

46

Directories to Protect

• As a minimum, all directories in root’s search path should be as secure as possible– / - The root user’s home directory– /dev - Contains all standard device files

• Only /dev/null, /dev/tty, and /dev/console should be “world” writeable

• Be suspicious of device files residing in directories other than /dev.

• Periodically scan your system for unauthorized device files

Page 47: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

47

Directory Permissions

/etc• Contains most of the system's configuration and

security files• No file or directory should be world-writeable

/home• Typically, this directory contains all the

directories assigned to each user (home directories)

• The recommended directory permissions for each user’s home directory is 700

Page 48: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

48

Protect Audit Data

• Access to directories and files that contain audit and audit log data must be particularly restrictive

• The recommended directory permissions should be 750, with root ownership and group ownership assigned to the security administrator’s group

• Ideally, access to the audit logs should be limited to security personnel

Page 49: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

49

Critical Files

• /dev/kmem character special device provides access to the virtual memory of a system

• /dev/mem character special device provides access to the physical memory of a system

• If an attacker can access these devices, he could alter the attributes of the system and processes

• Recommend permissions of 440 with root and sys group ownership

Page 50: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

50

/etc/aliases

• Contains system-wide e-mail aliases used by sendmail• Can be configured to automatically execute programs

– Example: encode/decode can be configured to make it easier for users to send/receive binary files

• Unfortunately, this becomes a place for attackers to introduce rogue executables

• The aliases file should not be writeable by users• Avoid program aliases or writes to a file unless you are

absolutely 100% certain what the outcome will be• Recommended setting file permissions to 644 with root

ownership and bin group membership

Page 51: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

51

Auditing Guidelines

• To minimize chance of security breaches you must monitor or audit your system regularly– You must know your system– You must know your security policy– You must audit regularly and often– You must understand the auditing tools

available and how to use them– Stay current - read books - use the Web

Page 52: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

52

Unix Security Tools

• Be familiar with all the tools available to help you maintain a secure unix system

• Some of the tools have already been mentioned,others will be covered in the next class, and some are reviewed here

Page 53: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

53

COPS• The COPS (Computer Oracle and Password System) package developed by

Dan Farmer of Sun Microsystems, is a security tool for system administrators that checks for numerous common security problems on UNIX systems.

• A collection of shell scripts and C programs (a new version uses PERL instead of C), COPS can be easily run on almost any UNIX variant.

• Among other things, it checks the following items and sends the results to the system administrator:

– Checks /dev/kmem and other devices for world read/writability– Checks special/important files and directories for “bad” modes (world-writable,

etc.)– Checks for easily-guessed passwords – Checks for duplicate user ids, invalid fields in the password file, etc.– Checks for duplicate group ids, invalid fields in the group file, etc.– Checks all users' home directories and their .cshrc, .login, profile, and .rhosts

files for security problems– Checks all commands in the /etc/rc files and cron files for world-writability– Checks for bad root search paths, NFS file systems exported to the world, etc.– Includes an expert system that checks to see if a given user (usually root) can be

compromised, given that certain conditions exist.

Page 54: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

54

npasswd• The npasswd command, developed by Clyde Hoover at the

University of Texas at Austin, is intended to be a replacement for the standard UNIX passwd command, as well as the SUN yppasswd command.

• The npasswd program makes passwords more secure by refusing to allow users to select insecure passwords.

• The following capabilities are provided by npasswd:– Configurable minimum password length– Configurable to force users to use mixed case or digits and

punctuation– Checking for “simple” passwords such as a repeated letter– Checking against the host name and other host-specific information– Checking against the login name, first and last names, and so on– Checking for words in various dictionaries, including the system

dictionary.

Page 55: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

55

Tripwire

• First of the file integrity checkers

• Unix and NT versions available– Network capable versions available

• Academic version is free. Commercial and NT versions are not.

• Useful in finding trojan programs

Page 56: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

56

Tripwire Capabilities

• It uses several checksum/signature routines to detect changes to files, as well as monitoring selected items of system-maintained information.

• The system also monitors for changes in permissions, links and sizes of files and directories.

• It can be made to detect additions or deletions of files from watched directories.

• The configuration of Tripwire is such that the system/security administrator can easily specify files and directories to be monitored or to be excluded from monitoring and to specify files which are allowed limited changes without generating a warning.

• Once installed on a "clean" system, it can detect changes from intruder activity, unauthorised modification of files to introduce back-door or logic-bomb code, virus activity in a UNIX environment.

Page 57: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

57

Sample Run

• A Tripwire run:

Notice: No changes

Page 58: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

58

Background

• Developed at MIT for Project Athena (`83)• Rationale: students within MIT were doing too

much network eavesdropping and continually obtained superuser password and modified (or rebooted) machines

• Works for UNIX TCP/IP networks; public domain

• Based on symmetric cryptography (uses DES)

• Uses trusted arbitrator

Page 59: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

59

Kerberos Design

• User must identify itself once at the beginning of a workstation session (login session).

• Passwords are never sent across the network in cleartext (or stored in memory)

• Every user has a password.

• Every service has a password.

• The only entity that knows all the passwords is the Authentication Server.

Page 60: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

60

Overview

• A client wants access to a server– Clients request a ticket for a Ticket Granting Service

(TGS) from the Kerberos server.– Kerberos server sends the ticket, encrypted with the

client's secret key.– Client then requests a ticket for a particular service

from the TGS– TGS supplies the requested ticket– Client presents the ticket to the server along with

authenticator– Server permits client to use the service

Page 61: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

61

Getting a Ticket

• Getting the initial ticket– User has a single piece of

secret information that can prove his/her identity (ex: a password).

– We don't want to send the password plaintext over the network!

– We do the following instead.

• User (client) sends a message to the Kerberos server, containing user name and the specific TGS desired. This is usually done as part of the login process.

KerberosKerberos

ClientClient

user namedesired service

user namepasswordservice

Page 62: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

62

Kerberos Server

• If user is in Kerberos DB ...– Generate a session

key to be used between user and the desired TGS (Ticket Granting Service); session key is the Ticket Granting Ticket, TGT.

– Encrypt the session key above with the client's secret key (a one-way hash of the user's password).

– Create a TGT for the client to use as authentication when communicating with the TGS. This is encrypted with the TGS's secret key.

Kerberos

Client

(1) look up user(2) make session key Cli-TGS (3) k1 = hash(user password)(4) determine TGS(5) construct TGT

(6) send E k1(Cli-TGS ), TGT

databaseof

keys/users

TGT = E Kerb-TGS (username, address, server ID)

Page 63: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

63

Getting the TGT

• Client can now decrypt the message and obtain the session key for the TGS.

– E k1(Cli-TGS ), TGT

– Yields session key s used for Cli-TGS and TGT

• Client removes the password from the system.• No one else can use the TGT... why???

User now has a ticket signed by Kerberos Serverauthenticating user for Ticket Granting Service

Client

Page 64: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

64

Getting Server Tickets

• Need one per service to be used, must get them one at a time.– Client sends a request to the

TGS (done automatically when the application is needed).

– Client creates an authenticator: name, address, timestamp and encrypts with the session key obtained from the Kerberos authentication server.

– Client then creates a request: server name, TGT from session that is encrypted with the TGS secret key, and the authenticator (above).

Client

TicketGrantingService

(2) request/receive server ticket

server ID, E Cli-TGS (username, address, timestamp) ,TGT = E Kerb-TGS (username, address, server ID)

Page 65: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

65

Ticket Granting Service

• Decrypt TGT with Kerb-TGS key• Use session key from TGT to decrypt the

authenticator, and checks it:– Compares authenticator information with the information on the

ticket, – compares network address of the request with the one inside the

request, and – checks the timestamp against the current time. – Proceed if everything matches.

Timestamp check means that clocks must be synchronized, and is done to reduce likelihood of replay

server ID, E Cli-TGS (username, address, timestamp) ,TGT = E Kerb-TGS (username, address, server ID)

server ID, E Cli-TGS (username, address, timestamp) ,TGT = E Kerb-TGS (username, address, server ID)

Page 66: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

66

Getting a Ticket for the Service

• TGS returns a valid ticket for the client to give to the requested application server. It will have:– Client name, address, timestamp, expiration, new session key. – Encrypt this with the application server's secret key.

• TGS will also send: – new session key for client and server (as mentioned above),

encrypted by the key shared between client and TGS.

E Cli-TGS (Cli-service) ,Ticket = E TGS-Servicee (username, address, timestamp, expiration, Cli-service)

E Cli-TGS (Cli-service) ,Ticket = E TGS-Servicee (username, address, timestamp, expiration, Cli-service)

Page 67: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

67

Authenticating

• Client receives message and decrypts to obtain session key for server.

E Cli-TGS (Cli-service) ,Ticket = E TGS-Servicee (username, address, timestamp, expiration, Cli-service)

E Cli-TGS (Cli-service) ,Ticket = E TGS-Servicee (username, address, timestamp, expiration, Cli-service)

Client can read the session key for the service, Cli-serviceOnly Service (or TGS) could decode the ticket

* ticket contains Cli-service* ticket has a timestamp, lifespan, etc

Page 68: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

68

Requesting a Service

• Client:– Creates a request for the server, containing an

authenticator consisting of client name, address, and timestamp (encrypted with the session key provided by the TGS)

– and the session key encrypted with the server's secret key provided by the TGS.

Client Server

(3) request service

Page 69: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

69

Application Service

• Server decrypts and checks ticket and authenticator, address and timestamp.

• If the application requires mutual authentication, the server will send the client a message containing the timestamp incremented by one (encrypted with the session key).

• Future messages are also encrypted with the session key, and these depend upon the application.

Page 70: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

70

Possible Quiz

• Remember that even though each quiz is worth only 5 to 10 points, the points do add up to a significant contribution to your overall grade

• If there is a quiz it might cover these issues:– What is social engineering?– What is the name of one unix tool?– What the purpose of suid?

Page 71: 1 Introduction to Computer Security Lecture 12 Dr. Richard Spillman Pacific Lutheran University Summer 2004 PLU Summer 2004.

71

Summary

•Computer Crimes

•History

•unix Security– unix weaknesses– unix attacks– unix advice